jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Re: Accessing data without using HTTP
Date Wed, 03 Aug 2011 16:26:21 GMT
Great, here we go!

I read the warning about RMI aswell but i need definitely to access the
repository from Java in a programatic way, therefore i need to obtain the
running repository object somehow and JNDI (at least for me) did tricky
things (such as effectively registering the repository object in the JNDI
namespace but returning null as i try to access to it). In my case,
performance is still not the point, but if it comes to performance i think
that the most convinient will be to use the WebDav access, for which there
is no warning, isn't it?. By now i need to have a basic repository running,
that is why RMI is enough for me (with some limitations: for example i did
not achieve to instantiate a UserManagerImpl object to deal with user
accounts (and queries are not supported neither i heard).

Let's go then. About the distribution of the system you mentioned: RMI
objects are available JVM-wide (as far as i know, you should confirm), here
you are some code snippets to get your running instance of the Repository
object:

*STANDALONE VERSION*

Fireup the repository:

java -jar jackrabbit-standalone-2.2.7.jar --conf /path/to/repository.xml
--repo /path/to/repositoryrootfolder

Obtain the repository object instance in your Java program:
...
Repository repository = JcrUtils.getRepository("http://localhost:8080/rmi");

Session session = repository.login(new SimpleCredentials("user",
"".toCharArray()));

*// if no exception && no null => running-repository object was retrieved
successfully***

System.out.println("Ready to operate the repository: " + repository);
...

*WAR VERSION*

bootstrap.properties file:

repository.name=XXXXX

# RMI Settings
rmi.enabled=true
# I guess that 0 means default port (that is 1099)
rmi.port=0
rmi.host=localhost

Obtain the repository object instance in yoir Java program:

Repository repository =
JcrUtils.getRepository("rmi://localhost:1099/XXXXX");
Session session = repository.login(new SimpleCredentials("user",
"".toCharArray()));
*// if no exception && no null => running-repository object was retrieved
successfully***
System.out.println("Ready to operate the repository: " + repository);
...

That is all, you should be able now to access the repository from a simple
Java program, but remember that not all the operations are supported by RMI
(nor WebDav).

Since you mentioned some design issues aswell i paste here some response i
got about similar issues (from Edouard Hue, in this list, don't know why it
was not published there by the way), just in case:

*The standalone version has the same capabilities as the WAR : both expose
HTTP (DAV) and RMI interfaces. It's a mode 3 deployment model, see
http://jackrabbit.apache.org/deployment-models.html. *
*You won't need a Servlet context to use these. Please also have a look at
this page : http://wiki.apache.org/jackrabbit/RemoteAccess*
*
*
*RMI and DAV remote interfaces don't implement 100% of the JCR API. Some
operations (such as querying) can only be achieved locally. The only
solution I know for this case is to use deployment model 2 and expose the
Repository through JNDI (
http://jackrabbit.apache.org/shared-j2ee-resource-howto.html).*

Hope that helps, greetings!






2011/8/3 Matthieu Legras <matthieu.legras@spotuse.com>

> Hi Francisco,
>
> That's exactly what I want to do, indeed!
>
> I'd also like to know if your solution implies some limitations, for
> example in case I want to have the java application and the JR Repo on
> different servers (in the future)? I found a notice saying "Warning: The
> current JCR-RMI library is designed for simplicity, not performance. You
> will probably experience major performance issues if you try running any
> non-trivial applications on top of JCR-RMI." on this page:
> http://jackrabbit.apache.org/repository-server-howto.html , which seems
> pretty scary to me (since splitting my java app and the JR repo to different
> servers would occur in case my application gets a considerable amount of
> users). Is the solution you develop concerned by this notice?
>
> Thanks for your help!
>
> Matthieu
>
> On Wed, Aug 3, 2011 at 3:57 PM, Francisco Carriedo Scher <
> fcarriedos@gmail.com> wrote:
>
>> Hi there Matthieu,
>>
>> during last week i have been developing a similiar solution, but i started
>> with the Java side of the system (use a repository through Java classes i
>> mean), so i think that perhaps i can result useful. For the sake of
>> simplicity, what you want to develope is the left part of this "graph",
>> isn't it?:
>>
>> Java applications                                                   HTTP
>> clients
>> accessing concurrently ====> JR Repo <====    GETTING [and
>> to the repository
>> PUTTING] resources
>>
>> If the answer is no i did not understand you, sorry... Otherwise, just
>> answer this email and i will try to tell you useful things from the last
>> week.
>>
>> Greetings!
>>
>>
>>
>>
>> 2011/8/3 Matthieu Legras <matthieu.legras@spotuse.com>
>>
>>> Hi,
>>>
>>> I'm currently implementing a calendar system using the CalDAV part of
>>> jackrabbit. I have to link it with an application, running on the same
>>> server, which will massively interact with the CalDAV data.
>>>
>>> Therefore, i'm looking for a way to add, suppress and synchronize data,
>>> without using an http connexion between jackrabbit and the application.
>>>
>>> Any help on this would be highly appreciated!
>>>
>>> Cheers,
>>>
>>> Matthieu
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message