[Geoserver-devel] Nightly down?

Hi,
looking at http://geo.openplans.org/nightly/trunk/ I see
ext-xxx has been generated in the last few days, but
geoserver-trunk-xxx hasn't. Something is not working as it
should in the deploy script I guess?

Cheers
Andrea

It looks like last night's went through ok. I noticed that svn was down
for a little while, that may have been why last night did not go through.

Andrea Aime wrote:

Hi,
looking at http://geo.openplans.org/nightly/trunk/ I see
ext-xxx has been generated in the last few days, but
geoserver-trunk-xxx hasn't. Something is not working as it
should in the deploy script I guess?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,472d9424176212090977483!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

It looks like last night's went through ok. I noticed that svn was down
for a little while, that may have been why last night did not go through.

Yeah, we miss Nov 2 and 3. Well, waiting for tomorrow's one then :slight_smile:
Cheers
Andrea

Andrea Aime wrote:

Justin Deoliveira ha scritto:

It looks like last night's went through ok. I noticed that svn was down
for a little while, that may have been why last night did not go through.

Yeah, we miss Nov 2 and 3. Well, waiting for tomorrow's one then :slight_smile:
Cheers

I see one for the 3rd. The only one that seems to be missing is the 2nd.
Unless I am missing something?

Andrea

!DSPAM:4007,472dea75261751804284693!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

It looks like last night's went through ok. I noticed that svn was down
for a little while, that may have been why last night did not go through.

Yeah, we miss Nov 2 and 3. Well, waiting for tomorrow's one then :slight_smile:
Cheers

I see one for the 3rd. The only one that seems to be missing is the 2nd.
Unless I am missing something?

There I just see
http://geo.openplans.org/nightly/trunk/geoserver-trunk-110107-bin.zip
http://geo.openplans.org/nightly/trunk/geoserver-trunk-110107-war.zip
for november?

Only the
http://geo.openplans.org/nightly/trunk/ext-110207/
http://geo.openplans.org/nightly/trunk/ext-110307/

have been generated for 2 and 3 november...
http://geo.openplans.org/nightly/1.5.x/ has everything instead.
Cheers
Andrea

I’m having trouble with a WFS filter on Geoserver 1.6-Beta4. The filter is:

ogc:Filter
ogc:PropertyInEqualTo
ogc:PropertyNamevagis:district_code</ogc:PropertyName>
ogc:Literal4</ogc:Literal>
</ogc:PropertyInEqualTo>
</ogc:Filter>

The PostGIS query that is generated is:

SELECT “ogc_fid”, encode(AsBinary(force_2d(“the_geom”), ‘XDR’),‘base64’), “objectid”, “district_code”, “district_name”, “shape_length”, “shape_area” FROM “public”.“vdot_districts” WHERE ‘district_code’ = ‘4’

Unfortunately this is incorrect. The line for ‘district_code’ should be “district_code” (double quotes not single quotes). Is there a work around this? Has anyone else seen this? It was working in 1.5.3.

Thanks in advance.
David Robison

I have a problem with geoserver 1.6-Beta4. When I try to log into the web app to configure geoserver, I enter the username and password (using defaults) and am returned to the front page without error. However, when I click on Configure, I am sent back to the login page. Any thoughts? It was working in 1.5.3.

Thanks, David Robison

Ahh... well thats it. The official place to grab nightlies is on the new
server:

http://traffic.openplans.org/geoserver/

I forgot to disable those cron jobs on the old box. I should probably do
that :).

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

It looks like last night's went through ok. I noticed that svn was down
for a little while, that may have been why last night did not go through.

Yeah, we miss Nov 2 and 3. Well, waiting for tomorrow's one then :slight_smile:
Cheers

I see one for the 3rd. The only one that seems to be missing is the 2nd.
Unless I am missing something?

There I just see
http://geo.openplans.org/nightly/trunk/geoserver-trunk-110107-bin.zip
http://geo.openplans.org/nightly/trunk/geoserver-trunk-110107-war.zip
for november?

Only the
http://geo.openplans.org/nightly/trunk/ext-110207/
http://geo.openplans.org/nightly/trunk/ext-110307/

have been generated for 2 and 3 november...
http://geo.openplans.org/nightly/1.5.x/ has everything instead.
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,472df37b273101439371379!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Strange... I heve never seen this one before... I do notice that your
request is not quite right. "PropertyInEqualTo" should be
"PropertyIsEqualTo".Is that just how you wrote it in the email, or is
that how it is actually specified in your request? When I tried it as
written it actually gave me a strange behavior and the error was not
obvious.

If that is not the proble, what is the type of "district_code" in the
database?

-Justin

David Robison wrote:

I'm having trouble with a WFS filter on Geoserver 1.6-Beta4. The filter is:

<ogc:Filter>
  <ogc:PropertyInEqualTo>
    <ogc:PropertyName>vagis:district_code</ogc:PropertyName>
    <ogc:Literal>4</ogc:Literal>
  </ogc:PropertyInEqualTo>
</ogc:Filter>

The PostGIS query that is generated is:

SELECT "ogc_fid", encode(AsBinary(force_2d("the_geom"),
'XDR'),'base64'), "objectid", "district_code", "district_name",
"shape_length", "shape_area" FROM "public"."vdot_districts" WHERE
'district_code' = '4'

Unfortunately this is incorrect. The line for 'district_code' should be
"district_code" (double quotes not single quotes). Is there a work
around this? Has anyone else seen this? It was working in 1.5.3.

Thanks in advance.
David Robison

!DSPAM:4007,472e58d9133493668746562!

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

!DSPAM:4007,472e58d9133493668746562!

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,472e58d9133493668746562!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Hmmm... strange. Which browser are you using? Have you tried clearing
the cache and see what happens?

David Robison wrote:

I have a problem with geoserver 1.6-Beta4. When I try to log into the
web app to configure geoserver, I enter the username and password (using
defaults) and am returned to the front page without error. However, when
I click on Configure, I am sent back to the login page. Any thoughts? It
was working in 1.5.3.

Thanks, David Robison

!DSPAM:4007,472e5c39140235219720167!

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

!DSPAM:4007,472e5c39140235219720167!

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,472e5c39140235219720167!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Not sure what the problem was but I loaded the latest nightly build and the problem seemed to go away. Thanks again, David


From: Justin Deoliveira [mailto:jdeolive@anonymised.com…]
To: David Robison [mailto:drrobison@anonymised.com]
Cc: Geoserver-devel [mailto:geoserver-devel@lists.sourceforge.net]
Sent: Sun, 04 Nov 2007 21:58:24 -0500
Subject: Re: [Geoserver-devel] PostGIS Filter Problem with 1.6-Beta4

Strange… I heve never seen this one before… I do notice that your
request is not quite right. “PropertyInEqualTo” should be
“PropertyIsEqualTo”.Is that just how you wrote it in the email, or is
that how it is actually specified in your request? When I tried it as
written it actually gave me a strange behavior and the error was not
obvious.

If that is not the proble, what is the type of “district_code” in the
database?

-Justin

David Robison wrote:

I’m having trouble with a WFS filter on Geoserver 1.6-Beta4. The filter is:

ogc:Filter
ogc:PropertyInEqualTo
ogc:PropertyNamevagis:district_code</ogc:PropertyName>
ogc:Literal4</ogc:Literal>
</ogc:PropertyInEqualTo>
</ogc:Filter>

The PostGIS query that is generated is:

SELECT “ogc_fid”, encode(AsBinary(force_2d(“the_geom”),
‘XDR’),‘base64’), “objectid”, “district_code”, “district_name”,
“shape_length”, “shape_area” FROM “public”.“vdot_districts” WHERE
‘district_code’ = ‘4’

Unfortunately this is incorrect. The line for ‘district_code’ should be
“district_code” (double quotes not single quotes). Is there a work
around this? Has anyone else seen this? It was working in 1.5.3.

Thanks in advance.
David Robison

!DSPAM:4007,472e58d9133493668746562!



This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

!DSPAM:4007,472e58d9133493668746562!



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,472e58d9133493668746562!


Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Is there a way for a custom DataStore to detect when the geoserver servle shuts down? Thanks, David

--

David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: drrobison@anonymised.com
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/book_detail.php?id=2579

Hi David,
I guess only in the very latest, not yet stable versions of geoserver there's
a propper mechanism to dispose datastores when geoserver is shut down, as a
dispose() method was added to the geotools DataStore interface just a little
while ago (http://jira.codehaus.org/browse/GEOT-1520).
So yes, if you're working with geoserver 1.6.x it should notify the datastores
to dispose at shutdown.

Gabriel
On Thursday 08 November 2007 04:40:38 pm David R Robison wrote:

Is there a way for a custom DataStore to detect when the geoserver
servle shuts down? Thanks, David

On Thu, November 8, 2007 5:17 pm, Gabriel Roldán wrote:

Hi David,
I guess only in the very latest, not yet stable versions of geoserver
there's a propper mechanism to dispose datastores when geoserver is shut
down, as a dispose() method was added to the geotools DataStore interface
just a little while ago (http://jira.codehaus.org/browse/GEOT-1520). So
yes, if you're working with geoserver 1.6.x it should notify the
datastores to dispose at shutdown.

There is one catch thought. The dispose method will be called by geoserver
every time it is about to throw away a datastore, and that happens every
time you press the "apply" button (all datastore get recreated) as well in
other activities during the geoserver configuration.

In fact the dispose() method is not called at all during shutdown... I
forgot to add it (in fact, for most datastores is not really necessary
since the application is going down, but at least ArcSde needs it). I've
created an issue to act on this:
http://jira.codehaus.org/browse/GEOS-1490

Cheers
Andrea