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.
Related
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.
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 trying to install & start a bundle from a osgi jar in the filesystem
Bundle bundle = context.installBundle("reference:file:" + fullPath);
bundle.start();
it worked for another simple bundle, but another more complex bundle has
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
in its manifest
this causes the following exception
(org.osgi.framework.BundleException) org.osgi.framework.BundleException: Unresolved constraint in bundle
Unable to resolve 42.0: missing requirement [42.0] osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))
how do I add this capability to my project?
also how would I remove this require from the other project?
all similiar questions I found didn't answer my question
thanks in advance for any answers and for helping me not pull out my hair :)
Edit:
as christian suggested I tried finding the configuration to felix in netbeans, as the felix framework is loaded by netbeans. I found some configurations inside the maven POM file, but could not use the "org.osgi.framework.system.capabilities" framework property which was mentioned by christian, which I couldn't find in the documentation.
I am putting a bounty as this is really important for me to resolve and is the only thing preventing me from using OSGi as far as I can see
The capability you identified:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
is a requirement for the osgi.ee namespace. This is the namespace which defines the execution environment for your framework. The filter then says that you need the execution environment to be JavaSE, and that you need the version attribute to be 1.8. This (unsurprisingly) corresponds to Java SE 8.
As others have indicated, this capability should be provided by the OSGi framework. You should not need to do anything to get this to happen. There are two main reasons that this capability would not be present.
You are using an older, or non SE, version of Java. This could easily happen if your NetBeans launch configuration is not using a Java 8 installation.
You are using a Felix framework which does not understand "new" versions of Java. This could be because your Felix framework is old (the latest version is 5.6.4) or because your Java version is very new (are you using a pre-release Java 9 build?).
This really should just work if you can run a newish Felix framework on top of Java 8. Do you have any more details about your environment?
Edit:
You can see the osgi.ee capability provided by the system bundle as follows:
// Get the wiring for the system bundle
BundleWiring wiring = context.getBundle(0).adapt(BundleWiring.class);
// Get the osgi.ee capability for the system bundle
List<Capability> eecaps = wiring.getCapabilities("osgi.ee");
// There must be exactly one capability to show
System.out.println(eecaps.get(0).getAttributes());
This is a capability that needs to be provided by your framework. It means that your project needs to run on Java 8.
It is configured in the framework property:
org.osgi.framework.system.capabilities=osgi.ee; osgi.ee="JavaSE"; version:List<Version>="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"
That said normally this is already configured when you for example start the felix distro.
This is a known felix bug which has been fixed in 2.0.4. From http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.bundlerepository-2.0.10/doc/changelog.txt ,
Changes from 2.0.2 to 2.0.4
---------------------------
** Bug
* [FELIX-3097] - LocalRepository is not updated when bundles are
* [FELIX-4571] - NullPointerException when using Repository impl with Aries subsystem impl
* [FELIX-4616] - BundleRepository ResourceComparator violates comparison contract
* [FELIX-4640] - missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
** Improvement
* [FELIX-4812] - BundleRepository can be quite CPU intensive when starting a lot of bundles
Dear all:
I write a sample plugin and i want insert this bundle into my controller. But error occurs when i start it in the OSGI, it show:
gogo: BundleException: The bundle "org.opendaylight.controller.ping.plugin_0.4.0.SNAPSHOT [98]" could not be resolved. Reason: Missing Constraint: Import-Package: org.opendaylight.controller.sal.binding.api; version="[1.1.0,2.0.0)"
Referring from this post page, I think that I've got a newer version of a plug-in without its dependencies.
The error shows that the minimum version number of org.opendaylight.controller.sal.binding.api is 1.1.0, and mine version is 1.0-1 as i lookup in my directory of controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/plugins.
My question is how to switch the version from 1.0-1 to 1.1, i can find the 1.1 version of sal.binding.api in my directory: ~/.m2/repository/org/opendaylight/controller/sal-binding-api/1.1-SNAPSHOT.
As i look into my pom.xml, i foud my dependency is 1.1:
<dependency>
<groupId>org.opendaylight.controller</groupId>
<artifactId>sal-binding-api</artifactId>
<version>1.1-SNAPSHOT</version>
</dependency>
I think it's very strange.
Great appreciation for anyone's reply!
Best Regards,
Vinllen
Plugin versions should be in the form 'major.minor.micro.build', where 'major', 'minor' and 'micro' are all numbers, 'build' can be anything. So you should have something like 1.1.0.SNAPSHOT.
I have solved this problem: change the version 1.1 to 1.0-1 in pom.xml. After then , if have any other problems, change the version 1.1 to 1.0-1 with the different jar packet continue.
I have an app running under Tomcat 6. The app contains/uses shared library, say Shared.jar. At some point it would copy Shared.jar with unique name, load it as an OSGi bundle into a Felix instance, and start it. In Shared.jar MANIFEST.MF there's
Import-Package: org.osgi.framework,javax.swing,javax.net,javax.net.ssl.
It's all fine with Java < 8, but with Java 8 the app itself starts fine, but starting a bundle fails with exception
Unresolved constraint in bundle [21431]: Unable to resolve 21431.0: missing requirement [21431.0] osgi.wiring.package; (osgi.wiring.package=javax.net)
What's wrong?
You need minimum Karaf 2.4 to support Java 8.
May be you would also need to add import package declaration in your pom.xml
<Import-Package>javax.net.*</Import-Package>
..but that doesn't look like the main issue, because it is working with older versions of JRE.