Now I can load jars which is under the EAR/lib.
But I want to put the jars to a common path, for other application to use.
I found that jboss-deployment-structure.xml file's tag can do this.
But it doesn't work. I got the ClassNotFound exception.
I don't know why?
<deployment>
<resources>
<resource-root path="/common/test.jar" />
</resources>
</deployment>
One way of using global libraries in different applications can be reached by making them available as modules.
Therefor, extend the modules by the library you are providing as a server provider.
Example:
To make your test.jar available to all applications, create a folder with the modules name and a main subdirectory (e.g. modules/commons/test/main).
Place your library there and a module description file with the name module.xml.
Example content:
<module xmlns="urn:jboss:module:1.0" name="commons.test">
<resources>
<resource-root path="test.jar"/>
</resources>
</module>
Now the library is available to all applications.
To get access to the module, your application has to define the dependency in the manifest.
Applications MANIFEST.MF:
Dependencies: commons.test
This can be also done by maven during build time.
Check https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 for details
Please note that you're modifying the server itself. All applications using your module are depending on it. A application with a dependency to the module commons.test wont be deployed on a server which does not have this module provided.
Related
I'm using Wildfly 11 with Java 8. Previously I was building a WAR file, which required the dom4j JAR file. Rather than including it in the WAR's WEB-INF/lib directory, I linked to the Wildfly modules JAR by adding an entry in the WEB-INF/jboss-deployment-structure.xml. Now I want to package this WAR as part of an EAR. So I created a jboss-deploymebnt-structure.xml file at teh root of the EAR, with these lines
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<sub-deployment name="myapp.war">
<dependencies>
...
<module name="org.dom4j" />
Now when I deploy the EAR, the WAR is failing to deploy with errors like
service jboss.undertow.deployment.default-server.default-host./myapp: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./orgsclient: java.lang.RuntimeException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [META-INF/spring/infrastructure.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/dom4j/io/STAXEventReader
What else do I need to do to tell the EAR file that the WAR is using the Wildly module dom4j as opposed to one I'm packaging with the EAR itself?
Check if your jboss-deploymebnt-structure.xml is correctly placed in META-INF subfolder (beside with application.xml) of your built ear package. If you're using maven ear plugin you should put the xml file in:
ear/src/main/application/META-INF/jboss-deploymebnt-structure.xml
Please note the application folder is default resource folder for ear plugin.
If you still have a problem with NoClassDefFound, try to redeclare the dependency as 'ear global' and set it as exported
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.dom4j" slot="main" export="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
If you still have a problem then declare the module as a global module in wildlfy config (under the ee subsystem). Then you can get rid off the the jboss deployment descriptor at all.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="org.dom4j">
</global-modules>
...
I'm building a product that must be extended by external people of our organization, we don't want the war to be changed by the "external people".
So, our application has the following structure.
EAR
WAR
JAR A
JAR B
extension module defined in jboss-deployment-structure
The extension module is like this
<sub-deployment name="A.war">
<dependencies>
<module name="extension.module" optional="false">
</module>
</dependencies>
</sub-deployment>
We thought the "external people" could create the "extension.module" module and than add the behavior they want. But to do that they need to add dependencies to the JAR A and JAR B inside the war/ear.
Can you help me solving this?
I have a project where I am packaging a WAR using simple maven-war-plugin. Along with all other dependencies one of the dependency say 'abc.jar' which is getting packaged in war contains a default spring configurations which I would like to update with the custom one before packaging. I have maven profile configured to be activated if following build command applied;
mvn clean install -DframeworkPacakging=XYZ
I am trying to use 'truezip-maven-plugin' to overwrite my custom spring configurations inside in 'abc.jar' present in 'target/aretfacts-id/WEB-INF/lib' but when maven-war-plugin finishes I loose my changes because war plugin takes the file from dependency definition. How can I solve this issue and what are my options?
P.S. Distributing configuration is not desirable as this setup would be used for Embedded Jetty Server running within Eclipse
to prevent inclusion of the original jar file, I would use go for approach suggested on: https://www.mail-archive.com/users#maven.apache.org/msg38537.html
Use <scope>provided</scope> for this dependency to keep it out of the
lib directory.
to include the repackaged one, I'd follow suggestion from: How to make Maven copy resource file into WEB-INF/lib directory?
Try changing the configuration of the maven war plugin to include a webResource:
<configuration>
<webResources>
<resource>
<directory>pathtorepackagedjar</directory>
<includes>
<include>**/abc.jar</include>
<includes>
<targetPath>WEB-INF/lib</targetPath>
</resource>
</webResources>
</configuration>
I have a regular maven jar project, which has dependencies such as the reflection library and I want to
convert it to osgi, what Ive already done.
created a common interface layer in a different (maven) jar
project and added it to the bundle as a dependencies.
changed the type of the osgi-module-to-be to 'bundle'.
created an implementation of BundleActivator
added this plugin the pom:
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Activator>my.package.MyServiceActivator</Bundle-Activator>
<Export-Package>
my.package.exp.*
</Export-Package>
<Import-Package>
!org.reflections,???
</Import-Package>
<Embed-Dependency>
slf4j-api;scope=compile,???
</Embed-Dependency>
</instructions>
</configuration>
here is where it gets lost, I need to figure out the "Import-Package" and "Embed-Dependency"
and, even more important figure how to deploy it on glassfish as a zip or,
maybe, ORB (or Gogo) so that it will deploy with all it's dependencies jars.
any ideas?
G.
BTW: the org.reflections package is not OSGi ready
It seems you're confused about how OSGi and the Maven Bundle plugin work.
Maybe reading the Felix guide will help you:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
Basically, you should have something like this:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Activator>my.package.MyServiceActivator</Bundle-Activator>
<Export-Package>
my.package.exp.*
</Export-Package>
<Import-Package>
!org.reflections*,*
</Import-Package>
<Embed-Dependency>
org.reflections
</Embed-Dependency>
</instructions>
</configuration>
</plugin>
By default (ie. if you just omit it, which is usually the case), your Import-Package instructions would be *, which means anything you refer to in the code which is not in java.* or in your own bundle should be imported. But as you have a dependency on a non-bundle jar you want to embed, you need to tell the plugin that by using the expression !org.reflections*,*, which means you don't want to import the org.reflections package but everything else is fine. You also need to declare that any artifactId called org.reflections should be embedded in the jar by using the Embed-Dependency instruction.
BTW, You most likely don't want to embed your logging framework SLF4J implementation, let alone the API, as just about any OSGi environment should provide a logging implementation for you.
After you package your bundle (mvn package or just mvn install) make sure to check the generated MANIFEST to ensure that it looks like everything is correct (importantly, check the Import-Package packages and see if your environment will have all bundles which provide such packages).
Once you get your bundle set up correctly, deploying it is trivial. Just drop it into your framework's bundle directory, ensure all other bundles you need are also there, and everything should work fine.
As a side note, you might want to consider wrapping the non-bundle JAR you need as a bundle by using PAX-WRAP or just Karaf (just throw a JAR in the deploy folder and you will get it wrapped as an OSGi bundle immediately), for example.
I am using maven jar plugin to package the jar file. But it looks like maven jar plugin just only pack the stuff that stay inside target/classes. I am also want to pack all the classes in target/classes and (resource and class) files from many other directories. How can i do that with maven jar?
The resource files stays in another folder of project.
If you can't (or just don't want to) put them under src/main/resources, you can declare additional resource locations using the <resource> element:
<project>
...
<build>
...
<resources>
<resource>
<directory> [your folder here] </directory>
</resource>
</resources>
...
</build>
...
</project>
See Specifying resource directories.
The other classes are generated classes.
The convention with plugins generating sources it to generate them in target/generated-sources/<tool> and a well implemented plugin should add the specified path as a source directory (so that generated code would be compiled). When they don't, the Build Helper Maven Plugin can come to the rescue.
If you are generating classes, why don't you generate them in ${project.build.outputDirectory} (i.e. target/classes by default)? I don't think you can add a 2nd classes directory anyway.
If this doesn't help, please clarify your exact constraints and requirements.
References
Specifying resource directories
MavenPropertiesGuide