-
1. Re: ModeShape 4.0 Sub-System Class Loader
hchiorean Jun 2, 2014 3:36 AM (in response to ma6rl)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
ma6rl Jun 2, 2014 1:52 PM (in response to hchiorean)1 of 1 people found this helpfulThanks, 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.
-
3. Re: ModeShape 4.0 Sub-System Class Loader
hchiorean Jun 3, 2014 2:41 AM (in response to ma6rl)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
ma6rl Jun 3, 2014 11:42 AM (in response to hchiorean)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.