[jboss-jira] [JBoss JIRA] (AS7-2442) Non ejb jars referenced from an ejb jar in an ear via META-INF/MANIFEST.MF have no visiblity to javax.* classes

Rodney Kite (Updated) (JIRA) jira-events at lists.jboss.org
Tue Nov 1 00:54:45 EDT 2011


     [ https://issues.jboss.org/browse/AS7-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

       



More information about the jboss-jira mailing list