Hi David. Thanks for the clarification. I created another, very simple, example with and this is resolved as expected. There might be a problem with the Provide-Capability-Header in my subsystem-feature
regards Marc Von: David Bosschaert <[email protected]> An: [email protected], Datum: 26.03.2015 17:33 Betreff: Re: Application-Subsystem not resolving provided capability from Feature-Subsystem Hi Marc, You should not need a DEPLOYMENT.MF if you don't want to have one. A DEPLOYMENT.MF is meant to restrict any version ranges that you might have in your SUBSYSTEM.MF. The idea is that you use the SUBSYSTEM.MF during development to create a subsystem that can work in a variety of contexts. Some people woud like to freeze their dependencies to what they are using during QA and the DEPLOYMENT.MF is for that. However you should be able to run without the DEPLOYMENT.MF. Your subsystem contains quite a lot of stuff. I would recommend to start with a small subsystem and see if you can get that working without the DEPLOYMENT.MF... Cheers, David On 26 March 2015 at 17:14, <[email protected]> wrote: > Hello again, > > I got my application at least started when I add DEPLOYMENT.MF files to my > subsystems. After Reading the specification I saw that the headers > (require-capability | provide-capability) are described under > Pre-Calculated-Deployment (134.15). > > Could someone please explain why I need a Deployment-Descriptor for > capabilities? The spec is kind of misleading, at least for me: > > 134.3 Subsystem-Region provides a example which fits my use-case (S1 > provides a capability, S2 requires one, the subsystem implementation is > responsible for the wiring) > 134.15 specify Capabilities only for Deployments > 134.16.1 says that capabilities are automatically imported (imho). Quote: > Any required capabilities that are > > not satisfied by the application's constituents are automatically shared in > (imported) from the parent > Subsystem. > > I would rather not maintain a DEPLOYMENT.MF for each subsystem except for > production-environments. > > But there seems to be another issue with Liberty. Even though my > application-subsystem is started, it is not recognized as a WAB. Going to > test it again packaged as EBA. > > Some clarification/explanation would be great > > regards > Marc > > > > Von: [email protected] > An: [email protected], > Datum: 25.03.2015 15:51 > Betreff: Application-Subsystem not resolving provided capability from > Feature-Subsystem > ________________________________ > > > > Hello everyone, > > I am trying to create a feature-subsystem, using the esa-maven-plugin, as > well as a application-subsystem. The features shall provide > Pax-Cdi-Capabilities to the application running on WebSphere-Liberty > (currently 8.5.5.5). > > I at least managed to deploy the feature-subsystem and I see some logging > from my internal bundles. > Unfortunately I cannot get the application resolved because the integrated > WAB-bundle specifies a Require-Capability which is necessary to use the > pax-cdi-extender. > > Unable to resolve IFileAdapter wrapping file with url > wsjar:file:/C:/Development/servers/liberty-8.5.5.5/usr/servers/defaultServer/dropins/liberty-pax-cdi-demo-app-0.0.1-SNAPSHOT.esa!/liberty-pax-cdi-demo-wab-0.0.1-SNAPSHOT.jar: > missing requirement > org.apache.aries.subsystem.core.archive.RequireCapabilityRequirement: > namespace=osgi.extender, attributes={}, > directives={filter=(osgi.extender=pax.cdi), effective=resolve, > resolution=mandatory}, resource=IFileAdapter wrapping file with url > wsjar:file:/C:/Development/servers/liberty-8.5.5.5/usr/servers/defaultServer/dropins/liberty-pax-cdi-demo-app-0.0.1-SNAPSHOT.esa!/liberty-pax-cdi-demo-wab-0.0.1-SNAPSHOT.jar > > According to the R5-Subsystem-Specification, chapter 134.2.1.6, a Scoped > Subsystem (aka application) needs to specify its required-capabilities. I am > not sure why this cannot be resolved from the subsystem-contents. > > This is what I have, the complete example can be found on GitHub ( > https://github.com/lostiniceland/issues/tree/master/liberty-pax-cdi ): > > a feature-subsystem providing the same capabilty as its contents > > Subsystem-ManifestVersion: 1 > Subsystem-SymbolicName: demo.liberty-pax-cdi-subsystem > Subsystem-Version: 0.0.1.SNAPSHOT > Subsystem-Name: liberty-pax-cdi-subsystem > Subsystem-Description: OSGi-Subsystem for PAX-CDI inside Liberty > Subsystem-Content: > org.apache.logging.log4j.api;version="[2.2.0,2.2.0]";start-order:="1", > org.ops4j.pax.logging.pax-logging-service;version="[1.8.2,1.8.2]";start-order:="2", > org.ops4j.pax.logging.pax-logging-api;version="[1.8.2,1.8.2]";start-order:="3", > com.google.guava;version="[18.0.0,18.0.0]";start-order:="4", > org.apache.geronimo.specs.geronimo-atinject_1.0_spec;version="[1.0,1.0]";start-order:="5", > javax.enterprise.cdi-api;version="[1.2.0,1.2.0]";start-order:="6", > javax.interceptor-api;version="[1.2,1.2]";start-order:="7", > org.apache.xbean.bundleutils;version="[4.1.0,4.1.0]";start-order:="8", > org.apache.xbean.finder;version="[4.1.0,4.1.0]";start-order:="9", > org.objectweb.asm.all;version="[5.0.3,5.0.3]";start-order:="10", > org.apache.felix.eventadmin;version="[1.4.2,1.4.2]";start-order:="11", > org.apache.felix.configadmin;version="[1.8.2,1.8.2]";start-order:="12", > org.apache.felix.http.api;version="[2.3.2,2.3.2]";start-order:="13", > org.ops4j.base.lang;version="[1.5.0,1.5.0]";start-order:="14", > org.ops4j.pax.cdi.weld;version="[0.11.0,0.11.0]";start-order:="15", > org.jboss.weld.osgi-bundle;version="[2.2.9.Final,2.2.9.Final]";start-order:="16", > org.jboss.logging.jboss-logging;version="[3.2.1.Final,3.2.1.Final]";start-order:="17", > org.ops4j.pax.cdi.api;version="[0.11.0,0.11.0]";start-order:="18", > org.ops4j.pax.cdi.spi;version="[0.11.0,0.11.0]";start-order:="19", > org.ops4j.pax.cdi.extender;version="[0.11.0,0.11.0]";start-order:="20", > org.ops4j.pax.cdi.extension;version="[0.11.0,0.11.0]";start-order:="21", > org.ops4j.pax.swissbox.lifecycle;version="[1.8.0,1.8.0]";start-order:="22", > org.ops4j.pax.swissbox.tracker;version="[1.8.0,1.8.0]";start-order:="23", > org.ops4j.pax.swissbox.core;version="[1.8.0,1.8.0]";start-order:="24" > Provide-Capability: osgi.extender; osgi.extender=pax.cdi, > org.ops4j.pax.cdi.extension; > extension=pax-cdi-extension > Subsystem-Type: osgi.subsystem.feature > > > a application-subsystem requiring those capabilities > > Subsystem-ManifestVersion: 1 > Subsystem-SymbolicName: demo.liberty-pax-cdi-demo-app > Subsystem-Version: 0.0.1.SNAPSHOT > Subsystem-Name: liberty-pax-cdi-demo-app > Subsystem-Description: Demo-Application for Pax-CDI on Liberty > Subsystem-Content: > demo.liberty-pax-cdi-demo-wab;version="[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT]" > Import-Package: javax.inject;version="1.0" > Preferred-Provider: liberty-pax-cdi-subsystem > Subsystem-Type: osgi.subsystem.application > Require-Capability: osgi.extender; filter:="(osgi.extender=pax.cdi)", > org.ops4j.pax.cdi.extension; > filter:="(extension=pax-cdi-extension)" > > and a bundle inside the application requiring the same capability > > Manifest-Version: 1.0 > Bnd-LastModified: 1427292914886 > Build-Jdk: 1.8.0_25 > Built-By: u000501 > Bundle-ClassPath: WEB-INF/classes > Bundle-ManifestVersion: 2 > Bundle-Name: liberty-pax-cdi-demo-wab > Bundle-SymbolicName: demo.liberty-pax-cdi-demo-wab > Bundle-Version: 0.0.1.SNAPSHOT > Created-By: Apache Maven Bundle Plugin > DynamicImport-Package: * > Export-Package: test;version="0.0.1.SNAPSHOT";uses:="javax.servlet,javax > .servlet.http" > Import-Package: javax.inject,javax.servlet,javax.servlet.http > Require-Capability: osgi.extender;filter:="(osgi.extender=pax.cdi)",org. > ops4j.pax.cdi.extension;filter:="(extension=pax-cdi-extension)",osgi.ee > ;filter:="(&(osgi.ee=JavaSE)(version=1.6))" > Tool: Bnd-2.3.0.201405100607 > Web-ContextPath: demo > > > Is there anything missing? I tried many different alternatives, checked my > spelling and so on: according to the spec my application should be correct. > > Any help is appreciated. > > regards > Marc
