Re: Predictable order of bundle resolution

[Neil Bartlett]

The implementation of the resolver will be different depending on the OSGi
Framework implementation, so you're really getting into the weeds if you
start relying on those internals.

If one of your bundle's imports is optional, then by definition your bundle
has to work when that import is not wired. The Framework is not required to
give you a wiring for the import even if a compatible export appears to be
available.

I agree with Justin that services are the answer, but I disagree a little
with the structure of his solution, there is no need for a shim. Here is
what I would do:

* Bundle A (for "API") exports both packages org.foo and org.bar. Both of
these are pure APIs without implementation, so there is no cost to
exporting both packages.
* Either bundle A or another bundle (A') provides a service implementing
the org.foo API, e.g. org.foo.Service.
* Bundle B (for "Bonus"?) imports package org.bar and provides a service
implementing the org.bar API, e.g. org.bar.BonusService.
* Bundle C ("Consumer") imports both packages org.foo and org.bar. Neither
of these are optional imports so they are always wired. C attempts to find
a service instance implementing the BonusService, but if it doesn't find
that then it can fall back to the inferioer org.foo.Service instance.

This can be easily modelled as a Declarative Services component with one
mandatory reference to org.foo.Service, and an optional+greedy reference to
the org.bar.BonusService.

Neil





On Fri, 15 Oct 2021 at 08:40, Dirk Rudolph  wrote:

> Thanks for the suggestion Justin.
>
> What if I cannot guarantee that the Shim API Bundle exists on all
> installations, same as Bundle B? That would mean the org.shim import
> in Bundle C is optional again.
>
> In fact I have a Bundle D already implementing both APIs from Bundle A
> and B and registering the implementation as a service of both.
>
> Bundle A
> interface org.foo.Service {}
>
> Bundle B
> interface org.bar.ServiceExt extends org.foo.Service {}
>
> Bundle D
> @Component(service = {org.foo.Service,org.bar.ServiceExt}) class
> ServiceImpl implements ServiceExt {}
>
> So Bundle B always resolves, at least wired to Bundle A and so the
> service from Bundle D is used with the org.foo API.
>
> If I understand the StatefulResolver correctly, it uses a ThreadPool
> as executor for the ResolverImpl, meaning it may happen that bundles
> do not alway get resolved in the same order. If so I would assume the
> implementation should repeat the resolution once a bundle fulfilling
> an optional requirement gets resolved (greedy behaviour). Is that the
> case? I haven't found anything about that in the specs.
>
> Regards,
> Dirk
>
>
>
>
>
>
> On Fri, 15 Oct 2021 at 00:09, Justin Edelson 
> wrote:
> >
> > Hi Dirk,
> > This is a possibly impractical suggestion in your context, but have you
> > thought about modeling this as services? Something like:
> >
> > Bundle A (ID: 200)
> > - Export-Package: org.foo;version=1.0.0
> >
> > Bundle B (ID: 210)
> > - Import-Package: org.foo;version="[1.0,2)"
> > - Export-Package: org.bar;version=1.0.0
> >
> > Shim API Bundle:
> > - Export-Package: org.shim;version=1.0.0
> >
> > Shim for Bundle A Bundle
> > - Import-Package: org.shim;version="[1.0.0,2)",org.foo;version="[1.0,2)"
> >
> > Shim for Bundle B Bundle
> > - Import-Package: org.shim;version="[1.0.0,2)",org.bar;version="[1.0,2)"
> >
> > Bundle C
> > - Import-Package: org.shim;version="[1.0.0,2)"
> >
> > The Shim API bundle exports a service interface that is implemented in
> both
> > "Shim for Bundle A Bundle" and "Shim for Bundle B Bundle" (backed by the
> > corresponding org.foo or org.bar API). The service in "Shim for Bundle B
> > Bundle" has a higher service ranking. The service reference in Bundle C
> > would (assuming it was properly set up) get one or the other.
> >
> > Regards,
> > Justin
> >
> > On Thu, Oct 14, 2021 at 1:40 PM Dirk Rudolph  wrote:
> >
> > > Hi,
> > >
> > > tldr; is the order in which bundles get resolved predictable?
> > >
> > > We are facing issues with the usage of optional imports. Sometimes an
> > > optionally imported package gets wired and sometimes it doesn't.
> > > Refreshing the consuming bundle's package imports after startup always
> > > works to get the wiring done right.
> > >
> > > Consider the following bundles:
> > >
> > > Bundle A (ID: 200)
> > > - Export-Package: org.foo;version=1.0.0
> > >
> > > Bundle B (ID: 210)
> > > - Import-Package: org.foo;version="[1.0,2)"
> > > - Export-Package: org.bar;version=1.0.0
> > >
> > > Bundle C (ID: 500)
> > > - Import-Package:
> > >
> org.foo;version="[1.0,2)",org.bar;version="[1.0,2)";resolution:=optional
> > >
> > > All bundles have the same startlevel (20), in case it matters (?).
> > >
> > > Our use-case is that Bundle C used to use an API provided by Bundle A,
> > > which got improved and extended into a new API provided by Bundle B.
> > > Not all installations provide Bundle B, but all provide Bundle A.
> > > Bundle C now prefers the 

Re: Enforcing mandatory components for an application

[Neil Bartlett]

On Wed, 13 Oct 2021 at 10:06, Bertrand Delacretaz 
wrote:

> On Tue, Oct 12, 2021 at 11:59 PM Neil Bartlett 
> wrote:
> > ...But you are building a closed
> > world with a well-defined set of bundles. As the application assembler
> you
> > know that there will never be another bundle to come along and save the
> day...
>
> In such cases, I think having a PERMANENT_FAILURE state for services
> would be useful, and that's where you would decide to give up.
>

There is the FAILED_ACTIVATION state already, which would certainly be a
specific error case that you can detect before waiting for a full timeout.
Sadly it's not enough for the general case. If the component is waiting for
a service reference then it will be UNSATISFIED, we don't know if it will
become satisfied soon. Unsatisfied is not a failure state!

You could dig deeper and try to work out why the referred service isn't
available but this requires quite a bit of knowledge of bundle internals,
e.g. "I know bundle X should provide this service but it is unresolved".


>
> I don't think there's such a concept for OSGI services, if I had to
> implement that I would probably implement my own "failed services
> registry"  where services can indicate that they're hopelessly dead.
> Each service can then decide on their own when that happens, probably
> based on service-specific timeouts.
>

This would require abandoning a lot of Declarative Services and all of its
advantages, instead doing all your service lookups directly in code.


>
> -Bertrand
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Enforcing mandatory components for an application

[Neil Bartlett]

This is an interesting problem and I'm also not clear on why Ray suggested
the Condition Service as a solution, as I can't see how it helps.

What you're trying to do is somewhat against the grain in OSGi. We assume
that the world as open and that failure is never permanent. Just because
the HTTP component has not started *yet* doesn't mean that it never
will...  if you could just install a bundle the right version of some
dependency it might all spring into life! But you are building a closed
world with a well-defined set of bundles. As the application assembler you
know that there will never be another bundle to come along and save the day.

Honestly, a launcher-based timeout may still be the best solution, e.g.
"HTTP server failed to start within 30 seconds, terminating application".
There may be some error conditions that you can detect without having to
wait for the full timeout, but you cannot *in general* tell the difference
between a component that will never be satisfied and a component that just
isn't satisfied yet.


On Tue, 12 Oct 2021 at 22:09, Robert Munteanu  wrote:

> Hello Ray,
>
> Thanks for your reply. I read through [1] and also the condition
> service specification [3] and I am not sure how this will help me.
>
> I am looking for a way to say "component X did not come up and will not
> come up" and at that moment halt the application. This is a bit of a
> closed-world/static approach, but I am fine with it for limited
> scenarios. E.g. if binding an HTTP server to port 8080 failed, I would
> not like the application to linger and wait for the admin to solve it
> and restart the component when done, but it should stop altogether.
>
> Where would you see the condition service helping here?
>
> Thanks,
> Robert
>
> [3]:
> https://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html
>
> On Tue, 2021-10-12 at 11:33 -0400, Raymond Augé wrote:
> > Hello Robert,
> >
> > You probably want to use the DS support [1] for the **NEW** _Condition
> > Service Specification_ which was added in OSGi Compendium R8 (currently
> > in
> > the release process).
> >
> > You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on
> > Maven
> > Central.
> >
> > The Condition Service Specification lets you model your application
> > conditions (as the name implies) using OSGi service filters.
> >
> > [1]
> >
> https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition
> > [2]
> >
> https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle
> >
> > On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu 
> > wrote:
> >
> > > Hi,
> > >
> > > I have written a couple of small OSGi apps where if a single top-
> > > level
> > > DS component, let's call it T, cannot start then the application
> > > should
> > > shut down immediately. One example are HTTP services where the HTTP
> > > server port cannot be bound to.
> > >
> > > The causes of failures I have seen are:
> > > - T activation fails
> > > - the bundle providing T fails to resolve
> > > - a dependency of T fails activation
> > > - a dependency of T cannot be provided because the bundle providing
> > > it
> > > failed to staret
> > >
> > > I can think of several ways of approaching the problem, but none of
> > > them perfect:
> > > - using the Felix Health Checks[1], that seems wrong since it's a
> > > polling-based approach and we very likely know when a dependency
> > > fails
> > > and stop immediately
> > > - using the SCR introspection API [2], which is again based on
> > > polling
> > > - waiting for the framework to start and then looking up the service;
> > > but we don't know when the SCR has 'settled'
> > >
> > > Are there any patterns or libraries that I can use to approach this
> > > problem?
> > >
> > > Thanks,
> > > Robert
> > >
> > > [1]:
> > >
> > >
> https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html
> > > [2]:
> > >
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > > For additional commands, e-mail: users-h...@felix.apache.org
> > >
> > >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Need documents for gogo shell

[Neil Bartlett]

The following from OSGi enRoute is a good starting place:
https://enroute.osgi.org/FAQ/500-gogo.html

On Fri, 12 Jun 2020 at 09:17, Asif Ansari  wrote:

> Hi
> I am not able to locate any documentation for gogo shell referring each
> command.
> e.g
> gogo:if
> gogo:new
> gogo:not
> gogo:set
> gogo:sh
> gogo:source
> gogo:telnetd
> gogo:throw
> gogo:try
> gogo:type
> gogo:until
> gogo:while
>
> etc
>
> Please suggest ..
> --
>
> Thanks and Regards
> Md. Asif Ansari
> Mobile: +91 9911562922
>

Re: Resolution and CNFE problems with Configurator 1.0.10

[Neil Bartlett]

I have raised a JIRA for this issue:
https://issues.apache.org/jira/browse/FELIX-6277

Cheers,
Neil

On Tue, 19 May 2020 at 08:58, Neil Bartlett  wrote:

> Hi Apache devs,
>
> I'm trying to use org.apache.felix.configurator version 1.0.10 in an OSGi
> enRoute project. EnRoute uses 1.0.6 by default, but I'm trying to bump the
> version to see if it addresses what might be a lifecycle bug (that's a
> topic for a separate email).
>
> Initially there were some problems resolving the bundle, so 1.0.10 has an
> import that was not required in 1.0.6:
>
> [ERROR] Resolution failed. Capabilities satisfying the following
> requirements could not be found:
> [<>]
>   ⇒ osgi.identity: (osgi.identity=org.example.app)
>   ⇒ [org.example.app version=0.0.1.202005190718]
>   ⇒ osgi.extender:
> (&(osgi.extender=osgi.configurator)(version>=1.0.0)(!(version>=2.0.0)))
>   ⇒ [org.apache.felix.configurator version=1.0.10]
>   ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=javax.json)(&(version>=1.0.0)(!(version>=2.0.0
>
> I tried adding org.apache.geronimo.specs:geronimo-json_1.0_spec (which is
> listed as a provided scope dependency of configurator) to the resolver
> input as follows:
>
> 
> org.apache.geronimo.specs
> geronimo-json_1.0_spec
> 1.0-alpha-1
> runtime
> 
>
> This successfully resolves, but the Configurator now throws a CNFE from
> its activator:
>
> ! Failed to start bundle org.apache.felix.configurator-1.0.10, exception
> activator error org.apache.johnzon.core.JsonProviderImpl not found from:
> javax.json.spi.JsonProvider:doLoadProvider#132
> org.osgi.framework.BundleException: Exception in
> org.apache.felix.configurator.impl.Activator.start() of bundle
> org.apache.felix.configurator.
> at
> org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:803)
> at
> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:732)
> at
> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
> at
> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357)
> ...
> Caused by: javax.json.JsonException:
> org.apache.johnzon.core.JsonProviderImpl not found
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:132)
> at javax.json.spi.JsonProvider.provider(JsonProvider.java:64)
> at javax.json.Json.createReader(Json.java:68)
> at
> org.apache.felix.configurator.impl.json.JSONUtil.parseJSON(JSONUtil.java:329)
> at
> org.apache.felix.configurator.impl.json.JSONUtil.readJSON(JSONUtil.java:161)
> at
> org.apache.felix.configurator.impl.json.JSONUtil.readJSON(JSONUtil.java:122)
> at
> org.apache.felix.configurator.impl.json.JSONUtil.readConfigurationsFromBundle(JSONUtil.java:86)
> at
> org.apache.felix.configurator.impl.Configurator.processAddBundle(Configurator.java:315)
> ...
> Caused by: java.lang.ClassNotFoundException:
> org.apache.johnzon.core.JsonProviderImpl
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> at
> org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> at
> javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:129)
> ...
>
> I am running on Java 11 (AdoptOpenJDK build 11.0.7+10). What combination
> of bundles does Configurator actually require? Why does this bundle allow a
> correct resolution of imports but then throw a CNFE at runtime? Note that
> configurator 1.0.6 embeds geronimo-json_1.0_spec-1.0-alpha-1.jar,
> johnzon-core-1.0.0.jar and org.apache.felix.converter-1.0.0.jar using
> Bundle-ClassPath, but this is no longer the case in 1.0.10. That seems like
> an error.
>
> Regards,
> Neil
>

Resolution and CNFE problems with Configurator 1.0.10

[Neil Bartlett]

Hi Apache devs,

I'm trying to use org.apache.felix.configurator version 1.0.10 in an OSGi
enRoute project. EnRoute uses 1.0.6 by default, but I'm trying to bump the
version to see if it addresses what might be a lifecycle bug (that's a
topic for a separate email).

Initially there were some problems resolving the bundle, so 1.0.10 has an
import that was not required in 1.0.6:

[ERROR] Resolution failed. Capabilities satisfying the following
requirements could not be found:
[<>]
  ⇒ osgi.identity: (osgi.identity=org.example.app)
  ⇒ [org.example.app version=0.0.1.202005190718]
  ⇒ osgi.extender:
(&(osgi.extender=osgi.configurator)(version>=1.0.0)(!(version>=2.0.0)))
  ⇒ [org.apache.felix.configurator version=1.0.10]
  ⇒ osgi.wiring.package:
(&(osgi.wiring.package=javax.json)(&(version>=1.0.0)(!(version>=2.0.0

I tried adding org.apache.geronimo.specs:geronimo-json_1.0_spec (which is
listed as a provided scope dependency of configurator) to the resolver
input as follows:


org.apache.geronimo.specs
geronimo-json_1.0_spec
1.0-alpha-1
runtime


This successfully resolves, but the Configurator now throws a CNFE from its
activator:

! Failed to start bundle org.apache.felix.configurator-1.0.10, exception
activator error org.apache.johnzon.core.JsonProviderImpl not found from:
javax.json.spi.JsonProvider:doLoadProvider#132
org.osgi.framework.BundleException: Exception in
org.apache.felix.configurator.impl.Activator.start() of bundle
org.apache.felix.configurator.
at
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:803)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:732)
at
org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
at
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357)
...
Caused by: javax.json.JsonException:
org.apache.johnzon.core.JsonProviderImpl not found
at javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:132)
at javax.json.spi.JsonProvider.provider(JsonProvider.java:64)
at javax.json.Json.createReader(Json.java:68)
at
org.apache.felix.configurator.impl.json.JSONUtil.parseJSON(JSONUtil.java:329)
at
org.apache.felix.configurator.impl.json.JSONUtil.readJSON(JSONUtil.java:161)
at
org.apache.felix.configurator.impl.json.JSONUtil.readJSON(JSONUtil.java:122)
at
org.apache.felix.configurator.impl.json.JSONUtil.readConfigurationsFromBundle(JSONUtil.java:86)
at
org.apache.felix.configurator.impl.Configurator.processAddBundle(Configurator.java:315)
...
Caused by: java.lang.ClassNotFoundException:
org.apache.johnzon.core.JsonProviderImpl
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at
org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at javax.json.spi.JsonProvider.doLoadProvider(JsonProvider.java:129)
...

I am running on Java 11 (AdoptOpenJDK build 11.0.7+10). What combination of
bundles does Configurator actually require? Why does this bundle allow a
correct resolution of imports but then throw a CNFE at runtime? Note that
configurator 1.0.6 embeds geronimo-json_1.0_spec-1.0-alpha-1.jar,
johnzon-core-1.0.0.jar and org.apache.felix.converter-1.0.0.jar using
Bundle-ClassPath, but this is no longer the case in 1.0.10. That seems like
an error.

Regards,
Neil

Re: Felix on jdk11

[Neil Bartlett]

No. The felix framework is only a single jar. Any other jars that happen to
have felix in their name are just bundles.

I’ll have to let Karl or another felix insider comment on your second
question. It would need to be clarified though since “conform to” could
mean any number of things.

Neil.

On Mon, 18 Feb 2019 at 18:39, Chuck Davis  wrote:

> So ALL the Felix jars go on the classpath not just felix.jar?  I'll
> experiment with that.  Thanks much for the assist.
>
> That begs the question then, when will Felix conform to jdk9+ modules?  I
> have an OpenJDK11/OpenJFX11 application I want to distribute as a
> self-updating application to the end-users.
>
> On Mon, Feb 18, 2019 at 10:31 AM Neil Bartlett 
> wrote:
>
> > It looks like you are still running with Felix on the modulepath rather
> > than the classpath. This is the giveaway from the output you showed:
> >
> > 'module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at org.apache.felix.framework@6.0.2'
> >
> > In other words, Java thinks that Felix is a module.
> >
> > Put Felix on the classpath and it should work.
> >
> > Regards,
> > Neil
> >
> >
> > On Mon, Feb 18, 2019 at 6:23 PM Chuck Davis  wrote:
> >
> > > Didn't make any difference.  Still getting the following exception with
> > > felix.jar on the classpath:
> > >
> > > chuck@linux-hk84:~> ./startJFXFelix
> > > The framework class is: org.apache.felix.framework.Felix
> > ><-- my class output
> > > loaded bundle: org.apache.felix.framework which is bundle number: 0
> > ><-- my class output
> > > Exception in thread "main" java.lang.ExceptionInInitializerError
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.URLHandlers.createURLStreamHandler(URLHandlers.java:513)
> > > at java.base/java.net.URL.getURLStreamHandler(URL.java:1415)
> > > at java.base/java.net.URL.(URL.java:633)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:256)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
> > > at org.apache.felix.framework@6.0.2
> > >
> /org.apache.felix.framework.cache.JarRevision.(JarRevision.java:76)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:799)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:480)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:148)
> > > at org.apache.felix.framework@6.0.2
> > >
> >
> /org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:462)
> > > at org.apache.felix.framework@6.0.2
> > > /org.apache.felix.framework.Felix.installBundle(Felix.java:3227)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:147)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:120)
> > > at
> > > JFXFelix/com.yakridge.jfxfelix.JFXMain.someNewMethod(JFXMain.java:65)
> > > at JFXFelix/com.yakridge.jfxfelix.JFXMain.main(JFXMain.java:30)
> > > Caused by: java.lang.RuntimeException: Unable to make protected boolean
> > > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL)
> accessible:
> > > module java.base does not "opens java.net" to module
> > > org.apache.felix.framework
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> > > ... 15 more
> > > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to
> make
> > > protected boolean
> > > java.net.URLStreamHandler.equals(java.net.URL,ja

Re: Felix on jdk11

[Neil Bartlett]

It looks like you are still running with Felix on the modulepath rather
than the classpath. This is the giveaway from the output you showed:

'module java.base does not "opens java.net" to module
org.apache.felix.framework
at org.apache.felix.framework@6.0.2'

In other words, Java thinks that Felix is a module.

Put Felix on the classpath and it should work.

Regards,
Neil


On Mon, Feb 18, 2019 at 6:23 PM Chuck Davis  wrote:

> Didn't make any difference.  Still getting the following exception with
> felix.jar on the classpath:
>
> chuck@linux-hk84:~> ./startJFXFelix
> The framework class is: org.apache.felix.framework.Felix
><-- my class output
> loaded bundle: org.apache.felix.framework which is bundle number: 0
><-- my class output
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.URLHandlers.createURLStreamHandler(URLHandlers.java:513)
> at java.base/java.net.URL.getURLStreamHandler(URL.java:1415)
> at java.base/java.net.URL.(URL.java:633)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:256)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
> at org.apache.felix.framework@6.0.2
> /org.apache.felix.framework.cache.JarRevision.(JarRevision.java:76)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:799)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:480)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:148)
> at org.apache.felix.framework@6.0.2
> /org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:462)
> at org.apache.felix.framework@6.0.2
> /org.apache.felix.framework.Felix.installBundle(Felix.java:3227)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:147)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:120)
> at
> JFXFelix/com.yakridge.jfxfelix.JFXMain.someNewMethod(JFXMain.java:65)
> at JFXFelix/com.yakridge.jfxfelix.JFXMain.main(JFXMain.java:30)
> Caused by: java.lang.RuntimeException: Unable to make protected boolean
> java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> module java.base does not "opens java.net" to module
> org.apache.felix.framework
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> ... 15 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> protected boolean
> java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> module java.base does not "opens java.net" to module
> org.apache.felix.framework
> at
>
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
>
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> at
> java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
> ... 15 more
>
>
> On Mon, Feb 18, 2019 at 9:39 AM Karl Pauls  wrote:
>
> > right, as I said, you need to put the felix jar on the classpath - then
> it
> > should work.
> >
> > regards,
> >
> > Karl
> >
> > On Monday, February 18, 2019, Chuck Davis  wrote:
> >
> > > I start my main class with the following bash script:
> > >
> > > java --module-path
> > > /sata2/modules:/sata2/modules/felix:/sata2/Downloads/javafx/
> > > javafx-sdk-11.0.1/lib
> > > --add-modules=ALL-MODULE-PATH com.yakridge.jfxfelix.JFXMain
> > > If I comment out all the Felix stuff the program runs fine.  My main
> > class
> > > is on the classpath.  The felix bundles are in /sata2/modules
> directory.
> > >
> > >
> > > On Mon, Feb 18, 2019 at 8:00 AM Karl Pauls 
> wrote:
> > >
> > > > How do you start this main class (and/or, are you embedding felix in
> a
> > > > module)?
> > > >
> > > > You need to be on the classpath and not on the module path to work.
> > > >
> > > > regards,
> > > >
> > > > Karl
> > > >
> > > >
> > >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> >
>

Re: Felix on jdk11

[Neil Bartlett]

Wait a minute... if Chuck is having problems running Felix on Java 11
because of dependencies on the platform, then how is adding MORE bundles by
using Karaf going to help?

Since Felix has been tested on Java 11 and is expected to work, it would be
really good to try to help out with the original problem, as Karl is trying
to do.

Neil

On Mon, Feb 18, 2019 at 3:16 PM James Carman 
wrote:

> People run karaf on Raspberry Pi devices.  It can be quite small.  What are
> your requirements on resources?
>
> On Mon, Feb 18, 2019 at 10:10 AM Chuck Davis  wrote:
>
> > Hi James:
> >
> > My understanding is that Karaf is quite heavy.  I want to keep my client
> as
> > light as possible.  This is for a Java client application that I want to
> > update automatically on a periodic basis.
> >
> > On Mon, Feb 18, 2019 at 5:41 AM James Carman  >
> > wrote:
> >
> > > Unless you really need to be “down and dirty” with OSGi, lots of folks
> > opt
> > > for using Apache Karaf, which is based on Felix (by default).  It takes
> > > care of a lot of the heavy lifting for you automatically.  If you
> really
> > > want to learn the insides and outs, though, stick with Felix, but
> you’ll
> > > want something like karaf when you deploy for real, most likely.
> > >
> > > On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis 
> wrote:
> > >
> > > > Thanks for responding, Rob.  I'm very new to OSGi and that sounds
> like
> > a
> > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > >
> > > > But the more I study it the more it makes sense to me and the
> > exceptions
> > > > I'm seeing.
> > > >
> > > > Thanks for your response.
> > > >
> > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > > >
> > > > > We have worked our Felix based app so that it runs on JDK11 - took
> a
> > > bit
> > > > > of tinkering, but there wasn't anything in core code we had to
> > change.
> > > > >
> > > > >
> > > > >
> > > > > We did need to load the following bundles separately to replace
> > missing
> > > > > classes:
> > > > >
> > > > >
> > > > >
> > > > > jre-1.8_extra_bundles=
> > > > >
> > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: maven-bundle-plugin multiple blueprint folders

[Neil Bartlett]

In bnd you could use macros, such as the -findpath macro (
https://bnd.bndtools.org/macros/findpath.html).

However I'm not sure if maven-bundle-plugin will process these.

Neil

On Wed, Jan 16, 2019 at 1:27 PM DERIES Sebastien <
sebastien.der...@thalesgroup.com> wrote:

> Hi Neil,
> thank you for your answer!
>
> Do you know if there is a way to configure the maven-bundle-plugin to
> automatically generate the bundle-blueprint header as you described (with
> the "/"):
> OSGI-INF/blueprint/folder1/, OSGI-INF/blueprint/folder2/,
> OSGI-INF/blueprint/folder3/
>
> If such a configuration exists, it would discover automatically the
> folders where blueprint XML files are, and list then in the header.
>
> Regards.
>
> Sebastien.
>
> -Message d'origine-
> De : Neil Bartlett [mailto:njbartl...@gmail.com]
> Envoyé : mercredi 16 janvier 2019 10:26
> À : users
> Objet : Re: maven-bundle-plugin multiple blueprint folders
>
> See OSGi Compendium specification, section 121.3.4. The Bundle-Blueprint
> header is a list of paths and only the last component of each path can be a
> wildcard. However if a path ends in a slash then it is inferred to mean
> *.xml under that path.
>
> Therefore you can define your Bundle-Blueprint header as:
> OSGI-INF/blueprint/folder1/, OSGI-INF/blueprint/folder2/,
> OSGI-INF/blueprint/folder3/
> (etc).
>
> Regards,
> Neil
>
> On Tue, Jan 15, 2019 at 10:30 AM DERIES Sebastien <
> sebastien.der...@thalesgroup.com> wrote:
>
> > Hi Felix users !
> >
> > First I wish you the best for this new year !
> >
> > Then, I have a question about the maven-bundle-plugin and the
> > bundle-blueprint manifest header.
> > Our application is built using the maven-bundle-plugin.
> >
> > Our bundles currently instanciate beans using many blueprint XML files.
> > The bean definitions are stored in the following file structure :
> > OSGI-INF
> > ->blueprint
> > -> file1.xml
> > -> file2.xml
> > -> ...
> > -> fileN.xml
> >
> > The maven-bundle-plugin generates for us a perfect MANIFEST.MF file, with
> > this structure.
> >
> > However, having such a flat file structure is not easily readable. I was
> > wondering if maven-bundle-plugin could automatically generate a
> MANIFEST.MF
> > with the right bundle-blueprint header corresponding to a file structure
> > like this:
> >
> > OSGI-INF
> > ->blueprint
> > -> folder1
> > > file1.xml
> > > file2.xml
> > -> folder2
> > > file1.xml
> > > file2.xml
> > -> folder3
> > > file1.xml
> > > file2.xml
> >
> > I tested this file structure with our current maven-bundle-plugin options
> > and it currently does not work. Is there a way to configure the
> > maven-bundle-plugin to have inside the manifest :
> > bundle-blueprint: blueprint/folder1, blueprint/folder2, blueprint/folder3
> >
> > Thank you!
> >
> > Cheers.
> >
> > Sebastien
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

Re: maven-bundle-plugin multiple blueprint folders

[Neil Bartlett]

See OSGi Compendium specification, section 121.3.4. The Bundle-Blueprint
header is a list of paths and only the last component of each path can be a
wildcard. However if a path ends in a slash then it is inferred to mean
*.xml under that path.

Therefore you can define your Bundle-Blueprint header as:
OSGI-INF/blueprint/folder1/, OSGI-INF/blueprint/folder2/,
OSGI-INF/blueprint/folder3/
(etc).

Regards,
Neil

On Tue, Jan 15, 2019 at 10:30 AM DERIES Sebastien <
sebastien.der...@thalesgroup.com> wrote:

> Hi Felix users !
>
> First I wish you the best for this new year !
>
> Then, I have a question about the maven-bundle-plugin and the
> bundle-blueprint manifest header.
> Our application is built using the maven-bundle-plugin.
>
> Our bundles currently instanciate beans using many blueprint XML files.
> The bean definitions are stored in the following file structure :
> OSGI-INF
> ->blueprint
> -> file1.xml
> -> file2.xml
> -> ...
> -> fileN.xml
>
> The maven-bundle-plugin generates for us a perfect MANIFEST.MF file, with
> this structure.
>
> However, having such a flat file structure is not easily readable. I was
> wondering if maven-bundle-plugin could automatically generate a MANIFEST.MF
> with the right bundle-blueprint header corresponding to a file structure
> like this:
>
> OSGI-INF
> ->blueprint
> -> folder1
> > file1.xml
> > file2.xml
> -> folder2
> > file1.xml
> > file2.xml
> -> folder3
> > file1.xml
> > file2.xml
>
> I tested this file structure with our current maven-bundle-plugin options
> and it currently does not work. Is there a way to configure the
> maven-bundle-plugin to have inside the manifest :
> bundle-blueprint: blueprint/folder1, blueprint/folder2, blueprint/folder3
>
> Thank you!
>
> Cheers.
>
> Sebastien
>
>

Re: Default reference policy option 'reluctant' stops new service being bound

[Neil Bartlett]

Probably the main reason (I wasn't involved in the EG discussions
personally) is that reluctant was the *only* option before DS 1.2 (part of
OSGi Release 5). If the greedy option had been introduced and used as the
default, it would have broken backwards compatibility.

Even before DS 1.2 and/or when using the reluctant option, a component can
still obtain the highest rank service simply by binding dynamically with
multiple cardinality, i.e. 0..n or 1..n. You just gather all the references
into a SortedSet.

Neil

On Thu, Dec 20, 2018 at 1:02 PM Jasper Simon  wrote:

> Hi Neil,
>
> I get what you’re saying, and indeed we’re building a workaround to
> disable the specific component to force re-binding.
> It does make me wonder why the default policy option is reluctant, not
> greedy? Are there some specific reasons to do it this way? This default
> seems to defeat the purpose of service rankings in some way.
>
> Kind regards,
> Jasper
>
> > On 20 Dec 2018, at 11:42, Neil Bartlett  wrote:
> >
> > On Thu, Dec 20, 2018 at 10:18 AM Jasper Simon  <mailto:jasperxsi...@gmail.com>>
> > wrote:
> >
> >> Hi Neil,
> >>
> >> Please excuse my confusing terminology, and thanks for the explanation.
> >> I’ll try to be more clear.
> >>
> >
> > No problem.
> >
> >
> >>
> >> Component A and C provide the same service. B binds to that service.
> >> Because B and C are in the same bundle and that bundle starts before the
> >> bundle containing A, on startup B will bind to the service provided by
> C.
> >>
> >
> > I see, this is much clearer now. Thank you.
> >
> >
> >> B and C are in an external library, so we do not maintain that code.
> >>
> >> How can I make B re-bind the reference, without changing the reference
> >> policy option?
> >
> >
> > As I explained, you can't because this is the very definition of the
> > reluctant policy option.
> >
> > Some aspects of a service reference can be changed through configuration
> > (i.e. using Config Admin). As of OSGi R7, these are limited to the target
> > filter and the minimum cardinality; the policy option cannot be modified
> by
> > config.
> >
> > However this suggests a hacky workaround perhaps. You could use Config
> > Admin to modify the target filter property of the reference in component
> B
> > so that the filter does not match the service from C. For example you
> could
> > use the service.bundleid property like this: `(!(service.bundleid=c))`
> > where `c` is the numeric bundle ID of the bundle containing components B
> > and C. You would have to generate this string programmatically. Bear in
> > mind that the B component would come up initially bound to the service
> from
> > C before your configuration can take effect.
> >
> > It works because you are now making it *impossible* for B to remain bound
> > to the service from C, which is the only time a reluctant reference will
> > re-bind. But it is not very satisfactory and I would strongly recommend
> > trying to adjust the original bundle instead!
> >
> > Neil
> >
> >
> >>
> >>
> >> Kind regards,
> >> Jasper
> >>
> >>
> >>> On 20 Dec 2018, at 10:32, Neil Bartlett  wrote:
> >>>
> >>> Hello Jasper,
> >>>
> >>> Your terminology is confused which makes this very hard to follow.
> >>> Hopefully I have interpreted correctly, see my actual answer below.
> >>>
> >>> On Thu, Dec 20, 2018 at 9:12 AM Jasper Simon 
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I’ve been trying to get my osgi component A bound to another component
> >> B.
> >>>
> >>>
> >>> Components do not bind to components, they bind to services. Those
> >> services
> >>> might be provided by components, or they might not.
> >>>
> >>>
> >>>> B already has a component C of that service bound to it, with default
> >>>> service ranking 0.
> >>>>
> >>>
> >>> So... component A binds to a service provided by component B? And B
> binds
> >>> to a service provided by the component C. Effectively there is a
> chain, A
> >>> -> B -> C? Is that correct? If not, please try to explain more clearly.
> >>>
> >>>
> >>>> For this reference in A, the policy option is reluctant. B and C are
> in
> >

Re: Default reference policy option 'reluctant' stops new service being bound

[Neil Bartlett]

On Thu, Dec 20, 2018 at 10:18 AM Jasper Simon 
wrote:

> Hi Neil,
>
> Please excuse my confusing terminology, and thanks for the explanation.
> I’ll try to be more clear.
>

No problem.


>
> Component A and C provide the same service. B binds to that service.
> Because B and C are in the same bundle and that bundle starts before the
> bundle containing A, on startup B will bind to the service provided by C.
>

I see, this is much clearer now. Thank you.


> B and C are in an external library, so we do not maintain that code.
>
> How can I make B re-bind the reference, without changing the reference
> policy option?


As I explained, you can't because this is the very definition of the
reluctant policy option.

Some aspects of a service reference can be changed through configuration
(i.e. using Config Admin). As of OSGi R7, these are limited to the target
filter and the minimum cardinality; the policy option cannot be modified by
config.

However this suggests a hacky workaround perhaps. You could use Config
Admin to modify the target filter property of the reference in component B
so that the filter does not match the service from C. For example you could
use the service.bundleid property like this: `(!(service.bundleid=c))`
where `c` is the numeric bundle ID of the bundle containing components B
and C. You would have to generate this string programmatically. Bear in
mind that the B component would come up initially bound to the service from
C before your configuration can take effect.

It works because you are now making it *impossible* for B to remain bound
to the service from C, which is the only time a reluctant reference will
re-bind. But it is not very satisfactory and I would strongly recommend
trying to adjust the original bundle instead!

Neil


>
>
> Kind regards,
> Jasper
>
>
> > On 20 Dec 2018, at 10:32, Neil Bartlett  wrote:
> >
> > Hello Jasper,
> >
> > Your terminology is confused which makes this very hard to follow.
> > Hopefully I have interpreted correctly, see my actual answer below.
> >
> > On Thu, Dec 20, 2018 at 9:12 AM Jasper Simon 
> wrote:
> >
> >> Hi,
> >>
> >> I’ve been trying to get my osgi component A bound to another component
> B.
> >
> >
> > Components do not bind to components, they bind to services. Those
> services
> > might be provided by components, or they might not.
> >
> >
> >> B already has a component C of that service bound to it, with default
> >> service ranking 0.
> >>
> >
> > So... component A binds to a service provided by component B? And B binds
> > to a service provided by the component C. Effectively there is a chain, A
> > -> B -> C? Is that correct? If not, please try to explain more clearly.
> >
> >
> >> For this reference in A, the policy option is reluctant. B and C are in
> >> same bundle, A is in another bundle with a higher start level. This
> means
> >> that when the bundle with A is started, B has already bound C and will
> not
> >> bind A, even though it has a higher service ranking.
> >
> >
> > If a component is bound to a service using a reluctant reference, then
> that
> > reference will NOT be re-bound when a higher-ranked service comes along.
> > This is part of the definition of the reluctant policy option, see OSGi
> > Compendium Release 6, section 112.3.7.
> >
> >
> >> In our case, it’s not possible to change the bundles' start order.
> >
> >
> > That's fine, the functionality of your system should not depend on
> > something so unstable as bundle start order.
> >
> > Making the reference policy option greedy is also not possible, as bundle
> >> B/C is imported as a dependency.
> >>
> >
> > This statement does not explain why you cannot make the reference policy
> > greedy. Reference policy has got absolutely nothing to do with bundle
> > dependencies.
> >
> > Neil
> >
> >
> >>
> >> Any thoughts?
> >>
> >> Kind regards,
> >> Jasper
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Default reference policy option 'reluctant' stops new service being bound

[Neil Bartlett]

Hello Jasper,

Your terminology is confused which makes this very hard to follow.
Hopefully I have interpreted correctly, see my actual answer below.

On Thu, Dec 20, 2018 at 9:12 AM Jasper Simon  wrote:

> Hi,
>
> I’ve been trying to get my osgi component A bound to another component B.


Components do not bind to components, they bind to services. Those services
might be provided by components, or they might not.


> B already has a component C of that service bound to it, with default
> service ranking 0.
>

So... component A binds to a service provided by component B? And B binds
to a service provided by the component C. Effectively there is a chain, A
-> B -> C? Is that correct? If not, please try to explain more clearly.


> For this reference in A, the policy option is reluctant. B and C are in
> same bundle, A is in another bundle with a higher start level. This means
> that when the bundle with A is started, B has already bound C and will not
> bind A, even though it has a higher service ranking.


If a component is bound to a service using a reluctant reference, then that
reference will NOT be re-bound when a higher-ranked service comes along.
This is part of the definition of the reluctant policy option, see OSGi
Compendium Release 6, section 112.3.7.


> In our case, it’s not possible to change the bundles' start order.


That's fine, the functionality of your system should not depend on
something so unstable as bundle start order.

Making the reference policy option greedy is also not possible, as bundle
> B/C is imported as a dependency.
>

This statement does not explain why you cannot make the reference policy
greedy. Reference policy has got absolutely nothing to do with bundle
dependencies.

Neil


>
> Any thoughts?
>
> Kind regards,
> Jasper

Re: Bundle inspection command for gogo

[Neil Bartlett]

There is already a bundle command which returns a Bundle object. The
problem is the formatting of that object, which is controlled by
the org.apache.felix.service.command.Converter service.

The implementation class org.apache.felix.gogo.shell.Converters (from the
shell bundle) implements a format method for Bundle objects at the LINE and
PART detail levels, which is why the output of the lb command doesn't look
terrible. It seems to lack an implementation for the INSPECT level however.

Regards,
Neil

On Tue, Nov 13, 2018 at 9:38 AM Todor Boev  wrote:

> Hello,
>
> Can we add a "bundle" command to gogo that will list a readable summary for
> a target bundle?
> Calling BundleContext.getBundle() and looking at the raw object print is
> almost useless.
>
> Also is there any reason this was not done until now?
>
> Regards,
> Todor
>

Re: How to configure LogService

[Neil Bartlett]

Alain: your image was removed by the mailing list manager, I believe.

On Tue, Sep 18, 2018 at 10:27 AM Philipp Höfler <
philipp.hoef...@pernexas.com> wrote:

> Hallo,
>
> @Raymond Auge
> I am using the new OSGi LogService 1.4.
> I’ve extended my small sample app. https://github.com/phhoef/osgi-test
> The problem is basically the same. The log can be written by some
> packages, but my packages are not.
> When the app is running, you can fire a request against my small rest
> service:
> http://localhost:9090/serverInfo?repoName=system1
> The log is written on line 55 of the ServerInfoControllerImpl.java in the
> rest-service bundle.
>
> I am also getting confused by the names. You’re saying it’s Felix logback.
> But on the logback website Felix or Apache is never mentioned. Maybe I am
> just using the wrong dependencies?
>
> @Alain Picard
> Thanks for the overview. Unfortunately, the picture was removed.
> I am the only one having this problem? Would you mind uploading the
> picture and sending the link?.
>
> Thanks for your help,
> Philipp
>
> Von: Alain Picard 
> Antworten an: "users@felix.apache.org" 
> Datum: Dienstag, 18. September 2018 um 10:59
> An: "users@felix.apache.org" 
> Betreff: Re: How to configure LogService
>
> We first struggle to get a good picture of logging and what this Felix
> Logback was doing. So here's a picture that might help. And btw, if our
> understanding is incorrect, please correct us.
>
> [image.png]
>
> On Tue, Sep 18, 2018 at 4:54 AM Raymond Auge  > wrote:
> On Tue, Sep 18, 2018 at 4:42 AM Philipp Höfler <
> philipp.hoef...@pernexas.com>
> wrote:
>
> > Hallo Ray,
> >
> > thanks for your explanation.
> >
> > Based on the new information, I am trying to use Logback.
> > I actually made some progress, but still have one fundamental problem.
> >
> > I added the logback maven dependencies. I found some documentation from
> > you, saying that I also have to add sl4j as dependency.
> > Why is this necessary?
> >
>
> slf4j is just a compile dependency. It's the API "used" by logback.
>
>
> >
> > I set the configurationFile as runproperties and of course I added the
> > configuration file itself:
> > 
> >
> > 
> > 
> > myApp.log
> > true
> > true
> >
> > 
> > %-4relative [%thread] %-5level %logger{35} -
> > %msg%n
> > 
> > 
> >
> > 
> > 
> >
> > 
> >  > name="Events.Service.org.eclipse.osgi"
> level="WARN"/>
> >
> > 
> > 
> >
> > 
> > 
> > 
> > 
> >
> > Here is where the problem starts.
> > I do not get any log entry for any of the three configured packages,
>
> especially of "com.pernexas".
> >
>
> What logging API does it use?
>
>
> > BUT, when I set the root level to DEBUG I do get log entries from several
> > bundles (e.g. jetty). Unfortunately, I do not get any log from
> com.pernexas.
> >
> > I found also your Github project "osgi-to-logback". I am not sure, if
> this
> > is still necessary now, after the release of osgi r7 and new logback?
> > Especially as the project is archived.
> >
>
> That project is no longer valid. It was the basis of the contribution to
> Apache Felix. You should ignore it.
>
>
> >
> > Is it still necessary to add a configuration for a bundle in order to
> > configure the log level through config admin? I was hoping, that this is
> > now done by logback?
> >
>
> When using Felix Logback, I would start by having NO configurations for
> logging besides the logback.xml.
>
> I wonder if it would be possible to share something like a git(hub) project
> with me?
>
> - Ray
>
>
> >
> > Thanks for your patient help.
> > Philipp
> >
> >
> > Am 17.09.18, 15:22 schrieb "Raymond Auge"  >:
> >
> > Philipp,
> >
> > a) you don't need logback, but the Log Service spec doesn't define
> > appenders per say, so you either have to provide your own LogListener
> > implementation, fetch a LogStreamProvider and process the events, or
> > maybe
> > the LogService implementation offers it's own appenders (my
> experience
> > has
> > been that I want everything to land in the same place.)
> > b) you can use configuration admin to configure log levels as per the
> > spec
> > [1] which is to say that you create a configuration using the
> > following PID
> > scheme [2].
> >
> > *Note:* every bundle has it's own LoggerContext (mapped to a
> > configuration
> > PID as described in [2]). There is also a ROOT context which is
> > effectively
> > the fallback for everything (so you could use that as the singular
> > configuration if you like.)
> >
> > Logback support is really to unify all the different logging APIs
> into
> > a
> > single backend because the stark reality is that you will encounter
> > other
> > logging APIs 

Re: How to investigate a "Unsatisfied" reference with felix.scr ?

[Neil Bartlett]

  Reference: EventAdminService
>> Interface Name: org.osgi.service.event.EventAdmin
>> Cardinality: 1..1
>> Policy: static
>> Policy option: reluctant
>> Reference Scope: bundle
>>   Reference: PreferencesService
>> Interface Name: org.osgi.service.prefs.PreferencesService
>> Cardinality: 1..1
>> Policy: static
>> Policy option: reluctant
>> Reference Scope: bundle
>>   Component Description Properties:
>>   Component Configuration:
>> ComponentId: 0
>> State: unsatisfied reference
>> SatisfiedReference: ConfigurationAdmin
>>   Target: null
>>   (unbound)
>> SatisfiedReference: PreferencesService
>>   Target: null
>>   (unbound)
>> UnsatisfiedReference: EventAdminService
>>   Target: null
>>   (no target services)
>> Component Configuration Properties:
>> component.id = 0
>> component.name = c8tech.osgi.lib.cm.internal.Co
>> mponentProviderConfigurationExtendedService
>>
>
> thanks to all,
>
> Cristiano
>
>
>
> On 11/07/2018 15:21, Neil Bartlett wrote:
>
>> Indeed this cannot be the scr:info command from Felix SCR, because the
>> Felix command requires an argument (the component ID) and would have
>> failed
>> when called without one.
>>
>> Perhaps a bundle listing would help us identify what you are working with.
>>
>> Neil
>>
>>
>>
>

Re: How to investigate a "Unsatisfied" reference with felix.scr ?

[Neil Bartlett]

Indeed this cannot be the scr:info command from Felix SCR, because the
Felix command requires an argument (the component ID) and would have failed
when called without one.

Perhaps a bundle listing would help us identify what you are working with.

Neil


On Wed, 11 Jul 2018 at 18:28, David Jencks  wrote:

> Hi Cristiano,
>
> That doesn’t look much like what I recall my version of scr:info produced,
> I’d expect better indenting and a ComponentConfiguration section following,
> and the ComponentConfiguration ought to list the references defined in the
> component xml.  Are you sure that you are actually using felix ds and that
> the scr:info command you use actually comes from felix? What is in the
> “equinox compendium” you mention?
>
> Did anyone significantly change how scr:info works?
>
> thanks
> david jencks
>
> > On Jul 11, 2018, at 9:51 AM, Cristiano  wrote:
> >
> > Hi David,  thanks for the time...
> >
> > Unfortunately, there are no enough information provided by scr:info in
> order to help identify what is happen with this immediate component.
> >
> > Below is what I'm seeing:
> >
> >> g! scr:info
> c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider
> >> Component Description:
> c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider
> >>
> 
> >> Class:
> c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider
> >> Bundle:1 (br.com.c8tech.osgi.lib.cm:0.1.1.SNAPSHOT)
> >> Enabled:   true
> >> Immediate: true
> >> Services: [c8tech.osgi.lib.api.cm.ConfigurationAdminExtendedService]
> >> Scope: singleton
> >> Config PID(s):
> [c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider],
> Policy: optional
> >> Base Props:(0 entries)
> >
> > best regards,
> >
> > Cristiano
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Resolving to micro version

[Neil Bartlett]

Thank you, now the answer is clear.

You can see that the lower version of rbl-osgi (bundle ID 9) has zero
active exports, and it is importing the package com.basistech.rbl.osgi from
the higher version of itself. This is because rbl-osgi has both an import
and an export of that package. When this happens, OSGi chooses either the
import OR the export to be active, but never both. When the higher version
is present, the export of the lower version is hidden. This is why bundle
13 does not resolve: because of its tight import range, there is no
matching export.

Like Ray, I think that your tight import range in bundle 13 is wrong. You
should not have semantic differences at the level of the micro version.
However if you really, really need such a tight range then you should also
use the same tight range on the import from bundle rbl-osgi.

Regards,
Neil



On Wed, Apr 4, 2018 at 1:04 PM, Katsuya Tomioka <katsuya.tomi...@gmail.com>
wrote:

> Thanks for the explanation. The narrow import range is intentional, I
> manually set the import in bnd (via bnd-maven-pugin) to satisfy functional
> requirements; I need to consume the version specifically. The runtime
> currently happened to have both versions of the component.
>
>
> g! inspect cap osgi.wiring.package 9
>08:01:30
> rbl-osgi [9] provides:
> --
> osgi.wiring.package [EMPTY]
> g! inspect cap osgi.wiring.package 10
> 08:01:49
> rbl-osgi [10] provides:
> ---
> osgi.wiring.package; com.basistech.rbl.osgi 7.24.104.c592 required by:
>rbl-osgi [9]
> g! inspect req osgi.wiring.package 13
> 08:01:57
> Bundle 13 is not resolved.
>
> Thanks,
> -Katsuya
>
>
> On Tue, Apr 3, 2018 at 11:58 PM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
>
> > What Ray said is absolutely true, but I don’t think it actually explains
> > the problem. As far as I can tell, the range should actually catch the
> > export from the "rbl-osgi (7.24.0.c592)” bundle.
> >
> > Katsuya-san: just to be sure, please type the following commands and send
> > the output:
> >
> > inspect cap osgi.wiring.package 9
> > inspect cap osgi.wiring.package 10
> > inspect req osgi.wiring.package 13
> >
> > Regards,
> > Neil
> >
> >
> >
> > > On 4 Apr 2018, at 03:39, Raymond Auge <raymond.a...@liferay.com>
> wrote:
> > >
> > > I think that, as James was alluding to, your problem is in the package
> > > import range you stated in your original message:
> > >
> > > "[7.24.0,7.24.1)"
> > >
> > > Do you know how the import range came to be so narrow? Typically the
> > range
> > > is something like
> > >
> > > "[7.24.0,7.25.0)"
> > >
> > > Perhaps the import policy was altered?
> > >
> > > - Ray
> > >
> > >
> > > On Tue, Apr 3, 2018, 19:10 Katsuya Tomioka, <katsuya.tomi...@gmail.com
> >
> > > wrote:
> > >
> > >> Thanks for the reply. I hugely omitted details, I realized.
> > >>
> > >>
> > >> This is the error from gogo with felix 5.6.10:
> > >>
> > >> ERROR: Bundle rex-osgi [13] Error starting file:/Users/kt/work/felix/
> > >>
> > >> felix-framework-5.6.10/bundle/com.basistech.rex-je-rex-osgi-
> > 7.33.101.c59.2.jar
> > >> (org.osgi.framework.BundleException: Unable to resolve rex-osgi
> [13](R
> > >> 13.0): missing requirement [rex-osgi [13](R 13.0)]
> osgi.wiring.package;
> > >>
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > 7.24.0)(!(version>=7.24.1)))
> > >> Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package;
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > >> 7.24.0)(!(version>=7.24.1)))])
> > >> org.osgi.framework.BundleException: Unable to resolve rex-osgi [13](R
> > >> 13.0): missing requirement [rex-osgi [13](R 13.0)]
> osgi.wiring.package;
> > >>
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > 7.24.0)(!(version>=7.24.1)))
> > >> Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package;
> > >> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
> > >> 7.24.0)(!(version>=7.24.1)))]
> > >> at org.apache.felix.framework.Felix.resolveBundleRevision(
> > Felix.java:4149)

Re: Resolving to micro version

[Neil Bartlett]

What Ray said is absolutely true, but I don’t think it actually explains the 
problem. As far as I can tell, the range should actually catch the export from 
the "rbl-osgi (7.24.0.c592)” bundle.

Katsuya-san: just to be sure, please type the following commands and send the 
output:

inspect cap osgi.wiring.package 9
inspect cap osgi.wiring.package 10
inspect req osgi.wiring.package 13

Regards,
Neil



> On 4 Apr 2018, at 03:39, Raymond Auge <raymond.a...@liferay.com> wrote:
> 
> I think that, as James was alluding to, your problem is in the package
> import range you stated in your original message:
> 
> "[7.24.0,7.24.1)"
> 
> Do you know how the import range came to be so narrow? Typically the range
> is something like
> 
> "[7.24.0,7.25.0)"
> 
> Perhaps the import policy was altered?
> 
> - Ray
> 
> 
> On Tue, Apr 3, 2018, 19:10 Katsuya Tomioka, <katsuya.tomi...@gmail.com>
> wrote:
> 
>> Thanks for the reply. I hugely omitted details, I realized.
>> 
>> 
>> This is the error from gogo with felix 5.6.10:
>> 
>> ERROR: Bundle rex-osgi [13] Error starting file:/Users/kt/work/felix/
>> 
>> felix-framework-5.6.10/bundle/com.basistech.rex-je-rex-osgi-7.33.101.c59.2.jar
>> (org.osgi.framework.BundleException: Unable to resolve rex-osgi [13](R
>> 13.0): missing requirement [rex-osgi [13](R 13.0)] osgi.wiring.package;
>> 
>> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=7.24.0)(!(version>=7.24.1)))
>> Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package;
>> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
>> 7.24.0)(!(version>=7.24.1)))])
>> org.osgi.framework.BundleException: Unable to resolve rex-osgi [13](R
>> 13.0): missing requirement [rex-osgi [13](R 13.0)] osgi.wiring.package;
>> 
>> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=7.24.0)(!(version>=7.24.1)))
>> Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package;
>> (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=
>> 7.24.0)(!(version>=7.24.1)))]
>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:2119)
>> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373)
>> at org.apache.felix.framework.FrameworkStartLevelImpl.run(
>> FrameworkStartLevelImpl.java:308)
>> 
>> The package is used in component interface.
>> 
>> lb of exporting (component) bundles:
>>9|Active |1|rbl-osgi (7.24.0.c592)|7.24.0.c592
>>   10|Active |1|rbl-osgi (7.24.104.c592)|7.24.104.c592
>> 
>> scr:list lists two components (one for each bundle):
>> [   9]   com.basistech.rbl.osgi.impl.BlComponentService  enabled
>>[   1] [satisfied   ]
>> ...
>> 
>> g! inspect cap service 9 (correct one)
>> rbl-osgi [9] provides:
>> --
>> service; com.basistech.rbl.osgi.RblRosetteComponentService with properties:
>> ...
>> 
>> I can see the same thing for the bundle 10.
>> [  10]   com.basistech.rbl.osgi.impl.BlComponentService  enabled
>>[   5] [satisfied   ]
>> 
>> 
>> Export:
>>  com.basistech.rbl.osgi {version=7.24.0.c592}
>> 
>> (from 7.24.104)
>>  com.basistech.rbl.osgi {version=7.24.104.c592}
>> 
>> Importing side:
>>  com.basistech.rbl.osgi {version=[7.24.0,7.24.1)}
>> 
>> 
>> On Tue, Apr 3, 2018 at 5:27 PM, Neil Bartlett <njbartl...@gmail.com>
>> wrote:
>> 
>>> 
>>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <katsuya.tomi...@gmail.com>
>>> wrote:
>>>> 
>>>> Felix users,
>>>> 
>>>> I have same bundles (say "A") installed only different by micro
>> versions,
>>>> 7.24.0 and 7.24.100. I have then another ("B") imports packages from
>> "A"
>>>> such that: "[7.24.0,7.24.1)". This works fine if I installed 7.24.0
>> only.
>>>> But soon as 7.24.100 installed, the bundle B fails to resolve with
>>>> unresolved requirements.
>>>> 
>>>> Would that be possible to resolve the bundle B even with both versions
>>> of A
>>>> installed? Or is even allowed in the spec?
>>> 
>>> This is definitely possible.
>>> 
>>> Please post the actual error message so that we can work out what is
>>> happening. It would also be helpful to see:
>>> 
>>> * the list of bundles;
>>> * the exact exports of the “A” bundles, and;
>>> * the exact imports of the “B” bundle.
>>> 
>>> Regards,
>>> Neil
>>> 
>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> -Katsuya
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Resolving to micro version

[Neil Bartlett]

> On 3 Apr 2018, at 22:17, Katsuya Tomioka  wrote:
> 
> Felix users,
> 
> I have same bundles (say "A") installed only different by micro versions,
> 7.24.0 and 7.24.100. I have then another ("B") imports packages from "A"
> such that: "[7.24.0,7.24.1)". This works fine if I installed 7.24.0 only.
> But soon as 7.24.100 installed, the bundle B fails to resolve with
> unresolved requirements.
> 
> Would that be possible to resolve the bundle B even with both versions of A
> installed? Or is even allowed in the spec?

This is definitely possible.

Please post the actual error message so that we can work out what is happening. 
It would also be helpful to see:

* the list of bundles;
* the exact exports of the “A” bundles, and;
* the exact imports of the “B” bundle.

Regards,
Neil


> 
> Thanks,
> 
> -Katsuya


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Can you make the maven bundle plugin use maven version ranges?

[Neil Bartlett]

I agree that Martin has probably done the right thing... even having tested
the various versions, which is above and beyond what most developers would
bother to do.

My criticism is aimed at the Wicket developers who have misused versions
and forced Martin to do all this extra work!

Regards,
Neil

On Fri, Mar 9, 2018 at 5:57 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> On this case I agree with Martin, there's a decision to be made to either
> violate DRY or SEMANTIC versioning.. For me DRY wins over SEMANTIC as he
> would have to 99.999% equal project with the only thing different being the
> wicket version.
>
>
> regards Nino
>
> On Thu, Mar 8, 2018 at 9:56 PM, Martin Nielsen <mny...@gmail.com> wrote:
>
> > I know its not exactly bulletproof, but i do have a pax exam test each
> > wicket major version so it is tested against wicket 6-8 on each build.
> >
> > But i agree that it is poisonous on large projects, but in this case it
> is
> > narrow and testable and i don't want to lock the plugin to a specific
> > wicket version if I dont have to.
> >
> > Concerning major versions in maven it is true that a major version
> signals
> > an api break somewhere, but if it isn't a part I use I think it should be
> > ok.
> >
> > Thanks alot for your swift help and input:)
> >
> > On 8 Mar 2018 19:05, "Raymond Auge" <raymond.a...@liferay.com> wrote:
> >
> > I concede the point! :)
> >
> > - Ray
> >
> >
> > On Thu, Mar 8, 2018 at 12:49 PM, Neil Bartlett <njbartl...@gmail.com>
> > wrote:
> >
> > > You don't actually have to duplicate anything. The lower bound appears
> in
> > > two places but that can be handled with a property:
> > >
> > > 
> > > 6.0.0
> > > 
> > >
> > > ...
> > >
> > > 
> > >     ...
> > > ${wicket.base.version}
> > > 
> > >
> > > ...
> > >
> > > org.apache.wicket.*; version="[${wicket.base.version},
> > 9)"
> > >
> > >
> > >
> > > On Thu, Mar 8, 2018 at 4:43 PM, Raymond Auge <raymond.a...@liferay.com
> >
> > > wrote:
> > >
> > > > On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett <njbartl...@gmail.com
> >
> > > > wrote:
> > > >
> > > > > If you're going to do this I would recommend instead building
> against
> > > the
> > > > > floor version 6.0.0 (i.e. 6.0.0 in the
> dependency
> > > > > section of the pom) and overriding the Import-Package with a
> simpler
> > > rule
> > > > > as follows:
> > > > >
> > > > > 
> > > > > org.apache.wicket.*; version="[6, 9)"
> > > > > 
> > > > >
> > > > > Building against version 6 will ensure that you do not accidentally
> > use
> > > > > bits of API from Wicket 7+ in your code, which could then result in
> > > > errors
> > > > > like NoSuchMethodError, making your users sad.
> > > > >
> > > >
> > > > The problem with that is that you have to maintain duplicate
> > information
> > > > about the upper bound, while with my solution you can forget the
> > package
> > > > import configuration and just adjust the pom's dependency.
> > > >
> > > > You are of course _assuming_ about the compatibility.
> > > >
> > > > So you have the two options:
> > > >
> > > > 1) Neil - compile against a concrete floor AND have to duplicate the
> > > > information manually
> > > > 2) Ray - compile against the latest, have the information not be
> dup'd,
> > > BUT
> > > > assume backward compatibility
> > > >
> > > > Pick your poison.
> > > >
> > > > We already determined that there is devils in the details w.r.t. the
> > fact
> > > > that Wicket is not semantically versioned.
> > > >
> > > > - Ray
> > > >
> > > >
> > > > > Neil
> > > > >
> > > > > On Thu, Mar 8, 2018 at 4:24 PM, Raymond Auge <
> > raymond.a...@liferay.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Totally +1 what Neil said.
> > > > > >
> > > > > > However there is one work around you can take if you really want
> to
>

Re: Can you make the maven bundle plugin use maven version ranges?

[Neil Bartlett]

You don't actually have to duplicate anything. The lower bound appears in
two places but that can be handled with a property:


6.0.0


...


...
${wicket.base.version}


...

org.apache.wicket.*; version="[${wicket.base.version}, 9)"



On Thu, Mar 8, 2018 at 4:43 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:

> On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
>
> > If you're going to do this I would recommend instead building against the
> > floor version 6.0.0 (i.e. 6.0.0 in the dependency
> > section of the pom) and overriding the Import-Package with a simpler rule
> > as follows:
> >
> > 
> > org.apache.wicket.*; version="[6, 9)"
> > 
> >
> > Building against version 6 will ensure that you do not accidentally use
> > bits of API from Wicket 7+ in your code, which could then result in
> errors
> > like NoSuchMethodError, making your users sad.
> >
>
> The problem with that is that you have to maintain duplicate information
> about the upper bound, while with my solution you can forget the package
> import configuration and just adjust the pom's dependency.
>
> You are of course _assuming_ about the compatibility.
>
> So you have the two options:
>
> 1) Neil - compile against a concrete floor AND have to duplicate the
> information manually
> 2) Ray - compile against the latest, have the information not be dup'd, BUT
> assume backward compatibility
>
> Pick your poison.
>
> We already determined that there is devils in the details w.r.t. the fact
> that Wicket is not semantically versioned.
>
> - Ray
>
>
> > Neil
> >
> > On Thu, Mar 8, 2018 at 4:24 PM, Raymond Auge <raymond.a...@liferay.com>
> > wrote:
> >
> > > Totally +1 what Neil said.
> > >
> > > However there is one work around you can take if you really want to
> open
> > > yourself up like that...
> > >
> > > http://bnd.bndtools.org/macros/range.html
> > >
> > > Specifically applied like so:
> > >
> > > Import-Package: org.apache.wicket.*; version="${range;[6,+)}", *
> > >
> > > This means use literal '6' as the floor, but increment the ceiling to
> > > the next MAJOR version
> > > above what's found on the classpath.
> > >
> > > i.e. if you compiled against 8 then the result would be "[6,8)"
> > >
> > >
> > > The one caveat is I'm not sure how well bnd's macros are handle using
> > > the maven-bundle-plugin but you could just try to see what happens
> > >
> > > - Ray
> > >
> > >
> > >
> > > On Thu, Mar 8, 2018 at 11:14 AM, Neil Bartlett <njbartl...@gmail.com>
> > > wrote:
> > >
> > > > Bnd (and by extension the maven-bundle-plugin) uses semantic versions
> > to
> > > > infer import ranges, based on the actual version that was compiled
> > > against.
> > > > If you build against version 8.0.0 of an API then we have no way to
> > know
> > > > that you are also compatible with versions 7.0.0 and 6.0.0.
> > > >
> > > > In fact it would be a violation of semantic versioning if major
> > versions
> > > > 6.0.0 through 8.0.0 were actually backwards compatible.
> > > >
> > > > It's my understanding that most Maven users consider build-time
> version
> > > > ranges to be a bad practice, because your build output could vary
> > wildly
> > > > depending on the content of your local repository. See "Should Maven
> > > > dependency version ranges be considered deprecated?"[1]
> > > >
> > > > Regards,
> > > > Neil
> > > >
> > > >
> > > > [1]
> > > > https://stackoverflow.com/questions/7167250/should-
> > > > maven-dependency-version-ranges-be-considered-deprecated
> > > >
> > > > On Thu, Mar 8, 2018 at 4:05 PM, Martin Nielsen <mny...@gmail.com>
> > wrote:
> > > >
> > > > > Hello everyone.
> > > > >
> > > > > I am trying to make the Maven Bundle Plugin use a version range i
> > have
> > > > > defined in the POM of my project.
> > > > > Basically a project of mine has a small wicket module which i know
> > > works
> > > > > through wicket 6-8. So i have defined the following dependency:
> > > > >
> > > > > 
> > > > >   org.

Re: Can you make the maven bundle plugin use maven version ranges?

[Neil Bartlett]

Bnd (and by extension the maven-bundle-plugin) uses semantic versions to
infer import ranges, based on the actual version that was compiled against.
If you build against version 8.0.0 of an API then we have no way to know
that you are also compatible with versions 7.0.0 and 6.0.0.

In fact it would be a violation of semantic versioning if major versions
6.0.0 through 8.0.0 were actually backwards compatible.

It's my understanding that most Maven users consider build-time version
ranges to be a bad practice, because your build output could vary wildly
depending on the content of your local repository. See "Should Maven
dependency version ranges be considered deprecated?"[1]

Regards,
Neil


[1]
https://stackoverflow.com/questions/7167250/should-maven-dependency-version-ranges-be-considered-deprecated

On Thu, Mar 8, 2018 at 4:05 PM, Martin Nielsen  wrote:

> Hello everyone.
>
> I am trying to make the Maven Bundle Plugin use a version range i have
> defined in the POM of my project.
> Basically a project of mine has a small wicket module which i know works
> through wicket 6-8. So i have defined the following dependency:
>
> 
>   org.apache.wicket
>   wicket-core
>   [6.0.0,9.0.0)
>   provided
> 
>
> The problem is that the Maven Bundle Plugin doesn't seem to care all that
> much, and i get the following dependency in the manifest:
>
> org.apache.wicket;version="[8.0,9)",org.apache.wicket.ajax;
> version="[8.0,9)",org.apache.wicket.ajax.form;version="[8.
> 0,9)",org.apache.wicket.behavior;version="[8.0,9)",
> org.apache.wicket.markup.html;version="[8.0,9)",org.apache.
> wicket.markup.html.basic;version="[8.0,9)",org.apache.
> wicket.markup.html.form;version="[8.0,9)",org.apache.
> wicket.markup.html.list;version="[8.0,9)",org.apache.
> wicket.markup.html.panel;version="[8.0,9)",org.apache.
> wicket.model;version="[8.0,9)",org.apache.wicket.model.util;
> version="[8.0,9)",org.apache.wicket.request.mapper.
> parameter;version="[8.0,9)",org.apache.wicket.util.string;
> version="[8.0,9)"
>
> My intent was to get a version range matching the maven range, but it seems
> that the Bundle Plugin just looks at the artifact which was actually
> resolved and uses that, which ends up being [8.0,9).
>
> Is there a way to make the Bundle Plugin parse the POM version range, or is
> there a fairly none-intrusive way to specify the version for all those
> packages?
>
>
> Thank you
> -Martin
>

Re: Re[2]: Replace ResourceServlet

[Neil Bartlett]

On Tue, Feb 13, 2018 at 11:32 AM, Thomas Driessen <
thomas.driessen...@gmail.com> wrote:

> Hi,
>
> @Karl: I tried this but it didn't work. Still the resource servlet got all
> requests for .css files.
>
> @Ray: I am already using the whiteboard for servlets. Is there a way to
> use the whiteboard for resources as well?
>


See OSGi Compendium R6 Specification, section 140.6 "Registering Resources".



>
> My current solution now involves a service that listens if there is any UI
> in debug mode, if so unregisters all resources and registers a
> VaadinServlet under //VAADIN/*
>
> I still would have thought that there is an easier way to replace this
> default resource servlet.
>
> Kind regards,
> Thomas
>
> -- Originalnachricht --
> Von: "Raymond Auge" 
> An: "felix users" 
> Cc: "Thomas Driessen" 
> Gesendet: 12.02.2018 22:51:01
> Betreff: Re: Replace ResourceServlet
>
>
> I feel like you'd be having way more fun if you bumped up to using Http
>> Whiteboard.
>>
>> Sincerely,
>> - Ray
>>
>> On Mon, Feb 12, 2018 at 4:41 PM, Karl Pauls  wrote:
>>
>> On Mon, Feb 12, 2018 at 4:22 PM, Thomas Driessen
>>>  wrote:
>>> > Hi,
>>> >
>>> > I'm currently trying to get Vaadin to work within OSGi and for this
>>> purpose
>>> > I'm using felix http as webserver.
>>> >
>>> > My current setup looks like this:
>>> > I have a ResourceTracker that tracks all themes/widgetsets/resources
>>> and
>>> > registers them according to the Vaadin scheme as resources via:
>>> >
>>> >
>>> > http.registerResources("/vaadin-8.2.1/VAADIN/path/to/resource",
>>> > "/VAADIN/path/to/resource", new MySpecialContext());
>>> >
>>> > This works fine for production mode where all scss files are compiled
>>> to
>>> > css.
>>> >
>>> > The problem is in debug mode, where Vaadin offers an on-the-fly
>>> compilation
>>> > from scss to css. For this purpose Vaadin states one should register a
>>> > VaadinServlet under "/VAADIN/*" (or "/vaadin-8.2.1/VAADIN/*" in an OSGi
>>> > context) that takes care of compiling scss files on the fly if the
>>> > corresponding css files can not be found.
>>> >
>>> > The problem is:
>>> >
>>> > When I register a Vaadin servlet under "/vaadin-8.2.1/VAADIN/*" then
>>> this
>>> > servlet is never used.
>>>
>>> I might not remember correctly but IIRC, you are not supposed to put a
>>> "/*" at the end of the alias. Can you try to register the servlet with
>>> an alias of: "/vaadin-8.2.1/VAADIN" and see if that works?
>>>
>>> regards,
>>>
>>> Karl
>>>
>>> > Requests to
>>> > "localhost:8080/vaadin-8.2.1/VAADIN/path/to/resource" are still
>>> handled
>>> by a
>>> > ResourceServlet (DefaultServlet?) which, of course, is not able to find
>>> the
>>> > non-existent css files.
>>> >
>>> > Is there a way to tell felix http to  use a custom servlet instead of
>>> its
>>> > default resource servlet?
>>> >
>>> > Kind regards,
>>> > Thomas
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpa...@gmail.com
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>>
>>>
>>
>> --
>> *Raymond Augé* 
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Felix Useradmin as service factory

[Neil Bartlett]

I can't think of a way. If a bundle does not provide a service as a
bundle-scope or prototype-scope service, you cannot force it to provide
multiple implementations.

You could go down the subsystems route in order to get multiple copies of
the UserAdmin bundle installed into the framework. Maybe you should
consider that as a high-level solution for what sounds like a multi-tenant
application... but it's very heavyweight if all you want is multiple copies
of a single service.

Neil

On Tue, Feb 13, 2018 at 11:13 AM, David Leangen  wrote:

>
> Hi!
>
> Although my question is probably a more general OSGi question, I thought I
> would try here first, as it is related to the Felix Useradmin…
>
> I intend to use multiple instances of the Useradmin. The reason is because
> I want to host multiple (small) enterprise customers in one installation,
> but I want to ensure safe segregation of user data. The spec seems to imply
> that there is only one Useradmin, yet I do not see anything in the spec
> that prohibits multiple instances of the service.
>
> In the Felix implementation, it is provided as a service singleton. In
> order to do what I want, I ended up embedding the felix implementation in
> my own bundle and wrapped it with a DS service factory component.
>
>
> I don’t like depending on the implementation code.
>
>
> Is there a better way?
>
>
> Cheers,
> =David
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: How to find the provider of a gogo command?

[Neil Bartlett]

There isn't a one to one mapping of scopes to bundles. Multiple bundles can
contribute commands into the same scope. To get down to the individual
bundle and service you need to inspect the low level service properties.

Neil.

On 10 Jan 2018 2:18 pm, "Erwin Hogeweg" <erwin.hoge...@seecago.com> wrote:

> Hi Derek,
>
> Cool thanks,
>
> g! type -a list
> list is void obr:list(boolean, String[])
> list is void scr:list(String)
> list is void scr:list()
> true
>
> That shows the scopes, not necessarily the bundle that implements the
> command though.
>
> Erwin
>
>
>
> On Jan 10, 2018, at 09:05, Derek Baum <de...@baums.org.uk<mailto:der
> e...@baums.org.uk>> wrote:
>
> You can also use the gogo 'type' command (which is modelled on the bash
> command of the same name):
>
>
>
> g! type --help
> type - show command type
> Usage: type [OPTIONS] [name[:]]
>  -a --all show all matches
>  -? --helpshow help
>  -q --quiet   don't print anything, just return status
>  -s --scope=NAME  list all commands in named scope
>  -t --types   show full java type names
> true
> g! type cd
> cd is void gogo:cd(CommandSession, String[])
> true
> g! type -a cd
> cd is void gogo:cd(CommandSession, String[])
> cd is File felix:cd(CommandSession, String)
> cd is File felix:cd(CommandSession)
> true
> g! type -t cd
> void org.apache.felix.gogo.jline.Posix._main(CommandSession, String[])
> true
>
>
> --
> Derek
>
>
> On 10 Jan 2018, at 13:56, Neil Bartlett <njbartl...@gmail.com jbartl...@gmail.com>> wrote:
>
> You can use the "inspect cap service" command and search for services with
> a property of "osgi.command.function" containing the command name you are
> looking for.
>
> Note that all of the duplicates you have shown are just overloaded methods.
> For example "cd" with no parameters prints the current directory whereas
> "cd " changes to the specified directory.
>
> Neil
>
> On Wed, Jan 10, 2018 at 1:52 PM, Erwin Hogeweg <erwin.hoge...@seecago.com<
> mailto:erwin.hoge...@seecago.com>>
> wrote:
>
> Hi,
>
> Is there a way to find out which bundle/component provides a certain gogo
> command?
>
> When I type help I see a couple of duplicates (see below), and I am trying
> to find out if I have a configuration problem or not.
>
> The framework is equinox with felix gogo and scr.
>
> Thanks,
>
> Erwin
>
>
> id State   Bundle
> 0 ACTIVE  org.eclipse.osgi_3.10.2.v20150203-1939
>   Fragments=5
> 1 ACTIVE  org.apache.felix.gogo.command_0.16.0
> 2 ACTIVE  org.apache.felix.gogo.runtime_0.16.2
> 3 ACTIVE  org.apache.felix.gogo.shell_0.12.0
> 8 ACTIVE  org.apache.felix.eventadmin_1.4.6
> 9 ACTIVE  org.apache.felix.scr_2.0.8
> 10 ACTIVE  org.apache.felix.configadmin_1.8.14
> 11 ACTIVE  org.apache.felix.fileinstall_3.5.4
>
>
> list - List component configurations of a specific bundle
>  scope: scr
>  parameters:
> String   Symbolic name or ID of the bundle
>
> list - List all component configurations
>  scope: scr
>
> up - Update the specified bundle from the specified location
>  scope: equinox
>  parameters:
> Bundle   Bundle to update
> URL   Location of the new bundle content
>
> up - update the specified bundle(s)
>  scope: equinox
>  parameters:
> Bundle[]   bundle(s) to update
>
> cd - change current directory
>  scope: felix
>  parameters:
> String   target directory
>
> cd - get current directory
>  scope: felix
>
>
> Erwin Hogeweg
> CTO
> 3690 Airport Road
> Boca Raton, FL 33431
> P. +1 (954) 556-6565
> M. +1 (561) 306-7395
> F. +1 (561) 948-2730
> [Seecago]<http://www.seecago.com>
>
>
>
> Erwin Hogeweg
> CTO
> 3690 Airport Road
> Boca Raton, FL 33431
> P. +1 (954) 556-6565
> M. +1 (561) 306-7395
> F. +1 (561) 948-2730
> [Seecago]<http://www.seecago.com>
>

Re: How to find the provider of a gogo command?

[Neil Bartlett]

You can use the "inspect cap service" command and search for services with
a property of "osgi.command.function" containing the command name you are
looking for.

Note that all of the duplicates you have shown are just overloaded methods.
For example "cd" with no parameters prints the current directory whereas
"cd " changes to the specified directory.

Neil

On Wed, Jan 10, 2018 at 1:52 PM, Erwin Hogeweg 
wrote:

> Hi,
>
> Is there a way to find out which bundle/component provides a certain gogo
> command?
>
> When I type help I see a couple of duplicates (see below), and I am trying
> to find out if I have a configuration problem or not.
>
> The framework is equinox with felix gogo and scr.
>
> Thanks,
>
> Erwin
>
>
> id State   Bundle
> 0 ACTIVE  org.eclipse.osgi_3.10.2.v20150203-1939
> Fragments=5
> 1 ACTIVE  org.apache.felix.gogo.command_0.16.0
> 2 ACTIVE  org.apache.felix.gogo.runtime_0.16.2
> 3 ACTIVE  org.apache.felix.gogo.shell_0.12.0
> 8 ACTIVE  org.apache.felix.eventadmin_1.4.6
> 9 ACTIVE  org.apache.felix.scr_2.0.8
> 10 ACTIVE  org.apache.felix.configadmin_1.8.14
> 11 ACTIVE  org.apache.felix.fileinstall_3.5.4
>
>
> list - List component configurations of a specific bundle
>scope: scr
>parameters:
>   String   Symbolic name or ID of the bundle
>
> list - List all component configurations
>scope: scr
>
> up - Update the specified bundle from the specified location
>scope: equinox
>parameters:
>   Bundle   Bundle to update
>   URL   Location of the new bundle content
>
> up - update the specified bundle(s)
>scope: equinox
>parameters:
>   Bundle[]   bundle(s) to update
>
> cd - change current directory
>scope: felix
>parameters:
>   String   target directory
>
> cd - get current directory
>scope: felix
>
>
> Erwin Hogeweg
> CTO
> 3690 Airport Road
> Boca Raton, FL 33431
> P. +1 (954) 556-6565
> M. +1 (561) 306-7395
> F. +1 (561) 948-2730
> [Seecago]
>

Re: Adding service programmatically so SCR sees it

[Neil Bartlett]

The SCR commands are only aware of Components, as defined by the DS
specification.

When you register a service using BundleContext#registerService, what you
have created is not a Component, but only an entry in the service registry.
Not all services are component and, incidentally, not all components
provide services.

The command you are looking for is "inspect". You can use this to list the
provided services of bundle id N by typing:

inspect cap service N

Where 'cap' is short for 'capability', i.e. provided rather than consumed.
If you omit the bundle id then it will list all services of all bundles...
there will be a lot.

Neil

On Wed, Jan 10, 2018 at 11:41 AM, Thomas Driessen <
thomas.driessen...@gmail.com> wrote:

> Hi,
>
> I had to write my own extender and am adding services via
>
> bundleContext.registerService(...)
>
> When I type "list" into gogo shell, these services are not listed.
> As the "list" command is provided by SCR I guess that SCR must be made
> aware of my service in order to list it.
>
> Is there a way to make SCR aware of services that I registered
> programmatically?
>
> If not, are there other commands to get a list of registered services?
>
> Kind regards,
> Thomas

Re: Override Require-Capability in Maven-Bundle-Plugin

[Neil Bartlett]

From your StackOverflow post it seems that the unsatisfied requirement is this 
one:

[caused by: Unable to resolve 
com.javatechnics.jpa.simple/1.0.0.SNAPSHOT: missing requirement 
[com.javatechnics.jpa.simple/1.0.0.SNAPSHOT] osgi.service; 
objectClass=javax.persistence.spi.PersistenceProvider; 
javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;
 effective:=active]]

If you *know* that a bundle, let’s call it xyz, provides the 
PersistenceProvider service then you can write one additional bundle that 
simply does this:

Require-Bundle: xyz
Provide-Capability: osgi.service;
objectClass=javax.persistence.spi.PersistenceProvider;

javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;
effective:=active

This effectively augments the the provider bundle with the capability that is 
needed. It’s still a hack but it’s IMHO a little cleaner than removing a 
requirement from a bundle that actually still has that requirement.

Regards,
Neil

> On 13 Dec 2017, at 12:19, Kerry <karaf-u...@avionicengineers.com> wrote:
> 
> David,
> 
> Thanks for taking a look. As you and Neil Bartlett have said, my work around 
> isn't the correct solution and I perhaps have to accept that I cannot achieve 
> my desired result.
> 
> I think this is because in part persistence units  don't have OSGi in mind so 
> don't place nice with it? I'm possibly trying to shoe-horn the proverbial 
> round peg into a square hole. Wherever those headers are being generated they 
> are required but the feature resolver is not quite clever enough to work out 
> that I am truly providing everything in my feature? I might be too hard on 
> the resolver here as it is likely that resolving dependencies is not as easy 
> as I am imagining.
> 
> I'll dig around a bit further but one solution is to provide separate 
> features and have to install them in a specific order. ( Not good either)
> 
> Kerry
> 
> ⁣Sent from BlueMail ​
> 
> On 12 Dec 2017, 23:22, at 23:22, David Jencks <david.a.jen...@gmail.com> 
> wrote:
>> Kerry,
>> 
>> I looked at your project and since you are not using any DS components
>> what I suggested does not apply.  I have no idea where the generated
>> capabilities/requirement headers are coming from.
>> 
>> In general I think it is worth expending considerable effort to
>> straighten out the capabilities/requirements wiring so it works
>> properly rather than trying to provide non-standard workarounds that
>> disable it and may have further unwanted side effects.
>> 
>> The obvious question is whether the openjpa feature includes a bundle
>> with a Provide-Capability header matching the unsatisfied
>> Require-Capability.  Frankly, I’d expect that what would be needed was
>> a Require-Capability header for a jpa extender, but I’m not that
>> familiar with jpa in osgi.  AFAICT your bundle doesn’t import the
>> java.persistence.provider package so it couldn’t do anything with the
>> service whether or not it was present.  This makes me wonder even more
>> where the generated headers are coming from any why.
>> 
>> david jencks
>> 
>> 
>>> On Dec 12, 2017, at 2:23 PM, Kerry <karaf-u...@avionicengineers.com>
>> wrote:
>>> 
>>> David,
>>> 
>>> I quickly tried your suggested POM modification and still generates
>> the headers for me, though I remember the underscore technique to pass
>> instructions direct to bnd so will investigate further.
>>> 
>>> The headers that are generated are:
>>> 
>>> Export-Service =
>>> 
>> com.javatechnics.jpa.dao.BookServiceDao;ServiceManager=Blueprint;name=BookServiceDao;osgi.service.blueprint.compname=bookServiceDao
>>> Provide-Capability =
>>> 
>> osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name=test,
>>> 
>> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name=test,
>>> 
>> osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name=test,
>>> 
>> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name=test
>>> Require-Capability =
>>> 
>> osgi.service;effective:=active;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;objectClass=javax.persistence.spi.PersistenceProvider,
>>>osgi.extender;osgi.extender=aries.jpa,
>>> 
>> osgi.service;effective:=active;filter:=(osgi.jndi.service.name=jdbc/test);objectClass=javax.sql.D

Re: Felix and JavaFX

[Neil Bartlett]

That's pretty easy to answer.

Felix by default exports all standard Java SE packages. JavaFX is not part
of Java SE, it is an extension that is only available on a subset of Java
implementations.

Neil

On 12 Dec 2017 2:56 pm, "Chuck Davis"  wrote:

> Hi Kerry:
>
> Thanks for the note.  Old indeed.  I don't remember anything I learned
> from that project (though I did keep the modules).  I did get it to work by
> including the module somebody mentioned.  It seems so easy, looking at that
> module, I can't understand why Felix doesn't do the export for JavaFX so
> that it's not even an issue -- at least an option that can be turned on or
> off, installed or uninstalled or some such and stop the necessity of all
> the work-arounds on which developers are having to waste their time.
>
> If I revisit OSGi I'll take a look at your project if Felix hasn't fixed
> the issue yet at the time.
>
> Thanks.
>
> CD
>
> On 12/12/2017 05:19 AM, Kerry wrote:
>
>> Hi Chuck,
>>
>> I realise that this is a response to an old message of yours but I have a
>> GitHub project that may be of interest to you that brings OSGi to JavaFx.
>>
>> https://github.com/jtkb/osgifx
>>
>> It aims to be simpler than Drombler and is agnostic to the OSGi
>> implementation. It is still a work in progress but check the examples and
>> integration-test modules to see how to use it. I have currently tested it
>> with Apache karaf which obviously used Apache Felix but plan to add tests
>> for other implementations too.
>>
>> If you try it out any comments you have or improvements are welcome. Any
>> issues also just ask. I'm in the process of improving the documentation at
>> the moment.
>>
>> Kerry
>>
>> ⁣Sent from BlueMail ​
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Creating a "partial" OBR

[Neil Bartlett]

I agree with Ray, you could use the bnd-indexer-maven-plugin. You would use 
this by creating a Maven module that references all of the modules that you 
want to include in the index. The plugin will index the full transitive 
dependency tree (compile + runtime scope) of the module it is attached to, 
though you can of course use  blocks to thin this down if you desire.

NB there is no requirement to use any of the other bnd Maven plugins… you can 
use the bnd-indexer-maven-plugin while continuing to use maven-bundle-plugin to 
build the actual bundles.

Regards,
Neil

> On 8 Oct 2017, at 09:18, Raymond Auge  wrote:
> 
> On Oct 8, 2017 6:39 AM, "Jean-Baptiste Onofré"  > wrote:
> 
> Hi David,
> 
> I guess the repository.xml is updated by the maven-bundle-plugin right (in
> your .m2/repository) ?
> 
> Regards
> JB
> 
> 
> On 10/08/2017 05:19 AM, David Leangen wrote:
> 
>> Hi!
>> 
>> I have a few felix projects that I have patched and would like to test,
>> but I need to create an OBR containing just those projects.
>> 
> 
> Just for purists sake, you probably mean R5 index as obr refers to a
> specific non-standard form of OSGi repository which should be avoided...
> 
> 
>> I am a bit stumped as to how to go about it, though.
>> 
> 
> Have you looked at the bnd-indexer-maven-plugin?
> https://github.com/bndtools/bnd/tree/master/maven/bnd-indexer-maven-plugin 
> 
> 
> - Ray
> 
> 
>> 
>> Specifically, there are 3 projects:
>> 
>>   * converter/converter
>>   * converter/serializer
>>   * converter/schematizer
>> 
>> 
>> I would like to have an OBR that contains only those 3 bundles.
>> 
>> 
>> Any suggestions as to how I could go about that?
>> 
>> maven-bundle-plugin is already configured in those projects. I am guess
>> that I just need to set it up properly, but I am not understanding from the
>> docs, and I have not found any examples.
>> 
>> 
>> Thanks!!
>> =David
>> 
>> 
>> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org

Re: how do I stop JavaFX bundles?

[Neil Bartlett]

Calling getBundle(0).stop() does not just shut down an OSGi bundle, it shuts 
down the entire OSGi framework. It’s not clear to me whether that’s what you 
should be doing.

As for shutting down JavaFX, you have found “Platform.exit()” but you are 
looking for a better way? Maybe this question should be asked on a JavaFX forum.

Regards,
Neil


> On 14 Sep 2017, at 03:36, Chuck Davis  wrote:
> 
> After a few weeks delay for knee replacement I cobbled together a program
> yesterday that uses the FrameworkFactory service to create a Framework and
> install 3 bundles -- all of which is working splendidly as expected.
> 
> My first bundle is this that Renato directed me to in the last thread about
> this issue which takes care of the classloading issue for JavaFX:
> 
> https://github.com/edvin/javafx-osgi
> 
> My second bundle creates the Stage service that Paul talked about.
> 
> My third bundle creates a couple Scenes and depending on the button pressed
> changes the Scene on the Stage.
> 
> This basic scheme is working now.
> 
> BUTnow I have to stop things "cleanly" as "OSGi In Action" mentions.
> Unfortunately, there is no JavaFX in the book.
> 
> My main class just installs the bundles and then is finished but does not
> terminate the JVM.
> 
> I dinked around today until I came up with the combination of
> Platform.exit() followed by BundleContext.getBundle(0).stop().  Stopping
> bundle 0 is apparently the accepted way to stop Felix.  With this
> combination both JVM instances end (my main class and the Framework) and
> the visual bits and pieces disappear.  It's not too elegant and I have to
> believe there is a better way to shut down JavaFX bundles.   
> 
> Anybody have suggestions?
> 
> Thanks in advance.


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: New to Felix - can someone help explain what this error means (and how to fix it)?

[Neil Bartlett]

This error message simply says that your bundle imports (that is, it depends 
on) the package named “oracle.security.jps”, but that no other bundle exports 
or provides that package.

The normal fix for this is to find a bundle that exports the package 
“oracle.security.jps” and install it into your framework. The documentation for 
OAM should have a list somewhere of all the bundles you need to make it work.

Regards,
Neil

> On 6 Sep 2017, at 19:19, o haya  wrote:
> 
> Hi,
> 
> I am working on what Oracle calls an "authentication plugin" to work with 
> their Oracle Access Manager (OAM) product.  
> 
> I have implemented one of their sample plugins (SampleAuthPlugin) but now 
> want to have that plugin access another API that they have called the 
> Identity Context API:
> 
> https://docs.oracle.com/cd/E27559_01/admin.1112/e27239/id_context.htm#AIAAG7296
> 
> So I added some snippets from one of their examples on that page (Example 
> 41-3) to make a method that would list/dump out the contents of the Identity 
> Context.  This new code has dependencies on several other Oracle JARs, from 
> what I can tell:
> 
> IdentityContext.jar
> jps-api.jar
> 
> Possibly some others, but my code compiled ok, and I could build a new 
> SampleAuthPlugin.jar successfully.
> 
> However, when I try to (what oracle calls) "Activate" the plugin, I am 
> getting errors.  I've tried all kinds of things, but at this point, I am 
> still getting this:
> 
> < 1:35:44 PM EDT>
>  starting the bundle.null
> java.lang.reflect.InvocationTargetException
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:606)
>at 
> oracle.security.am.plugin.internal.OSGIPluginService.installAndStartBundle(OSGIPluginService.java:179)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.installAndStartBundle(NodeMessageListener.java:66)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.receiveMessage(NodeMessageListener.java:112)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.receiveMessageList(NodeMessageListener.java:49)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.MessageListenerWrapper.objectCreated(MessageListenerWrapper.java:30)
>at 
> oracle.security.am.foundation.mapimpl.coherence.events.MapListenerWrapper.notifyListener(MapListenerWrapper.java:174)
>at 
> oracle.security.am.foundation.mapimpl.coherence.events.EventDispatcher.dispatch(EventDispatcher.java:132)
>at 
> oracle.security.am.foundation.mapimpl.coherence.events.EventDispatcher.run(EventDispatcher.java:114)
> Caused By: org.osgi.framework.BundleException: Unresolved constraint in 
> bundle SampleAuthPlugin [2]: Unable to resolve 2.0: missing requirement [2.0] 
> osgi.wiring.package; (osgi.wiring.package=oracle.security.jps)
>at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3980)
>at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
>at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
>at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:606)
>at 
> oracle.security.am.plugin.internal.OSGIPluginService.installAndStartBundle(OSGIPluginService.java:179)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.installAndStartBundle(NodeMessageListener.java:66)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.receiveMessage(NodeMessageListener.java:112)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.receiveMessageList(NodeMessageListener.java:49)
>at 
> oracle.security.am.extensibility.lifecycle.messaging.MessageListenerWrapper.objectCreated(MessageListenerWrapper.java:30)
>at 
> oracle.security.am.foundation.mapimpl.coherence.events.MapListenerWrapper.notifyListener(MapListenerWrapper.java:174)
>at 
> oracle.security.am.foundation.mapimpl.coherence.events.EventDispatcher.dispatch(EventDispatcher.java:132)
>at 
> oracle.security.am.foundation.mapimpl.coherence.events.EventDispatcher.run(EventDispatcher.java:114)
> 
> I guess the root cause must be this:
> 
> Unresolved constraint in bundle SampleAuthPlugin [2]: Unable to resolve 2.0: 
> missing requirement [2.0] 

Re: Antwort: RE: Felix and JavaFX

[Neil Bartlett]

In fact you ARE doing the things explained in Paul Bakker’s article. Or rather, 
Karaf does them for you: it sets up the system bundle exports using the 
contents of jre.properties.

By default Felix (and all other OSGi frameworks that I’m aware of) exports only 
the JavaSE standard packages. JavaFX is not part of JavaSE standard, therefore 
it is not exported by default. Somebody has to add its packages to the system 
bundle exports — you can do this yourself with a single line of code, or you 
can drag in all the dependencies of Karaf. I know which I would choose.

Regards,
Neil

> On 20 Jul 2017, at 13:25, CLEMENT Jean-Philippe 
>  wrote:
> 
> Ok, thanks.
> 
> At least with Karaf, there is no such "ClassNotFoundException"  (JavaFX 
> packages must declared in the jre.properties file). I don't use things 
> explained in Paul's article.
> 
> I just need the initialize() of the class below to be called within a 
> singleton bundle. That bundle should be started before any other which uses 
> JavaFX. Then there is no more "primary window" and any bundle can show 
> whatever things it needs.
> 
> public final class FXInitializer extends Application {
>private static BlockingQueue sync;
> 
>/**
> * Initializes the FX windowing system.
> *
> * @throws InterruptedException
> * If initialization was cancelled due to program exit
> */
>public static FXInitializer initialize() throws InterruptedException {
>return initialize(new String[0]);
>}
> 
>/**
> * Initializes the FX windowing system.
> *
> * @param a
> *Arguments as gave to the "main" application
> * @throws InterruptedException
> * If initialization was cancelled due to program exit
> */
>public static FXInitializer initialize(final String... a) throws 
> InterruptedException {
>try {
>Platform.setImplicitExit(false);
>sync = new SynchronousQueue<>();
>new Thread(() -> FXInitializer.launch(FXInitializer.class, 
> a)).start();
>return sync.take();
>} finally {
>sync = null;
>}
>}
> 
>@Override
>public void start(final Stage stage) throws InterruptedException {
>stage.hide();
>sync.put(this);
>}
> }
> 
> JP
> 
> 
> -Message d'origine-
> De : marc.schle...@sdv-it.de [mailto:marc.schle...@sdv-it.de] 
> Envoyé : jeudi 20 juillet 2017 13:50
> À : users@felix.apache.org
> Objet : Antwort: RE: Felix and JavaFX
> 
> I think you are refering to this one
> 
> http://paulonjava.blogspot.de/2014/11/making-javafx-better-with-osgi.html
> 
> regards
> Marc
> 
> 
> Von:CLEMENT Jean-Philippe 
> An: "users@felix.apache.org" , 
> Datum:  20.07.2017 10:26
> Betreff:RE: Felix and JavaFX
> 
> 
> 
> Sorry, I didn't find Paul's article. From my point of view there is no issue 
> with JavaFX 8 (also succeeded with Java 9). Just the tiny workaround in order 
> to start the JavaFX engine - which is a bundle containing a single class 
> class with few lines of code.
> 
> Could you please remind me the link to Paul's article?
> 
> Regards,
> JP
> 
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : jeudi 20 juillet 2017 
> 05:32 À : users@felix.apache.org Objet : Re: Felix and JavaFX
> 
> All the ones Paul's article delineates.
> 
> On Tue, Jul 18, 2017 at 8:12 AM, CLEMENT Jean-Philippe < 
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
> 
>> Paul?
>> 
>> I just replied to your initial question "I spent most of the day 
>> yesterday googling to find out if there is a way to build a JavaFX 
>> desktop application based upon Felix..."
>> 
>> Well, which problem are you experiencing with JavaFX?
>> 
>> JP
>> 
>> -Message d'origine-
>> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : lundi 17 juillet
>> 2017 18:41 À : users@felix.apache.org Objet : Re: Felix and JavaFX
>> 
>> JP, are you doing the same thing Paul outlines in his article?  If 
>> you've taken a different approach can you share it for the benefit of 
>> all of us following this thread?
>> 
>> Thanks.
>> 
>> On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe < 
>> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>> 
>>> Hi,
>>> 
>>> We are making OSGi desktop applications with JavaFX without any issue.
>>> We do not rely on Eclipse or Equinox. We are using Karaf and 
>>> maven-bundle-plugin.
>>> 
>>> There is only a small workaround for startup with a special bundle 
>>> which is a fake "Application" in order to start JavaFX engine.
>>> 
>>> JP
>>> 
>>> -Message d'origine-
>>> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : dimanche 9 
>>> juillet 2017 18:17 À : users@felix.apache.org Objet : Re: Felix and 
>>> JavaFX
>>> 
>>> I spent most of the day yesterday googling to find out if there is a 
>>> 

Re: Whiteboard not deploying properly

[Neil Bartlett]

Does your Servlet service have the "osgi.http.whiteboard.servlet.pattern” 
property? Can you list the full properties of the service?

Neil

> On 19 Jul 2017, at 15:15, Jason Tesser  wrote:
> 
> When I start the Whiteboard bundle I get the following logged
> [DEBUG] Ignoring Servlet Service [javax.servlet.Servlet], alias is missing
> or empty
> [INFO] Http service whiteboard started
> 
> The felix examples do not work and I cannot register a servlet.
> 
> I DO have the org.apache.felix.scr bundle and the org.apache.felix.http.api
> bundle Active.


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix and JavaFX

[Neil Bartlett]

Hi Chuck,

I read through Paul’s article and it still looks very relevant and well written.

You don’t really want to use bnd directly. It’s a low-level tool… it would be 
like using javac and the jar tool directly from the command line, rather than 
via a build system. Does anybody still do that?? Fortunately the Maven 
integration for bnd has improved markedly since Paul’s article was written, you 
can read about the suite of plugins available here: 
https://github.com/bndtools/bnd/tree/master/maven 
<https://github.com/bndtools/bnd/tree/master/maven>

Regards,
Neil


> On 9 Jul 2017, at 23:50, Chuck Davis <cjgun...@gmail.com> wrote:
> 
> Hi Neil:
> 
> I'm just beginning my investigation of OSGi because I want to do things
> that it sounds like OSGi was designed to do and I'm too lazy to reinvent
> the wheel if it already exists.  I develop desktop business applications
> and my development style is already quite modular in concept but I want to
> get to the next level of modularity.
> 
> Paul's article hits the nail on the head with what I am hung up on in the
> "Importing JavaFX Packages" subsection.  That is the first problem and Paul
> lays out that there are more ahead before/if I achieve victory.
> 
> I've done a bit more reading and it sounds like the Bndtools he endorses
> from Eclipse is just a more user-friendly version of Bnd so maybe I can
> find a way to use the Bnd tool directly.many challenges lie ahead it
> sound like.
> 
> Thanks for your interest.
> 
> 
> 
> On Sun, Jul 9, 2017 at 10:24 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> 
>> Hi Chuck,
>> 
>> Using Eclipse as an IDE does not tie you into using Equinox for your
>> runtime.
>> 
>> I don’t know much about JavaFX but what is the actual problem you are
>> experiencing with it? Isn’t it just a library like any other?
>> 
>> Neil
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 

Re: Felix and JavaFX

[Neil Bartlett]

Hi Chuck,

Using Eclipse as an IDE does not tie you into using Equinox for your runtime.

I don’t know much about JavaFX but what is the actual problem you are 
experiencing with it? Isn’t it just a library like any other?

Neil

> On 9 Jul 2017, at 18:18, Chuck Davis  wrote:
> 
> Thanks Bram.  I actually read that yesterday but unfortunately it's Eclipse
> related and that ties me to Equinox.  So far I haven't found anything to
> like about Eclipse and I want true OSGi compatibility -- not tied to a
> specific IDE or OSGi implementation.  At least the Eclipse people are
> wrestling with the issue and that is a good sign.  I've done some of the
> e(fx)clipse tutorials as well but, again, it makes me dependent on specific
> implementations.
> 
> I'm going to re-read the article and see if I've missed something
> though.
> 
> Again, thanks for your interest.
> 
> 
> On Sun, Jul 9, 2017 at 10:10 AM, Bram Pouwelse  wrote:
> 
>> Hi Chuck,
>> 
>> It's an old post but could be what you're looking for
>> 
>> http://paulonjava.blogspot.nl/2014/11/making-javafx-better-
>> with-osgi.html?m=1
>> 
>> Regards,
>> Bram
>> 
>> Op 9 jul. 2017 19:05 schreef "Chuck Davis" :
>> 
>>> Thanks Thomas.  I guess there must be a way.  I wish he would have just
>>> explained how to use JavaFX with Felix rather than develop a whole third
>>> party development environment.
>>> 
>>> On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
>>> thomas.dries...@ds-lab.org>
>>> wrote:
>>> 
 Hi Chuck,
 
 maybe this Project is an interesting starting Point for you:
 http://www.drombler.org
 
 Kind regards,
 Thomas
 
 Am 09.07.2017 18:17 schrieb "Chuck Davis" :
 
> I spent most of the day yesterday googling to find out if there is a
>>> way
 to
> build a JavaFX desktop application based upon Felix.  So far I've not
 found
> anything that advises how to do this or if it is even possible at
>> this
> stage of development.
> 
> Can anybody point me to an article that explains how, if this can be
 done?
> 
> TIA.
> 
 
>>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Maven bundle plugin equivalent for -metatypes

[Neil Bartlett]

> On 28 Jun 2017, at 13:55, Thomas Kellerer  wrote:
> 
>> Actually any JARs that you place under src/main/resources will be included 
>> in the bundle — just as in any other Maven project.
> 
> But the jars are not stored in src/main/resources 
> 
> They simply declared as dependencies in the Maven pom.

I see, fair enough. Then you do need a bnd.bnd file with -includeresource when 
you really need to embed a dependent library… though I still assert that this 
is rarely necessary.

> 
> 
>> But I’m wondering why you need to do this? Embedding JAR files should
>> be a rarely used technique, for example when wrapping an external
>> non-OSGi dependency for use in OSGi. If lots of your bundles need to
>> embed JARs then something very strange is going on.
> 
> I need this because my portlets need those jar files. 
> 
> I have no idea how else I could use those libraries in my portlets if I do 
> not include them in the bundle. 

Import-Package.

> 
> If I don't include them in the bundle, Liferay (Felix?) won't even load the 
> portlet. 
> 
> Thomas
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Maven bundle plugin equivalent for -metatypes

[Neil Bartlett]

Actually any JARs that you place under src/main/resources will be included in 
the bundle — just as in any other Maven project.

But I’m wondering why you need to do this? Embedding JAR files should be a 
rarely used technique, for example when wrapping an external non-OSGi 
dependency for use in OSGi. If lots of your bundles need to embed JARs then 
something very strange is going on.

Regards,
Neil


> On 28 Jun 2017, at 13:46, Thomas Kellerer <thomas.kelle...@mgm-tp.com> wrote:
> 
> Thanks for the quick reply, however I could not include any needed jar files 
> in the bundle without using "-includeresource:" in the bnd file for all 
> dependent jar files. 
> 
> Thomas
> 
> Neil Bartlett schrieb am 28.06.2017 um 14:40:
>> Just a quick note: the bnd.bnd file is NOT required by the biz.aQute.bnd 
>> plugins. It is only used when you need to do something special in a bundle 
>> definition like a custom annotation header.
>> 
>> Sorry I can’t answer your question about metatype with the 
>> maven-bundle-plugin.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> On 28 Jun 2017, at 13:35, Thomas Kellerer <thomas.kelle...@mgm-tp.com> 
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> I am fighting with getting my portlets to run with Liferay 7 and the whole 
>>> OSGi environment. 
>>> 
>>> So far the Felix Maven plugin was a big help because I don't have to manage 
>>> all the JAR file dependencies in my pom.xml *andÜ the bnd.bnd file that is 
>>> required by the biz.aQute.bnd plugins.
>>> 
>>> However, one thing I can't get working with the maven plugin is the 
>>> equivalent of 
>>> 
>>>  -metatype: *
>>> 
>>> in the bnd.bnd file which is required for the configuration stuff to work 
>>> in Liferay 7. 
>>> 
>>> I tried 
>>> 
>>>  <_metatypeannotations>*
>>> 
>>> and 
>>> 
>>>  <_metatypes>*
>>> 
>>> in the  section of the Maven plugin, but that didn't work. 
>>> When using biz.aQute.bnd plugin the corresponding directive scans the 
>>> classes for meta annotations and generates a corresponding XML file in 
>>> OSGI_INF/metatype/ inside the jar file. 
>>> 
>>> How can I get that to work with the Felix Maven plugin? 
>>> 
>>> Thanks
>>> Thomas
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Maven bundle plugin equivalent for -metatypes

[Neil Bartlett]

Just a quick note: the bnd.bnd file is NOT required by the biz.aQute.bnd 
plugins. It is only used when you need to do something special in a bundle 
definition like a custom annotation header.

Sorry I can’t answer your question about metatype with the maven-bundle-plugin.

Regards,
Neil


> On 28 Jun 2017, at 13:35, Thomas Kellerer  wrote:
> 
> Hello,
> 
> I am fighting with getting my portlets to run with Liferay 7 and the whole 
> OSGi environment. 
> 
> So far the Felix Maven plugin was a big help because I don't have to manage 
> all the JAR file dependencies in my pom.xml *andÜ the bnd.bnd file that is 
> required by the biz.aQute.bnd plugins.
> 
> However, one thing I can't get working with the maven plugin is the 
> equivalent of 
> 
>   -metatype: *
> 
> in the bnd.bnd file which is required for the configuration stuff to work in 
> Liferay 7. 
> 
> I tried 
> 
>   <_metatypeannotations>*
> 
> and 
> 
>   <_metatypes>*
> 
> in the  section of the Maven plugin, but that didn't work. When 
> using biz.aQute.bnd plugin the corresponding directive scans the classes for 
> meta annotations and generates a corresponding XML file in OSGI_INF/metatype/ 
> inside the jar file. 
> 
> How can I get that to work with the Felix Maven plugin? 
> 
> Thanks
> Thomas
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: API baselining with maven-bundle-plugin

[Neil Bartlett]

thing else called "1.0.0". But the detection of that isn't the job of the 
> bundle plugin's baseline goal which is solely concerned with package 
> versions, not bundle/project versions. What you are talking about here is, as 
> I've written previously, typically handled by the release process and, as 
> David wrong, enforced at the repository. It would violate the SRP for the 
> bundle plugin to get involved with this, especially since this problem has 
> absolutely nothing to do with OSGi.
> 
> Regards,
> Justin
> 
> 
> 
> 
>> And
>>  "I'm building something that the user wants to call 1.0.0. Once I've 
>> done that, I'll take that and compare it with another version to see 
>> whether the difference in version numbers, what the user has done to 
>> change the version numbers between those two versions, is consistent 
>> with any changes in the source code, and if not complain. The build 
>> artefact however will now exist".
>> 
>> I want the former. The maven bnd plugin appears to implement the latter.
>> As far as I understand, bndtools implements the former, I *can* 
>> implement the former with bnd. It doesn't appear possible to implement 
>> the former with maven due to the way it works.
> 
> 
>> 
>> 
>> -Original Message-
>> From: Neil Bartlett [mailto:njbartl...@gmail.com]
>> Sent: 22 June 2017 18:52
>> To: users@felix.apache.org
>> Subject: Re: API baselining with maven-bundle-plugin
>> 
>> Are you sure that you’re actually *releasing* every day? Or do you 
>> only mean sending out snapshots?
>> 
>> I agree with Justin that releases should be immutable, and that is 
>> what bnd and Bndtools have always tried to achieve. However bnd is not 
>> a complete end-to-end build system like Maven or Gradle, and Bndtools 
>> is only an IDE, so we don’t get a lot of say in the larger process. 
>> You should work within the conventions of whatever build tool you use.
>> 
>> The process encouraged by bnd is very close to the Maven one. Once a 
>> release is made, you must not change it. If you change a package after 
>> a release, then you move up to a new version number for that package. 
>> You can then build and publish as many snapshot of that new version 
>> number as you like, usually with a timestamp in the qualifier segment of the 
>> version.
>> Once you release, that version is consumed and you go back to the 
>> beginning of this paragraph.
>> 
>> Neil
>> 
>> 
>>> On 22 Jun 2017, at 18:12, Tom Quarendon <
>> tom.quaren...@worldprogramming.com> wrote:
>>> 
>>> The cadence is important I that if I want to "release" off the back 
>>> of
>> each build, I don't want to have to manually make a code modification 
>> every day, nor do I want to have the build process modify the source 
>> code, that just doesn't seem right.
>>> 
>>> I'm probably at odds with standard practice.
>>> 
>>> -Original Message-
>>> From: Justin Edelson [mailto:jus...@justinedelson.com]
>>> Sent: 22 June 2017 17:40
>>> To: users@felix.apache.org
>>> Subject: Re: API baselining with maven-bundle-plugin
>>> 
>>> The cadence of releases is irrelevant. But each release must have a
>> distinct (bundle) version number. Otherwise, the version loses any 
>> meaning since two copies of "version 1.0.0" are not necessarily the same.
>>> 
>>> If you only want to change the bundle version when you start 
>>> changing the project, that's certainly a choice you can make. I find 
>>> (and many others do
>>> too) it easier to do this automatically at the time of release (i.e. 
>>> set
>> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't 
>> get forgotten.
>>> 
>>> I can't speak to how bndtools work. I assume it must do some kind of
>> automatic bundle version management since it would be inappropriate to 
>> have mutable releases.
>>> 
>>> 
>>> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
>> tom.quaren...@worldprogramming.com> wrote:
>>> 
>>>> I perhaps have a different concept of how things work. But I'm not 
>>>> very familiar with how maven works.
>>>> 
>>>> Fundamentally, if I haven't changed any code, why have any of the 
>>>> version numbers changed? I'm perhaps viewing things from a 
>>>> continuous deployment perspective rather than a "release once a year" 
>&g

Re: API baselining with maven-bundle-plugin

[Neil Bartlett]

We don't like to overload the version with information about release
status, so no it's not exactly like maven. An artifact is a release simply
if it is present in a designated Release repository.

This enables a process where the artifact does not need to be rebuilt in
order to release it. Rebuilding at such a late stage can lead to
instability because small differences can creep in.

Neil

On 22 Jun 2017 8:23 p.m., "Justin Edelson" <jus...@justinedelson.com> wrote:

> Neil-
> Out of curiosity, in the bnd worldview you're describing, how is the
> distinction between a snapshot and release denoted? Is it like Maven where
> SNAPSHOT is used as a qualifier? Or is there some other convention?
>
> Thanks,
> Justin
>
>
> On Thu, Jun 22, 2017 at 1:51 PM Neil Bartlett <njbartl...@gmail.com>
> wrote:
>
> > Are you sure that you’re actually *releasing* every day? Or do you only
> > mean sending out snapshots?
> >
> > I agree with Justin that releases should be immutable, and that is what
> > bnd and Bndtools have always tried to achieve. However bnd is not a
> > complete end-to-end build system like Maven or Gradle, and Bndtools is
> only
> > an IDE, so we don’t get a lot of say in the larger process. You should
> work
> > within the conventions of whatever build tool you use.
> >
> > The process encouraged by bnd is very close to the Maven one. Once a
> > release is made, you must not change it. If you change a package after a
> > release, then you move up to a new version number for that package. You
> can
> > then build and publish as many snapshot of that new version number as you
> > like, usually with a timestamp in the qualifier segment of the version.
> > Once you release, that version is consumed and you go back to the
> beginning
> > of this paragraph.
> >
> > Neil
> >
> >
> > > On 22 Jun 2017, at 18:12, Tom Quarendon <
> > tom.quaren...@worldprogramming.com> wrote:
> > >
> > > The cadence is important I that if I want to "release" off the back of
> > each build, I don't want to have to manually make a code modification
> every
> > day, nor do I want to have the build process modify the source code, that
> > just doesn't seem right.
> > >
> > > I'm probably at odds with standard practice.
> > >
> > > -Original Message-
> > > From: Justin Edelson [mailto:jus...@justinedelson.com]
> > > Sent: 22 June 2017 17:40
> > > To: users@felix.apache.org
> > > Subject: Re: API baselining with maven-bundle-plugin
> > >
> > > The cadence of releases is irrelevant. But each release must have a
> > distinct (bundle) version number. Otherwise, the version loses any
> meaning
> > since two copies of "version 1.0.0" are not necessarily the same.
> > >
> > > If you only want to change the bundle version when you start changing
> > the project, that's certainly a choice you can make. I find (and many
> > others do
> > > too) it easier to do this automatically at the time of release (i.e.
> set
> > the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
> get
> > forgotten.
> > >
> > > I can't speak to how bndtools work. I assume it must do some kind of
> > automatic bundle version management since it would be inappropriate to
> have
> > mutable releases.
> > >
> > >
> > > On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> > tom.quaren...@worldprogramming.com> wrote:
> > >
> > >> I perhaps have a different concept of how things work. But I'm not
> > >> very familiar with how maven works.
> > >>
> > >> Fundamentally, if I haven't changed any code, why have any of the
> > >> version numbers changed? I'm perhaps viewing things from a continuous
> > >> deployment perspective rather than a "release once a year"
> perspective.
> > >>
> > >> As far as I can tell with bndtools, version numbers are changed as,
> > >> and only as necessary.
> > >> I check out the source code, and then as I change code, it prompts me
> > >> to change package and bundle versions appropriately.
> > >> Hence after my edits, the package and version numbers of things I
> > >> haven't changed are the same as they were, which seems right to me.
> > >> Things that I've changed have changed version package and bundle
> > version numbers.
> > >> If I then do a "mvn deploy" (well, "gradle release") on the resu

Re: API baselining with maven-bundle-plugin

[Neil Bartlett]

Are you sure that you’re actually *releasing* every day? Or do you only mean 
sending out snapshots?

I agree with Justin that releases should be immutable, and that is what bnd and 
Bndtools have always tried to achieve. However bnd is not a complete end-to-end 
build system like Maven or Gradle, and Bndtools is only an IDE, so we don’t get 
a lot of say in the larger process. You should work within the conventions of 
whatever build tool you use.

The process encouraged by bnd is very close to the Maven one. Once a release is 
made, you must not change it. If you change a package after a release, then you 
move up to a new version number for that package. You can then build and 
publish as many snapshot of that new version number as you like, usually with a 
timestamp in the qualifier segment of the version. Once you release, that 
version is consumed and you go back to the beginning of this paragraph.

Neil


> On 22 Jun 2017, at 18:12, Tom Quarendon  
> wrote:
> 
> The cadence is important I that if I want to "release" off the back of each 
> build, I don't want to have to manually make a code modification every day, 
> nor do I want to have the build process modify the source code, that just 
> doesn't seem right.
> 
> I'm probably at odds with standard practice.
> 
> -Original Message-
> From: Justin Edelson [mailto:jus...@justinedelson.com] 
> Sent: 22 June 2017 17:40
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
> 
> The cadence of releases is irrelevant. But each release must have a distinct 
> (bundle) version number. Otherwise, the version loses any meaning since two 
> copies of "version 1.0.0" are not necessarily the same.
> 
> If you only want to change the bundle version when you start changing the 
> project, that's certainly a choice you can make. I find (and many others do
> too) it easier to do this automatically at the time of release (i.e. set the 
> master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get 
> forgotten.
> 
> I can't speak to how bndtools work. I assume it must do some kind of 
> automatic bundle version management since it would be inappropriate to have 
> mutable releases.
> 
> 
> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon < 
> tom.quaren...@worldprogramming.com> wrote:
> 
>> I perhaps have a different concept of how things work. But I'm not 
>> very familiar with how maven works.
>> 
>> Fundamentally, if I haven't changed any code, why have any of the 
>> version numbers changed? I'm perhaps viewing things from a continuous 
>> deployment perspective rather than a "release once a year" perspective.
>> 
>> As far as I can tell with bndtools, version numbers are changed as, 
>> and only as necessary.
>> I check out the source code, and then as I change code, it prompts me 
>> to change package and bundle versions appropriately.
>> Hence after my edits, the package and version numbers of things I 
>> haven't changed are the same as they were, which seems right to me. 
>> Things that I've changed have changed version package and bundle version 
>> numbers.
>> If I then do a "mvn deploy" (well, "gradle release") on the result, 
>> then OK, the unchanged bundles will be re-released to the repository 
>> (or maybe not, maybe maven/gradle doesn't replace a bundle with one 
>> with the same version, don't know), but the contents are the same 
>> (from a source perspective anyhow), so that doesn't matter.
>> 
>> As I say, I don't have much experience of using maven etc, I was 
>> confused that it worked in an apparently different way to bndtools, 
>> which is based on the same thing.
>> 
>> 
>> 
>> -Original Message-
>> From: Justin Edelson [mailto:jus...@justinedelson.com]
>> Sent: 22 June 2017 15:15
>> To: users@felix.apache.org
>> Subject: Re: API baselining with maven-bundle-plugin
>> 
>> Hi,
>> I think you might be mixing up the bundle version (what I think you 
>> are referring to as the "project version") with the package versions. 
>> baseline is larger concerned with the latter, and only uses the former 
>> to find the comparison version.
>> 
>> Released versions should always be considered immutable, so you should
>> *always* change the project version immediately after a release. If 
>> you use the maven-release-plugin, this is automatically done, but 
>> otherwise you would need to do this manually.
>> 
>> Here's the way it is supposed to work:
>> 
>> * You have a bundle with version 1.0.0 and package com.myco.foo at 
>> version 1.0.0. This bundle is deployed in some repository.
>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or 
>> 1.0.1-SNAPSHOT in Maven terms).
>> * You make some change to one of the classes/interfaces in com.myco.foo.
>> * Then you run the baseline plugin. Baseline compares the current 
>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and 
>> checks each exported package. It sees that there has been some 

Re: Which osgi core dependency to use in maven projects

[Neil Bartlett]

Actually M is right, although it is strongly discouraged to use version ranges 
at build time, so that should just be 6.0.0.

This defines OSGi Release 6 which is supported by Felix. Usually you build 
against a specification (i.e. OSGi core R6) and then pick an implementation 
that supports it.

Neil


> On 12 May 2017, at 18:09, Roy Teeuwen  wrote:
> 
> Hey Mark,
> 
> But for this to work, you have to know which interfaces Felix supports of 
> OSGi R6, no? Because else why not write everything against the 6.0.0 
> dependency?
> 
> Greets,
> Roy
>> On 11 May 2017, at 11:39, list+org.apache.fe...@io7m.com wrote:
>> 
>> On 2017-05-09T21:33:46 +0200
>> Roy Teeuwen  wrote:
>> 
>>> Hey all,
>>> 
>>> I was wondering how you can know what version you can use as dependency in 
>>> your maven project when using felix. For example my current project has as 
>>> system bundle org.apache.felix.framework version 4.6.1. How can I know then 
>>> what artifact version I can use for org.osgi.core then?
>>> 
>>> I see that the following header is provided, does that help me?
>>> 
>>> Provide-Capability: osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 
>>> 1.1, 1.2", osgi.ee; osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 
>>> 1.4, 1.5, 1.6, 1.7, 1.8"
>> 
>> Hello.
>> 
>> I think you have to think in terms of the version(s) of the OSGi APIs
>> that you need. For example, if you're writing code that depends on the
>> interfaces and semantics provided by OSGi R6, then you'd probably use a
>> dependency like:
>> 
>> 
>>   org.osgi
>>   org.osgi.core
>>   [6.0.0, 7.0.0)
>>   provided
>> 
>> 
>> The specification versions going back to 4.0.0 are in Central.
>> 
>> M
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Not able to open through console

[Neil Bartlett]

What error?


> On 26 Feb 2017, at 10:00, Jay Trivedi  wrote:
> 
> Hi all,
> 
> I downloaded latest felix-framework--5.6.2, in windows 7 and while hitting 
> command to start felix i was not able to start it-it failed with following 
> error.
> 
> Can you let me know how to resolve it or how to look into source code.
> 
> 
> 
> Regards,
> Jay Trivedi
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [osgi-dev] Components are not started,although marked with immediate=true

[Neil Bartlett]

Normally it’s enough to have a Log Service bundle installed, such as 
org.apache.felix.log. Then you can view messages with the “log” command in the 
Gogo shell.


> On 17 Feb 2017, at 22:54, Thomas Driessen  wrote:
> 
> It has indeed been an Exception in the initializer.
> Thank you so much!
> 
> Can you point me to some resources on how to setup the logging for DS, so 
> that in the future I might see such Exceptions?
> 
> Kind regards,
> Thomas
> 
> -- Originalnachricht --
> Von: "David Jencks" 
> An: users@felix.apache.org
> Gesendet: 17.02.2017 22:42:18
> Betreff: Re: [osgi-dev] Components are not started,although marked with 
> immediate=true
> 
>> One way this could happen is if the activate methods on the testThread 
>> components threw exceptions.  You might try making the activate/deactivate 
>> methods empty to check.  If you’ve set up logging for DS (including the  
>> framework or config property ds.loglevel=debug) the logs will show in 
>> excruciating detail what is happening.
>> 
>> hope this helps, if it’s not exceptions please supply debug logs and i will 
>> take a look.
>> 
>> david jencks
>> 
>>> On Feb 17, 2017, at 12:36 PM, Thomas Driessen 
>>>  wrote:
>>> 
>>> After asking in the osgi-dev list in was adviced to try ist at the Felix
>>> Mailinglist.
>>> 
>>> Dies anyone know why Services that are marked as immediate are not started
>>> although marked as satisfied by felix-scr? ( See E-Mails below dir the Code)
>>> 
>>> Kind regards,
>>> Thomas
>>> -- Weitergeleitete Nachricht --
>>> Von: "BJ Hargrave" 
>>> Datum: 17.02.2017 21:09
>>> Betreff: Re: [osgi-dev] Components are not started,although marked with
>>> immediate=true
>>> An: , 
>>> Cc:
>>> 
>>> Seems like they should all be active. You may need to check with the
 felix-dev list about Felix SCR's handling of this.
 --
 
 BJ Hargrave
 Senior Technical Staff Member, IBM // office: +1 386 848 1781
 <(386)%20848-1781>
 OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
 <(386)%20848-3788>
 hargr...@us.ibm.com
 
 
 
 - Original message -
 From: "Thomas Driessen" 
 Sent by: osgi-dev-boun...@mail.osgi.org
 To: osgi-...@mail.osgi.org
 Cc:
 Subject: [osgi-dev] Components are not started, although marked with
 immediate=true
 Date: Fri, Feb 17, 2017 2:46 PM
 
 Hi,
 
 I have a problem with immediate services and hoped that you guys maybe can
 help.
 
 I'm currently trying to implement several services within one bundle (see
 below for code).
 I have set all of them to be immediate (by immediate=true), but still,
 when I start the OSGi container with my bundle in it, only Con1,
 InDataPort1 and OutDataPort1 are active. The rest is satisfied but not
 active according to felix.scr console output:
 
 g! list
 BundleId Component Name Default State
   Component Id State  PIDs (Factory PID)
 [  10]   test.Con1  enabled
   [   0] [active  ]
 [  10]   test.InDataPort1  enabled
   [   1] [active  ]
 [  10]   test.OutDataPort1  enabled
   [   2] [active  ]
 [  10]   test.Process1  enabled
   [   3] [satisfied   ]
 [  10]   test.Thread1_1  enabled
   [   4] [satisfied   ]
 [  10]   test.Thread1_2  enabled
   [   5] [satisfied   ]
 
 Am I doing something wrong?
 I assumed that all services should be started as soon as they are
 satisfied.
 
 Any advice is highly appreciated.
 
 Kind regards,
 Thomas
 
 
 @Component(immediate = true, service = IProcess.class, property =
 "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Process1")
 public class Process1 implements IProcess {
 
 @Reference(target = "(uid=test.Thread1_1)")
 private volatile IPeriodicThread thread1;
 
 @Reference(target = "(uid=test.Thread1_2)")
 private volatile IPeriodicThread thread2;
 }
 
 
 @Component(service = IPeriodicThread.class, property =
 "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_1", immediate =
 true)
 public class Thread1_1 implements IPeriodicThread {
 
 @Reference(target = "(uid=test.OutDataPort1)")
 private volatile IOutDataPort outport;
 
 @Activate
 public void initialize_FW() {
   init();
 }
 
 @Deactivate
 public void finalize_FW() {
   deinit();
 }
 }
 
 
 @Component(service = IPeriodicThread.class, property =
 "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_2", immediate =
 true)
 public class Thread1_2 implements IPeriodicThread {
 
 @Reference(target = "(uid=test.InDataPort1)")
 private volatile 

Re: iPOJO still alive?

[Neil Bartlett]

> On 18 Jan 2017, at 23:31, Guillaume Nodet  wrote:
> 
> 2017-01-18 21:05 GMT+01:00 :
> 
>> Hi,
>> 
>> I would welcome your response to these questions:
>> 
>> 1) Is the iPOJO project still alive? I'm asking because the last version,
>> 1.12.1, was released in the end of 2014.
>> 
> 
> You're right, a single commit since 2 years, so not sure if it's totally
> dead, but it's definitely not active.
> 
> 
>> 
>> 2) Does anyone have experience with iPOJO + BndTools? Do they work well
>> together?
>> 
> 
> Well bndtools is less than 2 years old, so not sure if they have been used
> together.


Less than 2 years old?? Bndtools 1.0 was released in 2011.


> 
> 
>> 
>> Many thanks in advance!
>> 
>> Tim Lee
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: SCR: Issues with static reference mixed with multiple dynamic ref

[Neil Bartlett]

Roy,

Using immediate (or not) will have absolutely NO effect on the References in 
your component… except of course that immediacy affects *when* your component 
activates, and you can have different services visible at different times.

These are completely orthogonal aspects of the component. If you are seeing an 
unexpected effect then please describe it in more detail. It’s either a bug in 
SCR or in your component code.

Regards,
Neil


> On 28 Nov 2016, at 20:42, Roy Teeuwen  wrote:
> 
> Hey David,
> 
> True, I know thats what the immediate=true will do. 
> What I don't understand is that when you don't use the immediate=true and my 
> service does get lazily loaded when it is finally needed, that it doesn't 
> load all it's references that are dynamic and multiple. 
> Seeing as I have been taught to try and avoid the immediate=true when it 
> isn't absolutely necessary, I am trying to see if there are possibilities to 
> remove it and still get all the dynamic references.
> 
> Greets,
> Roy
>> On 28 Nov 2016, at 22:37, David Daniel  wrote:
>> 
>> I believe the immediate true separates the lifecycle from the resolution
>> phase and is similar to starting a singleton.  If there is no immediate
>> true then the lifecylce is based on when the service is a dependency and
>> lazily loaded.  If another service depends on your service and is started
>> then your service will be started as well but when the other service
>> shutsdown and your service is not longer needed then your service will
>> shutdown as well without the immediate = true.
>> 
>> On Mon, Nov 28, 2016 at 3:33 PM, Roy Teeuwen  wrote:
>> 
>>> Hey Karel,
>>> 
>>> Sorry to go further than the original question, but seeing as my question
>>> is related to exactly the same thing, maybe you can help me understand it
>>> better.
>>> Using the exact same example as the in the initial post, if I don't put
>>> immediate=true, it won't bind all of the services get created at startup or
>>> get added during the runtime. Is there a reason why it has to be immediate
>>> = true?
>>> 
>>> I also tried it by using the following notation, and then this it doesn't
>>> even bind any of services:
>>> 
>>> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
>>> ReferencePolicy.DYNAMIC)
>>> private List stateMachines = new CopyOnWriteArrayList<>();
>>> 
>>> Greetings,
>>> Roy
 On 28 Nov 2016, at 21:39, Karel Haeck  wrote:
 
 Nicolas,
 
 the spec does not specify that static references should be injected
>>> before dynamic,
 but it does specify that references must be processed in sequence as
>>> specified in the component xml:
 
 "When binding services, the references are processed in the order in
>>> which they are specified in the
 component description. That is, target services from the first specified
>>> reference are bound before
 services from the next specified reference."
 
 In addition the spec specifies how @Reference annotations are ordered:
 
 " In the generated Component Description for a component, the references
>>> must be ordered in ascending
 lexicographical order (using String.compareTo ) of the reference names."
 
 Note that the default name is based on the field or method name. In your
>>> case get aclService  for the static reference
 and "" (empty string) for the dynamic reference as spec states that the
>>> add , bind or set prefix is removed.
 ( Actually if one uses Java naming conventions the event methods will
>>> have names starting with an upper case character and precede the field
>>> references).
 
 By specifying e.g.  @Reference( name = "zStateMachine", cardinality =
>>> ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC)
 the static reference should be bound first.
 
 Note that there is still a potential race condition between the add and
>>> an activate method if present,
 or between two concurrent add() executions.
 
 regards,
 Karel
 
 On 28/11/2016 12:09, Nicolas Brasey wrote:
> Hi,
> 
> I have a bind order issue with a component that has :
> 
> 1) A static reference specified with annotation @Reference on the
>>> private
> field
> 2) A dynamic multiple reference specificed with annotation on a method
> 
> The static reference is not bound before the dynamic ones.
> 
> The code looks like this:
> 
> @Component(immediate = true)
> public class MyServiceImpl implements MyService {
> 
>   @Reference
>   private AclService aclService;
> 
>   @Reference(
>   cardinality = ReferenceCardinality.MULTIPLE,
>   policy = ReferencePolicy.DYNAMIC
>   )
>   public void add(StateMachine stateMachine) {
>  
>   
>   }
> 
> 
> According to the Declarative Service 

Re: SCR: Issues with static reference mixed with multiple dynamic ref

[Neil Bartlett]

> On 28 Nov 2016, at 11:26, Nicolas Brasey <nicolas.bra...@gmail.com> wrote:
> 
> Hi Neil,
> 
> Thanks for the quick reply.
> 
> okay I see, I misinterpreted the specs then.
> 
> In my specific case, I need to make sure the static reference is there
> *before* the dynamic ones. What is the best patterns to ensure that ? Do I
> need to write synchonization code inside my component for that, or do you
> know a cleaner way with declarative services ?


The specs do not make that guarantee, so you need to write your code in such a 
way that it doesn’t matter what order the references are processed.

Typically this means deferring whatever action you take based on those 
references being bound. For example, both the static and the dynamic bind 
methods can call into a single “updateBindings” method, which checks whether 
everything is in place. That method will certainly need to be thread-safe, and 
synchronization is one way (though not the only way) to achieve that.

Regards,
Neil


> 
> Thanks!
> 
> Nicolas
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Nov 28, 2016 at 12:13 PM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
> 
>> 
>>> On 28 Nov 2016, at 11:09, Nicolas Brasey <nicolas.bra...@gmail.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I have a bind order issue with a component that has :
>>> 
>>> 1) A static reference specified with annotation @Reference on the private
>>> field
>>> 2) A dynamic multiple reference specificed with annotation on a method
>>> 
>>> The static reference is not bound before the dynamic ones.
>> 
>> 
>> That is not required. Dynamic references can be bound, unbound or replaced
>> at any time… even potentially *while* the static references are being
>> bound, or while the activate is executing.
>> 
>> 
>>> 
>>> The code looks like this:
>>> 
>>> @Component(immediate = true)
>>> public class MyServiceImpl implements MyService {
>>> 
>>>   @Reference
>>>   private AclService aclService;
>>> 
>>>   @Reference(
>>>   cardinality = ReferenceCardinality.MULTIPLE,
>>>   policy = ReferencePolicy.DYNAMIC
>>>   )
>>>   public void add(StateMachine stateMachine) {
>>>  
>>>   
>>>   }
>>> 
>>> 
>>> According to the Declarative Service specifications, the static
>> references
>>> should always be injected before the activate method.
>> 
>> 
>> That’s correct.
>> 
>> 
>>> 
>>> 
>>> Does anyone have any idea what might be wrong ?
>> 
>> 
>> It doesn’t sound like anything is going wrong.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> 
>>> 
>>> My env is Apache Karaf 4.0.5 with Felix SCR 2.0.2
>>> 
>>> 
>>> Thanks for you help!
>>> 
>>> Nicolas
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: SCR: Issues with static reference mixed with multiple dynamic ref

[Neil Bartlett]

> On 28 Nov 2016, at 11:09, Nicolas Brasey  wrote:
> 
> Hi,
> 
> I have a bind order issue with a component that has :
> 
> 1) A static reference specified with annotation @Reference on the private
> field
> 2) A dynamic multiple reference specificed with annotation on a method
> 
> The static reference is not bound before the dynamic ones.


That is not required. Dynamic references can be bound, unbound or replaced at 
any time… even potentially *while* the static references are being bound, or 
while the activate is executing.


> 
> The code looks like this:
> 
> @Component(immediate = true)
> public class MyServiceImpl implements MyService {
> 
>@Reference
>private AclService aclService;
> 
>@Reference(
>cardinality = ReferenceCardinality.MULTIPLE,
>policy = ReferencePolicy.DYNAMIC
>)
>public void add(StateMachine stateMachine) {
>   
>
>}
> 
> 
> According to the Declarative Service specifications, the static references
> should always be injected before the activate method.


That’s correct.


> 
> 
> Does anyone have any idea what might be wrong ?


It doesn’t sound like anything is going wrong.

Regards,
Neil


> 
> 
> My env is Apache Karaf 4.0.5 with Felix SCR 2.0.2
> 
> 
> Thanks for you help!
> 
> Nicolas


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Shutdown oddities with Gogo 1.0.0

[Neil Bartlett]

Speaking of Gogo 1.0.0, I’d love it if somebody looked at 
https://issues.apache.org/jira/browse/FELIX-5392

It’s kind of a pain that I always have to have bundlerepository now, which I 
have never used!


Neil


> On 14 Nov 2016, at 16:32, David Bosschaert  wrote:
> 
> Hi Benson,
> 
> I recently came across this too. I reopened
> https://issues.apache.org/jira/browse/FELIX-5077
> 
> Cheers,
> 
> David
> 
> On 14 November 2016 at 16:15, Benson Margulies 
> wrote:
> 
>> Here is felix 5.6.1 with gogo.
>> 
>> 
>> Welcome to Apache Felix Gogo
>> 
>> g! lb
>>   11:12:55
>> START LEVEL 1
>>   ID|State  |Level|Name
>>0|Active |0|System Bundle (5.6.1)|5.6.1
>>1|Active |1|JLine (3.0.0)|3.0.0
>>2|Active |1|Apache Felix Bundle Repository (2.0.8)|2.0.8
>>3|Active |1|Apache Felix Gogo Command (1.0.0)|1.0.0
>>4|Active |1|Apache Felix Gogo JLine Shell (1.0.0)|1.0.0
>>5|Active |1|Apache Felix Gogo Runtime (1.0.0)|1.0.0
>> 
>> 
>> g! exit 0
>>   11:12:45
>> g!
>> g!
>> g!
>> g!
>> g! !!! FAILED TO STOP EXECUTOR !!!
>> 
>> If I "control-D", I get an unhappy backtrace on the way out, but not
>> always:
>> 
>> gosh: stopping framework
>> gogo: unable to create consoleInterruptedIOException: Command interrupted
>> java.io.InterruptedIOException: Command interrupted
>> at org.jline.utils.ExecHelper.exec(ExecHelper.java:43)
>> at org.jline.terminal.impl.ExecPty.doGetConfig(ExecPty.java:158)
>> at org.jline.terminal.impl.ExecPty.getAttr(ExecPty.java:86)
>> at org.jline.terminal.impl.ExecPty.setAttr(ExecPty.java:92)
>> at org.jline.terminal.impl.AbstractPosixTerminal.close(
>> AbstractPosixTerminal.java:63)
>> at org.jline.terminal.impl.PosixSysTerminal.close(
>> PosixSysTerminal.java:85)
>> at org.apache.felix.gogo.jline.Activator.doStartShell(Activator.java:159)
>> at org.apache.felix.gogo.jline.Activator.lambda$startShell$0(
>> Activator.java:106)
>> at java.lang.Thread.run(Thread.java:745)
>> Caused by: java.lang.InterruptedException
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at java.lang.UNIXProcess.waitFor(UNIXProcess.java:396)
>> at org.jline.utils.ExecHelper.waitAndCapture(ExecHelper.java:63)
>> at org.jline.utils.ExecHelper.exec(ExecHelper.java:36)
>> ... 8 more
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: how can a bundle stop itself programmatically?

[Neil Bartlett]

Change the logic of the update… instead of always replacing the security.policy 
file, replace it only if it is not already in the required state. This makes 
your bundle idempotent (it doesn’t matter how many times it is called) which is 
a much more robust approach.

Neil

> On 19 Oct 2016, at 07:05, sid19039  wrote:
> 
> Hello Ray,
> 
> Thanks for your reply. Following is our use case:
> 
> we are making a bundle which would be used as a security patch meant to
> update a security.policy file.
> Now the scenario is that we are deploying that bundle on to a felix
> framework target via Apache Ace server. For the very first time when it
> starts, it updates the file - which is ok. But Apache Ace server refreshes
> the felix framework i.e it restarts all of the bundles installed previously
> also each time some new bundle is deployed onto the target. Due to which our
> security bundle also restarts and update security.policy file again which is
> not required. So we want it(the bundle) to be removed from the framework
> once it updates the file or simply runs only once until somebody tries to
> update the file by deploying its new version.
> 
> Any suggestions would be very helpful.
> 
> Regards
> Siddharth
> 
> 
> 
> --
> View this message in context: 
> http://apache-felix.18485.x6.nabble.com/how-can-a-bundle-stop-itself-programmatically-tp5018885p5018894.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: OSGi Declarative Services

[Neil Bartlett]

Oh I see. For that you should use a configuration type. See the first section 
of http://njbartlett.name/2015/08/17/osgir6-declarative-services.html

Regards,
Neil



> On 2 Oct 2016, at 22:43, Roy Teeuwen <r...@teeuwen.be> wrote:
> 
> Hey Neil,
> 
> See 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property
>  
> <http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property>
> Here you see you can also assign a label and a description to a property, 
> these will then be shown when configuring a component in the felix web 
> console. 
> Thats what I am looking for in the new OSGi DS
> 
> Greets,
> Roy
>> On 2 Oct 2016, at 23:37, Neil Bartlett <njbartl...@gmail.com> wrote:
>> 
>> Hi Roy,
>> 
>> What are you looking for exactly? Service properties are simply key-value 
>> pairs.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> On 2 Oct 2016, at 22:13, Roy Teeuwen <r...@teeuwen.be> wrote:
>>> 
>>> Hey all,
>>> 
>>> Seeing as we upgraded our instance, we want to switch from Apache Felix SCR 
>>> Annotations to OSGi Declarative Services for new components. 
>>> One of the things I noticed is that there is no @Property and @Properties 
>>> in declarative services. Is there still a way to provide label and 
>>> descriptions for properties? 
>>> Looking at the @Component it is just key=value property types, without any 
>>> extra metadata.
>>> 
>>> Greets,
>>> Roy
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: OSGi Declarative Services

[Neil Bartlett]

Hi Roy,

What are you looking for exactly? Service properties are simply key-value pairs.

Regards,
Neil


> On 2 Oct 2016, at 22:13, Roy Teeuwen  wrote:
> 
> Hey all,
> 
> Seeing as we upgraded our instance, we want to switch from Apache Felix SCR 
> Annotations to OSGi Declarative Services for new components. 
> One of the things I noticed is that there is no @Property and @Properties in 
> declarative services. Is there still a way to provide label and descriptions 
> for properties? 
> Looking at the @Component it is just key=value property types, without any 
> extra metadata.
> 
> Greets,
> Roy
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Neil Bartlett]

Hmm. This indicates that previously the cm export was satisfied by another 
bundle. Which of course it was because the Felix Config Admin implementation 
exports that package (in addition to importing it).

I am a little uncomfortable relying on this. I believe it would be legal for 
the framework to choose the export from the Config Admin bundle rather than 
from the system bundle. Ordinarily this would be fine because the consumer 
bundle would just wire to that export instead, but in your scenario the 
consumer bundle IS the system bundle, which cannot import.

Then again maybe the system bundle export will reliably take precedence. I’m 
not 100% clear on this.

Neil


> On 18 Sep 2016, at 20:44, Benson Margulies <ben...@basistech.com> wrote:
> 
> As usual, the answer occurred to me moments after I pressed 'send'. I
> neglected to specify a version for org.osgi.service.cm when adding it
> to the system bundle export list.
> 
> On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
>> This should work, but without a code sample it’s impossible to say what 
>> might be going wrong.
>> 
>> The usual pattern would be:
>> 
>> 1. Init and start the framework
>> 2. Install the bundles, including configadmin
>> 3. Create and open your tracker
>> 4. Start the bundles
>> 5. Enter framework.waitForStop(), where you will remain.
>> 
>> Config Admin will likely publish itself synchronously in step 4, and you 
>> will get a callback on the tracker. Or it might publish the service 
>> asynchronously later, which is also okay.
>> 
>> Neil
>> 
>>> On 18 Sep 2016, at 19:53, Benson Margulies <ben...@basistech.com> wrote:
>>> 
>>> My current task is to set up a Felix framework behind an API. To get
>>> actual work done, there are some interfaces in packages on the system
>>> bundle that are published by bundles of mine, and then the code
>>> 'outside' the framework obtains them.
>>> 
>>> For the main service I created, this all works find with a
>>> ServiceTracker as the tool for waiting for the code inside the
>>> container to get around (via SCR) to publishing the service I need.
>>> 
>>> Next, I decided that, as part of my bootstrap process, it would make
>>> sense for me to push some configuration into ConfigurationAdmin. So, I
>>> added the 'cmpn' jar to the outer classpath, and org.osgi.service.cm
>>> to the system bundle, and tried to use a service tracker to obtain a
>>> ConfigurationAdmin reference.
>>> 
>>> 'waitForService' on the tracker waits forever.
>>> 
>>> In the debugger, I can (eventually) obtain the ConfigurationAdmin
>>> reference against the system bundle context. So this leads me to
>>> believe that there's something I don't understand about threads and
>>> Felix; I was expecting that once I started the framework, things like
>>> activation of the ConfigurationAdmin service would happen on some
>>> other thread, so I could have my main thread wait for it with a
>>> ServiceTracker.
>>> 
>>> I can give up on this ConfigurationAdmin-from-outside bootstrap in
>>> favor of passing some properties into an interface of a service of
>>> mine, and let _it_ negotiate with ConfigurationAdmin for me, so if
>>> this whole approach is poor it's easy to abandon.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Neil Bartlett]

This should work, but without a code sample it’s impossible to say what might 
be going wrong.

The usual pattern would be:

1. Init and start the framework
2. Install the bundles, including configadmin
3. Create and open your tracker
4. Start the bundles
5. Enter framework.waitForStop(), where you will remain.

Config Admin will likely publish itself synchronously in step 4, and you will 
get a callback on the tracker. Or it might publish the service asynchronously 
later, which is also okay.

Neil

> On 18 Sep 2016, at 19:53, Benson Margulies  wrote:
> 
> My current task is to set up a Felix framework behind an API. To get
> actual work done, there are some interfaces in packages on the system
> bundle that are published by bundles of mine, and then the code
> 'outside' the framework obtains them.
> 
> For the main service I created, this all works find with a
> ServiceTracker as the tool for waiting for the code inside the
> container to get around (via SCR) to publishing the service I need.
> 
> Next, I decided that, as part of my bootstrap process, it would make
> sense for me to push some configuration into ConfigurationAdmin. So, I
> added the 'cmpn' jar to the outer classpath, and org.osgi.service.cm
> to the system bundle, and tried to use a service tracker to obtain a
> ConfigurationAdmin reference.
> 
> 'waitForService' on the tracker waits forever.
> 
> In the debugger, I can (eventually) obtain the ConfigurationAdmin
> reference against the system bundle context. So this leads me to
> believe that there's something I don't understand about threads and
> Felix; I was expecting that once I started the framework, things like
> activation of the ConfigurationAdmin service would happen on some
> other thread, so I could have my main thread wait for it with a
> ServiceTracker.
> 
> I can give up on this ConfigurationAdmin-from-outside bootstrap in
> favor of passing some properties into an interface of a service of
> mine, and let _it_ negotiate with ConfigurationAdmin for me, so if
> this whole approach is poor it's easy to abandon.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Semantics of Require-Capability of a service derived from DS @Reference

[Neil Bartlett]

It looks like you have solved this problem over in the bndtools-users list, but 
I want to point out one small misapprehension:

> On 31 Aug 2016, at 13:39, Benson Margulies  wrote:
> 
> The maven-bundle-plugin, in some cases, with _dsannotations enabled,
> produces Require-Capability instructions like the following:
> 
> Require-Capability: osgi.service;filter:="(objectClass=com.basistech.ros
> ette.osgi.Bus)";effective:=active,osgi.ee;filter:="(&(osgi.ee=JavaSE)(v
> ersion=1.8))"
> 
> I only noticed them when Karaf 4.0.6 stopped being able to resolve
> these. I assume that these derive somehow from DS @References, but the
> filters in the DS references are not fully copied into here.
> 
> The service in question is activated by a bundle that is present in
> the overall provisioning, but apparently is not starting before the
> Karaf resolver gets going.

The started state of the bundle providing these services is irrelevant. A 
Require-Capability header is always matched by a Provide-Capability header. The 
bundle that Provides the capability does not need to be started, it only needs 
to be resolved or resolvable.

By the way, the correct way to read such a Provide-Capability header is not 
that the bundle always provides the service but that it has the *potential* to 
provide a service, some of the time… if it feels like it. That’s why these 
requirements and capabilities are effective:=active, they should only be 
treated as hints to a provisioning agent and not as instructions to the OSGi 
Framework.



> Are these instructions required for DS? I'm
> about to try switching to the bnd-maven-plugin and see if I see
> anything different.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

[Neil Bartlett]

> On 12 Aug 2016, at 12:59, Benson Margulies  wrote:
> 
> On Fri, Aug 12, 2016 at 7:54 AM, Karel Haeck  > wrote:
>> 
>> You typically use a serviceTracker in the test bundle to obtain a reference
>> to the component 's service.
>> See http://enroute.osgi.org/tutorial_base/600-testing.html 
>>  for how to do
>> this in bndtools.
>> The service tracker open method will trigger the component's delayed
>> activation
> 
> I didn't realize that the service tracker could interact with DS. Thanks.


This is the great thing about OSGi Services — they enable any framework to 
interact with any other framework. You only need to use DS where it makes 
sense. In other places you might want to use low-level API or even another 
framework like Blueprint.

Okay just kidding, you never want to use Blueprint!! But hopefully you get the 
idea.

Neil

> 
> 
>> 
>> Karel
>> 
>> 
>> On 12/08/2016 13:30, Benson Margulies wrote:
>>> 
>>> Thank you all. Indeed, the component was not 'immediate', and that's
>>> why it wasn't set up.
>>> 
>>> My task of the moment it to add pax-exam tests for some individual
>>> components; in the past, I only tested this stuff with broad
>>> functional tests. This has led me, on this particular occasion,  end
>>> up trying to test this not-immediate component.
>>> 
>>> How do other people create pax-exam tests for @Components that are not
>>> immediate? By adding DS metadata to pax-exam bundles?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> g! scr:info com.basistech.ws.worker.core.Worker
>>> *** Bundle: rosapi-worker-core (59)
>>> Component Description:
>>>   Name: com.basistech.ws.worker.core.Worker
>>>   Implementation Class: com.basistech.ws.worker.core.Worker
>>>   Default State: enabled
>>>   Activation: immediate
>>>   Configuration Policy: ignore
>>>   Activate Method: activate
>>>   Deactivate Method: deactivate
>>>   Modified Method: -
>>>   Configuration Pid: [com.basistech.ws.worker.core.Worker]
>>>   Services:
>>> com.basistech.ws.worker.api.WorkerInterface
>>>   Service Scope: singleton
>>>   Reference: BusService
>>> Interface Name: com.basistech.ws.worker.api.WorkerBusService
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>>   Reference: WorkerComponentServices
>>> Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>>   Reference: WorkerConfiguration
>>> Interface Name:
>>> com.basistech.ws.worker.core.config.WorkerConfiguration
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>>   Component Description Properties:
>>>   Component Configuration:
>>> ComponentId: 5
>>> State: active
>>> SatisfiedReference: BusService
>>>   Target: null
>>>   Bound to:39
>>>   Reference Properties:
>>>   component.id = 3
>>>   component.name = com.basistech.ws.worker.bus.impl.BusService
>>>   licensePathname =
>>> 
>>> /Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
>>>   objectClass = [com.basistech.ws.worker.api.WorkerBusService]
>>>   service.bundleid = 24
>>>   service.id = 39
>>>   service.pid = com.basistech.ws.bus
>>>   service.scope = bundle
>>> SatisfiedReference: WorkerComponentServices
>>>   Target: null
>>>   Bound to:56
>>>   Reference Properties:
>>>   objectClass =
>>> [com.basistech.ws.worker.core.WorkerComponentServices]
>>>   service.bundleid = 59
>>>   service.id = 56
>>>   service.scope = singleton
>>> SatisfiedReference: WorkerConfiguration
>>>   Target: null
>>>   Bound to:40
>>>   Reference Properties:
>>>   component.id = 6
>>>   component.name =
>>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>>   configurationFilePathname =
>>> 
>>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>>>   endpointsPathname =
>>> 
>>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>>>   native-root =
>>> 
>>> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
>>>   objectClass =
>>> [com.basistech.ws.worker.core.config.WorkerConfiguration]
>>>   service.bundleid = 59
>>>   service.id = 40
>>>   service.pid = com.basistech.ws.worker
>>>   service.scope = bundle
>>>   subst = tsbus
>>> Component Configuration Properties:
>>> component.id = 5
>>> component.name = com.basistech.ws.worker.core.Worker
>>> 
>>> On Fri, Aug 12, 2016 at 6:05 

Re: scr claims to be unsatisfied for service that seems to be there

[Neil Bartlett]

Thanks Carsten, that was my expectation but I was waiting for the “inspect cap 
service” output to confirm.

One thing that can be quite confusing is that the service references, with 
cardinality of 1..1, are described as both satisfied and unbound. This sounds 
like a contradiction until you realise the component has not yet been 
instantiated. I assume that SCR at this point does know which services it 
*will* bind when the component is activated… maybe these could be shown here?

Neil


> On 12 Aug 2016, at 10:50, Carsten Ziegeler  wrote:
> 
> Your service is marked as "satisfied" but as noone else is using it,
> it's not activated. That's the lazy activation of SCR.
> 
> Carsten
> 
>> I have a component, which scr:info reports that is has three unbound 
>> references.
>> 
>> scr:info on the components that provide those services seem to show
>> that they are there. And if I set breakpoints on their activate
>> methods (they are @Components), they've been called, and did not
>> throw. I've put an scr:info for one of them at the end. What would
>> cause SCR to not pass these services into the component and activate
>> it?
>> 
>> g! scr:info com.basistech.ws.worker.core.Worker
>> *** Bundle: rosapi-worker-core (59)
>> Component Description:
>>  Name: com.basistech.ws.worker.core.Worker
>>  Implementation Class: com.basistech.ws.worker.core.Worker
>>  Default State: enabled
>>  Activation: delayed
>>  Configuration Policy: ignore
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid: [com.basistech.ws.worker.core.Worker]
>>  Services:
>>com.basistech.ws.worker.api.WorkerInterface
>>  Service Scope: singleton
>>  Reference: BusService
>>Interface Name: com.basistech.ws.worker.api.WorkerBusService
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: WorkerComponentServices
>>Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: WorkerConfiguration
>>Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Component Description Properties:
>>  Component Configuration:
>>ComponentId: 5
>>State: satisfied
>>SatisfiedReference: BusService
>>  Target: null
>>  (unbound)
>>SatisfiedReference: WorkerComponentServices
>>  Target: null
>>  (unbound)
>>SatisfiedReference: WorkerConfiguration
>>  Target: null
>>  (unbound)
>>Component Configuration Properties:
>>component.id = 5
>>component.name = com.basistech.ws.worker.core.Worker
>> 
>> 
>> 
>> g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>> *** Bundle: rosapi-worker-core (59)
>> Component Description:
>>  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>  Implementation Class:
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>  Default State: enabled
>>  Activation: immediate
>>  Configuration Policy: require
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid: [com.basistech.ws.worker]
>>  Services:
>>com.basistech.ws.worker.core.config.WorkerConfiguration
>>  Service Scope: singleton
>>  Component Description Properties:
>>  Component Configuration:
>>ComponentId: 6
>>State: active
>>Component Configuration Properties:
>>component.id = 6
>>component.name =
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>configurationFilePathname =
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>>endpointsPathname =
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>>native-root =
>> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
>>service.pid = com.basistech.ws.worker
>>subst = tsbus
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

[Neil Bartlett]

Please show:

1. The scr:info for the component that has unbound service references
2. The “inspect service” output that proves a service is available (showing 
scr:info for some other component does NOT prove this).

Neil



> On 12 Aug 2016, at 03:12, Benson Margulies  wrote:
> 
> I have a component, which scr:info reports that is has three unbound 
> references.
> 
> scr:info on the components that provide those services seem to show
> that they are there. And if I set breakpoints on their activate
> methods (they are @Components), they've been called, and did not
> throw. I've put an scr:info for one of them at the end. What would
> cause SCR to not pass these services into the component and activate
> it?
> 
> g! scr:info com.basistech.ws.worker.core.Worker
> *** Bundle: rosapi-worker-core (59)
> Component Description:
>  Name: com.basistech.ws.worker.core.Worker
>  Implementation Class: com.basistech.ws.worker.core.Worker
>  Default State: enabled
>  Activation: delayed
>  Configuration Policy: ignore
>  Activate Method: activate
>  Deactivate Method: deactivate
>  Modified Method: -
>  Configuration Pid: [com.basistech.ws.worker.core.Worker]
>  Services:
>com.basistech.ws.worker.api.WorkerInterface
>  Service Scope: singleton
>  Reference: BusService
>Interface Name: com.basistech.ws.worker.api.WorkerBusService
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Reference: WorkerComponentServices
>Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Reference: WorkerConfiguration
>Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Component Description Properties:
>  Component Configuration:
>ComponentId: 5
>State: satisfied
>SatisfiedReference: BusService
>  Target: null
>  (unbound)
>SatisfiedReference: WorkerComponentServices
>  Target: null
>  (unbound)
>SatisfiedReference: WorkerConfiguration
>  Target: null
>  (unbound)
>Component Configuration Properties:
>component.id = 5
>component.name = com.basistech.ws.worker.core.Worker
> 
> 
> 
> g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
> *** Bundle: rosapi-worker-core (59)
> Component Description:
>  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>  Implementation Class:
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>  Default State: enabled
>  Activation: immediate
>  Configuration Policy: require
>  Activate Method: activate
>  Deactivate Method: deactivate
>  Modified Method: -
>  Configuration Pid: [com.basistech.ws.worker]
>  Services:
>com.basistech.ws.worker.core.config.WorkerConfiguration
>  Service Scope: singleton
>  Component Description Properties:
>  Component Configuration:
>ComponentId: 6
>State: active
>Component Configuration Properties:
>component.id = 6
>component.name =
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>configurationFilePathname =
> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>endpointsPathname =
> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>native-root =
> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
>service.pid = com.basistech.ws.worker
>subst = tsbus
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: NoClassDefFoundError of classes that are in the JRE

[Neil Bartlett]

I want to try to give you a more solid basis for these discoveries.

A bundle MUST import all of the packages that it both (a) uses (that is, refers 
to from contained types) and (b) does not contain. There is a single exception 
to this rule: all package names beginning with “java.” are loaded by delegation 
to the Boot ClassLoader and cannot be imported.

See OSGi R6 Core Specification, section 3.9.3: "The Framework must always 
delegate any package that starts with java. to the parent class loader”. The 
reason for this exception is a security rule in the JVM… see the JavaDocs for 
ClassLoader.defineClass(): “SecurityException …  if name begins with 
"java.”. Only the Boot Class Loader is permitted to define classes in 
the “java.*” namespace. Everything else such as “javax.*” can and must be 
imported.

The OSGi Framework normally exports the standard set of Java SE packages from 
the System Bundle, so if you want javax.xml.parsers then you just import 
javax.xml.parsers and it gets wired to the export from the system bundle. I 
note that javax.xml.parsers is a standard Java SE package (since Java 1.4) and 
therefore should be exported already. Unfortunately the JCP specifications 
don’t provide versions for Java SE packages therefore the Framework exports 
them all as version 0.0.0.

However, the System, Bundle exports can be overridden with configuration. This 
is normally done if you want to use a non-standard JRE package like “sun.misc” 
– you can make the System Bundle export this package by specifying 
“org.osgi.framework.system.packages.extra=sun.misc”. It’s also possible for 
somebody to override the default behaviour and remove some of the Java SE 
packages. I have no idea whether WebLogic does this or not.

Finally, just because some other bundle imports a package doesn’t mean that 
your bundle gets that import too. I refer you back to the rule above: a bundle 
MUST import all the packages it uses except for those named java.*.

I hope this helps,

Neil



> On 11 Aug 2016, at 14:05, Remo Liechti  wrote:
> 
> Found it. You need to pass that imports along all bundles in between.
> 
> Let's say, you have bundle A, B and C. And Bundle C uses some javax.xml.* 
> stuff, while the bundles hierarchy sis like:
> A=Com.foo
> B=com.foo.bar
> C=com.foo.bar.util
> 
> Now you first need to add the javax.xml.parsers to the the extra property as 
> you said, then you need to add it to all of those 3 bundles as import 
> property.
> Afterwards, its loading.
> 
> Thanks mate!
> 
> 
> -Original Message-
> From: Robert Onslow [mailto:robert.ons...@gmail.com]
> Sent: Donnerstag, 11. August 2016 14:32
> To: users@felix.apache.org
> Subject: Re: NoClassDefFoundError of classes that are in the JRE
> 
> Nothing that occurs to me, unfortunately Remo Robert
> 
> On Thu, Aug 11, 2016 at 11:36 AM, Remo Liechti  
> wrote:
>> Robert
>> 
>> Thanks for pointing this out. I found the config location and in Weblogic 
>> you can actually set this property, but it seems to have no effect. I'll 
>> open a tracker with Oracle on this.
>> Anything else I can try?
>> 
>> Thanks
>> 
>> 
>> -Original Message-
>> From: Robert Onslow [mailto:robert.ons...@gmail.com]
>> Sent: Donnerstag, 11. August 2016 11:09
>> To: users@felix.apache.org
>> Subject: Re: NoClassDefFoundError of classes that are in the JRE
>> 
>> Remo
>> 
>> The other thing you may need to do is find the configuration file for
>> the felix installation, something like config.properties, and set
>> 
>> org.osgi.framework.system.packages.extra=javax.xml.parser, 
>> 
>> There's no need for a version number
>> 
>> Robert
>> 
>> On Thu, Aug 11, 2016 at 9:34 AM, Remo Liechti  
>> wrote:
>>> Hi Robert
>>> 
>>> Good to hear that. Anything else to put in, like version number or the 
>>> like? When I put it in like this, it didn't work:
>>> 
>>> Import-Package: javax.xml.parsers,
>>> ...,
>>> ...,
>>> 
>>> Thanks
>>> 
>>> 
>>> -Original Message-
>>> From: Robert Onslow [mailto:robert.ons...@gmail.com]
>>> Sent: Donnerstag, 11. August 2016 10:15
>>> To: users@felix.apache.org
>>> Subject: Re: NoClassDefFoundError of classes that are in the JRE
>>> 
>>> Remo
>>> 
>>> When I moved from eclipse to felix I found that everything apart from
>>> java.* has to be imported as in
>>> 
>>> Import-Package: javax.xml.parsers
>>> 
>>> Robert
>>> 
>>> On Thu, Aug 11, 2016 at 9:02 AM, Remo Liechti  
>>> wrote:
 Hi guys
 
 Another issue I came across while bundling the osgi application into a 
 webapplication for WebLogic.
 It seems like some of the bundles I like to start fail during activation, 
 because they cannot find the class description of classes that actually 
 are in the regular JRE:
 

 

Re: Logging uncaught exceptions?

[Neil Bartlett]

> On 4 Aug 2016, at 20:47, list+org.apache.fe...@io7m.com wrote:
> 
> On 2016-08-04T12:37:02 -0700
> David Jencks  wrote:
> 
>> BundleActivator behavior and DS component behavior are completely unrelated.
> 
> Hm, OK. I erroneously assumed that DS components would be built upon
> the activator behaviour. Clearly not!

Components have activate/deactivate methods but they are not BundleActivators 
because components are not bundles.

However, components are shipped *inside* bundles, and the containing bundle 
must be active in order for any of the components to be active. This can lead 
to an apparent connection, where the components get activated as a result of 
the bundle being activated.

Sorry that I missed this in your original mail, and well spotted David.


> 
>> I strongly suspect that you haven’t installed anything to record the logging 
>> or display it to you?  IIRC pax-logging is a popular way to hook osgi 
>> logging up to slf4j and make it easy to configure where it goes.
> 
> You suspect correctly!
> 
> START LEVEL 1
>   ID|State  |Level|Name
>0|Active |0|System Bundle (5.4.0)|5.4.0
>1|Active |1|Apache Felix Bundle Repository (2.0.6)|2.0.6
>2|Active |1|Apache Felix Configuration Admin Service 
> (1.8.10)|1.8.10
>3|Active |1|Apache Felix Gogo Command (0.16.0)|0.16.0
>4|Active |1|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>5|Active |1|Apache Felix Gogo Shell (0.10.0)|0.10.0
>6|Active |1|Apache Felix Log Service (1.0.1)|1.0.1
>7|Active |1|Apache Felix Metatype Service (1.1.2)|1.1.2
>8|Active |1|Apache Felix Declarative Services (2.0.4)|2.0.4
>   12|Active |1|application (0.1.0)|0.1.0
> 
> I'm currently only experimenting, so unless I've seen documentation 
> suggesting something, I don't have it installed.
> 
> I'll take a look at pax-logging. I use slf4j everywhere else, so 
> it seems like the right thing to do.
> 
> M


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Logging uncaught exceptions?

[Neil Bartlett]

If you DON'T install a log service, the errors are actually printed to the 
console.

If you DO have a log service then just use the command “log ” to list 
the most recent log entries at that level or above. For example “log warn” will 
give all the warnings and errors but not info or debug. This has a small 
advantage over printing to the console because you can show the entries at any 
time rather than scrolling back to when they happened.

Regards,
Neil

> On 4 Aug 2016, at 20:29, list+org.apache.fe...@io7m.com wrote:
> 
> Hello.
> 
> I have a simple declarative service such as:
> 
> --8<--
> @Component(immediate = true)
> public final class Speaker implements SpeakerType
> {
>  public Speaker()
>  {
>System.out.println("Speaker (declarative): constructor");
>  }
> 
>  @Activate
>  private void onActivate()
>  {
>System.out.println("Speaker (declarative): onActivate");
>  }
> 
>  @Override
>  public void speak(final String text)
>  {
>System.out.println("Speaker (declarative): speak: " + text);
>  }
> }
> -->8--
> 
> If I throw an exception in either the constructor or the onActivate()
> method, I get no indication that this has happened. A quick search
> through the core spec for the word "exceptions" leads me to 9.3.6,
> which I think may be relevant even though I'm going through the
> declarative services service:
> 
>  If the BundleActivator.start or stop method throws an Exception, then
>  the handling of this Exception is different depending who invoked
>  the start or stop method. 
> 
>  If the bundle is started/stopped due to a change in the active start
>  level or the bundle's start level, then the Exception must be wrapped
>  in a BundleException and broadcast as a FrameworkEvent.ERROR event.
>  Otherwise, a new BundleException must be created containing the
>  exception and this BundleException is then thrown to the caller.
> 
> So I assume that I need to register some sort of listener to receive
> errors. However, even assuming that I do this: What if the exception is
> of a type that the listener does not import?
> 
> Is there a bundle in the distribution that handles this? I have the Log
> service installed, but that doesn't appear to do anything (unless it
> requires extra configuration - I've not given it any). I just
> want errors logged to the console during development so that I don't
> sit here trying to debug silent failures.
> 
> M


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: doubt about component DS 1.3 with scope Prototype and ConfigurationPolicy.REQUIRE

[Neil Bartlett]

> On 27 Jun 2016, at 23:05, Cristiano Gavião <cvgav...@gmail.com> wrote:
> 
> Thanks David and Neil,
> 
> Humm, I don't think I understood yet.
> 
> Ok, I don't have any other bundle/component consuming this service, yet.
> 
> but in this case why I have an instance of the service that received the 
> configuration from CM registered ?

You don’t have an instance… you have a service registration. When another 
bundle sees this in the service registry and calls getService(), then an 
instance of the class will be created in order to provide the service. This is 
a key laziness feature offered by DS.

Regards,
Neil


> 
> Look at the log below:
> 
>   18:54:13.557 INFO : com.c4biz.feast.kernel.lib [ OSGI_BUNDLE ]:
>   ServiceEvent REGISTERED
>   
> [S:{com.c4biz.feast.FixedControllerService}={service.pid=fixed.controller-1467064453446-0,
>   service.factoryPid=fixed.controller,
>   component.name=com.c4biz.feast.ComponentControllerServiceProvider,
>   extenderAlias=ConfigurationManifestHeaderExtender,
>   targetBundleStateMask=32, component.id=4,
>   targetTrackingMode=manifest_header, service.id=56,
>   service.bundleid=18, service.scope=prototype}]
> 
> 
> 
> On 27/06/2016 18:47, Neil Bartlett wrote:
>> Probably lazy activation. Your component is a service, of type 
>> FixedControllerService. No instances will be created until a consumer binds 
>> to it.
>> 
>> Neil
>> 
>> 
>>> On 27 Jun 2016, at 22:42, Cristiano Gavião <cvgav...@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I'm facing a situation that I'm not understanding. I'm using 
>>> org.apache.felix.scr 2.0.2.
>>> I've set a component with this annotation:
>>> 
>>>   @Component(enabled = true, configurationPolicy =
>>>   ConfigurationPolicy.REQUIRE,
>>>scope = ServiceScope.PROTOTYPE, service =
>>>   FixedControllerService.class,
>>>configurationPid = {SERVICE_FACTORY_PID_CONTROLLER})
>>> 
>>>   http://www.osgi.org/xmlns/scr/v1.3.0;
>>>   name="com.c4biz.feast.ComponentControllerServiceProvider"
>>>   configuration-policy="require" enabled="true" activate="activate"
>>>   deactivate="deactivate" modified="modified"
>>>   configuration-pid="fixed.controller">
>>>  >>   class="com.c4biz.feast.ComponentControllerServiceProvider"/>
>>>  
>>>
>>>  
>>>   
>>> 
>>> In this component class I have a method (activate()) tagged with @Activate 
>>> annotation. And there are any reference bind being used for now.
>>> 
>>> From another bundle I'm creating a configuration using factoryPID = 
>>> SERVICE_FACTORY_PID_CONTROLLER.
>>> Interesting is that the service are being created and with in a proper 
>>> autogenerated PID and passed properties. At least I can see it when listing 
>>> the services using gogo console.
>>> 
>>> also scr:list tells me that the component is enabled and satisfied.
>>> 
>>> What I'm not understanding is that the activate method is not being 
>>> called...
>>> 
>>> could someone explain me what am I missing here?
>>> 
>>> thanks,
>>> 
>>> Cristiano
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: doubt about component DS 1.3 with scope Prototype and ConfigurationPolicy.REQUIRE

[Neil Bartlett]

Probably lazy activation. Your component is a service, of type 
FixedControllerService. No instances will be created until a consumer binds to 
it.

Neil


> On 27 Jun 2016, at 22:42, Cristiano Gavião  wrote:
> 
> Hello,
> 
> I'm facing a situation that I'm not understanding. I'm using 
> org.apache.felix.scr 2.0.2.
> I've set a component with this annotation:
> 
>   @Component(enabled = true, configurationPolicy =
>   ConfigurationPolicy.REQUIRE,
>scope = ServiceScope.PROTOTYPE, service =
>   FixedControllerService.class,
>configurationPid = {SERVICE_FACTORY_PID_CONTROLLER})
> 
>   http://www.osgi.org/xmlns/scr/v1.3.0;
>   name="com.c4biz.feast.ComponentControllerServiceProvider"
>   configuration-policy="require" enabled="true" activate="activate"
>   deactivate="deactivate" modified="modified"
>   configuration-pid="fixed.controller">
> class="com.c4biz.feast.ComponentControllerServiceProvider"/>
>  
>
>  
>   
> 
> In this component class I have a method (activate()) tagged with @Activate 
> annotation. And there are any reference bind being used for now.
> 
> From another bundle I'm creating a configuration using factoryPID = 
> SERVICE_FACTORY_PID_CONTROLLER.
> Interesting is that the service are being created and with in a proper 
> autogenerated PID and passed properties. At least I can see it when listing 
> the services using gogo console.
> 
> also scr:list tells me that the component is enabled and satisfied.
> 
> What I'm not understanding is that the activate method is not being called...
> 
> could someone explain me what am I missing here?
> 
> thanks,
> 
> Cristiano


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [maven-bundle-plugin] v.3.0.x regression for DS xml generation ?

[Neil Bartlett]

FWIW… I don’t think that List field should be volatile. SCR doesn’t replace the 
whole List, it calls the add/remove methods. The list itself can (and probably 
should) be final.

Neil

> On 25 Jun 2016, at 16:22, Christian Schneider  wrote:
> 
> I also had problems with the maven-bundle-plugin recently when using
> 
> @Reference
> volatile List myList;
> 
> This should create a dynamic list but did not work in maven-bundle-plugin. 
> After asking on the bndtools user list I got the response that
> it was a bug in an older version of bnd and that maven-bundle-plugin still 
> uses this old version.
> 
> I was able to fix this by switching to the bnd-maven-plugin. So I think the 
> maven-bundle-plugin should be updated to this newest bnd version.
> 
> Maybe you are facing a similar problem.
> 
> Christian
> 
> On 01.06.2016 22:25, Cristiano Gavião wrote:
>> Hi,
>> 
>> I used to use m-b-p version 2.5.4 and the generation of the DS component 
>> xmls was working fine.
>> 
>> But after I moved to version 3.0.1 (also tried with 3.0.0) the xml 
>> generation simply stops to work. also inside eclipse (with m2e).
>> 
>> There are any error message in the building maven console or eclipse 
>> console, but the xmls are simply not there...
>> 
>> I moved back to 2.5.4 again and things back to normal
>> 
>> I'm using the setup bellow:
>> 
>>   
>>   org.apache.felix
>>   maven-bundle-plugin
>> ${mbp.version}
>>true
>>
>>   NONE
>>
>>   ${project.url}
>>   ${project.name}
>> ${bundle.full.version}
>> lazy
>>   <_dsannotations>*
>>   <_metatypeannotations>*
>> JavaSE-1.8
>>   <_snapshot>${osgi-version-qualifier}
>> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))
>>
>>
>>   bundle
>>   jar
>>
>>
>>   
>>
>>   gen-bundle-manifest
>>
>>   manifest
>>
>>   process-classes
>>
>> 
>>
>>   all-permissions
>> {maven-dependencies},{maven-resources},META-INF/LICENSE=LICENSE.txt
>> <_removeheaders>Include-Resource,Private-Package,Ignore-Package
>>
>>
>>
>>
>> 
>> anyone have experienced this issue ?
>> 
>> thanks,
>> 
>> Cristiano
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Same private service in different bundles

[Neil Bartlett]

I guarantee that you will waste a lot of time on Find Hooks. Please don’t go 
that route!

The service *should* already be private so what you need to do is work out why 
that is not the case. Both bundles should simply contain the interface package 
as a private package. If either of them need to export the package (e.g. 
because other bundles also need it) then they must NOT import it.

Regards,
Neil



> On 17 Jun 2016, at 13:10, Vincent Vandemeulebrouck 
> <vincent.vandemeulebro...@ullink.com> wrote:
> 
> In our case, the reason behind the bundle-private service is that it is
> based on different other public services.
> 
> The current solution we have is to instantiate an object with all the
> requirements as construction parameters.
> 
> It becomes impractical because we have to repeat the exact same
> initialization ((add 3-4 requires, creation, call to the interesting
> method) in lots of different places just to have access to a very basic
> information. We end up with a lot of duplication in different components of
> different bundles. So an approach to simplify was to use a bundle private
> service that aggregates other services.
> 
> We tried different approaches, but have not found how to filter correctly,
> the other bundle service is visible. Basically, it is the same class (could
> be in a different version, but same java class & package, providing itself
> as implementation), loaded by another ClassLoader.
> 
> I will investigate how the
> https://osgi.org/javadoc/r6/core/org/osgi/framework/hooks/service/FindHook.html,
> can be used.
> 
> Thanks for the advice.
> 
> 
> *--Vincent Vandemeulebrouck | *Architect - UL MIDDLE and Extensions *|
> ULLINK | *D: +33 1 44 50 52 02* | *T: +33 1 49 95 30 00* | *23-25 rue de
> Provence, 75009 Paris, FRANCE *|* vincent.vandemeulebro...@ullink.com
> *| *
> <http://www.ullink.com/>
> 
> 
> 2016-06-17 13:53 GMT+02:00 Neil Bartlett <njbartl...@gmail.com>:
> 
>> You don’t need to use either registry hooks or regions for this. If the
>> service interface package is private within the bundle (or if each bundle
>> does not import the interface package from the other bundle) then your
>> service will only be visible within its own bundle. This is known as
>> service compatibility filtering — it is a core feature of the Service
>> Registry and it exists precisely to prevent the ClassCastException you are
>> talking about.
>> 
>> I also agree with David’s second paragraph. If the “service” is only used
>> within one bundle then why make it a service at all? Java’s  “new” keyword
>> is more concise and convenient.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> On 17 Jun 2016, at 12:47, David Bosschaert <david.bosscha...@gmail.com>
>> wrote:
>>> 
>>> You can also use OSGi Service Registry Hooks to enforce this, see here:
>>> 
>> https://osgi.org/javadoc/r6/core/org/osgi/framework/hooks/service/package-summary.html
>>> You would implement the service hooks in a separate bundle to control
>> which
>>> client gets which service.
>>> 
>>> On the other hand, if the object provided by the bundle should only be
>> used
>>> by its own bundle, I'm wondering whether services are the best approach.
>>> You could consider just instantiating the object directly if it's only
>> used
>>> within its own bundle. Services are really aimed at being useful outside
>> of
>>> the local bundle scope...
>>> 
>>> Best regards,
>>> 
>>> David
>>> 
>>> On 17 June 2016 at 11:45, Guillaume Nodet <gno...@apache.org> wrote:
>>> 
>>>> You can investigate the use of equinox regions.  You can define regions
>> and
>>>> visibility between regions.
>>>> 
>>>> 2016-06-17 12:27 GMT+02:00 Vincent Vandemeulebrouck <
>>>> vincent.vandemeulebro...@ullink.com>:
>>>> 
>>>>> I need two different bundles to have the same private iPojo service, to
>>>> be
>>>>> used internally. It is defined in a shared library, included in both
>>>>> bundle.
>>>>> 
>>>>> How can I enforce that the requiring service get the service from their
>>>> own
>>>>> bundle?
>>>>> 
>>>>> Currently, as each bundle has the same service and same
>> specifications, I
>>>>> end-up having the private service from the other bundle injected,
>> causing
>>>>> some illegal accesses.
>>>>> 
>>>>> Bundle

Re: Same private service in different bundles

[Neil Bartlett]

You don’t need to use either registry hooks or regions for this. If the service 
interface package is private within the bundle (or if each bundle does not 
import the interface package from the other bundle) then your service will only 
be visible within its own bundle. This is known as service compatibility 
filtering — it is a core feature of the Service Registry and it exists 
precisely to prevent the ClassCastException you are talking about.

I also agree with David’s second paragraph. If the “service” is only used 
within one bundle then why make it a service at all? Java’s  “new” keyword is 
more concise and convenient.

Regards,
Neil


> On 17 Jun 2016, at 12:47, David Bosschaert  wrote:
> 
> You can also use OSGi Service Registry Hooks to enforce this, see here:
> https://osgi.org/javadoc/r6/core/org/osgi/framework/hooks/service/package-summary.html
> You would implement the service hooks in a separate bundle to control which
> client gets which service.
> 
> On the other hand, if the object provided by the bundle should only be used
> by its own bundle, I'm wondering whether services are the best approach.
> You could consider just instantiating the object directly if it's only used
> within its own bundle. Services are really aimed at being useful outside of
> the local bundle scope...
> 
> Best regards,
> 
> David
> 
> On 17 June 2016 at 11:45, Guillaume Nodet  wrote:
> 
>> You can investigate the use of equinox regions.  You can define regions and
>> visibility between regions.
>> 
>> 2016-06-17 12:27 GMT+02:00 Vincent Vandemeulebrouck <
>> vincent.vandemeulebro...@ullink.com>:
>> 
>>> I need two different bundles to have the same private iPojo service, to
>> be
>>> used internally. It is defined in a shared library, included in both
>>> bundle.
>>> 
>>> How can I enforce that the requiring service get the service from their
>> own
>>> bundle?
>>> 
>>> Currently, as each bundle has the same service and same specifications, I
>>> end-up having the private service from the other bundle injected, causing
>>> some illegal accesses.
>>> 
>>> Bundles are implemented in java. The issue is that each bundle has its
>> own
>>> ClassLoader, and injecting the class from the othe ClassLoader causes a
>>> ClassCastException.
>>> 
>>> 
>>> *--Vincent Vandemeulebrouck | *Architect - UL MIDDLE and Extensions *|
>>> ULLINK | *D: +33 1 44 50 52 02* | *T: +33 1 49 95 30 00* | *23-25 rue de
>>> Provence, 75009 Paris, FRANCE *|* vincent.vandemeulebro...@ullink.com
>> *| *
>>> 
>>> --
>>> *The information contained in or attached to this email is strictly
>>> confidential. If you are not the intended recipient, please notify us
>>> immediately by telephone and return the message to us.*
>>> 
>> 
>> 
>> 
>> --
>> 
>> Guillaume Nodet
>> 
>> Red Hat, Open Source Integration
>> 
>> Email: gno...@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Get a list of paths of registered servlets

[Neil Bartlett]

Well, you CAN atomically find out whether the name you want to register is 
already registered: just try to do it, and catch the NamespaceException.

Neil


> On 1 Jun 2016, at 22:37, Marcel Offermans  wrote:
> 
> That only helps him if he uses the whiteboard API. If he directly talks to 
> HttpService it probably won’t work.
> 
> Another problem is that you probably can’t do this as an atomic operation so 
> after you’ve checked, someone else can still beat you to it.
> 
> That said I don’t have a great solution to your problem beyond keeping track 
> of this yourself and delegating the registration of the servlets to a service 
> you design (which can then atomically do such a check). Again, that only 
> works if everything then goes through your service.
> 
> Greetings, Marcel
> 
> On 1 June 2016 at 22:56:01, Raymond Auge (raymond.a...@liferay.com) wrote:
> 
> The Http Whiteboard API contains a runtime introspection API which returns  
> DTOs of what's registered.  
> 
> look for a service registered under interface:  
> 
> org.osgi.service.http.runtime.HttpServiceRuntime  
> 
> 
> - Ray  
> 
> On Wed, Jun 1, 2016 at 4:24 PM, David Daniel   
> wrote:  
> 
>> Is it possible to find out what servlets have been registered with the  
>> httpservice. I am dynamically registering servlets and want to verify that  
>> a servlet has not already been registered with the same path. Is there a  
>> way to query the httpservice for all servlet paths that are registered,  
>> should I be keeping that information elsewhere or is there a tracker of  
>> some sort.  
>> 
>> Thanks for any help,  
>> David  
>> 
> 
> 
> 
> --  
> *Raymond Augé*   
> (@rotty3000)  
> Senior Software Architect *Liferay, Inc.*   
> (@Liferay)  
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)  


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Plaintext password in configuration files for Jetty and Webconsole

[Neil Bartlett]

This is a tricky one… the components need to receive the password in plaintext, 
and FileInstall does not support decryption.

You could build a management agent that supports reading encrypted data, either 
at the individual field level or over the whole configuration file. You still 
have the problem of how to supply the decryption key, and this very much 
depends on your specific requirements. For example the app could prompt for a 
password at startup time.

Neil


> On 22 Apr 2016, at 09:00, Antonio Sanso  wrote:
> 
> hi,
> 
> I would actually have the same question?
> 
> Is there anything can be done here ? If not there is any plan to improve this?
> I might try to help out in this area providing a patch…
> 
> Anyone :)?
> 
> regards
> 
> antonio
> 
> On Apr 20, 2016, at 5:07 PM, Ferry Huberts  wrote:
> 
>> Hi
>> 
>> I use FileInstall to push config into ConfigAdmin.
>> 
>> Now for Jettry and WebConsole there are plaintext passwords in there and I 
>> could not find how to avoid that.
>> 
>> Is there a way to avoid plaintext password?
>> 
>> Below is an example.
>> 
>> org.apache.felix.http.cfg: 
>> org.apache.felix.https.keystore.password=mypassword
>> org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg: 
>> password=mypassword
>> 
>> 
>> -- 
>> Ferry Huberts
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [SCR] Selecting services without giving a service interface

[Neil Bartlett]

Hi Jens,

Can you clarify please… are you saying that you want to inject services of 
*any* type, using some kind of filter that looks at the other properties of the 
service reference?

This is an unusual requirement, and I don’t think you can do it with DS’s event 
strategy. You should use a ServiceTracker instead.

Regards,
Neil


> On 8 Apr 2016, at 10:23, Jens Offenbach  wrote:
> 
> Sorry, but I am confronted with a new problem.
> 
> I am declaring a Reference annotation on a method, but I cannot declare a 
> service interface. If I declare nothing than Object gets used and nothing is 
> happening. When I remove the interface definition from my XML descriptor, SCR 
> validation fails with "An interface must be declared for the reference". I 
> have a filter expression that selects my services, but they do not have an 
> interface in common.
> 
> I have to select some service based on a filter expression without indicating 
> a service interface. How is this achievable?
> 
> Again... Thanks a lot for your help!
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix and JavaMail

[Neil Bartlett]

Hi Frank,

I don't say Karaf is bloated as such. It's much better than the old JavaEE
app servers.

It's just that I have never seen a good reason to use it instead of plain
OSGi.

Regards, Neil.
On 7 Mar 2016 08:02, "Frank Langel" <fr...@frankjlangel.com> wrote:

> Well,
>
> Karaf is a strange journey. Some people like it, some don’t.
> I am more in the Neil Bartlett kind of Apache Felix camp who thinks Karaf
> too bloated.
>
> I discovered Hana is using Eclipse Equinox, so I need to get familiar with
> that.
>
> Let me know if you need help with the javamail, should be easy sailing
> though.
> Frank
>
>
> From:  Mark Derricutt
> Reply-To:  <users@felix.apache.org>
> Date:  Monday, March 7, 2016 at 1:26 AM
> To:  <users@felix.apache.org>
> Subject:  Re: Felix and JavaMail
>
> On 7 Mar 2016, at 10:32, Frank Langel wrote:
>
> I never had any issues sending mail. What exactly is your issue?
>
> Looks like Karaf already ships with javamail so it looks like it was more
> an issue with using the kar lifecycle and some extra
> strict checking of dependencies.
>
> I'm working thru migrating a project deployed via a rather ancient version
> of karaf so I think it's more just a matter of working out the build
> process to package things up.  Sending email from the application in
> question is already working fine.
>
> Mark
>
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
>

Re: Repackaged Bundle Activator

[Neil Bartlett]

So… dotCMS are doing something very odd using a hacked version of OSGi/Felix. 
Mad! It’s possible they are also using a hacked version of bnd in their Gradle 
builds.

It may be possible to turn off this error message with the -fixupmessages 
instruction in bnd: http://bnd.bndtools.org/instructions/fixupmessages.html 
<http://bnd.bndtools.org/instructions/fixupmessages.html>. 

Regards,
Neil

> On 21 Feb 2016, at 13:30, Jibie Job <jibie@gmail.com> wrote:
> 
> dotcms plugins are all expected to extend or implement from this repackaged
> set of libraries and and I have verified that this does work when the
> manifest is built by hand and the plugin loaded into dotcms.
> 
> here are some of their official examples:
> https://dotcms.com/docs/latest/osgi-services-plugin
> 
> Is there some way to either direct the maven-bundle-plugin to either
> disable validations or get it to use the repackaged library prefix for
> validations?
> 
> dotcms seems to use a gradle build with the osgi plugin which in turn uses
> bnd and my guess is that it's not doing these validations
> 
> So it's possible, but i'm not clear how to achieve the same effect with the
> maven plugin.
> 
> Thanks!
> 
> On Sun, Feb 21, 2016 at 8:21 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> 
>> If you change the BundleActivator interface to a different package then
>> the runtime OSGi Framework will not recognise it as a valid activator. So
>> this is probably not an error that should be ignored.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> On 21 Feb 2016, at 13:18, Jibie Job <jibie@gmail.com> wrote:
>>> 
>>> I was trying to build an OSGI plugin for dotCMS using the
>>> maven-bundle-plugin (3.0.1) and am having an issue with the build failing
>>> with an error:
>>> 
>>> The Bundle Activator com.threeci.dotcms.services.Activator does not
>>> implement BundleActivator.
>>> The issue is due to dotCMS repackaging the standard osgi framework
>> packages
>>> under com.dotcms.repackage as
>>> com.dotcms.repackage.org.osgi.framework.BundleActivator which means that
>>> the maven bundle tool is unable to successfully verify the Activator
>>> matches the expected interface.
>>> 
>>> Is there a way to specify which interface should be used in the bundle
>>> activator check via the maven configuration?
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 

Re: org.osgi.framework.bsnversion=multiple

[Neil Bartlett]

> On 14 Jan 2016, at 12:19, Malek Ben Salem <malek-ben.sa...@aicas.de> wrote:
> 
> Yes, I use the same location string. Is there another way to do this?

So this is the problem. As you quoted yourself: "Every bundle is uniquely 
identified by its location string. If an installed bundle is using the 
specified location, the installBundle methods must return the Bundle object for 
that installed bundle and not install a new bundle”. Therefore Felix is 
behaving correctly.

To pass a different location string, you can use the two-argument variant of 
installBundle(), i.e. the one that takes an InpuStream as its second arg. Now 
you can treat the location as an opaque string, as it no longer has to be a URL 
for the bundle data. I recommend using some kind of URN.


> 
> Shouldn't the framework just ignore the existing location if the bsnversion 
> switch is set to multiple? I mean, why bother "allow multiple bundles to be 
> installed having the same symbolic name and version" if the install method 
> will refuse it before checking? This is how I understand the spec, so I 
> changed my build to check the switch before eventually looking for the 
> location and then just do one thing or the other (return the existing bundle 
> or install a new one).

No it shouldn’t. As the spec clearly states, the location string must be unique 
even when bsnversion=multiple is enabled. In many ways the location string is 
the ultimate “primary key” of a bundle.

Regards,
Neil


> 
> Regards,
> Malek.
> 
> On 01/13/2016 03:40 PM, Neil Bartlett wrote:
>> Do you pass a unique location string each time you install?
>> 
>> Neil
>> 
>> 
>>> On 13 Jan 2016, at 12:12, Malek Ben Salem <malek-ben.sa...@aicas.de> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I'm trying to start many instances of the same bundle in one OSGi. I have 
>>> noticed that setting org.osgi.framework.bsnversion=multiple doesn't change 
>>> anything. The install command returns the ID of the already installed 
>>> bundle, no new bundle is installed, as specified in 4.4.3 of the OSGi Core 
>>> Release 6 Spec:
>>> 
>>> "Every bundle is uniquely identified by its location string. If an 
>>> installed bundle is using the specified
>>> location, the installBundle methods must return the Bundle object for that 
>>> installed bundle and not install a new bundle."
>>> 
>>> Yet the same section also says:
>>> 
>>> "If the to be installed bundle has a bundle symbolic name and version pair 
>>> that is already installed in
>>> the framework then the installation is only valid when the 
>>> org.osgi.framework.bsnversion framework launching property is set to 
>>> multiple or managed."
>>> 
>>> Section 10.1.15.49 (concerning org.osgi.framework.bsnversion=multiple) 
>>> actually says this should be possible:
>>> "Specifies the framework will allow multiple bundles to be installed having 
>>> the same symbolic name and version."
>>> 
>>> So, is this a bug in the framework? I actually use my own build of the 
>>> framework where I changed the installBundle method of 
>>> org.apache.felix.framework.Felix.java to force this option to work. I still 
>>> would like to know the better way to achieve this or to have the bug 
>>> corrected.
>>> 
>>> Regards,
>>> Malek.
>>> 
>>> -- 
>>> aicas GmbH
>>> Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
>>> http://www.aicas.com   * Tel: +49-721-663 968-0
>>> 
>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
>>> Geschäftsführer: Dr. James J. Hunt
>>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 
> -- 
> aicas GmbH
> Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
> http://www.aicas.com   * Tel: +49-721-663 968-0
> 
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
> Geschäftsführer: Dr. James J. Hunt
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: org.osgi.framework.bsnversion=multiple

[Neil Bartlett]

Do you pass a unique location string each time you install?

Neil


> On 13 Jan 2016, at 12:12, Malek Ben Salem  wrote:
> 
> Hi everyone,
> 
> I'm trying to start many instances of the same bundle in one OSGi. I have 
> noticed that setting org.osgi.framework.bsnversion=multiple doesn't change 
> anything. The install command returns the ID of the already installed bundle, 
> no new bundle is installed, as specified in 4.4.3 of the OSGi Core Release 6 
> Spec:
> 
> "Every bundle is uniquely identified by its location string. If an installed 
> bundle is using the specified
> location, the installBundle methods must return the Bundle object for that 
> installed bundle and not install a new bundle."
> 
> Yet the same section also says:
> 
> "If the to be installed bundle has a bundle symbolic name and version pair 
> that is already installed in
> the framework then the installation is only valid when the 
> org.osgi.framework.bsnversion framework launching property is set to multiple 
> or managed."
> 
> Section 10.1.15.49 (concerning org.osgi.framework.bsnversion=multiple) 
> actually says this should be possible:
> "Specifies the framework will allow multiple bundles to be installed having 
> the same symbolic name and version."
> 
> So, is this a bug in the framework? I actually use my own build of the 
> framework where I changed the installBundle method of 
> org.apache.felix.framework.Felix.java to force this option to work. I still 
> would like to know the better way to achieve this or to have the bug 
> corrected.
> 
> Regards,
> Malek.
> 
> -- 
> aicas GmbH
> Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
> http://www.aicas.com   * Tel: +49-721-663 968-0
> 
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
> Geschäftsführer: Dr. James J. Hunt
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr:info missing info

[Neil Bartlett]

For what it’s worth, I’ve long had in the back of my mind an idea to develop a 
DS diagnostic command that could try to work out for you exactly why a DS 
component is inactive.

For example it could look at the Configuration Policy and then the set of 
available PIDs in Config Admin and report that the configuration seems to be 
missing.

Or it could notice unsatisfied service references, and follow those to some 
other component that should provide the service but is inactive… and so on, 
down the chain. Of course this would not work with services that are published 
programmatically but it would still provide a lot of useful information.

It wouldn’t even be too hard to code this, given the existence of ScrService 
for introspection.

Neil


> On 3 Dec 2015, at 18:06, Raymond Auge  wrote:
> 
> On Thu, Dec 3, 2015 at 12:59 PM, David Jencks 
> wrote:
> 
>> Since the Component Configuration: header appears for each component
>> configuration, I might prefer
>> …
>> (No Component Configuration)
>> 
>> I think I’d leave this out when the component is disabled as an additional
>> clue about the state.
>> 
>> WDYT?
>> 
> 
> I'd be totally cool with that!
> 
> - Ray
> 
> 
>> 
>> thanks
>> david jencks
>> 
>>> On Dec 3, 2015, at 9:50 AM, Raymond Auge 
>> wrote:
>>> 
>>> On Thu, Dec 3, 2015 at 12:31 PM, David Jencks > >
>>> wrote:
>>> 
 well, to me it did state that quite plainly:
 
 Configuration Policy: require
 
>>> 
>>> 
>>> but that's not showing that it's "waiting" for something... only that one
>>> is required... Does it have any right now?
>>> 
>>> In your configuration list maybe all you need is:
>>> 
>>> -
>>> ...
>>> Configuration Policy: require
>>> ...
>>> Component Configuration: none
>>> -
>>> 
>>> That's not redundant.
>>> 
>>> It's a) indicating that it does indeed need something before it does
>>> anything b) it doesn't have anything right now.
>>> 
>>> I'd be totally satisfied with that. At least it would allow for a quick
>>> scan of the output to observe that it's just not configured!!
>>> 
>>> 
>>> 
 I look forward to your suggestions.
 
 thanks
 david jencks
 
> On Dec 3, 2015, at 9:12 AM, Raymond Auge 
 wrote:
> 
> The point is that it took me and a technical support person about 15
> minutes to figure out (this is not a module I wrote) why the component
> wasn't "activating".
> 
> If scr:info had inferred that "hey, this thing won't do anything until
>> it
> receives at least ONE configuration" it would have really helped us,
>> and
 I
> would have had more encouraging response than ... I guess you need to
 infer
> from the obscure messaging that it's in a "waiting" state.
> 
> I'll see what I can come up with.
> 
> - Ray
> 
> On Thu, Dec 3, 2015 at 11:56 AM, David Jencks <
>> david.a.jen...@gmail.com>
> wrote:
> 
>> Hi Ray,
>> 
>> You are confusing a lot of terms :-)
>> 
>> “enabled” is a component description state.  If the component is
 disabled,
>> whether there are CA configurations for it and required dependencies
>> present or missing is completely irrelevant because DS isn’t even
 looking
>> at that yet.
>> 
>> Once the component is enabled, then there’s a chance that you might
>> bet
>> one or more instances of the component….. component configurations,
>> not
 to
>> be confused with CA configurations.
>> 
>> Depending on the  configuration policy….
>> ignored >> one component configuration.  This will be satisfied if all
 the
>> required references are satisfied and result in (one or more)
>> instances
>> depending on the scope, immediate setting, and whether there are any
 users
>> of the exposed service (if any)
>> 
>> optionsl >> one or more component configurations depending on CA
>> configurations.  Each one will be satisfied or not depending on it’s
>> references, and again instances depend on scope, etc etc.  You can see
>> whether the one configuration is configured from CA by looking at the
>> properties for a pid/factory pid.
>> 
>> required >> 0 or more component configurations, one per CA
 configuration.
>> Each one will be satisfied or not depending on its references etc etc.
>> 
>> So, there are a lot of moving parts here.  I’m not sure it’s practical
 to
>> explain the entire DS model in the output of scr:info, which I think
>> is
>> what you’re aiming for.  However I’m happy to consider suggestions
>> that
 are
>> actually in line with the model.  I haven’t been able to figure out
>> improvements to what is there that actually seem to me to provide more
>> information without being 

Re: DS and .. Fragments (not)?

[Neil Bartlett]

Fragments are not allowed to declare the Service-Component header (or
rather, if they do it will be ignored by SCR). It is however possible for
the DS XML and/or classes to be located in fragments, so long as the
Service-Component header is declared on the host bundle. So that may be one
route.

Why not follow a composition approach rather than inheritance? You could
have a single aggregator component that is injected with all the various
services, and is then published as a service. Each of your smaller
components can then inject the aggregate service component.

Neil

On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies 
wrote:

> Thanks to all of you who educated me yesterday about DS annotation
> inheritance in bnd. I implemented it and it works very well. However,
> I have an incremental challenge.
>
> What I have here is a gaggle of web services. Most of the logic is
> common across them and lives in a base class, which now has @Reference
> injection to pick up things it needs from the larger environment, and
> activate/deactivate to manage lifecycle.
>
> However, I'd like to enable these services to come from disparate
> teams. Given the injunction to avoid cross-bundle inheritance of the
> DS annotations, I can't just export the package containing the base
> class from one bundle and then tell the teams to import and inherit.
>
> It only took about five minutes to think of the idea of putting each
> service in a fragment -- and then discard it, due to the fact that
> fragments can't carry DS metadata (according to Stack Overflow).
>
> Is there another trail to follow here, or is there just an inescapable
> dilemma between repeating DS annotations and decoupling the pieces?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: DS and .. Fragments (not)?

[Neil Bartlett]

> On 18 Nov 2015, at 12:46, Benson Margulies <ben...@basistech.com> wrote:
> 
> On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <njbartl...@gmail.com 
> <mailto:njbartl...@gmail.com>> wrote:
>> Fragments are not allowed to declare the Service-Component header (or
>> rather, if they do it will be ignored by SCR). It is however possible for
>> the DS XML and/or classes to be located in fragments, so long as the
>> Service-Component header is declared on the host bundle. So that may be one
>> route.
> 
> Right, that's the reading I did that caused me to conclude that I
> couldn't just trivially decorate classes in a fragment with DS
> annotations. I don't want the host to 'know' in advance the inventory
> of the fragments.

Right, this is certainly a limitation. Also you really don’t want to use 
fragments if you can avoid it.

> 
>> 
>> Why not follow a composition approach rather than inheritance? You could
>> have a single aggregator component that is injected with all the various
>> services, and is then published as a service. Each of your smaller
>> components can then inject the aggregate service component.
> 
> I more or less started with this, but the problem I had was deciding
> when all the services had arrived at the aggregator. I had to give the
> aggregator a property that told it how many services to expect, and
> this made me sad. I might be able to make the aggregator deal with
> them one-at-a-time instead of needing them all together, and then this
> would work tolerably well.


Notwithstanding your mood swings, what is wrong with setting the service 
references to mandatory (which is the default anyway)? Then the aggregator 
component will not be published until the references are satisfied.


> 
> Another line of thought I have involves letting them be fragments and
> then having the host collect them all and aggregate them. Is there a
> tasteful pattern for a host bundle to take note of its fragments, or
> is that inevitably ugly?

Given your BundleWiring instance, you can find all the wires provided by your 
bundle in the ‘osgi.wiring.host' namespace (HostNamespace.HOST_NAMESPACE) and 
following them through to their requirers. But I’m not sure what you are 
planning to do next with this information…


> 
> 
>> 
>> Neil
>> 
>> On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <ben...@basistech.com>
>> wrote:
>> 
>>> Thanks to all of you who educated me yesterday about DS annotation
>>> inheritance in bnd. I implemented it and it works very well. However,
>>> I have an incremental challenge.
>>> 
>>> What I have here is a gaggle of web services. Most of the logic is
>>> common across them and lives in a base class, which now has @Reference
>>> injection to pick up things it needs from the larger environment, and
>>> activate/deactivate to manage lifecycle.
>>> 
>>> However, I'd like to enable these services to come from disparate
>>> teams. Given the injunction to avoid cross-bundle inheritance of the
>>> DS annotations, I can't just export the package containing the base
>>> class from one bundle and then tell the teams to import and inherit.
>>> 
>>> It only took about five minutes to think of the idea of putting each
>>> service in a fragment -- and then discard it, due to the fact that
>>> fragments can't carry DS metadata (according to Stack Overflow).
>>> 
>>> Is there another trail to follow here, or is there just an inescapable
>>> dilemma between repeating DS annotations and decoupling the pieces?
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
> <mailto:users-unsubscr...@felix.apache.org>
> For additional commands, e-mail: users-h...@felix.apache.org 
> <mailto:users-h...@felix.apache.org>

Re: Uninstalled API bundle, yet implementation still resolves and starts

[Neil Bartlett]

Hi Richard,

I agree with you, and I understand why the existing active bundles remain wired 
to the uninstalled bundle until refresh. However it sounded like the newly 
installed bundle was wiring to the uninstalled bundle. This doesn’t sound 
right… the framework shouldn’t create new wires into uninstalled bundles, 
should it?

This assumes I have correctly understood the scenario as described by Maurice.

Neil

> On 4 Nov 2015, at 13:31, Richard S. Hall <he...@ungoverned.org> wrote:
> 
> 
> On 11/4/15 06:52 , i...@cuhka.com <mailto:i...@cuhka.com> wrote:
>> I 'solved' it by restarting the device. I rather don't, as I like solution 
>> where I can upgrade functionality without shutting down.
> 
> You don't need to shut down, you just need to refresh the framework. If you 
> update A and S, the old version of A is still hanging around because X1 is 
> using it. So, you have your framework state in somewhat of an "in between" 
> stage. Refreshing things gets everything back in shape. There are very few 
> rare instances where you would not want to refresh after an update or an 
> uninstall...99% of the time, you should refresh after either of those 
> operations.
> 
> -> richard
> 
>> 
>> Basically my structure is as follows:
>> Bundle A: API
>> Bundle S: Service (uses and provides some API implementation from A)
>> Bundle X1..N: Provide functionality for S using the extender pattern, use 
>> and provide some API implementation from A)
>> I updated A and S. For the X bundles the API change wasn't important, but 
>> for S it was. Somehow S still picked up old-A, while I had uninstalled old-A 
>> (and old-S). I have updated my tooling from 'THE OSGi plugin' from Gradle to 
>> use 'the bnd OSGi plugin'. I noticed that the old plugin would automatically 
>> add A's package as Export-Bundle, while with bnd's plugin I had to do that 
>> myself. Maybe that caused the problem.
>> 
>> Maurice.
>> 
>> Citeren Neil Bartlett <njbartl...@gmail.com>:
>> 
>>>> On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote:
>>>> 
>>>> Delete the directory called felix-cache??
>>> 
>>> No, in his second email he says that other bundles are still running that 
>>> use the old API. So we’re talking about a series of changes made in a 
>>> running OSGi Framework, and it wouldn’t be a good idea to delete the 
>>> storage directory underneath a running framework.
>>> 
>>> These changes *should* work. Best guess is that the implementation bundle 
>>> ships its own copy of the API bundle.
>>> 
>>> As a general rule, you should do a refresh after a series of changes to 
>>> bundle states (installs, uninstalls or updates). You can do this simply 
>>> with the “refresh” command in the Gogo shell. In this scenario, a refresh 
>>> would cause all the bundles that import from the API bundle to stop and 
>>> revert to INSTALLED state.
>>> 
>>> Regards,
>>> Neil
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
> <mailto:users-unsubscr...@felix.apache.org>
> For additional commands, e-mail: users-h...@felix.apache.org 
> <mailto:users-h...@felix.apache.org>

Re: Uninstalled API bundle, yet implementation still resolves and starts

[Neil Bartlett]

Thanks Richard, that’s very clear.

It almost makes me think that, if we were designing the OSGi APIs all over 
again, management agents should be required to open a batch operation in order 
to do any install/update/uninstall. The operations in the batch would not take 
effect in the framework until it was committed, which would be equivalent to a 
refresh.

Neil



> On 5 Nov 2015, at 14:31, Richard S. Hall <he...@ungoverned.org> wrote:
> 
> On 11/5/15 05:04 , Neil Bartlett wrote:
>> Hi Richard,
>> 
>> I agree with you, and I understand why the existing active bundles remain 
>> wired to the uninstalled bundle until refresh. However it sounded like the 
>> newly installed bundle was wiring to the uninstalled bundle. This doesn’t 
>> sound right… the framework shouldn’t create new wires into uninstalled 
>> bundles, should it?
> 
> It depends, but it is certainly not wrong to do so, since clearly the 
> packages are still available to the system.
> 
> I have made an argument before that installing to stale packages is 
> reasonable because it results in fewer class spaces if the framework is not 
> refreshed. I still think this argument is valid, although I admit that you 
> could differentiate between stale packages from an updated bundle versus 
> stale packages from an uninstalled bundle. However, I'm not sure it is 
> worthwhile to draw that distinction, since if you are uninstalling, you 
> should do a refresh. Period.
> 
> Peter has argued before on this top that any update/uninstall should *always* 
> be followed by a refresh, which I don't completely agree with but I do think 
> that in general it is the right thing to do and only people who know what 
> they are doing shouldn't refresh.
> 
> For example, if you have an bundle that exports some package and you make 
> changes that only impact internal packages and you really don't want to bring 
> down the entire system (potentially losing state, etc.), then it is possible 
> to update that bundle and not refresh so the system can continue to use the 
> stale packages.
> 
> Of course, this would only work if the bundle in question was importing what 
> it exported. Assuming it was, then the resolver is free to wire it to its own 
> stale packages.
> 
> As you can see, though, this is only for people who really know what they are 
> doing, which is why 99% of the time I agree with Peter on this subject that 
> you should refresh.
> 
> -> richard
> 
>> This assumes I have correctly understood the scenario as described by 
>> Maurice.
>> 
>> Neil
>> 
>>> On 4 Nov 2015, at 13:31, Richard S. Hall <he...@ungoverned.org 
>>> <mailto:he...@ungoverned.org>> wrote:
>>> 
>>> 
>>> On 11/4/15 06:52 , i...@cuhka.com <mailto:i...@cuhka.com> 
>>> <mailto:i...@cuhka.com <mailto:i...@cuhka.com>> wrote:
>>>> I 'solved' it by restarting the device. I rather don't, as I like solution 
>>>> where I can upgrade functionality without shutting down.
>>> You don't need to shut down, you just need to refresh the framework. If you 
>>> update A and S, the old version of A is still hanging around because X1 is 
>>> using it. So, you have your framework state in somewhat of an "in between" 
>>> stage. Refreshing things gets everything back in shape. There are very few 
>>> rare instances where you would not want to refresh after an update or an 
>>> uninstall...99% of the time, you should refresh after either of those 
>>> operations.
>>> 
>>> -> richard
>>> 
>>>> Basically my structure is as follows:
>>>> Bundle A: API
>>>> Bundle S: Service (uses and provides some API implementation from A)
>>>> Bundle X1..N: Provide functionality for S using the extender pattern, use 
>>>> and provide some API implementation from A)
>>>> I updated A and S. For the X bundles the API change wasn't important, but 
>>>> for S it was. Somehow S still picked up old-A, while I had uninstalled 
>>>> old-A (and old-S). I have updated my tooling from 'THE OSGi plugin' from 
>>>> Gradle to use 'the bnd OSGi plugin'. I noticed that the old plugin would 
>>>> automatically add A's package as Export-Bundle, while with bnd's plugin I 
>>>> had to do that myself. Maybe that caused the problem.
>>>> 
>>>> Maurice.
>>>> 
>>>> Citeren Neil Bartlett <njbartl...@gmail.com>:
>>>> 
>>>>>> On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote:
>>>>>

Re: Uninstalled API bundle, yet implementation still resolves and starts

[Neil Bartlett]

> On 4 Nov 2015, at 10:37, i...@cuhka.com wrote:
> 
> I have an API bundle and and implementation bundle. I removed both the API 
> and implementation, re-installed the implementation and started the 
> implementation. To my suprise the framework was willing to start the bundle, 
> even though the API isn't there anymore. It was present, so obviously it is 
> using some cached class.
> 
> I encountered this because I changed the signature of the API, updated all 
> bundle versions and redeployed it. The implementation resolved fine, but 
> didn't run because it could not find the updated signature.
> 
> Personally I would have expected the implementation bundle to have picked up 
> the changed api, and after uninstalling to not resolve. Is this assumption 
> incorrect?

No, this is basically correct.

However your description of the scenario is too vague to be able to tell 
exactly what happened in this case. If you specify which bundles import and 
export which packages, and what you did to those bundles in sequence, then we 
might get somewhere.

Neil

> 
> Maurice.
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Uninstalled API bundle, yet implementation still resolves and starts

[Neil Bartlett]

> On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote:
> 
> Delete the directory called felix-cache??

No, in his second email he says that other bundles are still running that use 
the old API. So we’re talking about a series of changes made in a running OSGi 
Framework, and it wouldn’t be a good idea to delete the storage directory 
underneath a running framework.

These changes *should* work. Best guess is that the implementation bundle ships 
its own copy of the API bundle.

As a general rule, you should do a refresh after a series of changes to bundle 
states (installs, uninstalls or updates). You can do this simply with the 
“refresh” command in the Gogo shell. In this scenario, a refresh would cause 
all the bundles that import from the API bundle to stop and revert to INSTALLED 
state.

Regards,
Neil


> 
> On Wed, Nov 4, 2015 at 10:42 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> 
>> 
>>> On 4 Nov 2015, at 10:37, i...@cuhka.com wrote:
>>> 
>>> I have an API bundle and and implementation bundle. I removed both the
>> API and implementation, re-installed the implementation and started the
>> implementation. To my suprise the framework was willing to start the
>> bundle, even though the API isn't there anymore. It was present, so
>> obviously it is using some cached class.
>>> 
>>> I encountered this because I changed the signature of the API, updated
>> all bundle versions and redeployed it. The implementation resolved fine,
>> but didn't run because it could not find the updated signature.
>>> 
>>> Personally I would have expected the implementation bundle to have
>> picked up the changed api, and after uninstalling to not resolve. Is this
>> assumption incorrect?
>> 
>> No, this is basically correct.
>> 
>> However your description of the scenario is too vague to be able to tell
>> exactly what happened in this case. If you specify which bundles import and
>> export which packages, and what you did to those bundles in sequence, then
>> we might get somewhere.
>> 
>> Neil
>> 
>>> 
>>> Maurice.
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Deploying Jetty 9.3.5 in Felix

[Neil Bartlett]

It looks like the ‘org.eclipse.jetty.websocket.server' and 
‘org.eclipse.jetty.websocket.servlet’ bundles have bad headers in their 
manifests. They both declare a Require-Capability in the osgi.extender 
namespace which is effective at resolve time. Bundles should never require 
anything from the osgi.extender namespace merely in order to resolve.

To proceed, you would have to find whatever bundle provides the 
“osgi.extender=osgi.serviceloader.processor” capability. I don’t know what 
bundle that might be. The Jetty developers *should* know… assuming they even 
tested their bundles before releasing them!

Neil


> On 29 Oct 2015, at 13:05, i...@cuhka.com wrote:
> 
> I've copied the jars that Jetty mentions into felix's bundle folder. I've 
> also copied the jars under the websocket folder into felix's bundle folder.
> 
> Two Websocket bundles don't resolve, but this is due to an OSGi service 
> loader bundle? Which bundle should I install?
> 
> 
> g! start 127
> org.osgi.framework.BundleException: Unable to resolve 
> org.eclipse.jetty.websocket.server [127](R 127.0): missing requirement 
> [org.eclipse.jetty.websocket.server [127](R 127.0)] osgi.extender; 
> (osgi.extender=osgi.serviceloader.registrar) Unresolved requirements: 
> [[org.eclipse.jetty.websocket.server [127](R 127.0)] osgi.extender; 
> (osgi.extender=osgi.serviceloader.registrar)]
> 
> g! start 128
> org.osgi.framework.BundleException: Unable to resolve 
> org.eclipse.jetty.websocket.servlet [128](R 128.0): missing requirement 
> [org.eclipse.jetty.websocket.servlet [128](R 128.0)] osgi.extender; 
> (osgi.extender=osgi.serviceloader.processor) Unresolved requirements: 
> [[org.eclipse.jetty.websocket.servlet [128](R 128.0)] osgi.extender; 
> (osgi.extender=osgi.serviceloader.processor)]
> 
> 
> 
>  109|Active |1|Jetty :: Deployers (9.3.5.v20151012)
>  110|Active |1|Jetty :: Http Utility (9.3.5.v20151012)
>  111|Active |1|Jetty :: IO Utility (9.3.5.v20151012)
>  112|Active |1|Jetty Servlet API and Schemas for OSGi (3.1.0.M3)
>  113|Active |1|Jetty :: Security (9.3.5.v20151012)
>  114|Active |1|Jetty :: Server Core (9.3.5.v20151012)
>  115|Active |1|Jetty :: Utilities (9.3.5.v20151012)
>  116|Active |1|Jetty :: Webapp Application Support (9.3.5.v20151012)
>  117|Active |1|Jetty :: XML utilities (9.3.5.v20151012)
>  118|Active |1|ASM (5.0.1)
>  119|Installed  |1|ASM commons classes (5.0.1)
>  120|Active |1|Jetty :: Websocket :: javax.websocket :: Client 
> Implementation (9.3.5.v20151012)
>  121|Installed  |1|Jetty :: Websocket :: javax.websocket.server :: Server 
> Implementation (9.3.5.v20151012)
>  122|Active |1|javax.annotation API (1.2.0)
>  123|Active |1|WebSocket server API (1.0.0)
>  124|Active |1|Jetty :: Websocket :: API (9.3.5.v20151012)
>  125|Active |1|Jetty :: Websocket :: Client (9.3.5.v20151012)
>  126|Active |1|Jetty :: Websocket :: Common (9.3.5.v20151012)
>  127|Installed  |1|Jetty :: Websocket :: Server (9.3.5.v20151012)
>  128|Installed  |1|Jetty :: Websocket :: Servlet Interface 
> (9.3.5.v20151012)
>  129|Active |1|Jetty :: Servlet Handling (9.3.5.v20151012)
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundle can't find its own classes: NoClassDefFoundError

[Neil Bartlett]

No, bnd does not write Bundle-ClassPath for you. 

Without some actual information (such as manifest, bundle content, stack 
trace?) it's impossible to do more than guess at reasons for the problem. 

Neil


> On 30 Oct 2015, at 18:05, i...@cuhka.com wrote:
> 
> Maybe,but how can that happen? I'm using Gradle with the OSGi plugin, so 
> AFAIK it is bnd that creates the Bundle-ClassPath entry. Also, my bundle is 
> still quite small, so it only contains a single package. It manages to find 
> the activator fine.
> 
> Maurice.
> 
> Citeren "Richard S. Hall" :
> 
>> Perhaps you didn't specify your Bundle-ClassPath correctly...
>> 
>> -> richard
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

[Neil Bartlett]

> On 27 Oct 2015, at 22:45, Balázs Zsoldos <balazs.zsol...@everit.biz> wrote:
> 
>> 
>> As an application developer, you don’t need to import anything from
>> extender bundles.
>> I would estimate that 90% of my bundles do not import anything from the
>> core OSGi framework, and I almost *never* write a BundleActivator.
> 
> 
> Probably "Import" was not the right word. As an application developer, you
> either have to implement BundleActivator, or use some technology that
> implements the extender pattern. That technology must either implement
> BundleActivator or use another technology that implements another extender
> pattern. And so on...
> 
> If org.osgi.framework is not part of the system packages, at least one of
> the bundles will not be able to resolve (the one that implements
> BundleActivator). As a result, no code will be executed in any of the
> bundles. (It can be executed if someone starts the framework
> programmatically than gets a class type from one of the bundles than
> instantiates it with reflection... I do not think anybody wants to do this).
> 
> In other words: The org.osgi.framework must ALWAYS export the
> org.osgi.framework package, otherwise no business logic will be executed.

Umm… yes. Luckily it already does this.

Sorry, struggling to see the deeper point you are making.


> 
> 
> On Tue, Oct 27, 2015 at 11:18 PM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
> 
>> 
>>> On 27 Oct 2015, at 17:33, Balázs Zsoldos <balazs.zsol...@everit.biz>
>> wrote:
>>> 
>>>> 
>>>> As an application developer, I don't need to implement the extender
>>>> pattern since framework developers have done that for me. It's all about
>>>> layers and perspective.
>>> 
>>> 
>>> As a technology developer, how would you implement an extender pattern
>>> without the framework packages? You could not. If those packages are not
>>> exported by the system bundle, you cannot implement the extender pattern.
>>> As an application developer, you could not import a bundle that
>> implements
>>> the extender pattern, as the bundle would not resolve.
>> 
>> 
>> As an application developer, you don’t need to import anything from
>> extender bundles.
>> 
>> I would estimate that 90% of my bundles do not import anything from the
>> core OSGi framework, and I almost *never* write a BundleActivator.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> 
>>> You mean that the Framework developers should implement technologies like
>>> Declarative Services and include it into the Framework?
>>> 
>>> 
>>> On Tue, Oct 27, 2015 at 6:27 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>> 
>>>> On 10/27/15 13:14 , Balázs Zsoldos wrote:
>>>> 
>>>>> That is not my interpretation. System packages are those packages
>> provided
>>>>>> by the system bundle. From a wiring perspective, all of the JRE
>> packages
>>>>>> look like they are coming from the system bundle just like the OSGi
>> core
>>>>>> packages, so your distinction doesn't really make sense to me.
>>>>>> 
>>>>> 
>>>>> Seems that we are different :). I interpret rules based on use-cases. I
>>>>> cannot find any use-case where I wanted to handle framework packages
>> like
>>>>> JDK packages. On the other hand, I see use-cases where I want to handle
>>>>> them separately.
>>>>> 
>>>> 
>>>> It is much more consistent to defines system.packages like,
>>>> "system.packages represents all packages that will be exported by the
>>>> system bundle", instead of something like "system.packages represents
>> all
>>>> packages exported by the system bundle plus some additional packages
>> that
>>>> will tacked on but may vary by framework implementation".
>>>> 
>>>> 
>>>>> Wrong. The extender pattern is based almost wholly around such an
>>>>> approach.
>>>>> 
>>>>> 
>>>>> How would you implement the extender pattern without the framework
>>>>> packages?
>>>>> 
>>>> 
>>>> As an application developer, I don't need to implement the extender
>>>> pattern since framework developers have done that for me. It's all about
>>>> layers and perspective.
>>>> 
>>>> 

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

 found exceptions are thrown (yeah, because most of those transitive 
> dependencies are not bundles!).
> 
> I have been in several projects these last 2 years which tried to make use of 
> OSGi. These three issues were prevalent:
> * *Lack of up-to-date documentation *about the tools we should use to build, 
> manage and deploy OSGi projects (maven-bundle-plugin, tycho, bndtools, 
> gradle, bnd, ant, karaf, etc.), most examples are just "hello-world" 
> examples, none of them cares with dependency management;
> * *Lack of a dependency management system *to automatically resolve 
> transitive dependencies;
> * *The OSGi community size is very small*, and the few people who try to 
> contribute do not always follow the good practices (specially with 
> bundelization of third-party libraries, were many imports are left unresolved 
> in the final bundle, or the third-party library isn't divided into 
> fine-grained bundles---which I am aware it is a very hard achievement for 
> most libraries, since most of them depend on the whole Internet).
> 
> In the end these are the reasons why everyone I know quits from OSGi, and I, 
> as an OSGi user have to face on a daily basis.
> Compare the effort of, in a basic Eclipse project you import the quartz jar 
> to the build path, you use it, build the project and everything goes fine. In 
> contrast, with OSGi you import quartz to your OSGi container (usually Felix, 
> unless you want to mess with equinox in an Eclipse environment, which is an 
> undocumented mess), and when you try to launch your container you witness the 
> gates of hell opening before you.


"Everything goes fine”? Pull the other one. You still have to make sure all the 
dependencies are there, or you will get a ClassNotFoundException or 
NoClassDefFoundError at runtime. OSGi doesn’t change the FACT that Quartz has 
all these dependencies. It just moves forward the error checking.

> 
> I have searched, made blog posts, made stackoverflow posts asking about the 
> transitive dependencies issue in OSGi, it seems that there is no solution so 
> far, of there is, there is no documentation of it. It doesn't help just 
> saying "ah use this or that tool", no... there must be documentation, not 
> just for hello-world scenarios where you have little or no dependencies, not 
> just to this specific transitive dependency, but for all transitive 
> dependencies. Undocumented tools do not exist, only for their creators.

I would document the “transitive dependencies issue in OSGi” if I understood 
it. Software has dependencies, and sometimes those dependencies have other 
dependencies. They all have to be satisfied or the software will not run. What 
is the issue exactly?

> 
> I am sure I am beating some people out of their comfort zone with this e-mail 
> but I can't take it anymore. No matter How I try to defend the OSGi project 
> because I truly believe in the philosophy behind true modular programming 
> (like the books explain), I cannot keep pushing forward alone. Most of the 
> times I feel I am alone in this community, and in the end I dont even 
> understand how can the authors of those books put in practice their teachings 
> in a mess like this…!


Maybe they just didn’t use Quartz. I mean, is it really the only alternative 
here? How hard can scheduling be??

I understand your frustration with tooling and documentation, I really do. I 
started the Bndtools project because I needed it for myself, which means the 
documentation is never where I would like it to be. But also, I (and other 
developers working on OSGi tools) cannot test with every damn library out there.

Also, I don’t have the patience to make somebody else’s crappy software work. 
The Java ecosystem is massive, and if a library doesn’t work then I won’t keep 
trying for weeks to make it work… I look for an alternative. If there is no 
alternative, I write my own. This position isn’t unique to OSGi and/or Java, I 
have had the same experience with crappy libraries in C/C++ and Haskell.

And to your colleagues who prefer to quit OSGi because of these problems: just 
wait till the Java 9 Module System comes along.

Neil

> 
> Sorry...
> 
> On 13/10/2015 23:24, Pedro Domingues wrote:
>> Thank you guys for your suggestions. I am gonna try them to see what fits 
>> best!
>> 
>> Best regards
>> 
>> On October 12, 2015 10:28:09 PM WEST, Paulo Renato de Athaydes 
>> <renatoathay...@hotmail.com> wrote:
>>> Yeah, I had already suggested that was probably the best solution
>>> My previous message had a huge blank space in the middle which I have
>>> no idea where it came from!!
>>> But it became a personal challenge to get that old c3p0 jar and quartz
>>> working in a OSGi environment.
>

Re: Scala support in Apache Felix

[Neil Bartlett]

It’s definitely possible. Scala compiles to bytecode which can be analysed for 
dependencies just like Java. Your bundles will import packages like scala.lang 
etc, so of course you need to install a bundle that exports those. I think the 
Scala runtime is already available as bundles. Just be aware that Scala does 
NOT use semantic versioning (e.g. 2.10 to 2.11 is a breaking change).

The main problem however is tooling. Last time I looked at it the Scala IDE was 
really terrible, but I was still able to set it up along with Bndtools so that 
the Scala Builder executed just before the Bndtools Builder. Hopefully Scala 
IDE has improved by now, but you’re certainly going to have to fiddle a lot to 
get a build process that you’re happy with.

Neil



> On 12 Oct 2015, at 17:48, Frank Langel  wrote:
> 
> Hello, 
> 
> Does anyone have experience developing OSGI modules in Scala using Felix? Any 
> input would be highly appreciated
> 
> Best
> Frank
> 
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

The import of the c3p0 package is problematic because c3p0 is not an OSGi 
bundle. However there is a bundle wrapping availabe: 
http://jpm4j.org/#!/p/sha/376EA3C3654A3E0593D1C135A7109ECE77D0BE70//0.0.0

Incidentally, c3p0 apparently hasn’t been updated or maintained for over 8 
years, so it’s a bit dubious to be using something like that in a production 
application.

Neil



> On 12 Oct 2015, at 22:07, Paulo Renato de Athaydes 
>  wrote:
> 
> 
> 
> 
> 
> The quartz bundle has the following imports:
> Import-Package: com.mchange.v2.c3p0,commonj.work;resolution:=optional, 
> javax.ejb;resolution:=optional,javax.jms;resolution:=optional,javax.m 
> ail;resolution:=optional,javax.mail.internet;resolution:=optional,jav 
> ax.management,javax.management.openmbean,javax.naming,javax.servlet;r 
> esolution:=optional,javax.servlet.http;resolution:=optional,javax.sql 
> ;resolution:=optional,javax.transaction;resolution:=optional,javax.xm 
> l.bind,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,oracle.s 
> ql;resolution:=optional,org.jboss.logging;resolution:=optional,org.jb 
> oss.naming;resolution:=optional,org.jboss.system;resolution:=optional 
> ,org.quartz,org.quartz.core,org.quartz.impl.matchers,org.quartz.impl. 
> triggers,org.quartz.jobs;resolution:=optional,org.quartz.spi,org.slf4 
> j;version="[1.6,2)",org.terracotta.toolkit;resolution:=optional,org.t 
> erracotta.toolkit.atomic;resolution:=optional,org.terracotta.toolkit. 
> builder;resolution:=optional,org.terracotta.toolkit.cluster;resolutio 
> n:=optional,org.terracotta.toolkit.collections;resolution:=optional,o 
> rg.terracotta.toolkit.concurrent.locks;resolution:=optional,org.terra 
> cotta.toolkit.config;resolution:=optional,org.terracotta.toolkit.inte 
> rnal;resolution:=optional,org.terracotta.toolkit.internal.concurrent. 
> locks;resolution:=optional,org.terracotta.toolkit.rejoin;resolution:= 
> optional,org.terracotta.toolkit.search;resolution:=optional,org.terra 
> cotta.toolkit.search.attribute;resolution:=optional,org.terracotta.to 
> olkit.store;resolution:=optional,org.w3c.dom,org.xml.sax,weblogic.jdb 
> c.jts;resolution:=optional,weblogic.jdbc.vendor.oracle;resolution:=op tional
> 
> The required dependencies (not optional) are the following:
> com.mchange.v2.c3p0
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> javax.managementjavax.management.openmbean
> javax.naming
> javax.xml.bind
> javax.xml.namespace
> javax.xml.parsers
> javax.xml.xpath
> org.quartz
> org.quartz.core
> org.quartz.impl.matchers
> org.quartz.impl. triggers
> org.quartz.spi
> org.slf4 j;version="[1.6,2)"
> org.w3c.dom
> org.xml.sax
> 
> 
> The first one, c3p0, comes from this artifact:
> "c3p0:c3p0:0.9.1.1"
> 
> Which is not a OSGi bundle. (the others, except quartz which comes from the 
> jar itself, don't seem to be a problem as the framework seems happy to 
> provide those).
> 
> 
> I wrapped it in a bundle anyway using osgi-run and then, after installing 
> them in Felix, I found out we need some logging libraries, org.sfl4j.api, 
> org.apache.log4j, osg.slf4j.impl (ouch!)
> 
> 
> A little bit painful to get this working.
> 
> 
> After a little guesswork, I found these 2 bundles meet the logging demands:
> 
> 
> osgiRuntime 'org.slf4j:slf4j-simple:1.7.5'
> osgiRuntime "org.slf4j:log4j-over-slf4j:1.7.5"
> 
> 
> But Felix threw horrible errors when I did this:
> 
> 
> ERROR: Bundle slf4j.api [8] Error starting 
> file:/Users/renato/programming/projects/osgi-run/osgi-run-test/quartz-sample/build/osgi/bundle/slf4j-api-1.6.6.jar
>  (java.lang.ArrayIndexOutOfBoundsException: -1)
> java.lang.ArrayIndexOutOfBoundsException: -1
>at java.util.ArrayList.elementData(ArrayList.java:418)
>at java.util.ArrayList.remove(ArrayList.java:495)
>at 
> org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
>at 
> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
>at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
>at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
>at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
>at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
>at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
>at java.lang.Thread.run(Thread.java:745)
> ERROR: Bundle slf4j.api [9] Error starting 

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

> On 11 Oct 2015, at 12:20, Pedro Domingues  wrote:
> 
> Greetings,
> 
> Sorry for bothering you, but I would like to ask for your help with your 
> Quartz bundle.
> 
> I am trying to install your Quartz OSGi bundle into my project:
> 
> 
> 
> However when I insert the bundle in my Apache Felix I keep getting the 
> unresolved dependencies error message like you can see here:
> 
> >java -jar bin/felix.jar
> ERROR: Bundle hydra.launcher [1] Error starting 
> file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar 
> (org.osgi.fram
> ework.BundleException: Unable to resolve org.apache.servicemix.bundles.quartz 
> [8](R 8.0): missing requirement [org.apache.servicemix.bundles.quartz [8
> ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging) 
> Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R 8.0)] 
> osg
> i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement 
> [org.apache.servicemix.bund
> les.quartz [8](R 8.0)] osgi.wiring.package; 
> (osgi.wiring.package=org.jboss.logging) Unresolved requirements: 
> [[org.apache.servicemix.bundles.quartz [8
> ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
> at hydra.launcher.Launcher.installStart(Launcher.java:78)
> 
> If I try to discard this dependency manually in your bundle's manifest I keep 
> getting other dependencies such as oracle.sql and so on... It is a true 
> dependency hell. 
> 
> However I do not need to use SQL nor JBOSS, I just want to use Quartz. Is 
> there any way I can solve this? Do I really need to include the thousand 
> transitive dependencies manually, which I will probably never use but since 
> these manifests are automatically generated they include them anyways?
> 
> This is the one thing that makes OSGi hard to use...

Thats not exactly fair. OSGi didn't create those dependencies -- they exist in 
the code.

Unfortunately, if a bundle has a large tree of dependencies then you have only 
two choices. Either use it and suck up the dependencies. Or just don't use it.

OSGi is not unique here. In all software development, you have to decide 
whether to import a module and pay the price of its dependencies, find a better 
module, or write your own.

Neil

> 
> Thanks!

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

Such a tool does exist… for example the Embed-Dependency and Embed-Transitive 
instructions in the maven-bundle-plugin. Of course, the price is that every 
bundle will contain its own copy of every library. So if you think this solves 
the problem then I recommend not bothering with OSGi or any other module system.

Ultimately there can be no automated substitute for developers paying attention 
to the two principles of modular composition: high cohesion and low coupling. 
When developers fail to do this (as the Quartz developers apparently did), 
users suffer.

Neil

> On 11 Oct 2015, at 16:17, Pedro Domingues  wrote:
> 
> I understand that everything has dependencies, however I wish this embedding 
> could be automated, for example having maven downloading and embedding 
> transitive dependencies into the quartz bundle.
> 
> Thanks
> 
> On 11/10/2015 16:08, e...@zusammenkunft.net  
> wrote:
>> Hello,
>> 
>> Have to agree with Neil, hower I want to add, that the bundling of Quartz 
>> here is the problem, it could make some dependencies optional and it could 
>> even add some of the dependencies inside the bundle. This is what I did with 
>> Quartz, I embedded Quartz and some of its dependencies inside a bundle to 
>> greatly remove its external dependencies. You can even overwrite/remove some 
>> imports for unused artifacts. Quartz needs this special treatment since its 
>> a big ugly blob of goo.
>> 
>> Greetings
>> Bernd
>> 
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
> 
> For additional commands, e-mail: users-h...@felix.apache.org 
> 

Re: @Reference multi binding & dynamics

[Neil Bartlett]

> On 7 Oct 2015, at 13:56, Ferry Huberts  wrote:
> 
> Hi,
> 
> Cross-posting because I don't know if the situation/problem below is by 
> design, a bug in bnd, or a bug in SCR
> 
> 
> I have a R6 component that does
>  @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
> 
> This appears to not bind new matching services, because the policy appears to 
> be STATIC by default.

Yes, static policy has always been the default in DS. You can see this right 
back in the very first DS specification found in OSGi Compendium R4.0, section 
112.3.3: "The static policy is the most simple policy and is the default 
policy”. Also section 112.10 that gives the XML schema, where the reference 
element has the policy attribute defined as:




> 
> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply 
> ReferencePolicy.DYNAMIC, just like the bnd annotations did.

Nope. These are new annotations in a new namespace. There is no reason to 
expect them to have the same behaviour as the bnd annotations.


> 
> Changing it to
>  @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
> ReferenceCardinality.AT_LEAST_ONE)
> 
> appears to make it work like I expected.
> 
> 
> Is this by design?
> 
> Coming from bnd annotations this - to me - seems like another (breaking) 
> subtlety.

It’s a subtlety perhaps because the standard annotations are just a direct, 
literal transformation to the XML, whereas the bnd ones tried to be “smart”. 
Yes, this is by design.

It’s certainly not breaking because, again, these are new annotations and there 
is no reason to expect them to do the same thing…


> 
> -- 
> Ferry Huberts
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to bndtools-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: @Reference multi binding & dynamics

[Neil Bartlett]

> On 7 Oct 2015, at 17:36, Ferry Huberts <maili...@hupie.com> wrote:
> 
> 
> 
> On 07/10/15 18:22, David Jencks wrote:
>> Another use case is where you have set the .cardinality.minimum 
>> property to the expected number of actual services.
>> 
> 
> 
> I can see Tim's case, but this one is rather icky/hackish to me. It implies 
> knowledge of how the component is going to be deployed.
> 
> Anyway, it's all cleared up now as being by design and I fixed up my code, so 
> thanks to all.


I do think there’s a case for bnd to give warnings for some combinations, it’s 
just not as straightforward as “multiple + static = bad”.

Please raise a feature request in the issue tracker.

Cheers,
Neil




> 
>> david jencks
>> 
>>> On Oct 7, 2015, at 12:17 PM, Tim Ward < 
>>> <mailto:tim.w...@paremus.com>tim.w...@paremus.com 
>>> <mailto:tim.w...@paremus.com>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 7 Oct 2015, at 18:13, Ferry Huberts <maili...@hupie.com 
>>>> <mailto:maili...@hupie.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 07/10/15 18:01, Neil Bartlett wrote:
>>>>>> On 7 Oct 2015, at 13:56, Ferry Huberts <maili...@hupie.com 
>>>>>> <mailto:maili...@hupie.com>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Cross-posting because I don't know if the situation/problem below is by 
>>>>>> design, a bug in bnd, or a bug in SCR
>>>>>> 
>>>>>> 
>>>>>> I have a R6 component that does
>>>>>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>>>>>> 
>>>>>> This appears to not bind new matching services, because the policy 
>>>>>> appears to be STATIC by default.
>>>>> Yes, static policy has always been the default in DS. You can see this 
>>>>> right back in the very first DS specification found in OSGi Compendium 
>>>>> R4.0, section 112.3.3: "The static policy is the most simple policy and 
>>>>> is the default policy”. Also section 112.10 that gives the XML schema, 
>>>>> where the reference element has the policy attribute defined as:
>>>>> 
>>>>>>>>> use="optional"/>
>>>>> 
>>>>> 
>>>>>> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply 
>>>>>> ReferencePolicy.DYNAMIC, just like the bnd annotations did.
>>>>> Nope. These are new annotations in a new namespace. There is no reason to 
>>>>> expect them to have the same behaviour as the bnd annotations.
>>>> 
>>>> However, I challenge you to give me _one_ use-case where 
>>>> ReferencePolicy.STATIC && ReferencePolicy.(MULTIPLE|AT_LEAST_ONE) makes 
>>>> sense...
>>>> That combination _creates_ a timing dependency, services might or might 
>>>> not be bound, depending on startup order.
>>>> 
>>> 
>>> You don't need to be dynamic if your reference is greedy. That will eagerly 
>>> pick up new services as they arrive too, just restarting the component when 
>>> it changes.
>>> 
>>> 
>>>> A warning in bndtools like 'you probably meant to use 
>>>> ReferencePolicy.DYNAMIC' when havingReferencePolicy.MULTIPLE or 
>>>> ReferencePolicy.AT_LEAST_ONE would be nice IMHO
>>>> 
>>>>> 
>>>>>> Changing it to
>>>>>> @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
>>>>>> ReferenceCardinality.AT_LEAST_ONE)
>>>>>> 
>>>>>> appears to make it work like I expected.
>>>>>> 
>>>>>> 
>>>>>> Is this by design?
>>>>>> 
>>>>>> Coming from bnd annotations this - to me - seems like another (breaking) 
>>>>>> subtlety.
>>>>> It’s a subtlety perhaps because the standard annotations are just a 
>>>>> direct, literal transformation to the XML, whereas the bnd ones tried to 
>>>>> be “smart”. Yes, this is by design.
>>>>> 
>>>>> It’s certainly not breaking because, again, these are new annotations and 
>>>>> there is no reason to expect them to do the same thing…
>>>>> 
>>>>> 
>>>>>> -- 
&

Re: Split-package warnings from embedded jars

[Neil Bartlett]

It does sound wrong to me.

maven-bundle-plugin is a Felix project.

Neil

> On 2 Oct 2015, at 16:56, Benson Margulies  wrote:
> 
> With maven-bundle-plugin 3.0.0, we are getting split-package
> complaints about packages that are (merely) split between two jar
> files both being embedded into the final result.
> 
> This surprises me. If it sounds wrong to the experts, can you suggest
> whether to point the bug report to bndtools or felix?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Split-package warnings from embedded jars

[Neil Bartlett]

> On 2 Oct 2015, at 22:30, Benson Margulies <ben...@basistech.com> wrote:
> 
> On Fri, Oct 2, 2015 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com 
> <mailto:njbartl...@gmail.com>> wrote:
>> It does sound wrong to me.
>> 
>> maven-bundle-plugin is a Felix project.
> 
> Yes, I do know that. But some problems point down to the bndtools
> below, and some don’t.


True, but I think it’s best to report the error to the project that you are 
directly using, and let the developers work out if it’s actually a lower-level 
dependency going wrong.


> 
> I will endeavour to create a test case.
> 
>> 
>> Neil
>> 
>>> On 2 Oct 2015, at 16:56, Benson Margulies <ben...@basistech.com> wrote:
>>> 
>>> With maven-bundle-plugin 3.0.0, we are getting split-package
>>> complaints about packages that are (merely) split between two jar
>>> files both being embedded into the final result.
>>> 
>>> This surprises me. If it sounds wrong to the experts, can you suggest
>>> whether to point the bug report to bndtools or felix?
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto:users-h...@felix.apache.org>
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
> <mailto:users-unsubscr...@felix.apache.org>
> For additional commands, e-mail: users-h...@felix.apache.org 
> <mailto:users-h...@felix.apache.org>

Re: BndTools 3.0.0. + felix.http.jetty = Unable to resolve

[Neil Bartlett]

BTW regarding that resolution error… the OSGi Compendium JAR does now have
“must.not.resolve” because it is not appropriate for runtime usage. But you
can use any of the APIs from the compendium by downloading the individual
spec bundle for that API. For example, the HttpService spec JAR is here:


http://search.maven.org/#artifactdetails|org.osgi|org.osgi.service.http|1.2.1|jar

Neil


On Thu, Oct 1, 2015 at 4:24 PM, Carsten Ziegeler 
wrote:

> Yes, you're right ,the docs are outdated :(
> (I'll try to update them)
>
> Carsten
>
> Am 01.10.15 um 16:54 schrieb Thomas Driessen:
> > That worked! Thanks a lot.
> >
> > Might it be, that the documentation for the felix.http project is a
> little
> > bit outdated? (
> >
> http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html
> ).
> > Or am I just searching at the wrong place?
> >
> > Kind regards,
> > Thomas
> >
> > 2015-10-01 16:39 GMT+02:00 Carsten Ziegeler :
> >
> >> I think you're missing the org.apache.felix.http.api bundle, version
> 3.0.0
> >>
> >> Carsten
> >>
> >> Am 01.10.15 um 13:12 schrieb Thomas Driessen:
> >>> Hi,
> >>>
> >>> I just started with a fresh Installation of Eclipse and BndTools
> 3.0.0. I
> >>> tried to run a minimal setup with:
> >>>
> >>> -runrequires: \
> >>> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
> >>> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)',\
> >>> osgi.identity;filter:='(osgi.identity=TexoTest)',\
> >>>
> >>
> osgi.identity;filter:='(&(osgi.identity=org.apache.felix.http.jetty)(version>=3.1.0))'
> >>>
> >>> where "TexoTest" is my own bundle and ended up with the following error
> >>> when resolving the bundles:
> >>>
> >>> org.osgi.service.resolver.ResolutionException: Unable to resolve
> >>> <> version=null: missing requirement
> >> org.apache.felix.http.jetty;
> >>> version=3.1.0
> >>> ->  Unable to resolve org.apache.felix.http.jetty version=3.1.0:
> missing
> >>> requirement org.osgi.service.http.context; version=[1.0.0,1.1.0)
> >>> ->  Unable to resolve osgi.cmpn version=6.0.0.201505202027: missing
> >>> requirement &(must.not.resolve=*)(must.not.resolve!=*)]]
> >>>
> >>> Is this an intended behaviour? As of v 6.0.0 the cpmn bundle has this
> >>> "must.not.resolve" thing. So do I get it right and I have to wait for
> >>> org.osgi.service.http.context to be updated so that the cpmn is not a
> >>> mandatory dependency for it anymore?
> >>>
> >>> Best regards,
> >>> Thomas
> >>>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> >> For additional commands, e-mail: users-h...@felix.apache.org
> >>
> >>
> >
> >
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: java.lang.NoClassDefFoundError

[Neil Bartlett]

Yes.

You have to import all packages that you use, except for “java.*”.


> On 18 Sep 2015, at 04:06, Lost  wrote:
> 
> HiI try to use saxReader with myproject,it
> happen:java.lang.NoClassDefFoundError:
> javax/xml/parsers/DocumentBuilderFactoryi think this class is in jre
> Runtime, should i import it ?
> 
> 
> 
> --
> View this message in context: 
> http://apache-felix.18485.x6.nabble.com/java-lang-NoClassDefFoundError-tp5014750.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Need help debugging Felix OSGi bundles (with Eclipse)

[Neil Bartlett]

Pedro,

You are using an unstable, alpha version of Bndtools. Please install the
latest stable release, version 3.0, by following the instructions at:
http://bndtools.org/installation.html

Also I strongly recommend following the tutorial first so you get an
understanding of bnd(tools) concepts: http://bndtools.org/tutorial.html

Regards,
Neil

PS: "I am being slaughtered without mercy"?? Please, stop.

On Sun, Sep 13, 2015 at 11:11 AM, Pedro Domingues <
pedro.doming...@ist.utl.pt> wrote:

> I am trying with bndtools but I am being slaughtered without mercy.
>
> I have like 30 bundles or so. I choose one of the main bundles and
> followed these instructions (
> http://bndtools.org/tutorial.html#run-an-osgi-framework), he created a
> *.bndrun* file in my bundle's root directory with the following:
>
> *-runfw: org.apache.felix.framework;version='[4,5)'*
> *-runee: JavaSE-1.7*
> *-runsystemcapabilities: ${native_capability}*
>
> *-resolve.effective: active;skip:="osgi.service"*
>
> However this happens when I try to edit the file in Eclipse:
>
> [image: http://i.imgur.com/FYKDnvE.png]
>
> However this looks a bit far from what I want. It seems this .bndrun will
> import a felix.jar from somewhere else, but in fact I want to use the one I
> have in C:\code\osgi_proj\deploy\bin\felix.jar because I already have there
> all the bundles I need and the configurations (unless for some debugging
> limitation eclipse needs to directly inject the bundles).
>
> Can this be done, or I will need to deeply modify my project in order for
> this to work?
>
> Thanks!
>
>
>
> On 12/09/2015 22:01, Christian Schneider wrote:
>
> If you only need plain felix then eclipse + bndtools might help.
>
> I just tried the new 3.0.0 version and was able to setup as small project
> in quite short time.
> It features very nice debug integration.
>
> Apart from this remote debugging always works but is less convenient.
>
> Christian
>
> Am 12.09.2015 um 21:31 schrieb Pedro Domingues:
>
> Hi,
>
> I really need to debug my code by the use of breakpoints, however this
> seems a complex undertaking with an OSGi container.
>
> I have Eclipse and Felix (both the latest). My project is a raw OSGi
> project, I am not using PDE, just maven bundle plugin to generate the
> bundles and then copy them to the /bundle folder in felix, then I perform
> java -jar bin/felix.jar and the project runs. So no fuss here.
>
> However I cannot debug the application that way. I've tried to read the
> docs (
> http://felix.apache.org/documentation/development/integrating-felix-with-eclipse.html)
> but they are outdated/broken and cant make them work...
>
> How can I debug this? Will I have to avoid using OSGi just because debug
> is not supported...? :(
>
> Thanks!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
>

Re: Need help debugging Felix OSGi bundles (with Eclipse)

[Neil Bartlett]

Debugging of OSGi runtimes is of course possible, and I have never had a 
problem with it — aside from the occasion difficulty in tracking down source 
code for third-party dependencies.

What IDE or tool would you usually use to debug a Java application?

Neil


> On 12 Sep 2015, at 20:31, Pedro Domingues  wrote:
> 
> Hi,
> 
> I really need to debug my code by the use of breakpoints, however this seems 
> a complex undertaking with an OSGi container.
> 
> I have Eclipse and Felix (both the latest). My project is a raw OSGi project, 
> I am not using PDE, just maven bundle plugin to generate the bundles and then 
> copy them to the /bundle folder in felix, then I perform java -jar 
> bin/felix.jar and the project runs. So no fuss here.
> 
> However I cannot debug the application that way. I've tried to read the docs 
> (http://felix.apache.org/documentation/development/integrating-felix-with-eclipse.html)
>  but they are outdated/broken and cant make them work...
> 
> How can I debug this? Will I have to avoid using OSGi just because debug is 
> not supported...? :(
> 
> Thanks!
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: maven-bundle-plugin with class based filtering ?

[Neil Bartlett]

Hi Christiano,

I *could* tell you how to do this. I could also tell you how to use a knife to 
open a vein in your wrist. Neither of these things are likely to be good for 
you. So it would be irresponsible to provide the information without first 
asking: why do you want to do this?

Regards,
Neil


> On 9 Sep 2015, at 20:34, Cristiano Gavião  wrote:
> 
> Hi,
> I've been using the private-package instruction in order to embed/ inline
> some packages with in some bundles that I'm working with.
> 
> But now I would like to filter a package and inline only some of its
> classes. Is there any way to perform a class based filtering ?
> 
> thanks,
> 
> Cristiano


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org