jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slater <li...@humanesoftware.com>
Subject Re: Model-2 Deployment example and test app [Fixed, with suggestions for updated docs]
Date Tue, 14 Feb 2006 10:38:08 GMT
I've finally got the servlet working (up to the point where it gets  
the repository that was configured in the Context). For whatever  
reason, using WEB-INF/context.xml (as suggested by the Tomcat and  
Jackrabbit docs) didn't work, but $CATALINA_HOME/conf/[enginename]/ 
[hostname]/[webappname].xml did. Also I had the same string in both  
the name attribute and global attribute of my ResourceLink.

 From what I've seen on other mailing lists and web forums, I'm not  
the only one who's had trouble figuring out where to put the Context  
information. I'd suggest the following diffs to the site  
documentation, just to make the alternate context location more  

Index: src/site/xdoc/doc/deploy/howto-model2.xml
--- src/site/xdoc/doc/deploy/howto-model2.xml   (revision 377679)
+++ src/site/xdoc/doc/deploy/howto-model2.xml   (working copy)
@@ -106,8 +106,10 @@
            In Tomcat versions 4.x and 5.0, add the following snippet
            in <code>server.xml</code> under the <code>Context</code>
            of your web application. In Tomcat version 5.5, add the  
-          in your application's <code>context.xml</code> file (or in  
-          <code>server.xml</code> file if you prefer central  
+          in your application's <code>context.xml</code> or
+          <code>$CATALINA_HOME/conf/[enginename]/[hostname]/ 
+          If you prefer central configuration, you can add the  
+          to the Host Context section in the <code>server.xml</code>.
<ResourceLink name="jcr/repository"
Index: src/site/xdoc/doc/deploy/howto-model1.xml
--- src/site/xdoc/doc/deploy/howto-model1.xml   (revision 377679)
+++ src/site/xdoc/doc/deploy/howto-model1.xml   (working copy)
@@ -104,8 +104,10 @@
            In Tomcat 5.5, add the following snippet in your  
-          <code>context.xml</code> file (or in the <code>server.xml</

-          file if you prefer central configuration).
+          <code>WEB-INF/context.xml</code> or
+          <code>$CATALINA_HOME/conf/[enginename]/[hostname]/ 
+          If you prefer central configuration, you can add the  
+          to the Host Context section in the <code>server.xml</code>.
<Resource name="jcr/repository"

I did find one other potential documentation bug in the howto- 
model1.xml page. The text says

         <strong>Limitations:</strong> the application should not be
         redeployed during the same JVM process to avoid creating  
         Jackrabbit instances with the same configuration. In case  
you want
         to redeploy your application be sure to shutdown the repository
         when your application is undeployed. It can be done by calling
         RepositoryImpl.shutdown() (e.g. in the destroy() method of a

I set up a model 1 repository in the same servlet (but with different  
repository settings) and tried to follow these directions. The  
problem that I ran into is that the shutdown() method is not in the  
javax.jcr.Repository interface, and BindableRepository is package  
protected so I can't even cast the object returned by the Context to  
a BindableRepository. Without that, I wasn't able to see how the  
shutdown() method could be called from my servlet's destroy() method.


On Feb 13, 2006, at 7:29 PM, Mark Slater wrote:

> Another update. I added the log4j.properties to tomcat and am now  
> able to watch it initialize the repository; there are no errors  
> during the process. Unfortunately, none of the jackrabbit code  
> seems to be executed when I try to get the BindableRepository from  
> the context. I'm assuming at this point its a Tomcat configuration  
> issue, because I've tried a fair number of configurations (embedded- 
> model-1, shared-model-2, both, defined in global context, defined  
> in local context, defined in server.xml, etc.) and am no closer to  
> a solution. I've posted to the Tomcat's users for help, but if  
> anyone here has a spare cycle to point me in the right direction,  
> I'd really appreciate it.
> In the most recent trial (embedded repository defined in  
> servlet.xml) I'm able to get an Integer value stored in the  
> context, but when I try to get the jackrabbit repository, I get a  
> class not found exception on BindableRepositoryFactory. This is  
> despite having the jackrabbit jar file in both the webapp's WEB-INF/ 
> lib/ and Tomcat's server/lib/.
> Mark
> On Feb 13, 2006, at 8:15 AM, Mark Slater wrote:
>> Nope. There's no errors in any of the log files. I tried moving  
>> Jackrabbit jar files (and dependencies) to server/lib (they had  
>> all been in common/lib) leaving only jcr-1.0.jar in common/lib ...  
>> restarted Tomcat ... no change in results.
>> I know Jackrabbit is being initialized because, over the weekend,  
>> as soon as I'd put all the dependencies into common/lib I stopped  
>> getting exceptions during Tomcat's initialization and the  
>> repository got initialized (the local file system and the database  
>> tables). That's when I started writing the servlet.
>> The only mention of Jackrabbit in the catalina.out file is at the  
>> very start of Tomcat's initialization, I get these lines:
>> log4j:WARN No appenders could be found for logger  
>> (org.apache.jackrabbit.core.fs.local.LocalFileSystem).
>> log4j:WARN Please initialize the log4j system properly.
>> I'd worry about the log4j configuration but the exception doesn't  
>> show any Jackrabbit code in the stack... its mostly tomcat,  
>> catalina, and naming packages, with a few calls to java/javax code  
>> and my doGet() servlet function.
>> Mark
>> On Feb 13, 2006, at 2:04 AM, Jukka Zitting wrote:
>>> Hi,
>>> On 2/13/06, Mark Slater <lists@humanesoftware.com> wrote:
>>>> However, when I run my servlet, I get:
>>>> javax.naming.NamingException: Cannot create resource instance
>>> Do you have some errors showing up in the Tomcat error log? One
>>> possible cause for this problem is that you don't have the  
>>> Jackrabbit
>>> jar files in the correct place. A safe alternative is to just put  
>>> all
>>> the jars in common/lib, but a more correct way would be to put only
>>> the jcr-1.0.jar in the common class loader and the Jackrabbit jar  
>>> file
>>> (and the dependencies) in the server class loader.
>>> BR,
>>> Jukka Zitting
>>> --
>>> Yukatan - http://yukatan.fi/ - info@yukatan.fi
>>> Software craftmanship, JCR consulting, and Java development

View raw message