[
https://issues.jboss.org/browse/AS7-2442?page=com.atlassian.jira.plugin.s...
]
Rodney Kite updated AS7-2442:
-----------------------------
Workaround Description: There is no work around considering some want to deploy their
application on other application servers by using the JEE standard with MANIFEST.MF files.
Using static modules will work but restricts the developer to having to restart JBoss
after compiles. (was: There is no work around considering some want to deploy their
application on other application servers by using the JEE standard and MANIFEST.MF files.
Using static modules will work but restricts the developer to having to restart JBoss
after compiles.)
Priority: Critical (was: Major)
Description: When an ejb jar file in an ear references a regular non ejb
jar file using the MANIFEST.MF Class-Path: entry the non ejb jar file has no visibility to
javax.* classes. This results in the run time exception java.lang.NoClassDefFoundError
when passing javax.* objects to the accessed jar or when constructing them in the jar.
For example "java.lang.NoClassDefFoundError: javax/naming/InitialContext" is
thrown when constructing a javax.naming.InitialContext in the accessed non ejb jar.
Referencing jars through a MANIFEST.MF is standard J2EE and is defined in the JBOSS AS 7
Documentation as proper for portability. Using <ejb>/lib for the jar does not
exhibit the error but prevents the jar from being used as a deployment module. Thus not a
solution for a jar that needs to be shared across ears such as one which contains remote
session bean interfaces. Adding javax.api to the Dependencies of the jars does not have
any affect. (was: When an ejb jar file in an ear references a standard jar file from
an MANIFEST.MF entry the standard jar file has no access to javax.* class. This results
in a run time exception "java.lang.NoClassDefFoundError:
javax/naming/InitialContext" when constructing a javax.naming.InitialContext or other
javax.* class in the standard jar. Referencing jars through a MANIFEST.MF is defined in
the JBOSS AS 7 Documentation as proper for portability. Using <ejb>/lib for the jar
works but restricts access to the jar as a deployment module. )
Non ejb jars referenced from an ejb jar in an ear via
META-INF/MANIFEST.MF have no visiblity to javax.* classes
---------------------------------------------------------------------------------------------------------------
Key: AS7-2442
URL:
https://issues.jboss.org/browse/AS7-2442
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
Environment: Windows 7 64 bit, Sun/Oracle 32 bit JDK 1.6.0_27-b07, Intel Core 2
Quad
Reporter: Rodney Kite
Assignee: David Lloyd
Priority: Critical
Fix For: No Release
Attachments: testJBossErrorApp.zip
When an ejb jar file in an ear references a regular non ejb jar file using the
MANIFEST.MF Class-Path: entry the non ejb jar file has no visibility to javax.* classes.
This results in the run time exception java.lang.NoClassDefFoundError when passing javax.*
objects to the accessed jar or when constructing them in the jar. For example
"java.lang.NoClassDefFoundError: javax/naming/InitialContext" is thrown when
constructing a javax.naming.InitialContext in the accessed non ejb jar. Referencing jars
through a MANIFEST.MF is standard J2EE and is defined in the JBOSS AS 7 Documentation as
proper for portability. Using <ejb>/lib for the jar does not exhibit the error but
prevents the jar from being used as a deployment module. Thus not a solution for a jar
that needs to be shared across ears such as one which contains remote session bean
interfaces. Adding javax.api to the Dependencies of the jars does not have any affect.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira