[Geoserver-devel] GSIP 52 - Catalog / Config DAO Refactor

Hi all,

Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.

http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Quick question:

This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?

I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1

Cheers,

Jody

On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:

Hi all,

Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.

http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi Jody,

On Thu, Oct 14, 2010 at 5:31 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Quick question:

This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?

Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.

I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1

We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.

Cheers,

Jody

On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:

Hi all,

Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.

http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb_______________________________________________
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.

Thanks for the extra detail; I assume you mean “GeoserverDAO” and not “GeosrverDAO”?
No you have a link that is consistent … why the odd speling?
Oh wait the link goes to a GeoServerDOA class (ha ha you are driving me nuts).

So if I read the code right - the GeoServerDOA has:

  • setGlobal( GeoServerInfo ); // save the global configuration - so is this used when the object is created by the loading code?
  • save( GeoServerInfo ); // save after modification - used from the ui to save I guess
  • getGlobal(); // the global GeoServer configuration

So yeah that is a clear hibernate style data access object api; looks good. Internally I imagine it unpacks the GeoServerInfo and does what is needed.

Is there anyway for you github links to highlight what you have changed? I was trying to see where the origional was modified to use the DOA.

Still these are clear; thanks for taking up this ball and moving it forward.

Jody

On 15/10/2010, at 10:39 AM, Justin Deoliveira wrote:

Hi Jody,

On Thu, Oct 14, 2010 at 5:31 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Quick question:

This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?

Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.

I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1

We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.

Cheers,

Jody

On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:

Hi all,

Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.

http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb_______________________________________________
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.

On Thu, Oct 14, 2010 at 10:17 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks for the extra detail; I assume you mean “GeoserverDAO” and not “GeosrverDAO”?
No you have a link that is consistent … why the odd speling?
Oh wait the link goes to a GeoServerDOA class (ha ha you are driving me nuts).

So if I read the code right - the GeoServerDOA has:

  • setGlobal( GeoServerInfo ); // save the global configuration - so is this used when the object is created by the loading code?
  • save( GeoServerInfo ); // save after modification - used from the ui to save I guess
  • getGlobal(); // the global GeoServer configuration

setGlobal() is more used on startup and not really meant to be called by client code. But it could be.

So yeah that is a clear hibernate style data access object api; looks good. Internally I imagine it unpacks the GeoServerInfo and does what is needed.

Is there anyway for you github links to highlight what you have changed? I was trying to see where the origional was modified to use the DOA.

You can look at the github commits which show the diffs but there are alot of them. But the entire patch is available on the jira issue that is linked from the proposal.

http://jira.codehaus.org/secure/attachment/51460/GEOS-3806.patch

Still these are clear; thanks for taking up this ball and moving it forward.

Jody

On 15/10/2010, at 10:39 AM, Justin Deoliveira wrote:

Hi Jody,

On Thu, Oct 14, 2010 at 5:31 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Quick question:

This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?

Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.

I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1

We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.

Cheers,

Jody

On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:

Hi all,

Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.

http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb_______________________________________________
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
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

You can also get a diff between two branches on master by using the branch list link on the main page for a project. For Justin’s geoserver mirror, this goes to http://github.com/jdeolive/geoserver/branches

You can also diff between specific revisions, but you have to hand-edit the diff URL for that (replace the name of the from or to branch with the SHA1 sum). You could use the network graph to find the checksum for the revision where wicket14 branched off, producing this permalink to the list of changesets:
http://github.com/jdeolive/geoserver/compare/3f4d57f4885639cb3d43bad23d5351953f3e0a01…wicket_14


David Winslow
OpenGeo - http://opengeo.org/

On Fri, Oct 15, 2010 at 9:33 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Thu, Oct 14, 2010 at 10:17 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks for the extra detail; I assume you mean “GeoserverDAO” and not “GeosrverDAO”?
No you have a link that is consistent … why the odd speling?
Oh wait the link goes to a GeoServerDOA class (ha ha you are driving me nuts).

So if I read the code right - the GeoServerDOA has:

  • setGlobal( GeoServerInfo ); // save the global configuration - so is this used when the object is created by the loading code?
  • save( GeoServerInfo ); // save after modification - used from the ui to save I guess
  • getGlobal(); // the global GeoServer configuration

setGlobal() is more used on startup and not really meant to be called by client code. But it could be.

So yeah that is a clear hibernate style data access object api; looks good. Internally I imagine it unpacks the GeoServerInfo and does what is needed.

Is there anyway for you github links to highlight what you have changed? I was trying to see where the origional was modified to use the DOA.

You can look at the github commits which show the diffs but there are alot of them. But the entire patch is available on the jira issue that is linked from the proposal.

http://jira.codehaus.org/secure/attachment/51460/GEOS-3806.patch

Still these are clear; thanks for taking up this ball and moving it forward.

Jody

On 15/10/2010, at 10:39 AM, Justin Deoliveira wrote:

Hi Jody,

On Thu, Oct 14, 2010 at 5:31 PM, Jody Garnett <jody.garnett@anonymised.com03…> wrote:

Quick question:

This is just the factoring out of data access objects right? Is the end goal of making a hibernate based catalog available for the community in the works?

Correct, this proposal is just the core refactoring that needs to be done in support of a db backed catalog. And indeed there is a module waiting on it. I will propose adding it after this proposal goes through.

I thought we introduced the new catalog api to have this separation - so the choice of XML or Hibernate could be implemented. So in terms of a technical direction this already had my support; if this refactoring is needed march towards that goal it also gets a +1

We did but the catalog has evolved since then. It hands much more than just data access. Event management, validation, lookup logic, etc… are all done by the catalog. Reimplementing the entire catalog interface woudl result in a lot of duplication between implementations, and undoubtedly lead to a lot of differences between the two. So the idea was to factor out just the minimum of data access and only implement that for the different backend.

Cheers,

Jody

On 14/10/2010, at 11:22 AM, Justin Deoliveira wrote:

Hi all,

Here is the official GSIP for the catalog/config refactor that is needed so support the dbconfig work. Ready for vote.

http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb_______________________________________________
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
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev


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