Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 5160 invoked from network); 18 Apr 2007 10:39:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Apr 2007 10:39:56 -0000 Received: (qmail 86913 invoked by uid 500); 18 Apr 2007 10:40:01 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 86889 invoked by uid 500); 18 Apr 2007 10:40:01 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 86880 invoked by uid 99); 18 Apr 2007 10:40:01 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Apr 2007 03:40:01 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=FROM_NO_LOWER X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [194.8.61.2] (HELO mailslot1.tirol.gv.at) (194.8.61.2) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Apr 2007 03:39:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C781A5.D8C5F031" x-cr-puzzleid: {85409325-A918-4970-87B1-BE1C4399EB12} x-cr-hashedpuzzle: Cj8= AQDU C1IB DIYK EDEe EPoA E7EZ E87r E+b/ FwEs H/4i Japs Jkdy KCuu KFJY L1To;1;dQBzAGUAcgBzAEAAagBhAGMAawByAGEAYgBiAGkAdAAuAGEAcABhAGMAaABlAC4AbwByAGcA;Sosha1_v1;7;{85409325-A918-4970-87B1-BE1C4399EB12};YwAuAGsAbwBlAGwAbABAAHQAaQByAG8AbAAuAGcAdgAuAGEAdAA=;Wed, 18 Apr 2007 10:39:20 GMT;QQBXADoAIABDAGEAYwBoAGkAbgBnACAAcAByAG8AYgBsAGUAbQAgAHcAaQB0AGgAIABzAGgAYQByAGUAZAAgAGQAZQBwAGwAbwB5AG0AZQBuAHQA Content-class: urn:content-classes:message Subject: AW: Caching problem with shared deployment Date: Wed, 18 Apr 2007 12:39:20 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Caching problem with shared deployment Thread-Index: AceBkRTSrzl66nc5TSKyRjdnCQYETwACWfdAAALEu1A= References: From: =?iso-8859-1?Q?K=D6LL_Claus?= To: X-OriginalArrivalTime: 18 Apr 2007 10:39:31.0213 (UTC) FILETIME=[D8E9B3D0:01C781A5] X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01C781A5.D8C5F031 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=FCngliche Nachricht----- Von: Hatherly, Adam (GE Money) [mailto:Adam.Hatherly@ge.com]=20 Gesendet: Mittwoch, 18. April 2007 12:18 An: users@jackrabbit.apache.org 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: = SimpleCredentials = javax.jcr.SimpleCredentials 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: NoTransaction rather than=20 XATransaction 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: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com]On Behalf Of Dominique Pfister Sent: 18 April 2007 09:10 To: users@jackrabbit.apache.org 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) 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:david.nuescheler@gmail.com] > Sent: 16 April 2007 15:31 > To: users@jackrabbit.apache.org > 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) 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: 'users@jackrabbit.apache.org' > > 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:marcel.reutegger@gmx.net] > > Sent: 16 April 2007 13:19 > > To: users@jackrabbit.apache.org > > 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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > will work. > > > > regards > > marcel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 =3D new InitialContext(); > > > _repository =3D (Repository) = ctx.lookup("java:comp/env/jcr/repository"); > > > SimpleCredentials cred =3D new = SimpleCredentials("user","password".toCharArray()); > > > Session session =3D _repository.login(cred, null); > > > Workspace workspace =3D 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:david.nuescheler@gmail.com] > > > Sent: 16 April 2007 11:55 > > > To: users@jackrabbit.apache.org > > > 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) = 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/ebd281b64edfb93b= 597753c5e716/%7b%7ddata.0.bin does not denote an existing file > > >> > > >> I am retrieving the node from the repository using: > > >> > > >> Node rootNode =3D session.getRootNode(); > > >> Node node =3D 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. > > >> > > >> > > > > > > ------_=_NextPart_001_01C781A5.D8C5F031 Content-Type: text/xml; name="ra.xml" Content-Transfer-Encoding: base64 Content-Description: ra.xml Content-Disposition: attachment; filename="ra.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCEtLQogICBMaWNlbnNlZCB0 byB0aGUgQXBhY2hlIFNvZnR3YXJlIEZvdW5kYXRpb24gKEFTRikgdW5kZXIgb25lIG9yIG1vcmUK ICAgY29udHJpYnV0b3IgbGljZW5zZSBhZ3JlZW1lbnRzLiAgU2VlIHRoZSBOT1RJQ0UgZmlsZSBk aXN0cmlidXRlZCB3aXRoCiAgIHRoaXMgd29yayBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBy ZWdhcmRpbmcgY29weXJpZ2h0IG93bmVyc2hpcC4KICAgVGhlIEFTRiBsaWNlbnNlcyB0aGlzIGZp bGUgdG8gWW91IHVuZGVyIHRoZSBBcGFjaGUgTGljZW5zZSwgVmVyc2lvbiAyLjAKICAgKHRoZSAi TGljZW5zZSIpOyB5b3UgbWF5IG5vdCB1c2UgdGhpcyBmaWxlIGV4Y2VwdCBpbiBjb21wbGlhbmNl IHdpdGgKICAgdGhlIExpY2Vuc2UuICBZb3UgbWF5IG9idGFpbiBhIGNvcHkgb2YgdGhlIExpY2Vu c2UgYXQKCiAgICAgICBodHRwOi8vd3d3LmFwYWNoZS5vcmcvbGljZW5zZXMvTElDRU5TRS0yLjAK CiAgIFVubGVzcyByZXF1aXJlZCBieSBhcHBsaWNhYmxlIGxhdyBvciBhZ3JlZWQgdG8gaW4gd3Jp dGluZywgc29mdHdhcmUKICAgZGlzdHJpYnV0ZWQgdW5kZXIgdGhlIExpY2Vuc2UgaXMgZGlzdHJp YnV0ZWQgb24gYW4gIkFTIElTIiBCQVNJUywKICAgV0lUSE9VVCBXQVJSQU5USUVTIE9SIENPTkRJ VElPTlMgT0YgQU5ZIEtJTkQsIGVpdGhlciBleHByZXNzIG9yIGltcGxpZWQuCiAgIFNlZSB0aGUg TGljZW5zZSBmb3IgdGhlIHNwZWNpZmljIGxhbmd1YWdlIGdvdmVybmluZyBwZXJtaXNzaW9ucyBh bmQKICAgbGltaXRhdGlvbnMgdW5kZXIgdGhlIExpY2Vuc2UuCiAgLS0+CjwhRE9DVFlQRSBjb25u ZWN0b3IgUFVCTElDCiAgICAnLS8vU3VuIE1pY3Jvc3lzdGVtcywgSW5jLi8vRFREIENvbm5lY3Rv ciAxLjAvL0VOJwogICAgJ2h0dHA6Ly9qYXZhLnN1bi5jb20vZHRkL2Nvbm5lY3Rvcl8xXzAuZHRk Jz4KPGNvbm5lY3Rvcj4KICAgIDxkaXNwbGF5LW5hbWU+SmFja3JhYmJpdCBKQ1IgQWRhcHRlcjwv ZGlzcGxheS1uYW1lPgogICAgPHZlbmRvci1uYW1lPkFwYWNoZS5vcmc8L3ZlbmRvci1uYW1lPgog ICAgPHNwZWMtdmVyc2lvbj4xLjA8L3NwZWMtdmVyc2lvbj4KICAgIDxlaXMtdHlwZT5KQ1IgQWRh cHRlcjwvZWlzLXR5cGU+CiAgICA8dmVyc2lvbj4xLjA8L3ZlcnNpb24+CiAgICAKICAgIDxsaWNl bnNlPgoJPGRlc2NyaXB0aW9uPkFTRjwvZGVzY3JpcHRpb24+Cgk8bGljZW5zZS1yZXF1aXJlZD5m YWxzZTwvbGljZW5zZS1yZXF1aXJlZD4KICAgIDwvbGljZW5zZT4KCiAgICA8cmVzb3VyY2VhZGFw dGVyPgoJPG1hbmFnZWRjb25uZWN0aW9uZmFjdG9yeS1jbGFzcz5vcmcuYXBhY2hlLmphY2tyYWJi aXQuamNhLkpDQU1hbmFnZWRDb25uZWN0aW9uRmFjdG9yeTwvbWFuYWdlZGNvbm5lY3Rpb25mYWN0 b3J5LWNsYXNzPgoJPGNvbm5lY3Rpb25mYWN0b3J5LWludGVyZmFjZT5qYXZheC5qY3IuUmVwb3Np dG9yeTwvY29ubmVjdGlvbmZhY3RvcnktaW50ZXJmYWNlPgoJPGNvbm5lY3Rpb25mYWN0b3J5LWlt cGwtY2xhc3M+b3JnLmFwYWNoZS5qYWNrcmFiYml0LmpjYS5KQ0FSZXBvc2l0b3J5SGFuZGxlPC9j b25uZWN0aW9uZmFjdG9yeS1pbXBsLWNsYXNzPgoJPGNvbm5lY3Rpb24taW50ZXJmYWNlPmphdmF4 Lmpjci5TZXNzaW9uPC9jb25uZWN0aW9uLWludGVyZmFjZT4KCTxjb25uZWN0aW9uLWltcGwtY2xh c3M+b3JnLmFwYWNoZS5qYWNrcmFiYml0LmpjYS5KQ0FTZXNzaW9uSGFuZGxlPC9jb25uZWN0aW9u LWltcGwtY2xhc3M+Cgk8dHJhbnNhY3Rpb24tc3VwcG9ydD5YQVRyYW5zYWN0aW9uPC90cmFuc2Fj dGlvbi1zdXBwb3J0PgoJPGNvbmZpZy1wcm9wZXJ0eT4KCSAgICA8Y29uZmlnLXByb3BlcnR5LW5h bWU+SG9tZURpcjwvY29uZmlnLXByb3BlcnR5LW5hbWU+CgkgICAgPGNvbmZpZy1wcm9wZXJ0eS10 eXBlPmphdmEubGFuZy5TdHJpbmc8L2NvbmZpZy1wcm9wZXJ0eS10eXBlPgoJPC9jb25maWctcHJv cGVydHk+Cgk8Y29uZmlnLXByb3BlcnR5PgoJICAgIDxjb25maWctcHJvcGVydHktbmFtZT5Db25m aWdGaWxlPC9jb25maWctcHJvcGVydHktbmFtZT4KCSAgICA8Y29uZmlnLXByb3BlcnR5LXR5cGU+ amF2YS5sYW5nLlN0cmluZzwvY29uZmlnLXByb3BlcnR5LXR5cGU+Cgk8L2NvbmZpZy1wcm9wZXJ0 eT4KCTxyZWF1dGhlbnRpY2F0aW9uLXN1cHBvcnQ+ZmFsc2U8L3JlYXV0aGVudGljYXRpb24tc3Vw cG9ydD4JCiAgICA8L3Jlc291cmNlYWRhcHRlcj4KPC9jb25uZWN0b3I+CgkgICAK ------_=_NextPart_001_01C781A5.D8C5F031--