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.
> > >>
> > >>
> > >
> >
>
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!DOCTYPE connector PUBLIC
'-//Sun Microsystems, Inc.//DTD Connector 1.0//EN'
'http://java.sun.com/dtd/connector_1_0.dtd'>
<connector>
<display-name>Jackrabbit JCR Adapter</display-name>
<vendor-name>Apache.org</vendor-name>
<spec-version>1.0</spec-version>
<eis-type>JCR Adapter</eis-type>
<version>1.0</version>
<license>
<description>ASF</description>
<license-required>false</license-required>
</license>
<resourceadapter>
<managedconnectionfactory-class>org.apache.jackrabbit.jca.JCAManagedConnectionFactory</managedconnectionfactory-class>
<connectionfactory-interface>javax.jcr.Repository</connectionfactory-interface>
<connectionfactory-impl-class>org.apache.jackrabbit.jca.JCARepositoryHandle</connectionfactory-impl-class>
<connection-interface>javax.jcr.Session</connection-interface>
<connection-impl-class>org.apache.jackrabbit.jca.JCASessionHandle</connection-impl-class>
<transaction-support>XATransaction</transaction-support>
<config-property>
<config-property-name>HomeDir</config-property-name>
<config-property-type>java.lang.String</config-property-type>
</config-property>
<config-property>
<config-property-name>ConfigFile</config-property-name>
<config-property-type>java.lang.String</config-property-type>
</config-property>
<reauthentication-support>false</reauthentication-support>
</resourceadapter>
</connector>
