Rodney Kite wrote:
It appears jar files in an ear which are not in the <ear>/lib directory and are not an ejb jar file referenced from application.xml have no access to javax.* classes. It does not matter if the jar file is referenced by a MANIFEST.MF entry from the ejb jar file or not. A java.lang.NoClassDefFoundError is raised when trying to access any javax.* classes in these jars. Is this a JBoss 7.0.2 bug?
It's not a bug. Such jars at the root of the .ear are neither deployments not libraries so the module dependencies won't apply for them. If they are not deployments, then why not place them in the .ear/lib folder?
Why would putting a jar in the root directory hide it from standardard Java JRE libraries? javax.api is supposed to be part of JBoss 7s implicit module dependencies. Referencing a jar in an ear with the MANIFEST.MF is the standard way to reference a jar in an ear. It is mentioned in the JBoss AS 7 documentation that using MANIFEST.MF is recommended if you want to make your deployment portable.
"The Java EE specification says that portable applications should not rely on sub deployments having access to other sub deployments unless an explicit Class-Path entry is set in the MANIFEST.MF. So portable applications should always use Class-Path entry to explicitly state their dependencies."
I want to make the jar a hot deployment. In my case I want to expose my ejb 3.0 jars to external wars. Jars in the root are made available to other ears by using deployment.MainEar.ear.utilities.jar . If you put them in the lib directory then they are hidden from other deployments.
Related FYI: It looks like Mr Kite created a ticket for this:
I'm having this problem too, but in my case I'm trying to create some javax security classes versus an InitialContext class as per Mr. Kite's example file attached to the issue ticket linked above.
A little background:
I am converting an application and using MANIFEST.MF entries to reference jars, and it only works if I put them all in my /lib directory. However, doing that will mean I will have to re-architect my project, and regardless, the JBoss documentation states that using the MANIFEST.MF way of doing things is more portable across different appservers.
My question is: Does anyone have a MANIFEST.MF based workaround that doesn't require everything to be thrown in the /lib directory? I tried the modules approach but it looks there's a bug in that too, at least for what I'm trying to do.
This is a real deal breaker for us.
If you're only deploying to JEE5 or JEE6 containers, then the use of the EAR /lib directory *is* portable because it's defined in those specs. And I know for a fact that it works correctly on JBoss 5.x -> 7.x, WebSphere 6.1, 7.0 and 8.0 and WebLogic 10.3.x.
We use the lib dir now because it simplifies the build process a lot. I think the term "re-architect" is a bit strong - this is an implementation detail.
Nevertheless, I agree that the MANIFEST.MF method should continue to function as it has done in the past. From a classloading/visibility perspective I would expect that declaring jars in the manifest or placing them in the EAR /lib directory to be manifestly equivalent.
Using the lib directory is unworkable for us. We need to expose ejb 3.0 entity beans, session bean interfaces and other serializable beans to separate ear files. The lib directory can not expose jars to separate ears/wars. Putting 1/4 of our classes in modules defeats hot deployment and causes a lot of rework. Craming 3/4 million lines of code in one jar is a bad architecture/solution as well.
Including a jar with a MANIFEST.MF Class-Path is supposed to include the jar in the classpath. It actually is doing that somewhat but for some reason is masking javax.* classes to the included jar. This worked great in JBoss 2.4, 3.01, 4.2.3, 5.1, 6.0. It should work in the 7.x series as well.
This is too large of a bug to let slide by. Modules are impacted as well. The manifest included jar can not see JBoss modules either even if they are included in its manifest Dependencies or its parent jars manifest Dependencies.
Not everyone can cram everything in one ear. Other contractors code calls our session beans as well so that is really not an option even with a re-architecture.