Hi,
I've just attached a patch to http://jira.codehaus.org/browse/GEOS-3622
that adds back a button to reload the catalog for everybody to use.
Screenshot attached.
As you can see there are now two buttons, the "resource cache" one that
clears the resource cache (cached datastores, feature types, readers)
and another that does it all and reloads the configuration and the
catalog.
I think I'm happy enough with this patch, but was wondering if the two
buttons shouldn't be in a more prominent place (like, below the
services in the home page or somewhere at the top of the page or
below the side menu)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
(attachments)
+1 for being more prominent.
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
On Fri, Apr 9, 2010 at 4:05 PM, Andrea Aime <aaime@anonymised.com> wrote:
Hi,
I've just attached a patch to http://jira.codehaus.org/browse/GEOS-3622
that adds back a button to reload the catalog for everybody to use.
Screenshot attached.
As you can see there are now two buttons, the "resource cache" one that
clears the resource cache (cached datastores, feature types, readers)
and another that does it all and reloads the configuration and the
catalog.
I think I'm happy enough with this patch, but was wondering if the two
buttons shouldn't be in a more prominent place (like, below the
services in the home page or somewhere at the top of the page or
below the side menu)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I think the patch is somewhat mixed in with the one for GEOS-3876?
As for making the button more prominent I would tend to think it is not
too crucial as people who manually modify configuration files and change
underlying database structures are in the minority. I could be wrong
though. Definitely not against it though? Where were you thinking it
would go?
Also how does this play with the hibernate catalog? Will the button be
totally disabled? Will there be an equivalent reload functionality for
people that want to change the underlying database on the fly?
-Justin
On 4/9/10 8:05 AM, Andrea Aime wrote:
Hi,
I've just attached a patch to http://jira.codehaus.org/browse/GEOS-3622
that adds back a button to reload the catalog for everybody to use.
Screenshot attached.
As you can see there are now two buttons, the "resource cache" one that
clears the resource cache (cached datastores, feature types, readers)
and another that does it all and reloads the configuration and the
catalog.
I think I'm happy enough with this patch, but was wondering if the two
buttons shouldn't be in a more prominent place (like, below the
services in the home page or somewhere at the top of the page or
below the side menu)
Cheers
Andrea
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I have been looking at the restconfig-java code... I had hoped there would be an easy temporary fix for all the missing parts that would just leave the missing parts unchanged, but the way the code is set up I do not see any easy way to do that. This is because it uses "@Xml..." annotations from the javax.xml.bind.annotation package to translate the xml into java objects, uses mutate methods to change things and then translates back to xml. So the code needs to be fixed to have all xml elements properly translated so that it doesn't wipe them out.
I am wondering if this is a reasonable approach- unless the Rest schema is very stable, this code will have to be carefully updated anytime something new is added to the schema, or it will cause these new elements to be wiped.
I am guessing this is what happend with the current code- it looks like the author wrote it to correspond to a different xml schema, and then the schema changed. Actually now that I know how it is supposed to work, I am reluctant to fix it, because then it becomes dangerous if the Rest schema changes, unless there are checks that will verify that the complete xml element was translated and shut down before any harm is done.
Before I heard of the restconfig-java module, I was working on some PHP that would download the xml into an object, change certain things, leave everything else the same and then upload. I think a similar approach would work in java using the DOM API. Although this is not as slick as using the @Xml annotations, it seems more robust to me.
Comments are appreciated,
Tara
Hi Tara,
First off there was never a schema published for the rest configuration api. The author (Ronak) I believe generated one on his own. There was some discussion on the list about whether to generate a schema or not.
But yes your findings sound reasonable and I like the approach (only changing what you care about and preserving the rest). At the same time I also see the case for a stable schema for developers to write against. Tough call.
There is actually talk currently going on to factor out some of the geoserver internals into a reusable client module. This would give java clients the same object model that we use internally in geoserver. The real benefit would be that all the XML marshaling/unmarshalling that exists in Geoserver today could be reused by the client. This is still a little far off though. But would probably be the most robust way to build a java restconfig client. I like the DOM approach though as you propose. It is nice and simple.
2 cents.
-Justin
On 4/12/10 10:10 AM, Tara Athan wrote:
I have been looking at the restconfig-java code... I had hoped there
would be an easy temporary fix for all the missing parts that would just
leave the missing parts unchanged, but the way the code is set up I do
not see any easy way to do that. This is because it uses "@Xml..."
annotations from the javax.xml.bind.annotation package to translate the
xml into java objects, uses mutate methods to change things and then
translates back to xml. So the code needs to be fixed to have all xml
elements properly translated so that it doesn't wipe them out.
I am wondering if this is a reasonable approach- unless the Rest schema
is very stable, this code will have to be carefully updated anytime
something new is added to the schema, or it will cause these new
elements to be wiped.
I am guessing this is what happend with the current code- it looks like
the author wrote it to correspond to a different xml schema, and then
the schema changed. Actually now that I know how it is supposed to
work, I am reluctant to fix it, because then it becomes dangerous if the
Rest schema changes, unless there are checks that will verify that the
complete xml element was translated and shut down before any harm is done.
Before I heard of the restconfig-java module, I was working on some PHP
that would download the xml into an object, change certain things, leave
everything else the same and then upload. I think a similar approach
would work in java using the DOM API. Although this is not as slick as
using the @Xml annotations, it seems more robust to me.
Comments are appreciated,
Tara
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Actually, it seems the shared-model-object approach would be subject to the same issues described in this thread, if you mismatched versions of the rest client and the rest service. This would make it tough for distributers of tools based on the RESTConfig service. I guess an easy fix would be to add some versioning info (like a 'X-GeoServer-REST-Version: 2.0.1' HTTP header or a '?v=2.0.1' query parameter) to each request and have the service refuse to handle transactions that mismatched in version. This would just make the mismatch less destructive, though.
I think in the end, client implementers will do best by modifying a dom (or a nested map structure if they are working against JSON) and simply preserving unrecognized entities.
--
David Winslow
OpenGeo - http://opengeo.org/
On 04/13/2010 11:25 AM, Justin Deoliveira wrote:
Hi Tara,
First off there was never a schema published for the rest configuration
api. The author (Ronak) I believe generated one on his own. There was
some discussion on the list about whether to generate a schema or not.
But yes your findings sound reasonable and I like the approach (only
changing what you care about and preserving the rest). At the same time
I also see the case for a stable schema for developers to write against.
Tough call.
There is actually talk currently going on to factor out some of the
geoserver internals into a reusable client module. This would give java
clients the same object model that we use internally in geoserver. The
real benefit would be that all the XML marshaling/unmarshalling that
exists in Geoserver today could be reused by the client. This is still a
little far off though. But would probably be the most robust way to
build a java restconfig client. I like the DOM approach though as you
propose. It is nice and simple.
2 cents.
-Justin
On 4/12/10 10:10 AM, Tara Athan wrote:
I have been looking at the restconfig-java code... I had hoped there
would be an easy temporary fix for all the missing parts that would just
leave the missing parts unchanged, but the way the code is set up I do
not see any easy way to do that. This is because it uses "@Xml..."
annotations from the javax.xml.bind.annotation package to translate the
xml into java objects, uses mutate methods to change things and then
translates back to xml. So the code needs to be fixed to have all xml
elements properly translated so that it doesn't wipe them out.
I am wondering if this is a reasonable approach- unless the Rest schema
is very stable, this code will have to be carefully updated anytime
something new is added to the schema, or it will cause these new
elements to be wiped.
I am guessing this is what happend with the current code- it looks like
the author wrote it to correspond to a different xml schema, and then
the schema changed. Actually now that I know how it is supposed to
work, I am reluctant to fix it, because then it becomes dangerous if the
Rest schema changes, unless there are checks that will verify that the
complete xml element was translated and shut down before any harm is done.
Before I heard of the restconfig-java module, I was working on some PHP
that would download the xml into an object, change certain things, leave
everything else the same and then upload. I think a similar approach
would work in java using the DOM API. Although this is not as slick as
using the @Xml annotations, it seems more robust to me.
Comments are appreciated,
Tara
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hmmm... i would say this is a different issue all together. How to handle changes to the core configuration model (and consequently the representations of resources in the rest api) seems a bit different than having a client being able to round trip all information working against a single version.
I do like the idea of having version information in the header and encouraging clients to specify versions of the api they know are supported.
On 4/13/10 9:37 AM, David Winslow wrote:
Actually, it seems the shared-model-object approach would be subject to
the same issues described in this thread, if you mismatched versions of
the rest client and the rest service. This would make it tough for
distributers of tools based on the RESTConfig service. I guess an easy
fix would be to add some versioning info (like a
'X-GeoServer-REST-Version: 2.0.1' HTTP header or a '?v=2.0.1' query
parameter) to each request and have the service refuse to handle
transactions that mismatched in version. This would just make the
mismatch less destructive, though.
I think in the end, client implementers will do best by modifying a dom
(or a nested map structure if they are working against JSON) and simply
preserving unrecognized entities.
--
David Winslow
OpenGeo - http://opengeo.org/
On 04/13/2010 11:25 AM, Justin Deoliveira wrote:
Hi Tara,
First off there was never a schema published for the rest configuration
api. The author (Ronak) I believe generated one on his own. There was
some discussion on the list about whether to generate a schema or not.
But yes your findings sound reasonable and I like the approach (only
changing what you care about and preserving the rest). At the same time
I also see the case for a stable schema for developers to write against.
Tough call.
There is actually talk currently going on to factor out some of the
geoserver internals into a reusable client module. This would give java
clients the same object model that we use internally in geoserver. The
real benefit would be that all the XML marshaling/unmarshalling that
exists in Geoserver today could be reused by the client. This is still a
little far off though. But would probably be the most robust way to
build a java restconfig client. I like the DOM approach though as you
propose. It is nice and simple.
2 cents.
-Justin
On 4/12/10 10:10 AM, Tara Athan wrote:
I have been looking at the restconfig-java code... I had hoped there
would be an easy temporary fix for all the missing parts that would just
leave the missing parts unchanged, but the way the code is set up I do
not see any easy way to do that. This is because it uses "@Xml..."
annotations from the javax.xml.bind.annotation package to translate the
xml into java objects, uses mutate methods to change things and then
translates back to xml. So the code needs to be fixed to have all xml
elements properly translated so that it doesn't wipe them out.
I am wondering if this is a reasonable approach- unless the Rest schema
is very stable, this code will have to be carefully updated anytime
something new is added to the schema, or it will cause these new
elements to be wiped.
I am guessing this is what happend with the current code- it looks like
the author wrote it to correspond to a different xml schema, and then
the schema changed. Actually now that I know how it is supposed to
work, I am reluctant to fix it, because then it becomes dangerous if the
Rest schema changes, unless there are checks that will verify that the
complete xml element was translated and shut down before any harm is done.
Before I heard of the restconfig-java module, I was working on some PHP
that would download the xml into an object, change certain things, leave
everything else the same and then upload. I think a similar approach
would work in java using the DOM API. Although this is not as slick as
using the @Xml annotations, it seems more robust to me.
Comments are appreciated,
Tara
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
OK, I think I’ll go back to my PHP scripts, as the java project has morphed into something way beyond my experience and time available. That should solve my immediate needs and perhaps produce something useful to others as a batch approach to the cURL commands.
Thanks for all your insights, Tara
Justin Deoliveira wrote:
···
--
Tara Athan
Owner, Athan Ecological Reconciliation Services
tara_athan at alt2is.com
707-272-2115 (cell, preferred)
707-485-1198 (office)
249 W. Gobbi St. #A
Ukiah, CA 95482
Java projects can do that 
If you could possibly share your scripts or simply document how to make some of the example calls in php that would be much appreciated. Currently (as you have seen) we only have examples in curl:
http://docs.geoserver.org/stable/en/user/extensions/rest/rest-config-examples.html
Let me know if you are interested.
-Justin
On 4/13/10 10:18 AM, Tara Athan wrote:
OK, I think I'll go back to my PHP scripts, as the java project has
morphed into something way beyond my experience and time available. That
should solve my immediate needs and perhaps produce something useful to
others as a batch approach to the cURL commands.
Thanks for all your insights, Tara
Justin Deoliveira wrote:
Hmmm... i would say this is a different issue all together. How to
handle changes to the core configuration model (and consequently the
representations of resources in the rest api) seems a bit different than
having a client being able to round trip all information working against
a single version.
I do like the idea of having version information in the header and
encouraging clients to specify versions of the api they know are supported.
On 4/13/10 9:37 AM, David Winslow wrote:
Actually, it seems the shared-model-object approach would be subject to
the same issues described in this thread, if you mismatched versions of
the rest client and the rest service. This would make it tough for
distributers of tools based on the RESTConfig service. I guess an easy
fix would be to add some versioning info (like a
'X-GeoServer-REST-Version: 2.0.1' HTTP header or a '?v=2.0.1' query
parameter) to each request and have the service refuse to handle
transactions that mismatched in version. This would just make the
mismatch less destructive, though.
I think in the end, client implementers will do best by modifying a dom
(or a nested map structure if they are working against JSON) and simply
preserving unrecognized entities.
--
David Winslow
OpenGeo -http://opengeo.org/
On 04/13/2010 11:25 AM, Justin Deoliveira wrote:
Hi Tara,
First off there was never a schema published for the rest configuration
api. The author (Ronak) I believe generated one on his own. There was
some discussion on the list about whether to generate a schema or not.
But yes your findings sound reasonable and I like the approach (only
changing what you care about and preserving the rest). At the same time
I also see the case for a stable schema for developers to write against.
Tough call.
There is actually talk currently going on to factor out some of the
geoserver internals into a reusable client module. This would give java
clients the same object model that we use internally in geoserver. The
real benefit would be that all the XML marshaling/unmarshalling that
exists in Geoserver today could be reused by the client. This is still a
little far off though. But would probably be the most robust way to
build a java restconfig client. I like the DOM approach though as you
propose. It is nice and simple.
2 cents.
-Justin
On 4/12/10 10:10 AM, Tara Athan wrote:
I have been looking at the restconfig-java code... I had hoped there
would be an easy temporary fix for all the missing parts that would just
leave the missing parts unchanged, but the way the code is set up I do
not see any easy way to do that. This is because it uses "@Xml..."
annotations from the javax.xml.bind.annotation package to translate the
xml into java objects, uses mutate methods to change things and then
translates back to xml. So the code needs to be fixed to have all xml
elements properly translated so that it doesn't wipe them out.
I am wondering if this is a reasonable approach- unless the Rest schema
is very stable, this code will have to be carefully updated anytime
something new is added to the schema, or it will cause these new
elements to be wiped.
I am guessing this is what happend with the current code- it looks like
the author wrote it to correspond to a different xml schema, and then
the schema changed. Actually now that I know how it is supposed to
work, I am reluctant to fix it, because then it becomes dangerous if the
Rest schema changes, unless there are checks that will verify that the
complete xml element was translated and shut down before any harm is done.
Before I heard of the restconfig-java module, I was working on some PHP
that would download the xml into an object, change certain things, leave
everything else the same and then upload. I think a similar approach
would work in java using the DOM API. Although this is not as slick as
using the @Xml annotations, it seems more robust to me.
Comments are appreciated,
Tara
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Tara Athan
Owner, Athan Ecological Reconciliation Services
tara_athan at alt2is.com
707-272-2115 (cell, preferred)
707-485-1198 (office)
249 W. Gobbi St. #A
Ukiah, CA 95482
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
I think the patch is somewhat mixed in with the one for GEOS-3876?
Sorry, cleaned it up.
As for making the button more prominent I would tend to think it is not too crucial as people who manually modify configuration files and change underlying database structures are in the minority. I could be wrong though. Definitely not against it though? Where were you thinking it would go?
Also how does this play with the hibernate catalog? Will the button be totally disabled? Will there be an equivalent reload functionality for people that want to change the underlying database on the fly?
Right... with the hibernate catalog humm... well, it depends.
The hibernate catalog is likely going to be using an ehcache provider
to avoid re-querying like crazy the database (I think I saw something
like that in the patches that were floating around, but I may be wrong).
So in that case the "reload" button could wipe out the ehcache contents
If there is no caching going we can either have the button disappear
or make it into a no-op.
Hmm... probably better to keep it in the Status page then 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.