Dieter: First up you are absolutely not "annoying" with all your visions. Indeed I am quite happy to have such a conversation and feel it it *excellent* to have such discussion with a) the initial migration completed so we can see how the API is used b) someone (you) passionate / interested / caring.
You may wish to try and attend one of the bi-weekly meetings for a more interactive discussion. I will try and respond to some of your ideas "inline" as part of this reply. > My IDE finds 163 usages. Most of them are clearly read attempts. > > What is missing is some hint about the intention (read or write). > Indeed if these are clearly read attempts then it would be good if they used *in()* or checked if the resource is a FILE before attempting a read. We have the *file*() method for when we work with systems like freemarker templates which only understand a java File reference. Any GeoServer code should be possible to refactor to use *in()*. > Currently we have no change, since the API promises to create the file. > > But I think this is misleading. I begin to understand the background of > Resource related to JDBCResource. > > In this case a file is created on demand from a database resource. > > But the relevant part is creating any missing directory structure, I think. > There are several relevant parts, creating the missing directory structure and creating the file avoid lots of code having to make such work. > > > Is there any description about what JDBCResource exactly does? > It should be an implementation of the Resource API backed by JDBC Blobs rather than files. In the case where a file is needed (for example freemarker template) the file contents are "unpacked" from the database blob into a file on disk for use. Indeed in a cluster each geoserver blob would unpack such a file for use. > If a Resource on the database was found, creating the associated file > seems OK. > > If not, does it make sense to create an empty file in advance? > If the file is being created to write to then indeed it should be created. > If the file Is written using out(), is it finally written back to the > database on close()? > Yes. > > > A possible refactoring process might be to introduce a method like > file(boolean create). > I am not sure this is needed. We do have some utility methods for common cases that could be used. I wish to have the minimal number of methods for resource store api implementations to manage. > At first we must define file() -> file(true), to retain the API. > > But we may change all those obvious read attempts to use file(false) in a > first step. > > Later on we can analyze the remaining calls. > > Could we make a summary of how many can be refactored to use *out()*, and make the rest use: - Resources.find(resource) - Resources.find(resource, boolean) Which behave in the manner you are proposing. > > > I observed, that FileSystemResource and ResourceAdaptor have a lot of > duplicate code in common. > > Is this intended? > ResourceAdaptor is intended to be quite independent, used for test cases and so forth. > ResourceAdaptor got some improvements which are not propagated to > FileSystemResource. > > I may have some suggestions to refactor the duplicate code… > Adding some package visible methods to Files class would be an appropriate location. > > > I also try to understand the lock() system. > I am curious what you will find. Another thing: If you are brave, the first thing you will notice is a terrible simulation of the Java file watching system. We were using an older version of Java that did not yet have WatchService when the API was implemented. What is there now was designed to be thrown away and replaced with WatchService when we upgraded to Java 7 :) The style of events is similar. > I read something about previous problems and I get the feeling there is > still a race condition. > > But I have to analyze this a bit deeper…. > > > > And some suggestion: I like to replace the IllegalStateException by > UncheckedIOException (since 1.8). > I think that will be fine; it will not be so confusing for JDBC implementation. -- Jody
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
