4 Replies Latest reply on Jun 3, 2014 11:42 AM by Richard Lucas

    ModeShape 4.0 Sub-System Class Loader

    Richard Lucas Apprentice

      I’m currently running ModeShape 4.0 in Wildfly 8 using the ModeShape sub-system. I have implemented a custom ModeShape authenticator and have deployed it as a module in Wildfly. This is working as expected.


      My preference would be to bundle my custom authenticator inside my WAR file and have the ModeShape sub-system access it from there so that I do not have to maintain and deploy a separate module. Is it possible to have the ModeShape sub-system class loader load classes from a WAR deployment in the same way it can load classes from another module?


      I know the Wildfly security subsystem supports this as I am able to get it to use a custom Login Module bundled in my WAR but I have not be able to get the ModeShape sub-system to do the same.

       

      Thanks in advance.

        • 1. Re: ModeShape 4.0 Sub-System Class Loader
          Horia Chiorean Master

          According to Class Loading in WildFly - WildFly 8 - Project Documentation Editor, deployed WARs are also modules (from a CL perspective). So all you need to do is figure out what the default module name/id of a deployed WAR in Wildfly is. Once you have it, you can pass it as the value of the authenticator's "module" attribute.

          • 2. Re: ModeShape 4.0 Sub-System Class Loader
            Richard Lucas Apprentice

            Thanks, that worked. For future reference if you need to reference you deployed WAR file as a module the naming syntax is:

             

            deployment.<war-name>.war e.g. deployment.myapp.war see (Class Loading in WildFly - WildFly 8 - Project Documentation Editor - Deployment Module Names) for more information.

             

            The only problem with is approach is if you include the version in your WAR name (which Maven does by default) you end up having to reference the war via deployment.myapp-1.0.0-SNAPSHOT.war and update this in the standalone.xml whenever it changes. I looked at the jboss-deployment-strucutre.xml and it does have a concept of a module-alias but when I set this


            <module-alias name="myapp.war" />


            and attempt to access the module using the alias e.g. deployment.myapp.war it does not work as per the error message below:


            [0m [31m10:48:48,097 ERROR [org.modeshape.jcr.JcrRepository] (default task-5) Unable to initialize authentication provider "{ "name" : "custom" , "classloader" : "deployment.myapp.war" , "classname" : "com.myapp.security.CustomAuthenticationProvider" }" for repository "myapp-repo": Unable to instantiate class com.myapp.security.CustomAuthenticationProvider: org.infinispan.commons.CacheConfigurationException: Unable to instantiate class com.myapp.security.CustomAuthenticationProvider


            I'm not sure if I'm doing something wrong or if the module-alias isn't supported when resolving the correct class-loader in ModeShape.

            1 of 1 people found this helpful
            • 3. Re: ModeShape 4.0 Sub-System Class Loader
              Horia Chiorean Master

              I suspect that the module-alias isn't really changing the runtime module name (see Re: How to override the module name of deployments?) for the webapp.

              In order to use a custom module classpath, ModeShape relies on the Widlfy API - namely the org.jboss.modules.ModuleLoader to resolve the CL and org.jboss.modules.ModuleIdentifier to load a module based on the "classname" attribute.

               

              So the question really is IMO how can one control the runtime module name via the jboss-deployment-structure.xml. I don't know the answer to this, so maybe it's worth posting it on the WF forums (the above mentioned thread seems to have a similar, unanswered question).

              • 4. Re: ModeShape 4.0 Sub-System Class Loader
                Richard Lucas Apprentice

                Thanks for your help with this.

                 

                I did some more digging and it looks like you are correct, the module-alias is not used to replace the runtime module name. From what I can tell there is no way to specify this is the jboss-deployment-structure.xml (there are several posts discussing this).

                 

                One alternative I did find was that when deploying via the JBoss CLI you can specify --name and --runtime-name which allows you to override the runtime name. While this is helpful it does appear to limit deployment via the CLI if you want to change the runtime name as I could not find a way to get this to work with either the Maven Wildfly Plugin or via Intellij.