What fixes did you have to install out of interest? -----Original Message----- From: KÖLL Claus [mailto:[EMAIL PROTECTED] Sent: 18 April 2007 11:39 To: [email protected] Subject: AW: Caching problem with shared deployment
Hi, we are using websphere 5.1 with jackrabbit ...no problems after some fixes :-) This is my ra.xml what i used to install the jca adapter. BR claus -----Ursprüngliche Nachricht----- Von: Hatherly, Adam (GE Money) [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 18. April 2007 12:18 An: [email protected] Betreff: RE: Caching problem with shared deployment Hi, I am using Websphere 5.1 which only supports connectors version 1.0, so I started with the example 1.0 ra.xml from the jackrabbit source distribution. The problem I got when I deployed that was I got the error: [18/04/07 10:09:14:641 BST] 776311ba ConnectionFac E J2CA0104E: Authentication mechanism preference BasicPassword is not supported by the resource adapter for connection factory or datasource Jackrabbit. [18/04/07 10:09:14:829 BST] 776311ba ConnectionFac A J2CA0014I: An exception occurred while building the reference for JNDI deployment of Jackrabbit : java.lang.Exception: RA does not support BasicPassword So, after lots of trial and error I added this section to the ra.xml: <authentication-mechanism> <authentication-mechanism-type>SimpleCredentials</authentication-mechanism-type> <credential-interface>javax.jcr.SimpleCredentials</credential-interface> </authentication-mechanism> Which solved that problem, although I don't know if that just works by accident rather than by design... >From that point on however, I had the transaction problem mentioned below. I then changed the ra.xml to have: <transaction-support>NoTransaction</transaction-support> rather than <transaction-support>XATransaction</transaction-support> And that seems to have solved all my problems. My question is - what is the implications of changing the transaction-support element, and why is it set to XATransaction in the example ra.xml files distributed with Jackrabbit? I'm sure there must be a good reason for it.... Adam. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dominique Pfister Sent: 18 April 2007 09:10 To: [email protected] Subject: Re: Caching problem with shared deployment Hi Adam, IMO, using jackrabbit as a resource adapter in WebSphere is the better approach. Can you tell me, what your ra.xml used in your deployment looks like? I suppose that WebSphere is asking for this "LocalTransaction" without ever actually using it, and therefore returning a "dummy" object may overcome your problem. Kind regards Dominique On 4/17/07, Hatherly, Adam (GE Money) <[EMAIL PROTECTED]> wrote: > Sounds like a good idea - I will have a look at raising one shortly. > > Unfortunately my websphere problems has not gone away, although I think I am > getting closer to a solution. > > I suspect that deploying as a "Resource Environment Provider" was resulting > in multiple versions of Jackrabbir running after all, which is what was > causing the problem. I have managed to get it to deploy as a proper resource > adapter now after a bit of tweaking in the ra.xml, but I am getting the > following error whenever I try to log in to the repository from my web app: > > > [17/04/07 15:32:58:887 BST] 57053d6b LocalTransact E J2CA0077E: An exception > was caught while trying to obtain a javax.resource.cci.LocalTransaction from > a ManagedConnection for resource jcr/local. The exception is: > java.lang.UnsupportedOperationException: Local transaction is not supported > > > I can't find anywhere that I can set the transaction handling to overcome > this problem - any ideas? > > Once I have it all working maybe I could document the process for WebSphere > to help other people who might want to run on this platform? > > Adam. > > > -----Original Message----- > From: David Nuescheler [mailto:[EMAIL PROTECTED] > Sent: 16 April 2007 15:31 > To: [email protected] > Subject: Re: Caching problem with shared deployment > > > Hi Adam, > > thanks for sending the report. > > The workspace template portion of the "repository.xml" is copied into > workspace.xml > of each workspace upon creation of the workspace. So each workspace gets its > own configuration, this allows to independently configure the workspaces. > I think this is why you did not see any changes after modifying the > repository.xml > since your workspace.xml still had the old values and after the deletion of > the > workspace it was recreated from the template. > I think we could put a comment into the repository.xml stating that this > section > is copied into the workspace.xml and where to find them. > > I think a number of people ran into similar issues before. Maybe this would be > worth a JIRA issue, just to clarify. What do you think? > > regards, > david > > On 4/16/07, Hatherly, Adam (GE Money) <[EMAIL PROTECTED]> wrote: > > Apologies - I restarted everything, killed all Websphere processes, deleted > > the repository directory and started again and it appears to be working now. > > If I get any more problems I will let you know - thanks again for all your > > help! > > > > Adam. > > > > -----Original Message----- > > From: Hatherly, Adam (GE Money) > > Sent: 16 April 2007 14:00 > > To: '[email protected]' > > Subject: RE: Caching problem with shared deployment > > > > > > Marcel, > > > > I am still getting the problem. > > Do I need to provide a different workspace name for the two web apps? If > > not then won't they be sharing the same local file system path anyway? > > Currently when I login I specify the workspace name as null. Also, if I use > > a different workspace I guess I will need to specify the correspondence > > somehow - are there any example of this you could point me to? > > > > Apologies if this is a bit of a newbie question - I am still getting up to > > speed with Jackrabbit. > > > > Adam. > > > > > > -----Original Message----- > > From: Marcel Reutegger [mailto:[EMAIL PROTECTED] > > Sent: 16 April 2007 13:19 > > To: [email protected] > > Subject: Re: Caching problem with shared deployment > > > > > > Hi Adam, > > > > your workspaces are configured to use the same local file system. > > > > Hatherly, Adam (GE Money) wrote: > > > Thanks for your speedy response - I am indeed running as a model 2 > > > deployment - my repository config is: > > > > > > <?xml version="1.0" encoding="ISO-8859-1"?> > > > <Repository> > > > <FileSystem > > > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> > > > <param name="path" value="c:/repository/repository"/> > > > </FileSystem> > > > <Security appName="Jackrabbit"> > > > <AccessManager > > > class="org.apache.jackrabbit.core.security.SimpleAccessManager"/> > > > <LoginModule > > > class="org.apache.jackrabbit.core.security.SimpleLoginModule"> > > > <param name="anonymousId" value="anonymous"/> > > > </LoginModule> > > > </Security> > > > <Workspaces rootPath="c:/repository/workspaces" > > > defaultWorkspace="default" /> > > > <Workspace name="${wsp.name}"> > > > <FileSystem > > > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> > > > <param name="path" value="c:/repository"/> > > > > <param name="path" value="${wsp.home}"/> > > > > will work. > > > > regards > > marcel > > > > > </FileSystem> > > > <PersistenceManager > > > class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager"> > > > <param name="url" > > > value="jdbc:derby:${wsp.home}/db;create=true"/> > > > <param name="schemaObjectPrefix" value="${wsp.name}_"/> > > > </PersistenceManager> > > > <SearchIndex > > > class="org.apache.jackrabbit.core.query.lucene.SearchIndex"> > > > <param name="path" value="${wsp.home}/index"/> > > > <param name="useCompoundFile" value="true"/> > > > <param name="minMergeDocs" value="100"/> > > > <param name="volatileIdleTime" value="3"/> > > > <param name="maxMergeDocs" value="100000"/> > > > <param name="mergeFactor" value="10"/> > > > <param name="bufferSize" value="10"/> > > > <param name="cacheSize" value="1000"/> > > > <param name="forceConsistencyCheck" value="false"/> > > > <param name="autoRepair" value="true"/> > > > <param name="analyzer" > > > value="org.apache.lucene.analysis.standard.StandardAnalyzer"/> > > > </SearchIndex> > > > </Workspace> > > > <Versioning rootPath="c:/repository/versions"> > > > <FileSystem > > > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> > > > <param name="path" value="c:/repository/versions"/> > > > </FileSystem> > > > <PersistenceManager > > > class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager"> > > > <param name="url" > > > value="jdbc:derby:${rep.home}/version/db;create=true"/> > > > <param name="schemaObjectPrefix" value="version_"/> > > > </PersistenceManager> > > > </Versioning> > > > </Repository> > > > > > > And I have set it up as a "Resource Environment Provider" in Websphere > > > 5.1, configured in a similar way as mentioned on this post: > > > http://epesh.blog-city.com/jackrabbit_and_glassfish_v2.htm > > > > > > To initialise the repository I use the code: > > > > > > InitialContext ctx = new InitialContext(); > > > _repository = (Repository) ctx.lookup("java:comp/env/jcr/repository"); > > > SimpleCredentials cred = new > > > SimpleCredentials("user","password".toCharArray()); > > > Session session = _repository.login(cred, null); > > > Workspace workspace = session.getWorkspace(); > > > > > > I did look at configuring the repository as a "Resource Adapter" rather > > > than a "Resource Environment Provider" but couldn't get it to work in > > > Websphere. > > > > > > Adam. > > > > > > > > > -----Original Message----- > > > From: David Nuescheler [mailto:[EMAIL PROTECTED] > > > Sent: 16 April 2007 11:55 > > > To: [email protected] > > > Subject: Re: Caching problem with shared deployment > > > > > > > > > hi adam, > > > > > > it sounds like you might be running two jackrabbit instances against the > > > same backing store, which is something that jackrabbit is not designed to > > > do. > > > i would recommend to connect from branding editor application through rmi > > > to the "web site"-app or run the repository as a resource in websphere. > > > http://jackrabbit.apache.org/doc/deploy.html > > > > > > if you already are running model (2) or model(3) then i think we would > > > have to look at your repository.xml file(s) and also see how you create > > > the > > > repository itself. maybe you could attach the code that you use to get a > > > hold > > > of the repository object? > > > > > > since lucene is not used for a getNode(key) call, i think it is unlikely > > > to > > > have something to do with lucene. > > > > > > regards, > > > david > > > > > > On 4/16/07, Hatherly, Adam (GE Money) <[EMAIL PROTECTED]> wrote: > > >> Hi - I have a small problem you may be able to help me with. > > >> > > >> I am using Jackrabbit to apply "branding" to a web page dynamically, and > > >> to that end I have deployed two separate web apps to a server - one > > >> which is the actual web site, and a second which is the "branding" > > >> editor that allows me to update image elements in the jackrabbit > > >> repository to alter branding on the page. > > >> > > >> My problem occurs if I delete an element and then recreate it using the > > >> same path. When I do that, the change is reflected correctly within the > > >> "editor" web app, but when the normal web app tries to retrieve the > > >> element I get this error: > > >> > > >> /89/25/ebd281b64edfb93b597753c5e716/%7b%7ddata.0.bin: the specified > > >> resource does not exist: > > >> /home/wasadmin/repository/workspaces/default/blobs/89/25/ebd281b64edfb93b597753c5e716/%7b%7ddata.0.bin > > >> does not denote an existing file > > >> > > >> I am retrieving the node from the repository using: > > >> > > >> Node rootNode = session.getRootNode(); > > >> Node node = rootNode.getNode(key); > > >> > > >> Where key is the path of the node I want. > > >> > > >> I can only assume it is related to some in-memory indexing/caching > > >> within lucene, as a server restart fixes the problem. Do you know of any > > >> way I can overcome the problem so I don't need a restart every time I > > >> change or delete/recreate a node? > > >> > > >> Thanks, > > >> Adam. > > >> > > >> > > > > > >
