Why we have to declare dependencies on manifest of JBOSS 8 (wildfly)?

Question

given the following EAR:

• my-app.ear
  • my-ejb.jar
  • my-webapp.war
  • lib
    • my-lib.jar

my-ejb need the oracle library to work with oracle spatial in order to construct geometry and to store data. The module of oracle is correctly loaded by JBOSS 8 (wildfly).

When I started the application I received ClassNotFoundException oracle.sql.STRUCT.

OK I added the dependency of oracle driver ojdbc6.jar on my-ejb META-INF/manifest.mf.

Class-Path: ojdbc6.jar
Dependencies: oracle.sql 

When I started the application I received ClassNotFoundException oracle.sql.StructDescriptor. I know that when I read data to and from a resultset, the object coming out of the resultset is an instance of a oracle.sql.STRUCT class but the oracle.sql.StructDescriptor is in the same package.

OK I added the same dependency of oracle driver ojdbc6.jar on my-lib META-INF/manifest.mf.

And it works!

My question is

• which is the role of manifets on JBOSS 8?
• why on oracle weblogic I do NOT need to add these dependencies on manifest.mf?

Answer 1

Santosh has given the correct response, but let me clarify some issues about weblogic vs jboss.

JBOSS and WebLogic have different classoader mechanism. Let me clarify:

1. why manifest?

Java-Oracle reply: You may need to reference classes in other JAR files from within a JAR file.

2. why manifest on EAR/WAR application?

Oracle Weblogic reply: WebLogic Server supports optional packages as described in the Java EE 5.0 Specification, Section 8.2 Optional Package Support, with versioning described in Optional Package Versioning. Optional packages provide similar functionality to Java EE libraries, allowing you to easily share a single JAR file among multiple applications. As with Java EE libraries, optional packages must first be registered with WebLogic Server by deploy the associated JAR file as an optional package. After registering the package, you can deploy Java EE modules that reference the package in their manifest files.

Optional packages differ from Java EE libraries because optional packages can be referenced from any Java EE module (EAR, JAR, WAR, or RAR archive) or exploded archive directory. Java EE libraries can be referenced only from a valid Enterprise Application.

[...]

Any Java EE application or module can reference an optional package (using META-INF/MANIFEST.MF), whereas only Enterprise Applications and Web applications can reference a shared Java EE library (using weblogic-application.xml or weblogic.xml)

3. then why we have to no declare java-ee-api.jar, jsf, jsp, ...

Jboss reply: The following table lists the modules that are automatically added to deployments as dependencies and the conditions that trigger the dependency.

Implicit_Module_Dependencies

4. are not all modules loaded by JBOSS?

Jboss reply: this chapter will talk about how applications packaged as jars can declare that they depend on one or more modules:

Dependencies: oracle.sql, another.module.with.version:1.0

Manifest module information

4.1 alternatively define the jboss-deployment-structure.xml

<jboss-deployment-structure>

   <deployment>

      <dependencies>
         <module name="oracle.sql" export="TRUE" />
      </dependencies>

   </deployment>

</jboss-deployment-structure>

Add anExplicit Module Dependency to a Deployment

4.2 with maven

<plugins>

   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <configuration>
         <archive>
            <manifestEntries>
               <Dependencies>org.javassist, org.apache.velocity</Dependencies>
            </manifestEntries>
         </archive>
      </configuration>
   </plugin> 

</plugins>

see: Generate MANIFESTMF entries using Maven

see: How do you generate module dependencies in MANIFEST.MF for JBoss AS 7 with maven?

7. why we didn't get this important information before?

With the new organizational model JBOSS 7/8 abandons the famous classloading hierarchy to switch to a simpler model based on the use of modular units (JBoss Modules Project) . The introduction of the architecture modules (in addition to the forthcoming introduction in the JDK, much in vogue at this time thanks to external projects such as OSGi) actually extends the model in use for the packaging of Java EE applications; a module can then be a library, a collection of classes, or more generally a collection of resources associated with a single classloader: therefore, unlike the past, where the classloader that was collected under a hierarchical organization of a set of classes, the point here of view is exactly reversed.

see: Class Loading in WildFly