The class name null specified for Detector is not a valid Java class name

[kbachl]

Hello,

I'm currently trying  to migrate brix, an wicket based CMS system, from jackrabbit 2 to modeshape. I started by

InputStream configStream = new FileInputStream(cfg);

JcrConfiguration config = new JcrConfiguration().loadFrom(configStream);

JcrEngine engine = config.build();

engine.start();

return engine.getRepository("default");

where configStream comes from an file that only has the content mentioned under http://docs.jboss.org/modeshape/latest/manuals/gettingstarted/html/using_modeshape.html in it.

The file can be viewed here: https://github.com/kbachl/brix-cms/blob/master/brix-demo/src/main/resources/brix/demo/repository-ms.xml

During the repository startup I allways end up having:

java.lang.RuntimeException: Could not create file repository at url: file://tmp/brix-jcr

...

Caused by: java.lang.IllegalArgumentException: The class name null specified for Detector is not a valid Java class name

    at org.modeshape.common.component.ComponentConfig.<init>(ComponentConfig.java:134)

    at org.modeshape.common.component.ComponentConfig.<init>(ComponentConfig.java:102)

    at org.modeshape.graph.mimetype.MimeTypeDetectorConfig.<init>(MimeTypeDetectorConfig.java:41)

    at org.modeshape.repository.ModeShapeEngine$ConfigurationScanner.getMimeTypeDetectors(ModeShapeEngine.java:518)

    at org.modeshape.repository.ModeShapeEngine.<init>(ModeShapeEngine.java:121)

    at org.modeshape.jcr.JcrEngine.<init>(JcrEngine.java:98)

    at org.modeshape.jcr.JcrConfiguration.build(JcrConfiguration.java:487)

    at brix.util.JcrUtils.createFileRepository(JcrUtils.java:120)

As I'm new to modeshape I don't know what I can do to this.

Best,

Kbachl

Ps: the project is located under https://github.com/kbachl/brix-cms with the steps done by me so far at https://github.com/kbachl/brix-cms/commit/2607f973eb9e2e63e05ecba61d3dba3fb9af8a93

[rhauch]

There's really nothing wrong with that configuration. The MIME type detectors section is commented out, meaning the default detector should be set up and configured. We do have an open issue (MODE-1087) in an OSGi-environment, but your error message is not quite the same as in that issue. Perhaps Brix (or Wicket?) is OSGi-based, but using a different OSGi container than Apache Sling (which I think uses a version of Felix)?

Can you explain a bit more about the environment?

Also, have you looked at any of Ale's workarounds described in MODE-1087?

Best regards

[kbachl]

Hello,

Brix isn't using OSGI active, merely its only in the maven xml.pom's so that one can use it with osgi if he likes, see:

<plugin>

    <groupId>org.apache.felix</groupId>

    <artifactId>maven-bundle-plugin</artifactId>

    <version>2.1.0</version>

    <extensions>true</extensions>

    <configuration>

     <instructions>

      <Export-Package>

       brix.plugin.site.page.tile.admin,brix.plugin.site.page.tile,brix.jcr,brix.web.admin,brix.config,brix.auth,brix,brix.web,brix.web.nodepage,brix.registry,brix.jcr.wrapper,brix.plugin.site,brix.web.picker.common,brix.web.reference,brix.web.util,brix.web.tab,brix.web.generic,brix.plugin.site.page.global,brix.plugin.site.picker.reference,brix.plugin.site.picker.node,brix.web.tree,brix.exception

      </Export-Package>

         <Import-Package>

             org.osgi*, brix.jcr.api, brix.jcr.*, com.inmethod.grid.*, javax.jcr.*, javax.servlet, javax.servlet.http,

             javax.swing.event, javax.swing.tree, org.apache.jackrabbit.api, org.apache.jackrabbit.spi.*,

             org.apache.jackrabbit.core, org.apache.jackrabbit.server.io, org.apache.wicket.*, org.htmlparser,

             org.htmlparser.lexer, org.htmlparser.util, org.slf4j, brix.workspace.rmi, org.apache.jackrabbit.commons.cnd

         </Import-Package>

         <Bundle-SymbolicName>${project.groupId}.${project.artifactId};singleton:=true</Bundle-SymbolicName>

      <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment>

     </instructions>

    </configuration>

   </plugin>

Wicket itself has no OSGI in it.

My environment is OS X 10.6.latest with JDK 1.6.0_24 and Glassfish 3.0.1 (that uses felix intern) - so far nothing special IMHO. I haven't yet digged any further as I was unsure with regards to the config file.

In case you are curious, too, you can simply get my git-repo as this is the full brix cms including the brix-demo;

Best and thank you for help

[rhauch]

Actually, I noticed in the parent POM that you're compiling with 1.5. I'm not sure whether that's the cause of the problem, but at the moment ModeShape does require 1.6. You may want to try changing the parent POM to use Java 1.6. I did create a test case that loads your configuration and it was able to start up correctly.

[rhauch]

Your exception shows that your WAR file obviously has the ModeShape JARs, as made clear by the 'org.modeshape.common' and 'org.modeshape.graph' classes in the stack trace. The stack trace shows that the code is trying to instantiate one or more MIME type detectors (I suspect the default ExtensionBasedMimeTypeDetector class, since none other are specified in the configuration). ModeShape does this reflectively, and so maybe the problem is the security manager or, as in MODE-1087, the classloader. After all, the ModeShape JARs are also OSGi-enabled, and maybe this is confusing the OSGi-aware classloader.

[kbachl]

Hello,

I solved the problem with the null-class. It was in fact based upon my 1.5 compiling of the brix project. I got a bit further, but now are on the access problem; I get:

The JAAS policy named 'modeshape-jcr' (nor the policy named 'other') could not be found; check the value of the 'JAAS_LOGIN_CONFIG_NAME' repository option in the configuration for the 'Brix repository' repository

How can I specify this? I don't want to rely on JAAS but instead provide some simple-credential login if possible;

I think it has something to do with the config option:

<jaasLoginConfigName jcr:primaryType="mode:option" mode:value="modeshape-jcr"/>

but I didn't see any way to do authentication via simple credentials matcher?

Best and thanks for your help so far

[kbachl]

PS: more easy said: what I try to do now is to translate the jackrabbit repository.xml (https://github.com/kbachl/brix-cms/blob/master/brix-demo/src/main/resources/brix/demo/repository.xml) to modeshape; I tried to feed the jackrabbit repository.xml but modeshape didn't like it

[rhauch]

The JAAS policy named 'modeshape-jcr' (nor the policy named 'other') could not be found; check the value of the 'JAAS_LOGIN_CONFIG_NAME' repository option in the configuration for the 'Brix repository' repository

How can I specify this? I don't want to rely on JAAS but instead provide some simple-credential login if possible;

I think it has something to do with the config option:

<jaasLoginConfigName jcr:primaryType="mode:option" mode:value="modeshape-jcr"/>

but I didn't see any way to do authentication via simple credentials matcher?

There's no other way to do simple-credential login without some form of authentication, and out-of-the-box ModeShape uses JAAS for authentication. But ModeShape does enable you to use other forms of authentication, with a bit more work. For example, you can use your servlet container's authentication mechanism, or even set up your own implementation. Section 9.4 of our Reference Guide has the details for setting up and using JAAS, custom authentication, servlet authentication, or anonymous logins.

Hope that helps.

[kbachl]

Hello,

even I've read the doc I'm still not getting forward. In doc there is the anonymousUserRoles mentioned that for a demo is good to use, so I did:

<anonymousUserRoles jcr:PrimaryType="mode:option" mode:value="admin" />

meaning all access should be routed to admin; I also stripped the jaasLoginConfigName away;

Log says:

Caused by: javax.jcr.LoginException: The JAAS policy named 'modeshape-jcr' (nor the policy named 'other') could not be found; check the value of the 'JAAS_LOGIN_CONFIG_NAME' repository option in the configuration for the 'brix' repository

    at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:1327)

    at brix.jcr.AbstractThreadLocalSessionFactory.createSession(AbstractThreadLocalSessionFactory.java:96)

    ... 34 more

but I did remove the JAAS part in the config?

[rhauch]

You're almost there.

If you want to use anonymous users, you should specify what rights you want anonymous users to have. If you used this in your configuration file:

<anonymousUserRoles jcr:PrimaryType="mode:option" mode:value="admin" />

ModeShape will allow anonymous users to read from, write to, and administer the repository. Then, your application should use the "Repository.login()" or "Repository.login(String)" methods. You can also use the "Repository.login(Credentials)" or "Repository.login(Credentials,String)" methods, but for anonymous users you need to pass null in for the Credentials.

Based upon this line number in the stacktrace:

    at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:1327)

I can tell that you're passing in a non-null Credentials object into the "Repository.login(Credentials)" or "Repository.login(Credentials,String)" method. And if you supply any Credentials object, ModeShape is going to try to authenticate using JAAS or, if you supply a SecurityContextCredentials instance, the SecurityContext (e.g., ServletSecurityContext or a custom implementation) inside the supplied SecurityContextCredentials.

(The "JAAS_LOGIN_CONFIG_NAME" merely tells ModeShape the name of the JAAS realm to use, and defaults to "modeshape-jcr". So removing the "jaasLoginConfigName" fragment from the configuration just signals ModeShape to use the default.)

Hope this helps.

P.S. I've just logged MODE-1121 as an enhancement to provide Credentials implementations for anonymous users. This may simplify things a bit.

[kbachl]

Heya Randall,

that was it! Thank you very much!!! I was able get a first version up and running - you may check it out here: https://github.com/kbachl/brix-cms

Also for MODE-1121 thank you! What would be cool if the behaviour in that in case would be that when he finds no JAAS corresponding for a given Credential for user A he gives this user A the anonymous role ans just does a short info-output on the logger;

Regarding modeShape there is 1 question left that I have:

Say one has 3 webapps each having a Brix CMS and they sit on same server and need to access the same repo: how should this be deployed? jackrabbit has some kind of JCA adapter, but its not shareable between different apps as they are differed in the java VM space.

Best

[rhauch]

that was it! Thank you very much!!! I was able get a first version up and running - you may check it out here: https://github.com/kbachl/brix-cms

Awesome. Glad it's working!

What would be cool if the behaviour in that in case would be that when he finds no JAAS corresponding for a given Credential for user A he gives this user A the anonymous role ans just does a short info-output on the logger;

That is an interesting idea. Would you be so kind as to log that as a feature request?

Say one has 3 webapps each having a Brix CMS and they sit on same server and need to access the same repo: how should this be deployed? jackrabbit has some kind of JCA adapter, but its not shareable between different apps as they are differed in the java VM space.

We talk about that a bit in Section 8.6 of the Reference Guide. If you're using JBoss AS, we have a kit that will install ModeShape as a service, so the web apps can just find the Repository instances via the standard ServiceLoader and JCR 2.0 RepositoryFactory mechanism. But if you're not using JBoss AS, you can do it several ways.

One approach is to set it up as some sort of centralized service and registering ModeShape with JNDI, so that web apps can easily access (again, using the ServiceLoader & RepositoryFactory mechanism). Most app servers have this capability, and we talk about how to do this with Tomcat in the Reference Guide.

A second approach that is maybe more portable is to create a WAR file that just has ModeShape engine, and then register ModeShape (or particular javax.jcr.Repository instances) in JNDI. Note that ModeShape can be configured to auto-register itself with JNDI upon engine startup. Then you can have other WAR files that look up the Repository instances in JNDI or get them via the JCR 2.0 RepositoryFactory approach (obviously we highly recommend this implementation-agnostic approach!).

[kbachl]

Heya,

I just created MODE-1122

If this works it would be a breeze to let the demo switch from jackrabbit to modeshape and back;

I've also read the 8.6 section and it is really nice to be able to share not only from the server but also from an modeshape war Is there a special reason JCA isn't used? (AFAIK JCA has just the purpose to be able to deploy content centrally within the app-server for others to consume)

In case anonymous is allowed: is there a way to access it from outside the local-server vm or is it just possible to do so? Meaning if I have an AppServer that has just 1 app running on it and no other person can access it, couldn't one not just use the anonymous access on it as its just accessibale from local? (or am I wrong here?)

[rhauch]

I just created MODE-1122

If this works it would be a breeze to let the demo switch from jackrabbit to modeshape and back;

Thanks!

I've also read the 8.6 section and it is really nice to be able to share not only from the server but also from an modeshape war Is there a special reason JCA isn't used? (AFAIK JCA has just the purpose to be able to deploy content centrally within the app-server for others to consume)

The only reason we haven't implemented a JCA connector is time and resources - it simply hasn't been important enough for the community. As always, we'd welcome anyone interested in helping out!

In case anonymous is allowed: is there a way to access it from outside the local-server vm or is it just possible to do so? Meaning if I have an AppServer that has just 1 app running on it and no other person can access it, couldn't one not just use the anonymous access on it as its just accessibale from local? (or am I wrong here?)

At this time, it's only possible to use the JCR API from within the same VM. ModeShape supports WebDAV and has a RESTful API. We would like to implement a ModeShape connector that talks to ModeShape in a remote VM. But again, it simply hasn't risen to the top of the list of things to do.

[kbachl]

If have to thank you for helping me

Regarding JCA: it was only a question - not that I see a real need for it;

Regarding access: so I can see any modeshape repo as secure per se in case only my app runs on server, thats fine for me.

Best