Hi, Thomas Müller schrieb: > Hi, > >> I would not do relative paths, this becomes very unstable. > > That's true. We could start with absolute path only. More features can > still be added later on if required (ideas: supporting "~" prefix, > supporting system property expansion).
As I said, I am -1 on this. This is not in the scope of the factory, it is the scope of the application using the factory to prepare the absolute URL. > >>> Instead of a new class with a constructor, I would add a static method >> Please not a static method. > > A regular method is fine as well. But _please_ not a constructor. A > constructor would mean the method can't return a different object. And > a constructor (again) means hardcoding a class in the application > instead of using interfaces. -1 for GenericRepository. > >>> We do have an API for shutdown now: RepositoryManager.stop(). >> Is this only for RepositoryImpl ? > > No, it's part of the Jackrabbit API. See JCR-1865 > http://svn.apache.org/viewcvs?view=rev&rev=815339 > > It's quite tricky to get the RepositoryManager instance, but all is > done using interfaces (no need to hardcode concrete classes). Nice, but, sorry, not very elegant and therefore a big -1 from me ;-) If it is easy to get a repository built it *must* be equally easy to get rid of that repository. And this mechanism *must* be in the same context. Having to resort to other objects just to get rid of a repository just is not an option ! Sorry. > >> Or this generically usable with the >> new GenericRepository ? > > I don't think it's possible. And that's good, because > GenericRepository, beeing a class and not an interface, would again > lead to big problems. -1 for GenericRepository (did I say that > already?). I don't care how it is done, really. As long as it is simple: * Get a repository factory * Get the repository from that factory * Get rid of the repository either through the repository itself or through the factory. Regards Felix > > Regards, > Thomas >
