Hi,
looking at the date time issues I noticed that Geoserver 1.6.x
has inconsistencies in the way it handles GML2.
The GML2 output format is using the old gt2 xml framework,
whilst parsing of features in WFS-T insert is done using the
new one anyways.
Hmm... shall we do switch to the new parser for GML2 too?
If so, I guess we should better issue a new beta instead of
an RC1, since the GML2 part is the one that will be hit
the most anyways and it's all new and untested.
Oh, this will mean the first GetFeature request will be
quite slow due to the initial GML schema loading... not
much we can do about it, that's how the new XML module
work, it walks and breaths by the xml schema, cannot
do anything without having it fully loaded in memory.
Cheers
Andrea
Andrea Aime wrote:
Hi,
looking at the date time issues I noticed that Geoserver 1.6.x
has inconsistencies in the way it handles GML2.
The GML2 output format is using the old gt2 xml framework,
whilst parsing of features in WFS-T insert is done using the
new one anyways.
Hmm... shall we do switch to the new parser for GML2 too?
If so, I guess we should better issue a new beta instead of
an RC1, since the GML2 part is the one that will be hit
the most anyways and it's all new and untested.
Oh, this will mean the first GetFeature request will be
quite slow due to the initial GML schema loading... not
much we can do about it, that's how the new XML module
work, it walks and breaths by the xml schema, cannot
do anything without having it fully loaded in memory.
Yup... they are very expensive objects to create... I think there is still a jira task to preload them on GeoServer startup to avoid that first request... as first impressions are the most important :).
http://jira.codehaus.org/browse/GEOS-907
The downside is it will make server startup slower...
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,469f6b34251511804284693!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Hi,
looking at the date time issues I noticed that Geoserver 1.6.x
has inconsistencies in the way it handles GML2.
The GML2 output format is using the old gt2 xml framework,
whilst parsing of features in WFS-T insert is done using the
new one anyways.
Hmm... shall we do switch to the new parser for GML2 too?
If so, I guess we should better issue a new beta instead of
an RC1, since the GML2 part is the one that will be hit
the most anyways and it's all new and untested.
Oh, this will mean the first GetFeature request will be
quite slow due to the initial GML schema loading... not
much we can do about it, that's how the new XML module
work, it walks and breaths by the xml schema, cannot
do anything without having it fully loaded in memory.
Yup... they are very expensive objects to create... I think there is still a jira task to preload them on GeoServer startup to avoid that first request... as first impressions are the most important :).
http://jira.codehaus.org/browse/GEOS-907
The downside is it will make server startup slower...
In the past I had a Swing app connecting to a db directly, and using
Hibernate in the middle for O/R mapping. Hibernate takes various
seconds to load a non trivial O/R mapping configuration, and this
was affecting the startup time too much.
What I did was to present a login dialog to the user to fill in,
and load the hibernate config in a background thread. By the time
the user filled in the login form the config was fully loaded on
most computers, and if it wasn't the code was setup to lock
the actual login interaction with the db until the config was
fully loaded.
I think we could do the same in Geoserver. Or we could have a config
allowing to choose between loading the schemas during startup
or at fist request (I prefer the latter for development,
since I don't alwasy need to play with GML or transactions).
Cheers
Andrea