On 6/30/05, Florian Ried <[EMAIL PROTECTED]> wrote: > Hi Edgar, > > > hi Florian > > > > Florian Ried wrote: > > > >> I'm trying to implement a JSR-170 Content Repository as an EJB > >> Application. This is a similar approach as described in JackRabbit > >> Deployment Model 3 (Repository Server with RMI). > > > > IMO it's not a similar approach. > > If I understand you correctly you want to *implement* a jcr compliant > > repository. The JCR-RMI contribution is not a full implementation, it > > consists of two parts, a server that wraps an already implemented jcr > > repository (e.g. Jackrabbit), and a client that lets you access the > > remote server transparently. > > Yes, that's right. I want to implement a jcr compliant repository > (server). I know, that the JCR-RMI package is for making remote calls to > a given jackrabbit repository. Am I right, that JCR-RMI can be used with > any jcr compliant repository? > > > > >> All methods in the (Remote-) interface RepositoryImpl have to throw > >> RemoteExceptions (see J2EE Spec) but the interface > >> javax.jcr.Repository doesn't define them. > > > > As you noted while compiling the remote interfaces of your EJBs, > > remote calls throw RemoteExceptions. jcr-rmi tackles this problem with > > a design that makes intensive use of the adapter pattern. It hides the > > RemoteExceptions and it makes the remote objects available locally > > through the jcr API. see > > http://svn.apache.org/viewcvs.cgi/incubator/jackrabbit/trunk/contrib/jcr-rmi/src/java/org/apache/jackrabbit/rmi/client/ClientItem.java?view=markup > > > > > > > Are there any solutions for this problem? > > If you want to implement a jcr compliant repository from scratch it > > will be hard work and you'll find many more problems in the path. I > > guess you should ask the Day team, they already walked that path and > > did a great job. > > If all you want is to access a remote jcr repository you might want to > > try jcr-rmi. > > > The adapter pattern seems also to be the right one for me. If I want to > call my EJB Repository implementation, I would have to write a Client > Adapter for these calls and then the remote interface shouldn't > implement the JCR Interfaces. I agree with you, this can be a hard job. > > >> > >> Why is the scenario of building a JCR-Server on top of a EJB > >> Container not considered by the specification? Is the approach of > >> building a JCR by using an EJB Container the right way? > > > > IMHO it's not. > > > >> Is it perhaps possible to use jackrabbit within an EJB-Container > >> (with custom DB-Mapping)? > > > > yes, you can use it in an ejb container. No matter the container I > > guess it shouldn't be so different to the example in the site. Just > > find out how to declare a jndi resource in your container and you'll > > be able to access the jcr repo either from your ejbs or from your > > jsp/servlets. > > > > The db topic was discussed quite a few times in the list, you'll find > > many threads in the archive > > (http://dir.gmane.org/gmane.comp.apache.jackrabbit.devel). You can > > also take a look to the wiki > > (http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ), it has some > > info about how the persistent storage is handled in jackrabbit and > > which are the current options. > > > My aim is to build a JCR compliant repository (level 1) on top of a > given database. The structure of the database is already given and > cannot be changed. The repository should be accessable by remote calls > (repository server). > > Can I use Jackrabbit an customize it to suite my requirements (remote > access, given db structure)? Can the repository persistance manager > adapt to almost every db structure (as it isn't a really SPI!)?
as edgar already pointed, have a look at http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ. <quote> Though it might be feasible to write a custom persistence manager to represent existing legacy data in a level-1 (read-only) repository, I don't think the same is possible for a level-2 repository and i certainly would not recommend it. </quote> it is possible to write a *level-1* PersistenceManager that is based on a legacy schema although jackrabbit has not been designed to cover this use case. it is certainly easier and less work than implementing the entire jcr api yourself. cheers stefan > > Is it perhaps better to implement the repsitory itself on top of my > given database and to use JCR-RMI to drill it to a repository server? > > -Flo > > > > > >
