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. >> >> >
