I am trying to get Log4J2 working via Pax Logging but online docs focus on Log4J (v1). My project is Java, Gradle with BND plugin for OSGi bundles aimed at the Equinox environment.
I am using Gradle 6.8.3
I have my build.gradle file for an OSGi bundle that aims to expose logging functionality to other bundles using:
implementation 'org.ops4j.pax.logging:pax-logging-api:2.1.0'
implementation 'org.ops4j.pax.logging:pax-logging-log4j2:2.1.0'
In my BND file, I include the following imports:
Import-Package: org.apache.logging.log4j;version="2.17.1";provider=paxlogging, org.apache.commons.logging;version="[1.1.1,2)";provider=paxlogging, org.apache.logging.log4j.core;version="2.17.1";provider=paxlogging
Since my project has file appenders defined, which don't form part of the Log4J2 API, but Log4J2 Core, I therefore export the following from the same bundle to enable Log4J2 Core classes to have visibility in other bundles that depend on the logging bundle:
Export-Package: com.mycompany.loggingbundle, org.apache.logging.log4j, org.apache.logging.log4j.message, org.apache.logging.log4j.util, org.apache.logging.log4j.core;version="2.17.1", org.apache.logging.log4j.core.appender;version="2.17.1", org.apache.logging.log4j.core.filter;version="2.17.1", org.apache.logging.log4j.core.impl;version="2.17.1", org.apache.logging.log4j.spi;version="2.17.1"
Everything compiles, builds and install fine.
At runtime, I have an issue:
org.osgi.framework.BundleException: Could not resolve module: com.mycompany.otherbundle [1306]
Unresolved requirement: Require-Bundle: com.mycompany.loggingbundle
-> Bundle-SymbolicName: com.mycompany.loggingbundle; bundle-version="<hidden>"; singleton:="true"
com.mycompany.loggingbundle [1311]
Unresolved requirement: Import-Package: org.apache.logging.log4j.core; provider="paxlogging"; version="2.17.1"
at org.eclipse.osgi.container.Module.start(Module.java:434)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Hopefully some OSGi expert knows what I've got wrong because the whole reason to use Pax Logging was to avoid the need to create Log4J2 fragments and have an easier configuration for a multi-bundled environment. Perhaps there is a systematic series of things to look at to resolve this?
Update
I opened up the pax-logging-log4j2 JAR file to review its manifest and can see it doesn't export anything from org.apache.logging.log4j.core so my re-exporting it from my bundle could never provide the core packages I was hoping.
This still leaves the problem of how to get access to things like a FileAppnder elsewhere in code, but it answers the question as to what is wrong with my approach.
Related
Does OSGI capabilities support versioning and how does it work? Say I have a module with the following declared:
Bundle-SymbolicName: my-module
Implementation-Version: 1.8.1-qualifier
Provide-Capability: org.foo.dependency;nameId="my-module",version="1.8.1-qualifier"
Would I then be able to add this require to get the module above?
Require-Capability: org.foo.dependency;filter:="&(nameId=my-module)(version>=1.8)"
Is there also a way to leverage Implementation-Version on the manifest if it's already specified in the provider module? I see references to osgi.wiring.bundle here. Would I be able to do this instead on the require:
Require-Capability: org.foo.dependency;filter:="(nameId=my.module)",osgi.wiring.bundle;filter:="(bundle-version>=1.8)"
Appreciate any pointers on the subject matter.
1.8.1-qualifier is not a valid OSGi version. 1.8.1.qualifier is a valid OSGi version.
&(nameId=my-module)(version>=1.8) is not a valid OSGi filter expression. You need to surround with parenthesis. (&(nameId=my-module)(version>=1.8))
You cannot use Implementation-Version, but you can use Bundle-Version.
Bundle-SymbolicName: my-module
Bundle-Version: 1.8.1.qualifier
Require-Capability: osgi.wiring.bundle;filter:="(&(osgi.wiring.bundle=my-module)(bundle-version>=1.8))"
See https://docs.osgi.org/specification/osgi.core/8.0.0/framework.namespaces.html#framework.namespaces.osgi.wiring.bundle.
I have a problem during an portlet deployment.
How to resolve?
Liferay (last version).
Eclipse + liferay plugin
2019-07-26 19:51:54.531 ERROR [fileinstall-D:/STUDIO JAVA/liferay-dxp-7.2.10-ga1/osgi/modules][LogService:93] Error while starting bundle: file:/D:/STUDIO%20JAVA/liferay-dxp-7.2.10-ga1/osgi/modules/com.prova.jar
org.osgi.framework.BundleException: Could not resolve module: com.prova [2197]_ Unresolved requirement: Require-Capability: osgi.ee; filter:="(osgi.ee=UNKNOWN)"_ [Sanitized]
at org.eclipse.osgi.container.Module.start(Module.java:444)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:428)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1264)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1237)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
It seems you hit https://issues.liferay.com/browse/LPS-93643
Long story short, the tooling is using old version of Bnd that does not know how to handle Java 11 runtime.
What you can do as workaround is disable the generation of the osgi.ee requirement. To do so you need to place this instruction in your bnd.bnd file:
-noee: true
As a result, OSGi runtime will not check if the Java version your module expects is compatible with the one of the runtime. It should not cause any issues for as long as you make sure you both build and run with the same Java version.
I'm currently developing a REST API with JAX-RS and Jackson in a Maven project but I'm facing some issues when I try to deploy it to the server.
2019-06-14 11:35:18.832 INFO [Refresh Thread: Equinox Container: 9d0f0e6b-9ad0-4d64-b221-2bde32f797ee][BundleStartStopLogger:39] STARTED XXXXREST_1.0.0 [1004]
2019-06-14 11:35:19.801 ERROR [fileinstall-C:/liferay-ce-portal-7.1.2-ga3/osgi/modules][org_apache_felix_fileinstall:97] Error while starting bundle: file:/C:/liferay-ce-portal-7.1.2-ga3/osgi/modules/XXXXREST.jar
org.osgi.framework.BundleException: Could not resolve module: com.xxxx.xxxx [995]_ Unresolved requirement: Import-Package: javax.ws.rs; version="[1.1.0,2.0.0)"_ [Sanitized]
at org.eclipse.osgi.container.Module.start(Module.java:444)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:428)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1258)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1230)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1218)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:507)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312)
2019-06-14 11:35:19.816 ERROR [fileinstall-C:/liferay-ce-portal-7.1.2-ga3/osgi/modules][org_apache_felix_fileinstall:97] Error while starting bundle: file:/C:/liferay-ce-portal-7.1.2-ga3/osgi/modules/XXXXREST.jar
org.osgi.framework.BundleException: Could not resolve module: com.xxxxx.xxxxx [995]_ Unresolved requirement: Import-Package: javax.ws.rs; version="[1.1.0,2.0.0)"_ [Sanitized]
at org.eclipse.osgi.container.Module.start(Module.java:444)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:428)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1258)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1230)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:512)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312)
2019-06-14 11:35:33.958 INFO [Refresh Thread: Equinox Container: 9d0f0e6b-9ad0-4d64-b221-2bde32f797ee][PortletHotDeployListener:288] 1 portlet for XXXXREST is available for use
2019-06-14 11:35:35.599 ERROR [Refresh Thread: Equinox Container: 9d0f0e6b-9ad0-4d64-b221-2bde32f797ee][com_liferay_portal_osgi_web_wab_extender:97] Catastrophic initialization failure! Shutting down XXXXREST WAB due to: The URI scheme bundleentry of the URI bundleentry://995.fwk1108589630/com/xxxxx/xxxxxx/domain/CommunityResource.class is not supported. Package scanning deployment is not supported for such URIs._Try using a different deployment mechanism such as explicitly declaring root resource and provider classes using an extension of javax.ws.rs.core.Application [Sanitized]
com.sun.jersey.core.spi.scanning.ScannerException: The URI scheme bundleentry of the URI bundleentry://995.fwk1108589630/com/xxxxx/xxxxx/domain/CommunityResource.class is not supported. Package scanning deployment is not supported for such URIs._Try using a different deployment mechanism such as explicitly declaring root resource and provider classes using an extension of javax.ws.rs.core.Application [Sanitized]
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:228)
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:142)
at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
at com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:104)
at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:78)
at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:89)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:696)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:674)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:205)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:394)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:577)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at com.liferay.portal.osgi.web.wab.extender.internal.adapter.AsyncAttributeAdapterServlet.init(AsyncAttributeAdapterServlet.java:54)
at com.liferay.portal.osgi.web.wab.extender.internal.adapter.ServletExceptionAdapter.init(ServletExceptionAdapter.java:62)
at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.init(EndpointRegistration.java:95)
at org.eclipse.equinox.http.servlet.internal.context.ContextController.doAddServletRegistration(ContextController.java:566)
at org.eclipse.equinox.http.servlet.internal.context.ContextController.addServletRegistration(ContextController.java:440)
at org.eclipse.equinox.http.servlet.internal.customizer.ContextServletTrackerCustomizer.addingService(ContextServletTrackerCustomizer.java:55)
at org.eclipse.equinox.http.servlet.internal.customizer.ContextServletTrackerCustomizer.addingService(ContextServletTrackerCustomizer.java:1)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:891)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:804)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:228)
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:469)
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:487)
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:1004)
at com.liferay.portal.osgi.web.wab.extender.internal.WabBundleProcessor.initServlets(WabBundleProcessor.java:692)
at com.liferay.portal.osgi.web.wab.extender.internal.WabBundleProcessor.init(WabBundleProcessor.java:225)
at com.liferay.portal.osgi.web.wab.extender.internal.WebBundleDeployer._initWabBundle(WebBundleDeployer.java:186)
at com.liferay.portal.osgi.web.wab.extender.internal.WebBundleDeployer.doStart(WebBundleDeployer.java:85)
at com.liferay.portal.osgi.web.wab.extender.internal.WabFactory$WABExtension.start(WabFactory.java:175)
at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:230)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:137)
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:129)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:191)
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
at org.eclipse.osgi.container.Module.start(Module.java:467)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
at org.eclipse.osgi.container.ModuleContainer.start(ModuleContainer.java:777)
at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:768)
at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:538)
at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:484)
at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:1028)
at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1409)
at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Apparently it has something to do with javax.ws.rs package. Maybe Liferay or Tomcat are using their own dependency which collides with the version that I'm using?
So far I've tried adding this line to my bnd.bnd file:
Import-Package: javax.ws.rs; version="[1.1.0,2.0.0)"
I also tried adding the dependency on my pom.xml (I tried multiple versions: 2.0, 2.0.1, 2.1, 2.1.1):
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.1.1</version>
</dependency>
I also tried adding to project's build path those javax.ws.rs-api-2.X.X.jar
Any ideas on what could be causing this? I don't know what else should I try.
Thanks in advance.
Contrary to Miroslav's comment, I didn't find javax.ws.rs-api in the provided dependencies. Thus, you're satisfying the build-time dependency (for the compiler) with your dependency declaration.
The generated artifact (your own bundle) still has a runtime dependency on javax.ws.rs-api-*.jar, and you'll need to deploy it as well: Just drop it into your ${liferay.home}/deploy folder. Now it's available for any upcoming bundle that has a dependency on it.
I'm suspecting that Miroslav did this some time ago, and now has it available in his runtime. Or I've tested on a wrong version (I've used DXP 7.2) or missed something.
I'm pretty new to osgi and bndtools, but in the past couple days have managed to get jar->bundle creation working using bnd ant task, plus wrapping of our 3rd party jars as bundles (for those not already defining an 'Export-Package' in the manifest file). I must comment that bndtools seems amazing for doing all the heavy lifting when it comes to exports and imports, so thank you to your hard work on this project!
i've got two issues that maybe you can shed some light on:
1
I'm trying to get the bundles to load in felix and am immediately running into resolution errors. In this basic scenario, we have our in-house bundle called omniquery_common, which uses several 3rd party jars, including gson. when i resolve i get this:
Unable to resolve <<INITIAL>> version=null:
missing requirement Require[osgi.identity]{}{filter=(osgi.identity=omniquery_common)} [caused by:
Unable to resolve omniquery_common version=1.0.0.0:
missing requirement Require[osgi.wiring.package]{}{filter=(&(osgi.wiring.package=com.google.gson)(version>=2.2.0)(!(version>=3.0.0)))}]
To me this says omniquery_common is importing com.google.gson (of a version at least 2.2 and less than 3.0). the gson bundle is exporting version 2.2.4, so this should satisfy its dependency, but is not.
can you help me understand how i am wiring this up wrong?
manifest for omniquery_common:
Manifest-Version: 1.0
Bnd-LastModified: 1442336803995
Bundle-ManifestVersion: 2
Bundle-Name: omniquery_common
Bundle-SymbolicName: omniquery_common
Bundle-Version: 1.0.0.0
Created-By: 1.8.0_40 (Oracle Corporation)
Export-Package: com.radian6.omni.common.osgi;version="1.0.0"
Import-Package: com.google.gson;version="[2.2,3)",com.radian6.omni.commo
n.util,org.apache.commons.io;version="[1.4,2)",org.apache.commons.lang;
version="[2.6,3)",org.junit
Private-Package: com.radian6.omni.common.core
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Tool: Bnd-2.4.1.201501161923
manifest for gson:
Manifest-Version: 1.0
Export-Package: com.google.gson;version=2.2.4, com.google.gson.annotat
ions;version=2.2.4, com.google.gson.reflect;version=2.2.4, com.google
.gson.stream;version=2.2.4, com.google.gson.internal;version=2.2.4, c
om.google.gson.internal.bind;version=2.2.4
Bundle-ClassPath: .
Built-By: inder
Bundle-Name: Gson
Created-By: Apache Maven 3.0.4
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-Vendor: Google Gson Project
Bundle-ContactAddress: http://code.google.com/p/google-gson/
Bundle-Version: 2.2.4
Build-Jdk: 1.7.0_21
Bundle-ManifestVersion: 2
Bundle-Description: Google Gson library
Bundle-SymbolicName: com.google.gson
Archiver-Version: Plexus Archiver
2
if i alter the order of the bundles in the 'run requirements' list, putting the gson bundle before omniquery_common, i then get
Unable to resolve <<INITIAL>> version=null:
missing requirement Require[osgi.identity]{}{filter=(osgi.identity=com.google.gson)}
which i find unintuitive - i would have thought the bundle order in that list would not matter...?
The order of the requirements in the -runrequirements list does matter, because if there is an error early in the list then we don't bother trying to resolve everything below it. That is: once we know that the resolution cannot succeed, we just exit and print the first error we encountered.
The second error message you copied (when you put the GSON requirement first) suggests that you simply don't have the GSON bundle in your repository. Or, it is not in a repository that is visible to the resolver. The filter (osgi.identity=com.google.gson) fails, which means there is no resource with the identity com.google.gson.
This would also explain the first error message from your own omniquery_common bundle. The resolver cannot find any bundle exporting the package com.google.gson, which would make perfect sense if the GSON bundle is not there.
So, look into the repositories you are resolving against and what their indexes contain. If GSON really does appear to be in there, then I will need further info on to figure out the problem.
Incidentally, once you have this working, you shouldn't need to list GSON explicitly at all in -runrequirements. That is the point of the resolver: we will find all your dependencies based on the packages you used.
I try to install a bundle in an OSGi environment (FUSE ESB) but do not manage to get it resolved. The error message is:
The bundle could not be resolved. Reason: Package uses conflict: Import-Package: de.foo.bar; version="0.0.0"
My bundle imports the package de.foo.bar.
The bundle which exports the package de.foo.bar does this with a 'uses' directive.
Export-Package = de.foo.bar;uses:="{other packages}";version="2.4.0"
As I understood I have to ensure that my bundle must import all other packages mentioned in the 'uses' directive of the de.foo.bar package (in the right version).
I checked this and also tried several version changes (0.0.0 and the real version numbers) but can not get it to work.
So, what does the error message realy means (maybe I understood it wrong)? What do I have to check?
Thanks for any help
Klaus
System Information:
FUSE ESB 4.2.0 (based on servicemix)
using maven-bundle-plugin 2.1.0 to generate OSGi MANIFEST header
I finally found what was wrong.
My bundle is a Spring Dynamic Module bundle and I did a mistake in the spring bean configuration (use a 'ref' instead a 'value' in a constructor-arg). Normally spring configuration errors are reported as such - I do not know why the current error resulted in the misleading message.
EDIT:
The faulty Spring configuration does not cause the uses conflict. It finally was the import of the package org.apache.log4j which is exported by different bundles (in my FUSE ESB container) and apparently was different wired to the bundles I tried to install.
Trying to solve my problem I found the article Diagnosing OSGi uses conflicts which I found helpfull to understand the problem.