From users-return-2942-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Apr 16 14:31:24 2007 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 61789 invoked from network); 16 Apr 2007 14:31:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Apr 2007 14:31:18 -0000 Received: (qmail 32011 invoked by uid 500); 16 Apr 2007 14:31:23 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 31996 invoked by uid 500); 16 Apr 2007 14:31:23 -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 31987 invoked by uid 99); 16 Apr 2007 14:31:23 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Apr 2007 07:31:23 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of david.nuescheler@gmail.com designates 66.249.92.174 as permitted sender) Received: from [66.249.92.174] (HELO ug-out-1314.google.com) (66.249.92.174) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Apr 2007 07:31:16 -0700 Received: by ug-out-1314.google.com with SMTP id p31so927143ugc for ; Mon, 16 Apr 2007 07:30:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DLP3Om1SFuCiW8JWeeYwyN3Fv2U5Uerk3LqIkNuvBsnmnQ5qogv6Lyiemlx1u1AB4RVavTmES91W94uhHhGOw0eqQVY4cJY5cSTX7BMaRV60ohGI2ZC9LCBmSzW3FdTwcovrKTzCbt4jsw/pC8URD9spDwjfsbYt0TChs7km6E0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q/sdxjnY0BhxXP/OCnfvc5u3yaB9GNGSUJq06JMbWNhR9VBDzp1f0XC6D001RPypGhuKoIG8rxBN857JuWFFt7NU/eNJUG+tbam8gXY/Yq7u8HKeUzIqc2WF78tP4oQypXFqWnFQMgshbIFXG3o3TcYJF46HIrN4bU1XylvUICA= Received: by 10.82.160.2 with SMTP id i2mr1993277bue.1176733855031; Mon, 16 Apr 2007 07:30:55 -0700 (PDT) Received: by 10.82.126.2 with HTTP; Mon, 16 Apr 2007 07:30:54 -0700 (PDT) Message-ID: Date: Mon, 16 Apr 2007 16:30:54 +0200 From: "David Nuescheler" To: users@jackrabbit.apache.org Subject: Re: Caching problem with shared deployment In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Checked: Checked by ClamAV on apache.org 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 = 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: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/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. > >> > >> > > >