Hi Gabriel, The intent of making ServiceInfoImpl concrete was to allow services to plug-in into the catalog and create configuration without the need to subclass. I was mostly thinking of the hibernate case in which a new subclass means a new table in the database. So the use case was to be able to add a new service without changing the underlying database.
The id thing is something that we need to make a decision on actually. The way I designed the api (and this may not be explicit enough) is that id is actually more of an "internal" identifier, rather than used by the rest of the application. Name is more used for the latter. So in the hibernate case, the id is indeed assigned by hibernate and will be some numeric value. In the in memory catalog it just matches the name. So... for that reason none of the CatalogFactory methods take an id, since those methods are more intended for client code. And it is assumed that the catalog implementation will worry about setting id's internally. Thoughts? Gabriel Roldán wrote: > Hi Justin, > > I'm looking for some clarification on the intended usage of ServiceInfo. > My confusion comes from the fact that the interface states its an abstract > base for service information, but the implementation is concrete. > More over, on test cases ServiceInfoImpl is used directly, and code shall > cast > to ServiceInfoImpl in order to set the id, cause the interface has no setId, > nor the GeoServerFactory.createService() allows to pass the id as an > argument. > > So, what do you think would be saner? Add an id argument to createService or > making ServiceInfoImpl abstract? > > Cheers, > > Gabriel > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
