I am on 2.6.x not 2.5.x (so you may need to think when applying the patches to 2.5.x?) I generated the patch with svn diff so it should not be that effected by platform.
I have created a bug report here: - http://jira.codehaus.org/browse/GEOT-2486 I will see if I can apply the changes to 2.5.x for you. Jody On Fri, May 15, 2009 at 4:51 PM, Christian Müller <[email protected]> wrote: > I cannot apply your patches. All 3 files report errors when applying with > patch -p0 < patchfile > I am up to date with 2.5.x repository > No idea, I think you are sitting in front of an M$ box, I am working on a > linux box. Converting with dos2unix does not help either. > Can you try it agein after an "svn up" on 2.5.x or send me the java files. > thanks > > Jody Garnett writes: >> >> Just to follow up - Christian and I sorted out some things over IRC; >> and he is reviewing a patch right now. >> Jody >> On Thu, May 14, 2009 at 10:52 PM, Jody Garnett <[email protected]> >> wrote: >>> >>> Sorry my previous reply fell of the list ... here is a proposal for a >>> "refreshed" Repository interface: >>> public interface Repository { >>> /** >>> * Search for the DataAccess (or DataStore) providing access >>> * to the indicated typeName. >>> * <p> >>> * This lookup method is not namespace aware; and will find the first >>> * possible match. >>> * <p> >>> * @param name Name of the DataStore to retrieve >>> * @return DataStore >>> */ >>> DataAccess<?,?> access( String typeName ); >>> /** >>> * Search for the DataAccess (or DataStore) providing access >>> * to the indicated typeName. >>> * >>> * @param Name The typeName (namespace and name) to search for >>> * @return DataAccess api providing access to the >>> indicatedTypeName (or null if not found) >>> */ >>> DataAccess<?,?> access( Name name ); >>> } >>> A couple changes from yours: >>> - DataAccess is returned rather than DataStore >>> - namespace is part of Name >>> I find this a little weak in that you cannot "browse" the contents of >>> the Registery; however since we do not have a need for that - only >>> look up - I think we are fine. >>> I find it really stange that you are lookin up DataStore here; by the >>> typeName the DataStore produces. A code example would end up being. >>> Name typeName = new NameImpl( namespace, name ); >>> DataStore<?,?> data = (DataStore<?,?>) registery.access( typeName ); >>> FeatureSource<?,?> source = data.getFeatureSource( typeName ); >>> I would find it easier with a single registery.source( typeName ) >>> method; but whatever. I might also suggest a dataStore method to avoid >>> the cast to DataStore. >>> So how about it; if I make this modification can we update your code >>> (and implementation) to make use of it? >>> Jody >>> On Thu, May 14, 2009 at 10:33 PM, Jody Garnett <[email protected]> >>> wrote: >>>>> >>>>> Jody I took a deeper look to Catalog interface and I got dazed and >>>>> confused. >>>> >>>> Not the catalog interface the simple repository interface ... >>>> interface { >>>> Map getDataStores(); >>>> SortedMap getFeatureSources(); >>>> Set getPrefixes(); >>>> boolean lockExists(String lockId) >>>> boolean lockRefresh(String lockId, Transaction) >>>> boolean lockRelease(String lockId, Transaction) >>>> source source(String dataStoreId, String typeName ) >>>> } >>>> And you have: >>>> public interface DataStoreLookup { >>>> public void initialize(Object source); >>>> public DataStore getDataStoreFor(String name); >>>> public DataStore getDataStoreFor(String namespace, String name); >>>> } >>>> So one is working with FeatureSource and the other is working with >>>> DataStore; incidentally how do you look up a datastore for a >>>> namespace/name ? does that not indentify a single feature type? I also >>>> do not know what your initialize( source ) method is for ... >>>>> >>>>> Again I agree on having a central repository interface but a redesign >>>>> is not a matter of adding some methods. >>>> >>>>> Some thoughts >>>>> 1) I am missing the clean concept of namespace handling >>>> >>>> Then we add it; right now the api documents something stupid - a >>>> datastore id since that is what geoserver had when it was written. >>>> Which each have a lookup method that takes two strings - both are >>>> supposed to be a simple front end to the geoserver catalog so they >>>> probably end up acting the same. >>>>> >>>>> 2) It must be possible to write a Repository implementation acting as >>>>> adapter for the geoserver catalog (supporting the workspace concept, >>>>> which I >>>>> think we could handle with 1). The same must be possibile for UDIG. The >>>>> interface implementation must be configurable externally, we need >>>>> something >>>>> like a "RepositoryFactory" >>>> >>>> Ignore uDig for a moment; focus on what geoServer is doing; I can make >>>> udig work later. >>>> I did not follow you their; you probably intend to pass in this >>>> repository as a connection parameter to your pregeneralized datastore? >>>> Something either application can do. >>>>> >>>>> 3) Unlucky naming of methods, "source" as an example. You must look at >>>>> the >>>>> source code to have an idea what this method is doing. Missing methods, >>>>> how >>>>> to get a datastore with his name and namespace ? >>>> >>>> You are focused on name and namespace; that is fine. Source is the >>>> super type of FeatureSource (something gabriel did). I am not sure if >>>> your datastore is generic enough to work on Source (does it assume >>>> simple features or not?). >>>>> >>>>> 4) No idea about the locking methods, I think nobody calls them, and >>>>> btw, I >>>>> would delegate the locking to an >>>>> external locking manager. And why should a repository do locking at all >>>>> ? >>>> >>>> We can remove them; the reason locking had the responsibility was >>>> because it was the only interface that "knows" all the datastores and >>>> thus can perform cross datastore operations (such as locking). >>>>> >>>>> So, I think we would a least need >>>>> RepositoryInterface >>>>> RepositoryFactory >>>> >>>> I think we can skip the factory on this one; we are not creating a >>>> generic Repository; we are being passed in an adapter to the geoserver >>>> catalog. >>>>> >>>>> RepositoryImpl for geotools >>>> >>>> This is pretty simple to write; just store the datastores in a map. >>>>> >>>>> RepositoryImpl for geoserver >>>>> RepositoryImpl for udig ? >>>> >>>> These other two seem okay. >>>>> >>>>> This would be a real improvement but it would block me for weeks. >>>> >>>> I do not want to introduce duplicate api for the same function; would >>>> you like to have a breakout IRC session and fix the repository >>>> interface to match your datastore finder? You do have to explain your >>>> two part namespace / name lookup - looking up a DataStore for me; >>>> right now that makes little sense to me. >>>>> >>>>> As a proposal, I would like to continue with the DataStoreLookup and >>>>> mark it >>>>> depricated as soon we have implemented a cleanrepository concept. >>>>> christian >>>> >>>> I am interested in going the other direction; replacing the Repository >>>> interface methods with what you have in DataSource lookup. Part of the >>>> difficulty here is that your module "introduces" public api - not >>>> simply implementing the DataStoreFactory (which can be dropped into >>>> any app; but instead asks to go out into the app that is hosting it >>>> and look up other datastores). >>>> Jody >>> > > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
