You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Florian Ried <Fl...@gmx.de> on 2005/06/29 19:34:40 UTC
Implementing JSR-170 as EJB Application
Hi everyone,
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). My underlying data
storage will be a Database. At the moment I am having a problem
implementing the interfaces (e.g. javax.jcr.Repository), because their
method signature doesn't comply with the restrictions given by the J2EE
Specification. An example:
class RepositoryImplBean implements javax.ejb.SessionBean,
javax.jcr.Repository{
public String getDescriptor(String arg0){
...
}
}
interface RepositoryImpl extends javax.ejb.EJBObject, javax.jcr.Repository {
public String getDescriptor(String arg0) throws RemoteException;
}
All methods in the (Remote-) interface RepositoryImpl have to throw
RemoteExceptions (see J2EE Spec) but the interface javax.jcr.Repository
doesn't define them. Are there any solutions for this problem?
Recompling the javax.jcr.* Interfaces?
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?
Is it perhaps possible to use jackrabbit within an EJB-Container (with
custom DB-Mapping)?
Thanks for your answers.
-Flo
how can i connect a jackrabbit repository to weblogic9.2
Posted by sachin shrivastava <sh...@yahoo.com>.
sir
i want to connect my prebuild jackrabbit repository in weblogic 9.2 for use
in weblogic 9.2 project plz suggest me how can i do it .what is the spi
implementation of jackrabbit repository that is required in weblogic to connect
third party repository to weblogic
any type of help is really appreciating
thanking you
Re: Implementing JSR-170 as EJB Application
Posted by Stefan Guggisberg <st...@gmail.com>.
On 6/30/05, Florian Ried <Fl...@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
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
>
>
>
>
>
>
Re: Implementing JSR-170 as EJB Application
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Florian Ried wrote:
> 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?
Yes, the RMI layer depends only on the JCR API and is thus independent
of the underlying implementation.
> 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).
Have you considered deploying your implementation fully on the client
side and using normal JDBC for remote access. This approach makes it
hard to implement functionality like observation, but seems like a good
fit for a simple level 1 implementation.
BR,
Jukka Zitting
Re: Implementing JSR-170 as EJB Application
Posted by Florian Ried <Fl...@gmx.de>.
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
Re: Implementing JSR-170 as EJB Application
Posted by Edgar Poce <ed...@gmail.com>.
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.
> 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.
> Recompling the javax.jcr.* Interfaces?
it doesn't seem a good idea. What's the point of making a jcr compliant
impl that's not jcr compliant? ;)
>
> 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.
kind regards,
edgar
>
> Thanks for your answers.
>
> -Flo
>