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!)?
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
