Hi, FYI, there is an article about the "Factory Method" design pattern at http://java.dzone.com/news/gof-design-patterns-factory-me
"The Factory Method returns an instance of a class (ConcreteProduct) that is defined through an interface or abstract parent (Product) class." In our case an interface is cleaner, but abstract parent is an option as well (calling methods of abstract classes is slightly faster than methods of interfaces, but really only slightly). Regards, Thomas On Mon, Apr 21, 2008 at 11:04 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > Hi, > > > > there is no technical reason why remoting couldn't be reasonably > > fast > > I agree. Because there is an overhead for each TCP/IP roundtrip, > remote access can never be as fast as when running Jackrabbit in the > same virtual machine, except if requests are very coarse grained. > > > > That's IMHO a minor nit. You can avoid that with: > > JackrabbitRepository repository = RepositoryImpl.create(...); > > The recommended factory method should be declared to return > JackrabbitRepository (or maybe a new interface). However I'm not sure > if the recommended factory method should be RepositoryImpl.create. > It's inconsistent to get a remote repository object using "new > ClientRepositoryFactory().getRepository(String)" but a embedded > repository using "RepositoryImpl.create(RepositoryConfig)". It would > be better to have only one factory for Jackrabbit, and only one way to > get a repository object, for example: > > JackrabbitRepositoryFactory.open(String url) > > This 'service provider' approach is used by the following APIs: > - JDBC (java.sql.DriverManager.getConnection) > - Security (for example java.security.MessageDigest.getInstance) > - Cryptography (javax.crypto.Cipher.getInstance) > - XML > - Sound (for example javax.sound.sampled.AudioSystem.getAudioInputStream) > - Java Naming Services (javax.naming.spi.NamingManager. getInitialContext) > - Java Image I/O (for example javax.imageio.ImageIO.read) > - New IO (java.nio.channels, java.nio.charset) > - Input Methods (java.awt.im) > - ... and various other places > > When using the 'service provider' appraoch, interfaces are used. It is > not required to hardcode any implementation classes. > > > an application that embeds RepositoryImpl ... needs to call shutdown() ... > > > Is it a big problem that when making this call you > > see extra stuff in IDE autocomplete and the javadocs? > > You see those 'forbidden but public' methods whenever you call > anything on RepositoryImpl. Developers shouldn't see any method that > they must not call. It's just one of many problems you get when you > force developers to use RepositoryImpl directly. It's a potential > problem an can be easily avoided by using an interface. > > Regards, > Thomas >
