I have a problem with Weblogic classloader.
When I try to deploy my app on WL 12.2.1.2.0 it fails.
In the logs on my server I see
java.lang.ClassNotFoundException: org.w3c.dom.ElementTraversal
The class belongs to xml-apis library. The library comes into my app with another dependency(so as transitive dependency). The version of xml-apis is 1.4.01.
After that I added exception in my deployment descriptor:
<container-descriptor>
<prefer-application-packages>
<package-name>org.w3c.dom.*</package-name>
</prefer-application-packages>
</container-descriptor>
And later a new deployment. The described issue with org.w3c.dom.ElementTraversal was solved. There is no any information about missing org.w3c.dom.ElementTraversal class anymore.
But there is a new issue:
java.lang.ClassNotFoundException: org.w3c.dom.Document
After analysis I figured out that org.w3c.dom.Document class comes from JRE(jre/lib/rt.jar).
So in deployment descriptor I've said:
"if I need something from org.w3c.dom.* package - please load it from my app distribution". And now there is such inconsistency.
I've had idea to use WL Classloader Analysis Tool(CAT) but it is impossible because the deploy was failed.
Excluding xml-apis and xerces libraries from my ear we mentioned here didn't help me.
Does anybody have idea how to solve my problem?
Thanks in advance for your answers.
Excluding xercexImpl library from my EAR without changing the deployment descriptor was solved my problem. Mentioned classes during new deployment were loaded from WL distribution.
I'm trying to get the library BioJava to work inside an OSGi context.
To get the JAR into the OSGi context, I'm using the Maven plugin p2-maven-plugin, which generates a file Manifest.MF, and the part relevant to the exception I'm facing is:
Bundle-SymbolicName: org.biojava.core
Bundle-Version: 5.3.0
Import-Package: [snip],
org.slf4j;resolution:=optional,
[snap]
Which looks okay to me. However when I access a class that uses slf4j I get the titular exception:
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.biojava.nbio.core.sequence.template.AbstractCompoundSet.<clinit>(AbstractCompoundSet.java:40)
at org.biojava.nbio.core.sequence.io.ABITrace.getSequence(ABITrace.java:179)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory cannot be found by org.biojava.core_5.3.0
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:511)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414)
Now it's easy to find this exception everywhere, because a lot of people have tried (and failed) to install slf4j. I checked sites like the documentation or the SO question ClassNotFoundException: org.slf4j.LoggerFactory and hence tried to add the following bundles:
slf4j-simple
slf4j-log4j12 (plus the log4j dependencies)
pax-logging-log4j2
However neither worked. Maybe the OSGi container is having problems, but slf4j JARs have the bundle information with the export packages out of the box, so I'm assuming these work. And the BioJava JAR has an import package, so I have no idea why it wouldn't be able to find the class.
Oh, I checked, the LoggerFactory is present in slf4j-api, so it's not that, either.
I also tried different start levels and autostart for the implementations. And I rebundled the JAR without the optional dependency, but I keep having problems because now the MD5 hash is broken.
Has anybody managed to get slf4j to work in OSGi? Or failing that, is there any way to replace that stupid dependency with some kind of Java proxy so I will not need the broken dependency anymore?
resolution:=optional means that when the bundle resolves, it will either get access to the package or not. The framework is permitted to resolve the bundle without access to the package. If the bundle needs access to the package, why make resolution of the package optional?
I have felix-framework-5.0.1 and I'm trying to start slf4j-api-1.6.0.jar bundle into felix isgi container.
in felix console I'm typing install file:bundle/slf4j-api-1.6.0.jar
I'm getting a message Bundle ID: 42
then I'm trying to start the bundle start 42
I'm getting the message
org.osgi.framework.BundleException: Unable to resolve slf4j.api [42](R 42.0): missing requirement [slf4j.api [42](R 42.0)] osgi.wiring.package; (&(osgi.wiring.p
ackage=org.slf4j.impl)(version>=1.5.5)) Unresolved requirements: [[slf4j.api [42](R 42.0)] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=
1.5.5))]
g!
Can any body help me? how can I start slf4j bundle into felix?
slf4j-api needs org.slf4j.impl package. This package is included into every slf4j implementations like slf4j-simple, slf4j-logback, etc.
The implementation bundles need org.slf4j package that comes from the API artifact. There is a cross-reference. This can work only due to the reason that implementations are fragment bundles of the API. When the implementation is installed together with the API, they will have a common classloader and they will be resolved together. Both of their requirements will be satisfied.
In short: You must choose one of the implementations and install that as well. E.g.: slf4j-simple.
You should use the same version of API and implementation to satisfy their "cross requirement".
Your library contains the following 3 packages (link):
org.slf4j
org.slf4j.helpers
org.slf4j.spi
but you have to have an additional library that will contain org.slf4j.impl package.
Also, from manifest file you can see what packages are exported (Export-Package) (they are visible by other bundles) and what packages are imported (Import-Package) (they have to be accessible for the given bundle). Sometimes the given package have to be from bundle with the correct version.
If you cannot find correct bundle maybe this page will help you.
I have created an bundle which relies on SLF4J and as such am using Logback for the OSGI implementation. This all bundles up and installs OK but when I come to start the bundle I get the following exception:
org.osgi.framework.BundleException: Unable to resolve com.felix.test
[20](R 20.0): missing requirement [com.felix.test [20](R 20.0)]
osgi.wiring.package; (osgi.wiring.package=groovy.lang) Unresolved
requirements: [[com.felix.test [20](R 20.0)] osgi.wiring.package;
(osgi.wiring.package=groovy.lang)]
I can see in my manifest file groovy.lang is listed in Import-Package and I'm pretty sure the problem is that Logback is being embedded but none of it's references are.
I'm using to create the bundle, here's the config:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.5.4</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Import-Package>
*
</Import-Package>
<Embed-Dependency>
*
</Embed-Dependency>
<Embed-Directory>
osgi-inf/libs
</Embed-Directory>
<Embed-Transitive>
true
</Embed-Transitive>
</instructions>
</configuration>
</plugin>
Here's my manifest:
Manifest-Version: 1.0
Bnd-LastModified: 1436982944102
Build-Jdk: 1.8.0_45
Built-By: tim.clifford
Bundle-ClassPath: .,osgi-inf/libs/org.osgi.core-1.0.0.jar,osgi-inf/libs/
servlet-api-2.5.jar,osgi-inf/libs/org.apache.felix.scr.annotations-1.9.
6.jar,osgi-inf/libs/httpclient-osgi-4.5.jar,osgi-inf/libs/httpclient-4.
5.jar,osgi-inf/libs/httpcore-4.4.1.jar,osgi-inf/libs/commons-logging-1.
2.jar,osgi-inf/libs/commons-codec-1.9.jar,osgi-inf/libs/httpmime-4.5.ja
r,osgi-inf/libs/httpclient-cache-4.5.jar,osgi-inf/libs/fluent-hc-4.5.ja
r,osgi-inf/libs/ehcache-2.10.0.jar,osgi-inf/libs/slf4j-api-1.7.7.jar,os
gi-inf/libs/commons-lang3-3.4.jar,osgi-inf/libs/logback-classic-1.1.3.j
ar,osgi-inf/libs/logback-core-1.1.3.jar
Bundle-ManifestVersion: 2
Bundle-Name: com.felix.test
Bundle-SymbolicName: com.felix.test
Bundle-Version: 1.0.0.SNAPSHOT
Created-By: Apache Maven Bundle Plugin
Embed-Dependency: *
Embed-Directory: osgi-inf/libs
Embed-Transitive: true
Embedded-Artifacts: osgi-inf/libs/org.osgi.core-1.0.0.jar;g="org.apache.
felix";a="org.osgi.core";v="1.0.0",osgi-inf/libs/servlet-api-2.5.jar;g=
"javax.servlet";a="servlet-api";v="2.5",osgi-inf/libs/org.apache.felix.
scr.annotations-1.9.6.jar;g="org.apache.felix";a="org.apache.felix.scr.
annotations";v="1.9.6",osgi-inf/libs/httpclient-osgi-4.5.jar;g="org.apa
che.httpcomponents";a="httpclient-osgi";v="4.5",osgi-inf/libs/httpclien
t-4.5.jar;g="org.apache.httpcomponents";a="httpclient";v="4.5",osgi-inf
/libs/httpcore-4.4.1.jar;g="org.apache.httpcomponents";a="httpcore";v="
4.4.1",osgi-inf/libs/commons-logging-1.2.jar;g="commons-logging";a="com
mons-logging";v="1.2",osgi-inf/libs/commons-codec-1.9.jar;g="commons-co
dec";a="commons-codec";v="1.9",osgi-inf/libs/httpmime-4.5.jar;g="org.ap
ache.httpcomponents";a="httpmime";v="4.5",osgi-inf/libs/httpclient-cach
e-4.5.jar;g="org.apache.httpcomponents";a="httpclient-cache";v="4.5",os
gi-inf/libs/fluent-hc-4.5.jar;g="org.apache.httpcomponents";a="fluent-h
c";v="4.5",osgi-inf/libs/ehcache-2.10.0.jar;g="net.sf.ehcache";a="ehcac
he";v="2.10.0",osgi-inf/libs/slf4j-api-1.7.7.jar;g="org.slf4j";a="slf4j
-api";v="1.7.7",osgi-inf/libs/commons-lang3-3.4.jar;g="org.apache.commo
ns";a="commons-lang3";v="3.4",osgi-inf/libs/logback-classic-1.1.3.jar;g
="ch.qos.logback";a="logback-classic";v="1.1.3",osgi-inf/libs/logback-c
ore-1.1.3.jar;g="ch.qos.logback";a="logback-core";v="1.1.3"
Export-Package: com.felix.test;version="1.0.0"
Import-Package: groovy.lang,javax.crypto,javax.crypto.spec,javax.jms,jav
ax.mail,javax.mail.internet,javax.management,javax.management.openmbean
,javax.naming,javax.naming.directory,javax.naming.ldap,javax.net,javax.
net.ssl,javax.security.auth.x500,javax.sql,javax.swing.event,javax.tran
saction,javax.transaction.xa,javax.xml.datatype,javax.xml.namespace,jav
ax.xml.parsers,javax.xml.stream,javax.xml.stream.events,net.spy.memcach
ed,org.apache.avalon.framework.logger,org.apache.felix.scrplugin,org.ap
ache.felix.scrplugin.annotations,org.apache.felix.scrplugin.description
,org.apache.log,org.apache.log4j,org.codehaus.commons.compiler,org.code
haus.groovy.control,org.codehaus.groovy.control.customizers,org.codehau
s.groovy.reflection,org.codehaus.groovy.runtime,org.codehaus.groovy.run
time.callsite,org.codehaus.groovy.runtime.typehandling,org.codehaus.gro
ovy.runtime.wrappers,org.codehaus.groovy.transform,org.codehaus.janino,
org.hibernate,org.hibernate.cache,org.hibernate.cache.access,org.hibern
ate.cfg,org.hibernate.impl,org.hibernate.stat,org.hibernate.transaction
,org.ietf.jgss,org.osgi.service.cm,org.quartz,org.quartz.impl,org.quart
z.impl.jdbcjobstore,org.quartz.impl.matchers,org.quartz.simpl,org.terra
cotta.quartz,org.terracotta.toolkit,org.terracotta.toolkit.atomic,org.t
erracotta.toolkit.builder,org.terracotta.toolkit.cache,org.terracotta.t
oolkit.cluster,org.terracotta.toolkit.collections,org.terracotta.toolki
t.concurrent.locks,org.terracotta.toolkit.config,org.terracotta.toolkit
.events,org.terracotta.toolkit.feature,org.terracotta.toolkit.internal,
org.terracotta.toolkit.internal.cache,org.terracotta.toolkit.internal.c
luster,org.terracotta.toolkit.internal.collections,org.terracotta.toolk
it.internal.concurrent.locks,org.terracotta.toolkit.internal.feature,or
g.terracotta.toolkit.monitoring,org.terracotta.toolkit.nonstop,org.terr
acotta.toolkit.rejoin,org.terracotta.toolkit.search,org.terracotta.tool
kit.search.attribute,org.terracotta.toolkit.store,org.xml.sax,org.xml.s
ax.helpers,sun.misc,sun.reflect
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"
Tool: Bnd-2.4.1.201501161923
Am I going about it the right way or is there a better method?
Thank you!
To your question "am I going about is the right way", the answer is "definitely not"!
Please, please don't use Embed-Dependency. This simply takes all of the transitive dependency graph (which in your case includes the Groovy language runtime, somehow) and sticks it inside your bundle.
This misses the point of OSGi entirely. Worse, when you develop your next bundle you will have to go through all this again! Eventually you will have tens of bundles, each carrying around a massive, dead weight of embedded dependencies.
As Christian said, stick to the defaults provided by the maven-bundle-plugin. You don't even need to specify <Import-Package>*</Import-Package> since this is already the default. As a result you will get a bundle that has package imports, which is a good thing! But you need to install bundles that provide exports that will match your imports.
You should not embed all dependencies into your bundle. Instead just run with maven bundle plugin defaults. It should create a bundle that you can then deploy into an OSGi container.
I am most experienced with Apache Karaf. There you can just install the bundle using:
install -s mvn:groupId/artifactId/version
In your case this might already work as Apache Karaf comes with pax-logging pre installed.
If you want to use plain felix it is a little more complicated as you will have to gather all dependencies and create a suitable start configuration. In that case bndtools might help.
From the exception you reported in your question I would say none of the bundles in your osgi environment is currently exporting the groovy.lang package.
I would suggest to install the felix gogo shell in your runtime and to issue the following command in the osgi console:
g! inspect cap osgi.wiring.package
This will give you the list of all exported packages in your osgi instance: in this way you can verify whether or not the groovy.lang package is indeed missing.
If this is the case, then you should wrap the groovy-all jar in a bundle as explained here and include it in your running osgi bundles. If you want, you can search a ready-to-use osgi bundle for groovy-all in jpm4j website.
I use osgi container (virgo) [i'm not very good in that].
I added a dependency to my pom.xml
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-osgi_2.10</artifactId>
<version>2.2-M3</version>
</dependency>
I put akka-osgi_2.10-2.2-M3.jar to my lib/deploy folder to OSGI server (to myserver/repository/usr).
I added dummy actor to my code base:
import akka.actor.UntypedActor;
public class ManagerActor extends UntypedActor {
#Override
public void onReceive(Object o) throws Exception {
// ...
}
}
I build and start my application.
And as result I have the following exceptions in my log (it complains to version="0.0.0"):
.. failed. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'com.
com.mycompnay.mything-security' at version '1.0.1.BUILD-SNAPSHOT': Cannot resolve: com.mycompany.mything-security
Resolver report:
An Import-Package could not be resolved. Resolver error data <Import-Package: akka.actor; version="0.0.0">. Caused by missing constrai
nt in bundle <com.mycompany.mything-security_1.0.1.BUILD-SNAPSHOT>
constraint: <Import-Package: akka.actor; version="0.0.0">
I go to my template.mf file, which is used to generate final MANIFEST.MF file. To specify the range of versions for AKKA lib I use. Putting there:
Import-Template:
akka.actor.*;version="[2.2.0.M3, 2.3)"
Import-Package:
akka.actor;version="[2.2.0.M3, 2.3)"
Then rebuild and start app.
But in console it complains to akka versions (complains to version="[2.2.0.M3,2.3.0)" now):
An Import-Package could not be resolved. Resolver error data <Import-Package: akka.actor; version="[2.2.0.M3,2.3.0)">. Caused by missi
ng constraint in bundle <com.mycompany.mything-security_1.0.1.BUILD-SNAPSHOT>
constraint: <Import-Package: akka.actor; version="[2.2.0.M3,2.3.0)">
Q: what's wrong?
Also I tried to add this line: to Import-Bundle:
Import-Bundle:
...
com.typesafe.akka.osgi;version="[2.2.0.M3, 2.3)"
Then I have it in the log (now it complains to com.typesafe.akka.osgi version):
.. failed. org.eclipse.virgo.kernel.deployer.core.DeploymentException: Unable to satisfy dependencies of bundle 'com.mycompany.mything-security
' at version '1.0.1.BUILD-SNAPSHOT': Import-Bundle with symbolic name 'com.typesafe.akka.osgi' in version range '[2.2.0.M3, oo)' could not be
satisfied
The reason was:
I need to put akka-actor_2.10-2.2-M3.jar (along with akka-osgi_2.10-2.2-M3.jar) to my osgi (virgo) deploy folder.
So, we should NOT do it manually but with help of maven (in order not to miss some jar that comes along with expecting one).