Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 193.19.192.5 is neither permitted nor
 denied by domain of the.mindstorm.mailinglist@gmail.com)
Message-ID: <43931282.3050707@gmail.com>
Date: Sun, 04 Dec 2005 18:00:02 +0200
From: Alexandru Popescu <the.mindstorm.mailinglist@gmail.com>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Deployment Model 2 questions
References: <43922DF6.7000801@gmail.com> <43930118.9060600@gmail.com>
In-Reply-To: <43930118.9060600@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

#: Edgar Poce changed the world a bit at a time by saying on  12/4/2005 4:45 PM :#
> Hi alexandru,
> 
> Alexandru Popescu wrote:
>> [quote]
>>  Place the Jackrabbit jar file and all the dependencies (including the 
>> JCR API jar file) under [Tomcat folder]/common/lib.
>> [/quote]
>> 
>> Now my question is: is this really necessary? I am thinking that the 
>> only jar file needed in the common/lib is the jcr jar.
>> 
> 
> AFAIK, in order to run a shared jackrabbit instance all the classes must 
> be loaded by the same classloader. In Tomcat in can be achieved by 
> placing all the needed jars at the server level.
> 
>> Considering 2 applications accessing the shared JCR, only the first one 
>> requesting from JNDI the repository will really need to provide the 
>> jackrabbit classes. 

> I'm not sure, I haven't tested it but I guess you would get a 
> ClassNotFoundException if you try this configuration. 

In fact it is working :-). I have in the common/lib only the jcr jar, and both applications have 
their version of libraries.

AFAIK if you
> define a shared resource the shared jars must be placed under 
> ${TOMCAT_HOME}/common/lib or any common path, see 
> ${TOMCAT_HOME}/conf/catalina.properties#common.loader. The idea behind a 
> shared resource is that no webapp need to know anything about the 
> concrete implementation. Moreover in the scenario you are describing the 
> correct behavior of your webapps would depend in the order in which the 
> web applications are accessed, which doesn't seem to be a good option.

As I presented initially the idea, yes this was true (the order might have been important). But 
having both applications have their own jackrabbit (and related jars) removes this problem.

I am trying to do this deployment scenario because I don't want to expose to all applications 
deployed in that Tomcat instance the jakarata-commons, log4j and some of the other jackrabbit 
dependencies. I wouldn't have a problem to have in common/lib jackrabbit, jcr and berkleydb for 
example, but having all the others dependencies make me feel unconfortable.

thanks for helping Edgar. Is anybody else have tried this or have been passing through this process?

./alex
--
.w( the_mindstorm )p.

> 
> br,
> edgar
> 
> ps, it's pretty much the same with other embedded resources.
> e.g.
> http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0508bader/ 
>   (The enterprise scenario)
> http://db.apache.org/derby/integrate/DerbyTomcat5512JPetStor.html
> 

I will check the articles. Thanks for pointing.

>> thanks a lot in advance,
>> 
>> ./alex
>> -- 
>> .w( the_mindstorm )p.
>> 
>> 
>> 
>> 
>> 
>> [1] 
>> http://incubator.apache.org/jackrabbit/doc/arch/deploy/howto-model2.html
>> 
> 
> 
> 
> 
> !DSPAM:4393013828894855527208!
> 
>