jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Implementing JSR-170 as EJB Application
Date Thu, 30 Jun 2005 09:27:19 GMT
On 6/30/05, Florian Ried <FlorianRied@gmx.de> 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 

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.

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.


> 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

View raw message