$GLASSFISH/domains/$DOMAINNAME/lib/ext/. The list: commons-collections-3.1.jar, jackrabbit-core-1.1-SNAPSHOT.jar, jcr-1.0.jar, slf4j-jdk14.jar, concurrent-1.3.4.jar, jackrabbit-index-filters-1.0.1.jar, and lucene-1.4.3.jar.jcr/repository".javax.jcr.Repository".org.apache.jackrabbit.core.jndi.BindableRepositoryFactory".configFilePath, pointing to a configuration XML file with an absolute path on the server. I used the example configuration file verbatim.repHomeDir pointing to the absolute filesystem path for the repository. (Note that this might be different depending on the configuration settings. For example, if you use a search engine and a repository that only use a database, you might not use the filesystem at all.jcr/repository and use JCR to manage content in your application server.
Does this work for SUN Java System Application Server 8.x
I followed the same procedure , restarted my appserver but I am not able to
see the repository registered with the following directories under
repHomeDir :
meta,namespaces,nodetypes
On SJSAS 9,
InitialContext ctx = new InitialContext ();
Repository repo = null;
repo = (Repository) ctx.lookup ("jcr/repository");
Credentials cred = new SimpleCredentials ("user",new char[]{'p','w','d'});
Session s = repo.login (cred);
Node rn = s.getRootNode ();
log.info (">> " + rn);
s.logout ();
ctx.close ();
at sun.nio.ch.FileChannelImpl $SharedFileLockTable.checkList(FileChannelImpl.java:1173)
at sun.nio.ch.FileChannelImpl$SharedF ileLockTable.add(FileChannelImpl.java:1075)
This installation appears to be a great deal more than trivial. As long as
users have to name their own unique types and classes before defining new
properties, this is never going to get out to the mainstream of its
intended users.
I have the same locking-problems as vincent has... does anybody have a
solution?