Re: [osgi-dev] Usage of prototype components

[Raymond Auge via osgi-dev]

There must be at least one "getter" of the service for that to occur.

I guess you need to debug who/what is triggering this instance.

- Ray

On Sun, Aug 2, 2020 at 5:01 PM Paul F Fraser via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> My aim is to only instantiate a prototype component  when required but in
> my code a protype
> component is allways created on startup without a distinct action to get
> the service.
>
> This intial instance is activated and then immediately deactivated in my
> case which does not cause
> me any hassles but it seems unnecessary.
>
> Is this to be expected and if so how can I prevent, or is it necessry to
> prevent this initial instance?
>
> Paul Fraser
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Library development

[Raymond Auge via osgi-dev]

FYI, One thing few people realize is that Service Loader Mediator does
allow your providers to be consumed via the service registry.

If you use the bnd SPI annotations I already mentioned this is a default
behavior.

- Ray

On Thu, May 21, 2020 at 9:19 AM Raymond Auge 
wrote:

> Another alternative designed specifically for this scenario is the OSGi
> Service Loader Mediator Specification [1].
>
> Java's default _service_ mechanism is Service Loader SPI. The Service
> Loader Mediator Specification adds a veneer of pure metadata over this to
> allow it to function in OSGi.
>
> There are even SPI annotations [2] in the Bnd project to help with this
> (you should be able to use these with the maven-bundle-plugin if necessary).
>
> In this way the code is exactly 100% identical in OSGi and outside it.
>
> Sincerely,
> - Ray
>
> [1]
> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html
> [2] https://bnd.bndtools.org/chapters/240-spi-annotations.html
>
> On Thu, May 21, 2020 at 3:54 AM Neil Bartlett via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Along the lines of Bernd's answer, here is what I do:
>>
>> 1. Use declarative services.
>> 2. For injection of service references, prefer constructor injection.
>> 3. The component implementation should be in a private package. However,
>> non-OSGi consumers don't know anything about exported versus private
>> packages, so they just directly instantiate the DS component instance.
>> Because we used constructor injection, it's clear what dependencies
>> they need to provide to the component.
>> 5. If there is a need to interact with OSGi's APIs (e.g. BundleContext),
>> keep that code in a separate factory component. Put this code in a separate
>> class from the "business logic". Don't necessarily worry about using a
>> separate package for this... because Java ClassLoading is extremely lazy,
>> non-OSGi consumers will only be exposed to the OSGi-specific code if they
>> go out of their way to load it.
>>
>> On Thu, 21 May 2020 at 01:50, Bernd Eckenfels via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hello,
>>>
>>> We typically use declarative services (DS) with the Maven bundle plugin
>>> and Annotations. This leaves no (optional) OSGi framework dependency and
>>> still allows a compliant container to manage the lifecycle of the component.
>>>
>>> In some (rare) cases when you have to deal with service references or
>>> OSGi context and you need the core API it does also not hurt to make it
>>> optional, as long as the class which uses it (and would not resolve) is not
>>> used by the stand alone code. This is typically the case for OSGi first
>>> components which are made compatible with stand alone unit tests.
>>>
>>> You can even have the factory receive the service, and therefore be
>>> useable inside the runtime.
>>>
>>> An alternative is, to just have the bundle headers and no service, this
>>> is still useful to OSGi code in many instances where you don't have a
>>> service lifecycle.
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> --
>>> *Von:* osgi-dev-boun...@mail.osgi.org 
>>> im Auftrag von David Leangen via osgi-dev 
>>> *Gesendet:* Thursday, May 21, 2020 12:44:04 AM
>>> *An:* osgi-dev@mail.osgi.org 
>>> *Betreff:* [osgi-dev] Library development
>>>
>>> Hi!
>>>
>>> What is the best way to prepare a library to OSGi-compatible, but not
>>> force the use of OSGi (including forcing transitive dependencies)?
>>>
>>> The library should be split into api / implementation and offered as a
>>> service, but it should be possible for those who do not use OSGi to obtain
>>> the implementation class from a factory. There should be no runtime
>>> dependency on the OSGi framework.
>>>
>>> Are there any good examples out there that I could try to emulate?
>>>
>>> If not, can anybody provide me with some advice?
>>>
>>> My thought is to have:
>>>
>>>  1. A public api package (for all cases)
>>>  2. A private “factory” package (which for OSGi users would just be
>>> private and ignored, and for non-OSGi users would be the part of the
>>> library they would use to obtain the service class), and
>>>  3. An “internal” package that includes an Activator (in an OSGi
>>> environment this would provide the service implementation, for non-OSGi
>>> users it would be ignored).
>>>
>>>
>>> Thanks so much!!
>>>
>>> Cheers,
>>> =David
>>>
>>>
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> 

Re: [osgi-dev] Library development

[Raymond Auge via osgi-dev]

Another alternative designed specifically for this scenario is the OSGi
Service Loader Mediator Specification [1].

Java's default _service_ mechanism is Service Loader SPI. The Service
Loader Mediator Specification adds a veneer of pure metadata over this to
allow it to function in OSGi.

There are even SPI annotations [2] in the Bnd project to help with this
(you should be able to use these with the maven-bundle-plugin if necessary).

In this way the code is exactly 100% identical in OSGi and outside it.

Sincerely,
- Ray

[1] https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html
[2] https://bnd.bndtools.org/chapters/240-spi-annotations.html

On Thu, May 21, 2020 at 3:54 AM Neil Bartlett via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Along the lines of Bernd's answer, here is what I do:
>
> 1. Use declarative services.
> 2. For injection of service references, prefer constructor injection.
> 3. The component implementation should be in a private package. However,
> non-OSGi consumers don't know anything about exported versus private
> packages, so they just directly instantiate the DS component instance.
> Because we used constructor injection, it's clear what dependencies
> they need to provide to the component.
> 5. If there is a need to interact with OSGi's APIs (e.g. BundleContext),
> keep that code in a separate factory component. Put this code in a separate
> class from the "business logic". Don't necessarily worry about using a
> separate package for this... because Java ClassLoading is extremely lazy,
> non-OSGi consumers will only be exposed to the OSGi-specific code if they
> go out of their way to load it.
>
> On Thu, 21 May 2020 at 01:50, Bernd Eckenfels via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hello,
>>
>> We typically use declarative services (DS) with the Maven bundle plugin
>> and Annotations. This leaves no (optional) OSGi framework dependency and
>> still allows a compliant container to manage the lifecycle of the component.
>>
>> In some (rare) cases when you have to deal with service references or
>> OSGi context and you need the core API it does also not hurt to make it
>> optional, as long as the class which uses it (and would not resolve) is not
>> used by the stand alone code. This is typically the case for OSGi first
>> components which are made compatible with stand alone unit tests.
>>
>> You can even have the factory receive the service, and therefore be
>> useable inside the runtime.
>>
>> An alternative is, to just have the bundle headers and no service, this
>> is still useful to OSGi code in many instances where you don't have a
>> service lifecycle.
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> --
>> *Von:* osgi-dev-boun...@mail.osgi.org 
>> im Auftrag von David Leangen via osgi-dev 
>> *Gesendet:* Thursday, May 21, 2020 12:44:04 AM
>> *An:* osgi-dev@mail.osgi.org 
>> *Betreff:* [osgi-dev] Library development
>>
>> Hi!
>>
>> What is the best way to prepare a library to OSGi-compatible, but not
>> force the use of OSGi (including forcing transitive dependencies)?
>>
>> The library should be split into api / implementation and offered as a
>> service, but it should be possible for those who do not use OSGi to obtain
>> the implementation class from a factory. There should be no runtime
>> dependency on the OSGi framework.
>>
>> Are there any good examples out there that I could try to emulate?
>>
>> If not, can anybody provide me with some advice?
>>
>> My thought is to have:
>>
>>  1. A public api package (for all cases)
>>  2. A private “factory” package (which for OSGi users would just be
>> private and ignored, and for non-OSGi users would be the part of the
>> library they would use to obtain the service class), and
>>  3. An “internal” package that includes an Activator (in an OSGi
>> environment this would provide the service implementation, for non-OSGi
>> users it would be ignored).
>>
>>
>> Thanks so much!!
>>
>> Cheers,
>> =David
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Service binding issue and package wiring

[Raymond Auge via osgi-dev]

You cannot have two bundles where:
- each exports the same package (and does not import it)
- AND each exports a service for a type in said package
- AND those services are compatible

Basics of OSGi Classloading:
- each bundle is loaded in a separate classloader
- classloaders load classes (and therefore packages) so a package can be
loaded as many times as there are classloaders (bundles) that can load it
- each of those package instances are incompatible since they come from
different classloaders
- two bundles exporting the same package are immediately incompatible
UNLESS the framework has enough information (substitutable imports) to be
able to only load one of those packages during runtime (in which case it
won't actually load the package from each bundle that provides it, but only
from one such bundle, and let all the other bundles import it instead of
using their own) then the classes and instances would be compatible.

But why you would deliberately subject yourself to that kind of scenario is
beyond me.

Exporting the package from a single API bundle has never been a bad thing.
That should be your goto approach.

- Ray


On Wed, Mar 11, 2020 at 10:57 AM Clément Delgrange via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> > Since both bundles B and C offer to export the api.a package, the
> framework could resolve both bundles to each export the package. Thus you
> can end up with 2 exports of the api.a package in the framework. So bundle
> D will import api.a from either bundle B or bundle C and thus will not be
> able to see the service from the other bundle since it is not type
> compatible.
>
> Maybe I lack some basic knowledge about Java class loading, but I thought
> that as the packages were at the same version there was nothing that can
> really distinguish them, the framework will choose to use one of the
> packages from a specific location (eg; Bundle B) and so the services could
> not be impacted by a type compatibility issue. This is what I understand
> from the blog post sent by Ray too: "*Because the OSGi framework controls
> the classloading on the package level, when multiple bundles export the API
> package(s), the OSGi framework can decide which exporting bundle ultimately
> provides the API package(s) to each bundle importing the API, that is, to
> each API consumer.*". But as I can factually see and from your
> explanation things can happen differently?!
>
> > You may want to also look at
> https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html
>
> Thanks for the link. In the section Going Forward, it is wrote that we
> should consider not embedding API packages that are defined by OSGi
> specifications, does this advice also holds for our own service definitions?
>
> When building a system with multiple related features does it makes sens
> to provide a compile time Bundle with all the API packages, and, one
> runtime API Bundle for each API packages? Is it what the blog post is
> telling us? What is the relation between osgi.cmpn and the set of osgi
> runtime API bundles?
>
> I like to have one API bundle per workspace, it makes dependency
> management easier and I have one unique project to be careful with. Would
> it be relevant that bnd/bndtools provides a support to release multiple
> runtime API Bundles from one API project simply by configuring something in
> the bnd.bnd file. I am not sure to be clear, but this is to control the
> number of projects needed.
>
> Another solution would be to make the API Bundle resolvable, but I had
> some issue with that in the past...
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday 11 March 2020 14:19, Raymond Auge 
> wrote:
>
> Hi Clément,
>
> You may want to also look at
> https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html
>
> :)
>
> - Ray
>
> On Wed, Mar 11, 2020 at 9:16 AM BJ Hargrave via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Since both bundles B and C offer to export the api.a package, the
>> framework could resolve both bundles to each export the package. Thus you
>> can end up with 2 exports of the api.a package in the framework. So bundle
>> D will import api.a from either bundle B or bundle C and thus will not be
>> able to see the service from the other bundle since it is not type
>> compatible.
>>
>> In this scenario, it is better to have only a single exporter of api.a.
>> Bundle A would be the best choice here as it is the original source of the
>> package. But you would need to allow it to be resolvable so it can be used
>> at runtime.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com
>>
>>
>>
>> - Original message -
>> From: "Clément Delgrange via osgi-dev" 
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: OSGi Developer Mail List 
>> Cc:
>> Subject: [EXTERNAL] [osgi-dev] Service binding issue and package wiring
>> Date: Wed, Mar 

Re: [osgi-dev] Intermittent failure to getService

[Raymond Auge via osgi-dev]

On Wed, Mar 11, 2020 at 10:02 AM Raymond Auge 
wrote:

> Prototype scope is super important. It's true we don't have a huge number
> of uses (it may be less than 1% of all services), but where you need them
> they are incredibly useful, particularly in modelling behaviours defined
> outside the realm of OSGi.
>
> For instance, JAX-RS expects resources to be instantiated per request
> (where it can do it's own internal form of injection) so publishing a
> resource as a service really should be done as prototype scope otherwise
> you will surely mess up your state.
>
> CDI expects (Portable) Extensions to be instantiated exactly one time (and
> can have their own state since they are also injected as beans) and so,
> since the OSGi CDI bundle
>

read "CDI container within a CDI bundle can be restarted"


> can be restarted AND in order to support legacy Extension implementations
> you have to pretty much assure that these are provided as prototype scope
> services so that you never reuse the instances.
>
> So these have many real uses where otherwise you'd be forced to use a
> non-osgi factory model.
>
> - Ray
>
>
>
> On Wed, Mar 11, 2020 at 9:30 AM Peter Kriens via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> It all depends ... In general state can be managed in many different
>> ways. Prototype scope is too much in your face, too much boilerplate, that
>> is why I avoid it. It works nicely behind the scenes though like DS and
>> CDI. I do not think I've ever used them so far. (Which is a self
>> perpetuating truth, I know.)
>>
>> PK
>>
>>
>>
>> On 11 Mar 2020, at 13:26, Alain Picard  wrote:
>>
>> Peter and Tim,
>>
>> Thanks for the pointers. The error was caused by some invalid use of a
>> disposed object. This was using factory components and I switched all of it
>> to use prototype components instead which IMHO are easier to manage.
>>
>> And Peter to your question about using prototype scope, those objects
>> contain state and it is my understanding that prototype scope is required
>> in those cases.
>>
>> Thanks
>> Alain
>>
>>
>> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens 
>> wrote:
>>
>>> Some remarks:
>>>
>>> * Yes, it is thread safe. In OSGi we mark all thread safe types with the
>>> @ThreadSafe annotation.
>>> * The error message is not in the log you listed. Since the log contains
>>> a deactivation message, I hope you're handling the case corrected that
>>> you're being called after deactivation? Seems too simple, but anyway ... :-)
>>>
>>> * And for something completely different, is there any reason you use
>>> the prototype scope? You real code might need it but for this code it just
>>> looks like making it accidentally complex?
>>> * And last but not least, you seem to be using slf4j? Did you wire up
>>> the OSGi log to it? I've seen cases where the information was in the OSGi
>>> log but those messages were discarded.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>> Question: The method getDiagnosticForEObject can be called by different
>>> threads. Can this be the source of the issue? I see that
>>> ComponentServiceObject is tagged as ThreadSafe, but?
>>>
>>> Alain
>>>
>>>
>>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard 
>>> wrote:
>>>
 Tim,

 I don't think so. BaValidationManagerExt is used in only 1 place and it
 is instantiated in activate and released in deactivate:
 @Component(
 factory = ValidationManager.CONFIG_FACTORY,
 service = ValidationManager.class
 )
 public final class CoreValidationManager extends
 CDODefaultTransactionHandler1 implements ValidationManager,
 CDOTransactionHandler2 {
 ...
 @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
 private ComponentServiceObjects extenderFactory;
 private ValidationManagerExt extender;

 @Activate
 private void activate() {
 log.trace("Activating {}", getClass()); //$NON-NLS-1$

 extender = extenderFactory.getService();
 }

 @Deactivate
 private void deactivate() {
 log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
 extenderFactory.ungetService(extender);
 }

 Cheers,
 Alain

 Alain Picard
 Chief Strategy Officer
 Castor Technologies Inc
 o:514-360-7208
 m:813-787-3424

 pic...@castortech.com
 www.castortech.com


 On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:

> Hi Alain,
>
> Is it possible that someone has a reference to a
> BaValidationManagerExt service instance that they aren’t releasing after
> ungetting it (or that they’re holding onto after it has been 
> unregistered)?
> It might be an SCR bug, but it’s more likely to be some code holding onto 
> a
> component instance that it shouldn’t.
>
> Best Regards,
>
> Tim
>
> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
> 

Re: [osgi-dev] Intermittent failure to getService

[Raymond Auge via osgi-dev]

Prototype scope is super important. It's true we don't have a huge number
of uses (it may be less than 1% of all services), but where you need them
they are incredibly useful, particularly in modelling behaviours defined
outside the realm of OSGi.

For instance, JAX-RS expects resources to be instantiated per request
(where it can do it's own internal form of injection) so publishing a
resource as a service really should be done as prototype scope otherwise
you will surely mess up your state.

CDI expects (Portable) Extensions to be instantiated exactly one time (and
can have their own state since they are also injected as beans) and so,
since the OSGi CDI bundle can be restarted AND in order to support legacy
Extension implementations you have to pretty much assure that these are
provided as prototype scope services so that you never reuse the instances.

So these have many real uses where otherwise you'd be forced to use a
non-osgi factory model.

- Ray



On Wed, Mar 11, 2020 at 9:30 AM Peter Kriens via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> It all depends ... In general state can be managed in many different ways.
> Prototype scope is too much in your face, too much boilerplate, that is why
> I avoid it. It works nicely behind the scenes though like DS and CDI. I do
> not think I've ever used them so far. (Which is a self perpetuating truth,
> I know.)
>
> PK
>
>
>
> On 11 Mar 2020, at 13:26, Alain Picard  wrote:
>
> Peter and Tim,
>
> Thanks for the pointers. The error was caused by some invalid use of a
> disposed object. This was using factory components and I switched all of it
> to use prototype components instead which IMHO are easier to manage.
>
> And Peter to your question about using prototype scope, those objects
> contain state and it is my understanding that prototype scope is required
> in those cases.
>
> Thanks
> Alain
>
>
> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens 
> wrote:
>
>> Some remarks:
>>
>> * Yes, it is thread safe. In OSGi we mark all thread safe types with the
>> @ThreadSafe annotation.
>> * The error message is not in the log you listed. Since the log contains
>> a deactivation message, I hope you're handling the case corrected that
>> you're being called after deactivation? Seems too simple, but anyway ... :-)
>>
>> * And for something completely different, is there any reason you use the
>> prototype scope? You real code might need it but for this code it just
>> looks like making it accidentally complex?
>> * And last but not least, you seem to be using slf4j? Did you wire up the
>> OSGi log to it? I've seen cases where the information was in the OSGi log
>> but those messages were discarded.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> Question: The method getDiagnosticForEObject can be called by different
>> threads. Can this be the source of the issue? I see that
>> ComponentServiceObject is tagged as ThreadSafe, but?
>>
>> Alain
>>
>>
>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard 
>> wrote:
>>
>>> Tim,
>>>
>>> I don't think so. BaValidationManagerExt is used in only 1 place and it
>>> is instantiated in activate and released in deactivate:
>>> @Component(
>>> factory = ValidationManager.CONFIG_FACTORY,
>>> service = ValidationManager.class
>>> )
>>> public final class CoreValidationManager extends
>>> CDODefaultTransactionHandler1 implements ValidationManager,
>>> CDOTransactionHandler2 {
>>> ...
>>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>>> private ComponentServiceObjects extenderFactory;
>>> private ValidationManagerExt extender;
>>>
>>> @Activate
>>> private void activate() {
>>> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>>>
>>> extender = extenderFactory.getService();
>>> }
>>>
>>> @Deactivate
>>> private void deactivate() {
>>> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
>>> extenderFactory.ungetService(extender);
>>> }
>>>
>>> Cheers,
>>> Alain
>>>
>>> Alain Picard
>>> Chief Strategy Officer
>>> Castor Technologies Inc
>>> o:514-360-7208
>>> m:813-787-3424
>>>
>>> pic...@castortech.com
>>> www.castortech.com
>>>
>>>
>>> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:
>>>
 Hi Alain,

 Is it possible that someone has a reference to a BaValidationManagerExt
 service instance that they aren’t releasing after ungetting it (or that
 they’re holding onto after it has been unregistered)? It might be an SCR
 bug, but it’s more likely to be some code holding onto a component instance
 that it shouldn’t.

 Best Regards,

 Tim

 On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

 Hi

 I am having a very intermittent issue with getService on a prototype
 component. This is called hundreds of times and I put a breakpoint a few
 weeks ago and have now gotten the error.

 I have this class:
 

Re: [osgi-dev] Service binding issue and package wiring

[Raymond Auge via osgi-dev]

Hi Clément,

You may want to also look at
https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html

:)

- Ray

On Wed, Mar 11, 2020 at 9:16 AM BJ Hargrave via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Since both bundles B and C offer to export the api.a package, the
> framework could resolve both bundles to each export the package. Thus you
> can end up with 2 exports of the api.a package in the framework. So bundle
> D will import api.a from either bundle B or bundle C and thus will not be
> able to see the service from the other bundle since it is not type
> compatible.
>
> In this scenario, it is better to have only a single exporter of api.a.
> Bundle A would be the best choice here as it is the original source of the
> package. But you would need to allow it to be resolvable so it can be used
> at runtime.
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: "Clément Delgrange via osgi-dev" 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List 
> Cc:
> Subject: [EXTERNAL] [osgi-dev] Service binding issue and package wiring
> Date: Wed, Mar 11, 2020 08:13
>
> Hi all,
>
> I have some sparse service binding issues at runtime that I think are
> related at how my bundles export packages.
>
> Here is what I have:
> - Bundle A exports API package api.a and is not resolvable (not present at
> runtime).
> - Bundle B provides api.a.Service1 service and export/import  api.a
> package.
> - Bundle C provides api.a.Service2 service and export/import  api.a
> package.
> - Bundle D consumes Service1 or Service2 and import api.a package.
>
> In this case is there any reason related to the way packages are wired
> that could lead bundle D to not get Service1 or Service2? Subsidiary
> question, is it fine to have an API package partly provided by two
> different bundles when provider bundles embed their API?
>
> In a more general practice, for a specific functionality, I have often one
> core service contract, some DTOs and some DAO services. Which one of this
> combination is better (considering that I have always an unresolvable API
> bundle and my providers export the API package they provide):
>
> - Core service, DAOs and DTOs in one API package then two providers, one
> for the core service implementation and DTOs and the other for the DAOs
> implementation.
> - Core service, DAOs and DTOs split in different API packages then three
> providers, one for each.
>
> Regards,
> Clement
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

On Fri, Jan 3, 2020 at 10:29 AM Martin Petzold  wrote:

> IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and bnd
> "hate" Eclipse. It was never easy. The worst ever was not to find together!
>
Sounds like you may not have tried bndtools.m2e integration in a long time
or ever. OSGi, bnd, bndtools.m2e + Eclipse are a happy team that I use
every single day on about 15 projects, including in IDE integration testing
and live coding!

Furthermore, the bnd team (disclosure: of which I am part) are very active
[1] in improving the IDE experience and are more than happy to address any
issues you encounter.

Anyway, if you like what you have then more power to you :) but it seems
like you might be alone on an island which can be awesome!... but it can
also be bad.

Sincerely,
- Ray

[1] https://github.com/bndtools/bnd/pulse/monthly *(Activity - 1 month: 49
merged pull requests, 68 commits, 29 closed issues, 3 new issues)*

=> My approach works well, I have a lot under my control and am able to
> migrate to plain Java (with or without modules) if it is required
>
> I still love the OSGi specifications and framework, use a lot of them, and
> learned a lot of them and all people involved!
>
> Am 03.01.20 um 16:22 schrieb Dirk Fauth:
>
> I also think that the chosen approach is not the best. Actually it is a
> mixture of Tycho and plain maven that mostly works but can lead to
> resolution issues like the one discussed.
>
> For plain OSGi and Maven I agree with Ray. But you need to migrate to bnd
> of course and get rid of the manual manifest configuration (which is good
> IMHO).
>
> If you really want to stick with manual manifest management, you should
> use Tycho in its intended way by using repositories or a target definition
> so the dependencies can be resolved automatically via p2. pomDependencies
> consider is intended for adding dependencies that are not available via p2
> update sites.
>
> But of course this is only my personal opinion based on my experience.
>
> Greez,
> Dirk
>
> Raymond Auge  schrieb am Fr., 3. Jan. 2020,
> 15:49:
>
>> I would recommend, since you are using maven, not really using tycho for
>> much AND in order to future proof your OSGi application you should probably
>> migrate to bnd-*-maven-plugin(s) [1]
>>
>> These are better integrated with maven, maven scopes and give you a full
>> cycle of tools to go from building to running. Also it's the most cutting
>> edge OSGi build support under the hood and will reduce your MANIFEST
>> editing to its most minimal.
>>
>> - Ray
>>
>> [1] https://github.com/bndtools/bnd/blob/master/maven/README.md
>>
>> On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> I'm using:
>>>
>>> 
>>> consider
>>> 
>>>
>>> It is working now with the following dependencies in my POM for
>>> build/compile time. At runtime I use org.eclipse.osgi (without the service
>>> and util bundle) and implementations of cm (apache felix), event (apache
>>> felix), and log (within org.eclipse.osgi an my own).
>>>
>>> 
>>>
>>> 
>>> org.eclipse.platform
>>> org.eclipse.osgi
>>> ${dependency.org.eclipse.osgi}
>>> 
>>>
>>> 
>>>
>>> 
>>> org.osgi
>>> org.osgi.service.cm
>>> ${dependency.org.osgi.service.cm}
>>> 
>>> 
>>> org.osgi
>>> org.osgi.service.event
>>> ${dependency.org.osgi.service.event}
>>> 
>>> 
>>> org.osgi
>>> org.osgi.service.log
>>> ${dependency.org.osgi.service.log}
>>> 
>>> Am 03.01.20 um 15:29 schrieb Dirk Fauth:
>>>
>>> Well afaik Tycho has its own reactor for resolving dependencies. That's
>>> why I am a bit confused about your message. If you build via Tycho you need
>>> to have a working target definition or repositories configuration. POM
>>> dependencies are not considered by default. If you update to R7 you need to
>>> update to a current Eclipse update site and ensure that all related bundles
>>> and/or features are included.
>>>
>>> But of course I am not sure if I understand your issue completely. If
>>> you are not building using Tycho but plain Maven probably some dependencies
>>> are not resolvable. But the previous answers already covered most topics. I
>>> just stepped in because of mentioning Tycho and pom dependencies.
>>>
>>> Greez,
>>> Dirk
>>>
>>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>>>
 Because I want to manage my package dependencies in the MANIFEST.MF and
 I want to be able to run my application in an PDE environment with a
 separate target platform within Eclipse. However, this post is only related
 to my build and not to my development environment.
 Am 03.01.20 um 15:11 schrieb Dirk Fauth:

 And why are you using Tycho when there is no PDE involved?

 Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:

> Only Maven repositories. No PDE. Plain OSGi application with my own
> launcher at runtime. At runtime there is no problem. This application is
> running for 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

I would recommend, since you are using maven, not really using tycho for
much AND in order to future proof your OSGi application you should probably
migrate to bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give you a full
cycle of tools to go from building to running. Also it's the most cutting
edge OSGi build support under the hood and will reduce your MANIFEST
editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I'm using:
>
> 
> consider
> 
>
> It is working now with the following dependencies in my POM for
> build/compile time. At runtime I use org.eclipse.osgi (without the service
> and util bundle) and implementations of cm (apache felix), event (apache
> felix), and log (within org.eclipse.osgi an my own).
>
> 
>
> 
> org.eclipse.platform
> org.eclipse.osgi
> ${dependency.org.eclipse.osgi}
> 
>
> 
>
> 
> org.osgi
> org.osgi.service.cm
> ${dependency.org.osgi.service.cm}
> 
> 
> org.osgi
> org.osgi.service.event
> ${dependency.org.osgi.service.event}
> 
> 
> org.osgi
> org.osgi.service.log
> ${dependency.org.osgi.service.log}
> 
> Am 03.01.20 um 15:29 schrieb Dirk Fauth:
>
> Well afaik Tycho has its own reactor for resolving dependencies. That's
> why I am a bit confused about your message. If you build via Tycho you need
> to have a working target definition or repositories configuration. POM
> dependencies are not considered by default. If you update to R7 you need to
> update to a current Eclipse update site and ensure that all related bundles
> and/or features are included.
>
> But of course I am not sure if I understand your issue completely. If you
> are not building using Tycho but plain Maven probably some dependencies are
> not resolvable. But the previous answers already covered most topics. I
> just stepped in because of mentioning Tycho and pom dependencies.
>
> Greez,
> Dirk
>
> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>
>> Because I want to manage my package dependencies in the MANIFEST.MF and I
>> want to be able to run my application in an PDE environment with a separate
>> target platform within Eclipse. However, this post is only related to my
>> build and not to my development environment.
>> Am 03.01.20 um 15:11 schrieb Dirk Fauth:
>>
>> And why are you using Tycho when there is no PDE involved?
>>
>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:
>>
>>> Only Maven repositories. No PDE. Plain OSGi application with my own
>>> launcher at runtime. At runtime there is no problem. This application is
>>> running for years and I have worked with OSGi for years now. I just have
>>> this trouble migrating to OSGi 7.0.0 and at compile / build time with
>>> Maven+Tycho.
>>> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>>>
>>> And do you get the error at build time or when running your result?
>>>
>>> With Tycho you typically use PDE mechanisms to resolve dependencies, not
>>> maven dependencies.
>>>
>>> And what is your result? A plain OSGi application or a RCP application?
>>>
>>> Greez,
>>> Dirk
>>>
>>> Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:
>>>
 Hi,

 If you are using Tycho, which repository are you using for dependency
 resolution? Or do you build using a target definition? If so, which eclipse
 software site have you configured?

 Greez,
 Dirk

 Martin Petzold via osgi-dev  schrieb am Fr.,
 3. Jan. 2020, 14:20:

> Dear Neil,
>
> thanks, but now we start again at the beginning at my first message
> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
> (with Tycho) because it requires 'osgi.unresolvable;
> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>
> Kind regards,
>
> Martin
> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>
>
>
> On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Okay, thanks. This is clear now.
>>
>> However, Ray told me to set the dependency for "org.eclipse.osgi" to
>> "runtime" scope. But how can my implementation then depend on
>> "org.osgi.framework" package during compile time? Either there is a
>> separate API bundle from OSGi Alliance containing "org.osgi.framework"
>> (which one is it?)
>>
>
> Yes, this is the org.osgi:osgi.core dependency. That contains the pure
> api and no implementation, whereas org.eclipse.osgi is an implementation.
>
> Or you could just use org.eclipse.osgi at both compile time and
> runtime, but then you should be careful to avoid using equinox internal
> packages.
>
> or I should set the scope to compile instead of runtime?
>>
>> I am using the BundleContext and need access to this package.
>>
>> Thanks and kind 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

A bit of rational about why companion jars are unresolvable:

The OSGi specs are to a very high degree independent from each other.
There's no reason for you to be forced to use all R5 specs, or all R6 or
whatever. Those are simply marketing versions.

What you are really using are the individual specs at a given version.

For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly fine
combination given you can find providers of each that work together well.
The APIs themselves won't care.

However some providers actually package OSGi spec APIs which they provide
implementations for, which means if you include the aggregate companion
jars also at runtime you may have two API versions to contend with.

You may inadvertently expose yourself to a wrong API version, hence why
they will no longer resolve.

- Ray

On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge 
wrote:

> Yes and yes.
>
> OSGi started adding the unresolveable requirement at release 6 IIRC. So if
> you are using a prior releases of the companion jars (including cmpn,
> enterprise) they won't give you this failure, so you should upgrade.
>
> *Replacements:* Replace the compendium APIs with their respective
> individual api jars available on maven central, like this one [1].
>
> [1]
> https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar
>
> - Ray
>
>
> On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold  wrote:
>
>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
>> remove this dependency too?
>> Am 02.01.20 um 18:23 schrieb Raymond Auge:
>>
>>
>>
>> On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Dear OSGi gurus,
>>> I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The
>>> reason is that I need access to the "org.osgi.framework" package. I am
>>> using Maven (3.6) and Tycho (1.5.1) for building. The build platform runs
>>> Debian 10 and Java 11.
>>>
>>> *I get the following error:*
>>>
>>> Missing requirement: osgi.core 7.0.0.201802012106 requires
>>> 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it
>>> could not be found
>>>
>>
>> The "companion jars" are not meant for runtime and since resolving is a
>> runtime operation (even when performed during build, i.e. deployment
>> purposes) should not be included.
>>
>>
>>> *However, if I remove the dependency I get the following error:*
>>> Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package;
>>> org.osgi.framework 1.7.0' but it could not be found
>>>
>>
>> This means you have no runtime framework available! Add a runtime
>> dependency on the equinox framework:
>>
>> 
>> org.eclipse.platform
>> org.eclipse.osgi
>> 3.x.0
>> runtime
>> 
>> // of course use tycho mechanism for above.
>>
>>
>>> *What is going wrong? How can I resolve this problem?*
>>>
>>> Stack Overflow:
>>> https://stackoverflow.com/questions/59563368/maven-tycho-cannot-resolve-osgi-core-bundle
>>>
>> I'll answer there in a moment.
>>
>> - Ray
>>
>>
>>> Thanks and kind regards,
>>>
>>> Martin
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>>
>>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

Yes and yes.

OSGi started adding the unresolveable requirement at release 6 IIRC. So if
you are using a prior releases of the companion jars (including cmpn,
enterprise) they won't give you this failure, so you should upgrade.

*Replacements:* Replace the compendium APIs with their respective
individual api jars available on maven central, like this one [1].

[1]
https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar

- Ray


On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold  wrote:

> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
> remove this dependency too?
> Am 02.01.20 um 18:23 schrieb Raymond Auge:
>
>
>
> On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Dear OSGi gurus,
>> I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The reason
>> is that I need access to the "org.osgi.framework" package. I am using Maven
>> (3.6) and Tycho (1.5.1) for building. The build platform runs Debian 10 and
>> Java 11.
>>
>> *I get the following error:*
>>
>> Missing requirement: osgi.core 7.0.0.201802012106 requires
>> 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it
>> could not be found
>>
>
> The "companion jars" are not meant for runtime and since resolving is a
> runtime operation (even when performed during build, i.e. deployment
> purposes) should not be included.
>
>
>> *However, if I remove the dependency I get the following error:*
>> Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package;
>> org.osgi.framework 1.7.0' but it could not be found
>>
>
> This means you have no runtime framework available! Add a runtime
> dependency on the equinox framework:
>
> 
> org.eclipse.platform
> org.eclipse.osgi
> 3.x.0
> runtime
> 
> // of course use tycho mechanism for above.
>
>
>> *What is going wrong? How can I resolve this problem?*
>>
>> Stack Overflow:
>> https://stackoverflow.com/questions/59563368/maven-tycho-cannot-resolve-osgi-core-bundle
>>
> I'll answer there in a moment.
>
> - Ray
>
>
>> Thanks and kind regards,
>>
>> Martin
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
>
>

-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Dear OSGi gurus,
> I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The reason
> is that I need access to the "org.osgi.framework" package. I am using Maven
> (3.6) and Tycho (1.5.1) for building. The build platform runs Debian 10 and
> Java 11.
>
> *I get the following error:*
>
> Missing requirement: osgi.core 7.0.0.201802012106 requires
> 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it
> could not be found
>

The "companion jars" are not meant for runtime and since resolving is a
runtime operation (even when performed during build, i.e. deployment
purposes) should not be included.


> *However, if I remove the dependency I get the following error:*
> Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package;
> org.osgi.framework 1.7.0' but it could not be found
>

This means you have no runtime framework available! Add a runtime
dependency on the equinox framework:


org.eclipse.platform
org.eclipse.osgi
3.x.0
runtime

// of course use tycho mechanism for above.


> *What is going wrong? How can I resolve this problem?*
>
> Stack Overflow:
> https://stackoverflow.com/questions/59563368/maven-tycho-cannot-resolve-osgi-core-bundle
>
I'll answer there in a moment.

- Ray


> Thanks and kind regards,
>
> Martin
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] serviceloader

[Raymond Auge via osgi-dev]

You could also use bnd's `@ServiceProvider` and/or `@ServiceConsumer`
annotations which handle all of this magic for you.

The addition of the service capability was recently added so is not
available until next release (5.0.0), but everything else is handled.

Before 5.0.0 this is what I typically use:

@Capability(
 attribute =
"objectClass:List=javax.enterprise.inject.spi.Extension",
 namespace = SERVICE_NAMESPACE
)
@ServiceProvider(
 attribute = {
 CDI_EXTENSION_PROPERTY + '=' + EXTENSION_NAME,
 SERVICE_SCOPE + '=' + SCOPE_PROTOTYPE, // specially supported by
SpiFly to provide prototype scoped services
 SERVICE_VENDOR + "=Apache Software Foundation",
 "version:Version=" + EXTENSION_VERSION
 },
 uses = Extension.class,
 value = Extension.class
)
// implements Extension
public class MPConfigExtension extends ConfigExtension { ... }


- Ray

On Tue, Dec 17, 2019 at 9:28 AM David Bosschaert via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Markus,
>
> Sorry for the late reply.
>
> I think it makes sense in the bundle_provider to also have the capability
> Provide-Capability: osgi.service;objectClass:List="foo.bar.MySPI"
>
> Ideally this could be automatically generated by tooling, when it sees the
>   Provide-Capability: osgi.serviceloader;osgi.serviceloader=...
> capability, but I don't think this auto-generation happens right now.
>
> > Or should the requirement
>
>> > osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
>> > also be satisfied by the provided
>> > osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI
>> > (and its requirement for the Registrar) by the resolving
>> implementations?
>>
>
> I don't think that during resolution such 'complicated' mapping should
> take place. Capabilities and requirements are straightforward so an
> osgi.service requirement should be satisfied by an osgi.service capability,
> not a capability in some other namespace.
>
> But yes, providing the additional osgi.service capability in
> the bundle_provider makes sense to me.
>
> Best regards,
>
> David
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Questions about R7 Configurator

[Raymond Auge via osgi-dev]

... not just DS, but OSGi CDI too with Bean Property Types [1]!

:)

[1]
https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html#service.cdi-bean.property.types

On Tue, Dec 17, 2019 at 7:03 AM David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Hi David,
>
> Ah, ok. Yes, that helps indeed. Thanks!
>
> Cheers,
> =David
>
>
> On Dec 17, 2019, at 19:55, David Bosschaert 
> wrote:
>
> Hi David,
>
> This means that having an untyped map of configuration data is in most
> cases not what you want. More convenient is to convert it to a typed api.
> Using the OSGi converter to create an annotation instance is a very
> convenient way to do this. Annotations are particularly useful since they
> allow you to specify defaults too.
>
> The converter spec at
> https://osgi.org/specification/osgi.enterprise/7.0.0/util.converter.html#util.converter-maps
> just under table 707.5 has an example of this.
>
> The converter allows you to do this anywhere you like; Declarative
> Services also has this functionality built-in. There it's called 'component
> property types'.
>
> Hope this helps,
>
> David
>
> On Tue, 17 Dec 2019 at 06:56, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>>
>> Hi!
>>
>> I have a question about the Configurator spec. I am trying to update from
>> the old enRoute Configurer to the new R7 Configurator.
>>
>>
>> I am not sure what this means:
>>
>> A convenient way to convert a configuration map to the desired data types
>> is by using the Converter to convert it to an annotation instance or by
>> using a Declarative Services component property type.
>>
>>
>>
>> Can somebody enlighten me?
>>
>>
>>
>> I will surely have more questions later. :-)
>>
>>
>> Cheers,
>> =David
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Raymond Auge via osgi-dev]

On Wed, Oct 16, 2019 at 7:53 PM Greg Amerson via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> And with regards to version increases, if a new method added to
> `DataHandler` that would break API and cause a major version increase for
> the package, however, if a new method was added to `DataContext` since that
> API is marked `@ProviderType` the package version increase would only have
> to be minor.  Is that correct?
>

That is correct!

- Ray


>
> On Wed, Oct 16, 2019 at 6:06 PM Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Let me see if I can take a crack at it! Though I'm often told I also
>> don't understand when I try to explain it. :D
>>
>> Suppose you have an API like so:
>>
>> interface DataHandler {
>>  void processData(DataContext context);
>> }
>>
>> This API has 2 interfaces `DataHandler` and `DataContext`
>>
>> Now you happen to know there is a library data.machine-1.2.3.jar which is
>> a data processing engine and to use it all you need to do is publish an
>> OSGi service of type `DataHandler` and it will do some magic.
>>
>> Since you implement `DataHandler` this interface is sensitive to you as a
>> consumer. If the API were to add a method if would break your code. In this
>> case DataHandler is effectively @ConsumerType. It is a type which is
>> implemented in order to _use_ the API.
>>
>> Now, DataContext is not so sensitive for you in this scenario because you
>> only _recieve_ instances of it. You never have to implement it in your
>> _use_ of the API. In this case DataContext is @ProviderType since it's an
>> interface which only _providers_ implement. Therefore if a new method was
>> added to it, it would _not_ break your code, it _would_ however force the
>> implementers of data.machine-1.2.3.jar to make a new release since they are
>> a _provider_ of the API.
>>
>> So you see, both interfaces are part of the same API, yet one is
>> @ConsumerType (DataHandler) and the other is @ProviderType (DataContext).
>>
>> I hope that helps. Others feel free to correct my understanding and
>> hopefully, I'll finally grok it myself.
>> - Ray
>>
>>
>> On Wed, Oct 16, 2019 at 3:34 PM Milen Dyankov via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Welcome to the club ;) I struggled with that myself for a long time.
>>>
>>> I think I finally got to understand it couple of years ago. Here is how
>>> I explained it during one of my talks:
>>> https://www.youtube.com/watch?v=hGNrZmr0zz8=youtu.be=1569
>>> I hope this helps better than me trying to write it all down here.
>>>
>>> Best,
>>> Milen
>>>
>>> On Wed, Oct 16, 2019 at 9:15 PM Leschke, Scott via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>>> I’m trying to wrap my head around these two annotations and I’m
>>>> struggling a bit. Is the perspective of the provider and consumer roles
>>>> from a bundle perspective or an application perspective?
>>>>
>>>> I’ve read the Semantic Versioning whitepaper a number of times and it
>>>> doesn’t really clear things up for me definitely.
>>>>
>>>>
>>>>
>>>> If an application has an API bundle that only exposes Interfaces and
>>>> Abstract classes, and those interfaces are implemented by other bundles in
>>>> the app, are those bundles providers or consumers? My inclination is that
>>>> they’re providers but then when does a bundle become a consumer?  Given
>>>> that API bundles are compile only (this is the rule right?), would a good
>>>> rule be that if you implement the interface and export the package it’s in,
>>>> that type would be @ProviderType, if you don’t implement it it’s
>>>> @ConsumeType?
>>>>
>>>>
>>>>
>>>> It would seem to me that @ProviderType would be the default using this
>>>> logic, as opposed to @ConsumerType, which leads me to believe that I’m
>>>> thinking about this wrong.
>>>>
>>>>
>>>>
>>>> Any help appreciated as always.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Scott Leschke
>>>> ___
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>>
>

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Raymond Auge via osgi-dev]

Let me see if I can take a crack at it! Though I'm often told I also don't
understand when I try to explain it. :D

Suppose you have an API like so:

interface DataHandler {
 void processData(DataContext context);
}

This API has 2 interfaces `DataHandler` and `DataContext`

Now you happen to know there is a library data.machine-1.2.3.jar which is a
data processing engine and to use it all you need to do is publish an OSGi
service of type `DataHandler` and it will do some magic.

Since you implement `DataHandler` this interface is sensitive to you as a
consumer. If the API were to add a method if would break your code. In this
case DataHandler is effectively @ConsumerType. It is a type which is
implemented in order to _use_ the API.

Now, DataContext is not so sensitive for you in this scenario because you
only _recieve_ instances of it. You never have to implement it in your
_use_ of the API. In this case DataContext is @ProviderType since it's an
interface which only _providers_ implement. Therefore if a new method was
added to it, it would _not_ break your code, it _would_ however force the
implementers of data.machine-1.2.3.jar to make a new release since they are
a _provider_ of the API.

So you see, both interfaces are part of the same API, yet one is
@ConsumerType (DataHandler) and the other is @ProviderType (DataContext).

I hope that helps. Others feel free to correct my understanding and
hopefully, I'll finally grok it myself.
- Ray

On Wed, Oct 16, 2019 at 3:15 PM Leschke, Scott via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I’m trying to wrap my head around these two annotations and I’m struggling
> a bit. Is the perspective of the provider and consumer roles from a bundle
> perspective or an application perspective?
>
> I’ve read the Semantic Versioning whitepaper a number of times and it
> doesn’t really clear things up for me definitely.
>
>
>
> If an application has an API bundle that only exposes Interfaces and
> Abstract classes, and those interfaces are implemented by other bundles in
> the app, are those bundles providers or consumers? My inclination is that
> they’re providers but then when does a bundle become a consumer?  Given
> that API bundles are compile only (this is the rule right?), would a good
> rule be that if you implement the interface and export the package it’s in,
> that type would be @ProviderType, if you don’t implement it it’s
> @ConsumeType?
>
>
>
> It would seem to me that @ProviderType would be the default using this
> logic, as opposed to @ConsumerType, which leads me to believe that I’m
> thinking about this wrong.
>
>
>
> Any help appreciated as always.
>
>
>
> Regards,
>
>
>
> Scott Leschke
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Raymond Auge via osgi-dev]

Let me see if I can take a crack at it! Though I'm often told I also don't
understand when I try to explain it. :D

Suppose you have an API like so:

interface DataHandler {
 void processData(DataContext context);
}

This API has 2 interfaces `DataHandler` and `DataContext`

Now you happen to know there is a library data.machine-1.2.3.jar which is a
data processing engine and to use it all you need to do is publish an OSGi
service of type `DataHandler` and it will do some magic.

Since you implement `DataHandler` this interface is sensitive to you as a
consumer. If the API were to add a method if would break your code. In this
case DataHandler is effectively @ConsumerType. It is a type which is
implemented in order to _use_ the API.

Now, DataContext is not so sensitive for you in this scenario because you
only _recieve_ instances of it. You never have to implement it in your
_use_ of the API. In this case DataContext is @ProviderType since it's an
interface which only _providers_ implement. Therefore if a new method was
added to it, it would _not_ break your code, it _would_ however force the
implementers of data.machine-1.2.3.jar to make a new release since they are
a _provider_ of the API.

So you see, both interfaces are part of the same API, yet one is
@ConsumerType (DataHandler) and the other is @ProviderType (DataContext).

I hope that helps. Others feel free to correct my understanding and
hopefully, I'll finally grok it myself.
- Ray


On Wed, Oct 16, 2019 at 3:34 PM Milen Dyankov via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Welcome to the club ;) I struggled with that myself for a long time.
>
> I think I finally got to understand it couple of years ago. Here is how I
> explained it during one of my talks:
> https://www.youtube.com/watch?v=hGNrZmr0zz8=youtu.be=1569
> I hope this helps better than me trying to write it all down here.
>
> Best,
> Milen
>
> On Wed, Oct 16, 2019 at 9:15 PM Leschke, Scott via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> I’m trying to wrap my head around these two annotations and I’m
>> struggling a bit. Is the perspective of the provider and consumer roles
>> from a bundle perspective or an application perspective?
>>
>> I’ve read the Semantic Versioning whitepaper a number of times and it
>> doesn’t really clear things up for me definitely.
>>
>>
>>
>> If an application has an API bundle that only exposes Interfaces and
>> Abstract classes, and those interfaces are implemented by other bundles in
>> the app, are those bundles providers or consumers? My inclination is that
>> they’re providers but then when does a bundle become a consumer?  Given
>> that API bundles are compile only (this is the rule right?), would a good
>> rule be that if you implement the interface and export the package it’s in,
>> that type would be @ProviderType, if you don’t implement it it’s
>> @ConsumeType?
>>
>>
>>
>> It would seem to me that @ProviderType would be the default using this
>> logic, as opposed to @ConsumerType, which leads me to believe that I’m
>> thinking about this wrong.
>>
>>
>>
>> Any help appreciated as always.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Scott Leschke
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> http://about.me/milen
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Deactivating a component manually

[Raymond Auge via osgi-dev]

I'm wondering if you might be suffering from this Apache Felix SCR bug:
https://issues.apache.org/jira/plugins/servlet/mobile#issue/FELIX-5974

- Ray

On Sat, Sep 21, 2019, 11:53 Alain Picard via osgi-dev, <
osgi-dev@mail.osgi.org> wrote:

> Ray,
>
> The service being "destroyed" is BaViewPointsViewModel and you can see
> that ViewpointsViewModeTabViewModel has an instance of it. So I want to
> make sure that it is correctly released so that SCR can then deactivate
> ViewpointsViewModeTabViewModel and whatever else depended on
> ViewpointsViewModeTabViewModel and on and on.
>
> Alain
>
>
> On Sat, Sep 21, 2019 at 10:34 AM Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hey Alain,
>>
>> Just trying to understand the use case better, so a couple questions:
>>
>> Since your component is prototype scope, and if no one has any instances
>> of it why bother disabling it, isn't it effectively only a fairly inert
>> service reference at that point?
>> Are you saying that when released as a prototype instance, it should
>> never be used again, ever?
>> Perhaps the service you described above could be a factory for instances
>> of `ZkViewModel, BaItem, MasterDetailTopMenuListener` instead of being one
>> itself.
>>
>> - Ray
>>
>> On Sat, Sep 21, 2019 at 5:05 AM Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> I'm facing a case where the UI framework is sending a destroy request
>>> when a page is destroyed and I want to use that to also deactivate the
>>> component, so that its "host" can then automatically get deactivated and so
>>> on so forth as needed.
>>>
>>> As shown below I tried to use disableComponent. That results in some
>>> errors as it runs under [SCR Component Actor] thread that is not session
>>> aware and also looking at the stack trace it seems to be deactivating the
>>> full user session, which is not what I'm expecting.
>>>
>>> So am I deactivating correctly here, how can I make sure this runs in a
>>> session aware thread (as I don't control here this separate thread
>>> launch/run) and is there a utility to better understand service instance
>>> dependencies that would allow tracking the impact of a deactivation.
>>>
>>> Cheers,
>>> Alain
>>>
>>>
>>>
>>> Here's the case:
>>> @Component(service = ViewpointsViewModeTabViewModel.class, scope =
>>> ServiceScope.PROTOTYPE)
>>> public class ViewpointsViewModeTabViewModel extends
>>> ViewModeTabboxItemViewModel {
>>> ...
>>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>>> private BaViewPointsViewModel baViewPointsViewModel;
>>> ...
>>> }
>>>
>>> and
>>> @Component(service = BaViewPointsViewModel.class,
>>> scope=ServiceScope.PROTOTYPE)
>>> @Init(superclass = true)
>>> public final class BaViewPointsViewModel extends
>>> ViewPointsViewModel
>>> implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
>>> ...
>>> @Activate
>>> private void activate(ComponentContext context, Map
>>> properties) {
>>>   this.context = context;
>>>   pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);
>>>
>>>log.trace("Activating {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>>   initTabs();
>>> }
>>> @Deactivate
>>> private void deactivate() {
>>>   log.trace("Deactivating {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>>   super.zkDestroy();
>>>   ungetServices();
>>>   clearTabs();
>>> }
>>>
>>> @Override
>>> @Destroy
>>> public void zkDestroy() {
>>>   log.trace("Destroying {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>>   deactivate();
>>>   context.disableComponent(pid);  //attempt to manually deactivate
>>> itself.
>>> }
>>> }
>>>
>>>
>>> Alain Picard
>>> Chief Strategy Officer
>>> Castor Technologies Inc
>>> o:514-360-7208
>>> m:813-787-3424
>>>
>>> pic...@castortech.com
>>> www.castortech.com
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Deactivating a component manually

[Raymond Auge via osgi-dev]

Hey Alain,

Just trying to understand the use case better, so a couple questions:

Since your component is prototype scope, and if no one has any instances of
it why bother disabling it, isn't it effectively only a fairly inert
service reference at that point?
Are you saying that when released as a prototype instance, it should never
be used again, ever?
Perhaps the service you described above could be a factory for instances of
`ZkViewModel, BaItem, MasterDetailTopMenuListener` instead of being one
itself.

- Ray

On Sat, Sep 21, 2019 at 5:05 AM Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I'm facing a case where the UI framework is sending a destroy request when
> a page is destroyed and I want to use that to also deactivate the
> component, so that its "host" can then automatically get deactivated and so
> on so forth as needed.
>
> As shown below I tried to use disableComponent. That results in some
> errors as it runs under [SCR Component Actor] thread that is not session
> aware and also looking at the stack trace it seems to be deactivating the
> full user session, which is not what I'm expecting.
>
> So am I deactivating correctly here, how can I make sure this runs in a
> session aware thread (as I don't control here this separate thread
> launch/run) and is there a utility to better understand service instance
> dependencies that would allow tracking the impact of a deactivation.
>
> Cheers,
> Alain
>
>
>
> Here's the case:
> @Component(service = ViewpointsViewModeTabViewModel.class, scope =
> ServiceScope.PROTOTYPE)
> public class ViewpointsViewModeTabViewModel extends
> ViewModeTabboxItemViewModel {
> ...
> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
> private BaViewPointsViewModel baViewPointsViewModel;
> ...
> }
>
> and
> @Component(service = BaViewPointsViewModel.class,
> scope=ServiceScope.PROTOTYPE)
> @Init(superclass = true)
> public final class BaViewPointsViewModel extends
> ViewPointsViewModel
> implements ZkViewModel, BaItem, MasterDetailTopMenuListener {
> ...
> @Activate
> private void activate(ComponentContext context, Map
> properties) {
>   this.context = context;
>   pid = (String)properties.get(ComponentConstants.COMPONENT_NAME);
>
>log.trace("Activating {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
>   initTabs();
> }
> @Deactivate
> private void deactivate() {
>   log.trace("Deactivating {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
>   super.zkDestroy();
>   ungetServices();
>   clearTabs();
> }
>
> @Override
> @Destroy
> public void zkDestroy() {
>   log.trace("Destroying {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
>   deactivate();
>   context.disableComponent(pid);  //attempt to manually deactivate itself.
> }
> }
>
>
> Alain Picard
> Chief Strategy Officer
> Castor Technologies Inc
> o:514-360-7208
> m:813-787-3424
>
> pic...@castortech.com
> www.castortech.com
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Using Gradle or Maven on a new OSGi project

[Raymond Auge via osgi-dev]

On Thu, Jul 25, 2019 at 11:24 AM Stephen Schaub via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Over on the bndtools list, Raymond Auge indicated that live code
> deployment isn't supported in Eclipse with a standard Gradle project
> structure.
>

Yet! :) but it's not too far away I would think.

- Ray


>
> Stephen
>
> On Thu, Jul 25, 2019 at 11:04 AM Tim Ward  wrote:
>
>> Interestingly this is the opposite conclusion that most people come to.
>> Until recently Bndtools did not support Maven at all and was 100% Gradle.
>> There has been a lot of work to bring Maven support up to the same level as
>> Gradle by the team, but I don’t think that many of us would say that Maven
>> support was at parity yet, let alone better.
>>
>> You absolutely do get live code deployment when using Bndtools + Gradle
>> (Maven only recently got this feature and Gradle has had it for years).
>> Live baselining in Eclipse is still only available with Gradle, as are the
>> quick-fixes for lots of bed-detected problems.
>>
>> You are correct that IntelliJ is more Maven-focussed, but that is because
>> it doesn’t have additional plugins like Bndtools, so you’re just getting
>> the support they have for Maven.
>>
>> When it comes to Karaf, that isn’t really part of Bndtools. The Karaf
>> project has always been heavily Maven-based, and so if you want to use
>> their tools then Maven is probably the way to go.
>>
>> All the best,
>>
>> Tim
>>
>> On 25 Jul 2019, at 14:31, Stephen Schaub via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> A brief follow-up to this thread, after another month into my project:
>>
>> I have found that although Gradle will work fine as a build tool for
>> OSGi, it does seem that Maven is better supported for OSGi development in
>> Eclipse. For example, the Eclipse bndtools plugins support live code
>> deployment if you're using Maven, but not Gradle. I have also seen a post
>> describing doing live code deployment from IDEA that requires Maven. So, I
>> conclude that Maven is definitely preferred over Gradle when it comes to
>> OSGi IDE tooling.
>>
>> Also, although there is a Gradle plugin for generating kar archives for
>> Karaf, I have encountered issues using it with current versions of Gradle.
>>
>> Finally, many OSGi examples I find online seem to be using Maven rather
>> than Gradle as the build tool.
>>
>> These issues have not caused me to abandon Gradle, because I prefer it to
>> Maven, and I am grateful that the bnd project continues to have great
>> support for Gradle. However, overall, I am left with the impression that
>> there is better support for Maven than for Gradle in the broader OSGi
>> ecosystem.
>>
>> Stephen
>>
>> On Tue, Jun 25, 2019 at 10:11 AM Stephen Schaub 
>> wrote:
>>
>>> Thanks to all for the helpful responses. I was concerned about using
>>> Gradle as a build tool because so many OSGi resources I was finding seemed
>>> to be using Maven, and the change of enRoute docs from Gradle to Maven
>>> seemed to communicate a move away from Gradle as a "preferred" build tool.
>>> But given that Maven still seems to be the dominant build tool in the Java
>>> world, I can understand the rationale for transitioning enRoute from Gradle
>>> to Maven. Also, I can understand that maintaining both Maven and Gradle
>>> versions of enRoute would be a burden.
>>>
>>> Stephen
>>>
>>> On Mon, Jun 24, 2019 at 4:28 PM Stephen Schaub 
>>> wrote:
>>>
 I'm new to OSGi and am starting a project. I found the enRoute material
 and noticed that the enRoute tutorials apparently at one time utilized
 Gradle as the build tool, but are now using Maven.

 I'm more familiar with Gradle and have worked out how to use Gradle to
 do what I need for the project, but I was wondering 1) why the switch from
 Gradle to Maven for enRoute and 2) is Maven the preferred build tool for
 OSGi going forward? Is there a reason I should consider switching to Maven?

 I've poked through the mailing list archives trying to find answers to
 these questions but can't seem to find a record of any discussions about
 this, so am hoping someone can shed some light for me.

 --
 Stephen Schaub

>>>
>>>
>>>
>>
>> --
>> Stephen Schaub
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>
> --
> Stephen Schaub
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Help with the OSGi Converter

[Raymond Auge via osgi-dev]

I don't have a concrete answer since I'd have to also debug. However, I can
make a suggestion to perhaps try:


  org.apache.felix
  org.apache.felix.converter
  1.0.8


which is Apache Felix implementation of the osgi converter spec. What
you'll find is that it's moving along a little faster with bug fixes. It's
a drop in replacement.

It also means that Apache Felix mail list may have a few more bodies
monitoring it that have deep knowledge of the implementation details.

Also note that Apache Felix converter implementation was the seed code for
the official OSGi artifact.

- Ray

On Fri, May 17, 2019 at 12:43 PM Clément Delgrange via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> I use the OSGi Converter to convert a proxy of an Interface to a Map and I
> get an exception:
>
>
>
> org.osgi.util.converter.ConversionException: Cannot convert null to
> interface java.util.Map
> at
> org.osgi.util.converter.ConvertingImpl.convertToMapType(ConvertingImpl.java:650)
> at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:187)
> at
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
> at
> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:144)
> ...
>
> I don't know if it is a bug or not? Here is what I am doing:
>
> 1- I have two interfaces:
> public interface ParentType
> {
>   String test();
> }
>
> public interface ChildType extends ParentType
> {
>   // Marker interface
> }
>
> 2- I instantiate my proxy:
> ChildType proxy = createProxy(); // My proxy return a constant "test" when
> test() is invoked.
>
> 3- I try to convert and get the exception:
> converter.convert(proxy).sourceAs(ChildType.class).to(new
> TypeReference>() {/**/}));
>
> If I add a method to ChildType ('String qq();') the conversion works.
>
> Here is what I have found while debugging:
> 1- The converter tries to determine if my source is a map type
> (ConvertingImpl.isMapType)
> 2- For this, it calls the method ConvertingImpl.getInterfaces0(Class< ? >
> cls) with cls=ChildType.class. For ChildType be considered as a map type,
> this method should return a set of interfaces that contains
> ParentType.class (which has public method) but it doesn't. Indeed,
> implemented/extended interfaces are added to the result only if `cls` is
> not an interface, I don't really understand why?
>
> Sorry if this mail is a bit obscure and specific, I didn't find an other
> place to ask...
>
> You can find a repository demonstrating the issue here:
> https://github.com/cdelg/demo-converter-bug-or-not
>
> Thanks for help.
>
> Clément.
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Migrating from OSGI to Microservices

[Raymond Auge via osgi-dev]

On Thu, May 2, 2019 at 10:53 AM BJ Hargrave via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> With OSGi's JAX-RS support [1], you can easily publish and consume RESTy
> endpoints in your OSGi application.
>
> So there is no need to "leave" OSGi to participate in a microservice
> environment.
>
> [1]:
> https://osgi.org/specification/osgi.enterprise/7.0.0/service.jaxrs.html
>

And a real basic, single module, example of such a "mircoservice" [1]:

(CDI usage here is beside the point. It's just an incidental choice of
technology, could have been Declarative Services)

[1]
https://github.com/rotty3000/com.github.rotty3000.examples/tree/master/com.github.rotty3000.cdi.jaxrs

- Ray


> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Neil Bartlett via osgi-dev 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: Mohamed AFIF , OSGi Developer Mail List <
> osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
> Date: Thu, May 2, 2019 6:37 AM
>
> Well the good news is that OSGi is already a microservice architecture, so
> you have already finished. Congratulations!
>
> If that answer doesn't quite satisfy you, maybe you'd like to describe in
> more detail what you are attempting to achieve and why?
>
> Regards,
> Neil
>
> On Thu, 2 May 2019 at 11:06, Mohamed AFIF via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hello everybody,
>
> We 're starting to study the possibility to transform our architcteure in
> order to migrate from OSGI to microservice architecture, and I would like
> to know if there is alreay some people who had thought about this subject
> or already start this migration.
> Because at first sight it would not be an easy task, many problems/issues
> we will be facing to them (blueprint injections, managing ditrubued caches
> instead of one cache in one JVM...)
>
> Many thanks
>
>
>
> --
>
> Cdt
> Mohamed AFIF
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Multiple bind attempts to 8080

[Raymond Auge via osgi-dev]

In the second case, could the runbundles contain duplicate felix jetty
bundles (like of different versions)?

- Ray

On Sat, Mar 23, 2019 at 9:58 AM jhrayburn--- via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I have multiple sets of bundles for different capabilities.
>
>
>
> AuthApp
>
> AuthProvider
>
> AuthProviderApi
>
> AuthPersistence
>
> AuthPersistenceApi
>
> AuthRestService
>
>
>
> ResApp
>
> RestProvider
>
> RestProviderApi
>
> RestPersistence
>
> RestPersistenceApi
>
> ResRestService
>
>
>
> The Auth bundles are independent of the Res bundles. When I Run the
> AuthApp,
>
>
>
> *-runfw*: org.apache.felix.framework;version='[6.0.0,6.0.0]'
>
> *-runee*: JavaSE-1.8
>
> *-runprovidedcapabilities*: ${native_capability}
>
>
>
> -resolve.effective: active
>
>
>
> *-runvm*: -ea, -Xms10m, -Dlogback.configurationFile=resources/logback.xml
>
>
>
> *-runproperties*: org.osgi.service.http.port=8080
>
>
>
> *-runrequires*: \
>
>bnd.identity;id='AuthApp'
>
> ...
>
>
>
> The runs without any issue and connection can be made to the rest endpoints
>
>
>
> When I run the ResApp, with the following source
>
>
>
> *-runfw*: org.apache.felix.framework;version='[6.0.0,6.0.0]'
>
> *-runee*: JavaSE-1.8
>
> *-runprovidedcapabilities*: ${native_capability}
>
>
>
> -resolve.effective: active
>
>
>
> *-runvm*: -ea, -Xms10m, -Dlogback.configurationFile=resources/logback.xml
>
>
>
> *-runproperties*: org.osgi.service.http.port=8080
>
>
>
> *-runrequires*: \
>
>bnd.identity;id='ResApp',\
>
>bnd.identity;id='AuthApp'
>
> ...
>
>
>
> The OSGi is bound to 0.0.0.0:8080 and listening. In addition I am seeing
> the following lines and exception.
>
>
>
> 03/23/2019 09:41:58.645|INFO |main|Started ServerConnector@77a074b4
> {HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
>
> [INFO] Started Jetty 9.4.9.v20180320 at port(s) HTTP:8080 on context path
> / [minThreads=8,maxThreads=200,acceptors=1,selectors=6]
>
> 03/23/2019 09:41:58.799|INFO |main|created whiteboard from configuration:
> {service.pid=org.apache.aries.jax.rs.whiteboard.default}
>
> Mar 23, 2019 9:41:58 AM org.apache.cxf.endpoint.ServerImpl initDestination
>
> INFO: Setting the server's publish address to be /
>
> [DEBUG] [ServiceReference 34 from bundle 35 :
> org.apache.aries.jax.rs.whiteboard:1.0.1
> ref=[org.osgi.service.http.context.ServletContextHelper]
> properties={objectClass=[org.osgi.service.http.context.ServletContextHelper],
> original.service.bundleid=35, original.service.id=33,
> osgi.http.whiteboard.context.name=default,
> osgi.http.whiteboard.context.path=,
> osgi.http.whiteboard.target=(osgi.http.endpoint=*),
> osgi.jaxrs.application.base=/, osgi.jaxrs.name=.default,
> osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default),
> service.bundleid=35, service.id=34,
> service.pid=org.apache.aries.jax.rs.whiteboard.default,
> service.ranking=-2147483648, service.scope=singleton}] Ignoring invalid
> ServletContextHelper service
>
> [DEBUG] Adding bundle org.apache.felix.http.jetty:4.0.0 (48) : active
>
> [DEBUG] Adding bundle org.apache.felix.http.jetty:4.0.6 (49) : starting
>
> 03/23/2019 09:41:59.029|INFO |main|jetty-9.4.14.v20181114; built:
> 2018-11-14T21:20:31.478Z; git: c4550056e785fb5665914545889f21dc136ad9e6;
> jvm 1.8.0_192-b12
>
> 03/23/2019 09:41:59.031|INFO |main|DefaultSessionIdManager workerName=node0
>
> 03/23/2019 09:41:59.032|INFO |main|No SessionScavenger set, using defaults
>
> 03/23/2019 09:41:59.032|INFO |main|node0 Scavenging every 66ms
>
> 03/23/2019 09:41:59.036|INFO |main|Started
> o.e.j.s.ServletContextHandler@2a39aa2b{/,null,AVAILABLE}
>
> 03/23/2019 09:41:59.036|INFO |main|Started @2828ms
>
> 03/23/2019 09:41:59.036|INFO |main|node0 Scavenging every 66ms
>
> [ERROR] Failed to start Connector: ServerConnector@3b7eac14
> {HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
>
> *java.io.IOException*: Failed to bind to 0.0.0.0/0.0.0.0:8080
>
>at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(
> *ServerConnector.java:346*)
>
>at org.eclipse.jetty.server.ServerConnector.open(
> *ServerConnector.java:308*)
>
>at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(
> *AbstractNetworkConnector.java:80*)
>
>at org.eclipse.jetty.server.ServerConnector.doStart(
> *ServerConnector.java:236*)
>
>at org.eclipse.jetty.util.component.AbstractLifeCycle.start(
> *AbstractLifeCycle.java:68*)
>
>at org.apache.felix.http.jetty.internal.JettyService.startConnector(
> *JettyService.java:695*)
>
>at org.apache.felix.http.jetty.internal.JettyService.initializeHttp(
> *JettyService.java:546*)
>
>at
> org.apache.felix.http.jetty.internal.JettyService.initializeJetty(
> *JettyService.java:444*)
>
>at org.apache.felix.http.jetty.internal.JettyService.startJetty(
> *JettyService.java:305*)
>
>at org.apache.felix.http.jetty.internal.JettyService.start(
> *JettyService.java:148*)
>
>at 

Re: [osgi-dev] Combine requirements from different namespaces

[Raymond Auge via osgi-dev]

Instead of trying to kick people out of the party, why even let them in to
begin with?

i.e. sounds like you have the well documented problem of _not well curated
repository_

- Ray

On Sun, Mar 3, 2019, 07:35 Michael Lipp via osgi-dev, <
osgi-dev@mail.osgi.org> wrote:

> Is it possible to write a requirement that combines criteria from
> different namespaces? I want the resolution to exclude all providers of
> org.log4j.impl -- except the one that I want.
>
> So I'd need something like this:
>
> -runblacklist: \
> osgi.wiring;filter:='(org.wiring.package=org.slf4j.impl)' AND
> osgi.identity;filter:='(!(osgi.identity=de.mnl.osgi.slf4j2osgi))'
>
> ... which does, of course, not work. All the descriptions and examples
> that I could find are about requirements that can be expressed within a
> single namespace.
>
> Best Regards,
>
> Michael Lipp
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] SCR API

[Raymond Auge via osgi-dev]

Another option is Aries Component DSL [1].

- Ray

[1] https://github.com/apache/aries/tree/trunk/component-dsl

On Thu, Feb 21, 2019 at 1:21 PM BJ Hargrave via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> There is not plan for Declarative Services to have an API for imperatively
> creating components/services. The whole point of Declarative Services is
> the declarative nature of it. You can always use the service APIs of the
> framework to create services. Or something like felix dependency manager.
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Thomas Driessen via osgi-dev 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: "OSGi Developer Mail List" 
> Cc:
> Subject: [osgi-dev] SCR API
> Date: Thu, Feb 21, 2019 7:16 AM
>
> Hi,
>
> currently I'm debating on a Vaadin FLow issue how to best create
> components in OSGi programmatically. The answer of my last question on this
> mailing list regarding this topic was to use scope=PROTOTYPE and then
> ServiceObjects#getService(). This is a solution far better than the
> approach I used before but still has some flaws, resulting in the following
> question:
>
> Is there (or is it planned to create) an API for SCR to programmatically
> create components at runtime?
>
> I think of something like the Apache Felix DependencyManager where I can
> register services but not components (with refrences and stuff).
>
> What I think of would be something like this:
>
> scr.createCmp(Class class)
> .setActivateMethod(...)
> .setReferenceField(...)
> .etc...
>
> Kind regards,
> Thomas
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] ComponentServiceObjects vs ServiceObjects

[Raymond Auge via osgi-dev]

Thomas,

You can only use ComponentServiceReference where you have @Reference.

In other words, if you create a raw service tracker, or if you get service
directly (and I sincerely hope not), the you _must_ use ServiceObjects.

In a few months when you ultimately switch over to CDI integration ;)
you'll then use org.osgi.service.cdi.reference.BeanServiceObjects with the
same goal as ComponentServiceObjects.

:)

- Ray

On Tue, Feb 19, 2019 at 2:07 PM Thomas Driessen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Tim,
>
> as always this is super informative :) Thanks.
>
> Should I then use ComponentServiceObjects too when I'm not in the context
> of a @Component annotated class?
> In my last sketch for the OSGi integration in Vaadin Flow I used
> ServiceObjects instead. Would ComponentServiceObjects be better here?
>
> This is the class I'm talking about:
> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/v2/OSGiInstantiatorV2.java
>
> Kind regards,
> Thomas
>
> -- Originalnachricht --
> Von: "Tim Ward" 
> An: "Thomas Driessen" ; "OSGi Developer
> Mail List" 
> Gesendet: 19.02.2019 14:02:21
> Betreff: Re: [osgi-dev] ComponentServiceObjects vs ServiceObjects
>
> As I get it ComponentServiceObjects are just for use within Components and
> are obtained vie @Reference?
>
>
> Yes - you should *always* use ComponentServiceObjects if you want to get
> on-demand instances of a prototype scope service inside your DS component.
>
> But why are not ServiceObjects used for this?
>
>
> ServiceObjects is a low-level API. You are responsible for ensuring that
> *every* call to get is balanced by a call to unget. This gives your
> component a big tidy-up job in its deactivate method (and other places as
> necessary). If you use ComponentServiceObjects then DS is able to track all
> of the instances that you’ve created and make sure that they all get
> released automatically if your component is deactivated or the reference is
> rebound (for example with a greedy dynamic mandatory reference).
>
> ComponentServiceObjects is therefore much safer to use than ServiceObjects
> as you don’t need to be worried about the mess that could be ongoing when
> your component stops. Note that if your component can create a potentially
> unlimited number of service instances from the ComponentServiceObjects you
> must still make sure to release instances that you create. If you fail to
> do this you will run out of memory.
>
> I hope this helps.
>
> Tim
>
> On 19 Feb 2019, at 13:53, Thomas Driessen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
> can someone explain to me the difference between ComponentServiceObjects
> and ServiceObjects and when to use which?
>
> As I get it ComponentServiceObjects are just for use within Components and
> are obtained vie @Reference? But why are not ServiceObjects used for this?
>
> Kind regards,
> Thomas
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Clarification on reference behavior regarding field injection

[Raymond Auge via osgi-dev]

You're chart doesn't appear to list _which_ field (Reference) was
associated with any given line (collection vs. scalar). It makes a
difference.

- Ray

On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> I'm trying to get an overview over the effects of different combinations
> of cardinality, policy and policyOption within a @Reference annotation for
> a field.
>
> My Example looks like this:
>
> @Component
> public class MyComp{
>   @Reference(...)
>   ITest myTest;
>
>   @Reference(...)
>   List myTests;
> }
>
> and the observed behavior for this setup with different combinations of
> the above named properties is:
> [image: image.png]
>
> I'm especially interested in the yellow marked cases: Is this an intended
> behavior?
>
> Kind regards,
> Thomas
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Vaadin flow works in bnd workspace, fails in enRoute project

[Raymond Auge via osgi-dev]

On Sat, Feb 16, 2019 at 12:45 AM Paul F Fraser via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> On 16/01/2019 10:51 pm, Tim Ward wrote:
>
> Is there a bug repot filed for this bug? Otherwise we should do that.
>
> https://issues.apache.org/jira/browse/FELIX-6029
>
> It would appear that http.jetty-4.08 fixes this but I cannot find v4.08.
>
> Where should I look?
>
It's not released yet. I tried to build to release a snapshot but I can
never get the felix http stack to build. I always get failing tests :(

You'll have to petition the felix dev list for a release.

- Ray



> Thanks
>
> Paul Fraser
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Programmatically creating DS components

[Raymond Auge via osgi-dev]

On Sun, Feb 10, 2019 at 11:20 AM Thomas Driessen <
thomas.driessen...@gmail.com> wrote:

> Hi Ray,
>
> I'm not defining any additional manifest header if that's what you mean. I
> have no real control over the bundles I need to scan.
>
> What I do is registering a BundleTracker that scans a bundle's classes if
> its wiring states it is importing the package of the annotation I'm looking
> for.
> (Can be seen here:
> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiRouteTracker.java
> )
>

This is precisely the "extender pattern" [1].


>
> Those classes usually look something like this:
>
> @Route("")
> @Component(factory="fqcn")
> public class MyFancyUI extends Component {
>   @Reference
>SomeService service;
>   ...
> }
>
So I'm looking into the wiring of the bundle if it has imported the package
> "com.vaadin.flow.router" . If so I then scan the bundle's classes for
> the @Route annotation (and @RouteAlias).
> Classes that have this annotation can later on be instantiated via
> ComponentFactory.
>
> Can I instantiate such a component with the Apache Aries approach and if
> so will its reference be injected? I'm not sure if this is done if I'm
> registering the instance just as a service.
>

Let's start with how the classes came to be annotated with @Component, and
why that isn't already enough.

- Ray

[1] https://blog.osgi.org/2007/02/osgi-extender-model.html


>
> Kind regards,
> Thomas
>
> Am So., 10. Feb. 2019 um 15:38 Uhr schrieb Raymond Auge <
> raymond.a...@liferay.com>:
>
>> Are you implementing this using the extender pattern? If so, I would not
>> use DS. I would use something lower level.
>>
>> There are plenty of good alternatives for doing this, but I would suggest
>> looking at Apache Aries Component DSL [1] (it's what is used to implement
>> Aries JAXRS Whiteboard).
>>
>> - Ray
>>
>> [1] https://github.com/apache/aries/tree/trunk/component-dsl
>>
>> On Sun, Feb 10, 2019 at 8:01 AM Thomas Driessen via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hi,
>>>
>>> I'm currently trying to sketch out a possible better OSGi integration
>>> for Vaadin 10+.
>>>
>>> For this I need to programmatically create DS components in order to
>>> make @Route/@RouteAlias annotated classes also DS components.
>>>
>>> Right now I'm doing this via ComponentFactory and the assumption that
>>> all @Route annotated classes are also annotated with
>>> @Component(factory="fully qualified class name")
>>>
>>> I don't think this is the best way to do this. Having to type the fqcn
>>> seems rather errorprone to me and therefore I wanted to ask if there is a
>>> better way (maybe even a typesafe way) to do this?
>>>
>>> The code instantiating a component can be seen here:
>>> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiInstantiator.java
>>> The class that shall be instantiated can be seen here:
>>> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.simpleui/src/main/java/io/jatoms/flow/osgi/simpleui/MainView.java
>>>
>>> Any advice is highly appreciated.
>>>
>>> Kind regards,
>>> Thomas
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>

-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Programmatically creating DS components

[Raymond Auge via osgi-dev]

Are you implementing this using the extender pattern? If so, I would not
use DS. I would use something lower level.

There are plenty of good alternatives for doing this, but I would suggest
looking at Apache Aries Component DSL [1] (it's what is used to implement
Aries JAXRS Whiteboard).

- Ray

[1] https://github.com/apache/aries/tree/trunk/component-dsl

On Sun, Feb 10, 2019 at 8:01 AM Thomas Driessen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> I'm currently trying to sketch out a possible better OSGi integration for
> Vaadin 10+.
>
> For this I need to programmatically create DS components in order to
> make @Route/@RouteAlias annotated classes also DS components.
>
> Right now I'm doing this via ComponentFactory and the assumption that
> all @Route annotated classes are also annotated with
> @Component(factory="fully qualified class name")
>
> I don't think this is the best way to do this. Having to type the fqcn
> seems rather errorprone to me and therefore I wanted to ask if there is a
> better way (maybe even a typesafe way) to do this?
>
> The code instantiating a component can be seen here:
> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.integration/src/main/java/io/jatoms/flow/osgi/integration/FlowOsgiInstantiator.java
> The class that shall be instantiated can be seen here:
> https://github.com/Sandared/flow-osgi/blob/master/flow.osgi.simpleui/src/main/java/io/jatoms/flow/osgi/simpleui/MainView.java
>
> Any advice is highly appreciated.
>
> Kind regards,
> Thomas
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] enRoute workspace debugging

[Raymond Auge via osgi-dev]

The bigger question is why I'm the world are there java files in target?
target is the build directory. We are there source files in there?

- Ray

On Fri, Feb 1, 2019, 13:47 Paul F Fraser via osgi-dev <
osgi-dev@mail.osgi.org wrote:

> Thomas,
> Thank goodness someone else has experienced this. I thought it was my
> problem only.
> I mentioned this on this list previously but so far no response.
> Paul
>
>
> On 2/02/2019 3:54 am, Thomas Driessen via osgi-dev wrote:
>
> Hi,
>
> now that I'm using the enroute maven workspace I stumbled upon another
> issue.
>
> When I'm debugging and a breakpoint is hit, then Eclipse does not open the
> respective .java file in my project,
> but the java file from the target folder.
> Now each time I want to change breakpoints/code/etc. I have to go back to
> the workspace .java file.
> Is there a way to tell Eclipse to use the workspace .java file instead of
> the target folder .java file for debugging?
>
> Kind regards,
> Thomas
>
> ___
> OSGi Developer Mail 
> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Raymond Auge via osgi-dev]

Sorry, this is my typo, I'm using const so i replaced the const with
>> their values here so u can see how those classes are related, somehow i
>> replaced the property osgi.jaxrs.resource=true by
>> osgi.jaxrs.extension=true when copying here
>>
>>>
>>>
>>> What I observe is that the filter got activated 25 times, although all
>>> the resource classes and the filter bind to the same jaxrs application. Is
>>> this normal?
>>>
>>>
>>> Depending on the underlying implementation of the whiteboard and the
>>> registration order of the services this may or may not happen. Some JAX-RS
>>> implementations are not dynamic, in this case the whole application must be
>>> bounced when a change occurs. This will result in the currently registered
>>> services being discarded and re-created.
>>>
>>> Best Regards,
>>>
>>> Tim
>>>
>>>
>>> On 30 Jan 2019, at 15:01, Nhut Thai Le  wrote:
>>>
>>> Tim,
>>>
>>> I have one jaxrs application:
>>> @Component(
>>> service = Application.class,
>>> property= {
>>> "osgi.jaxrs.name=DiagramRestApp",
>>> "osgi.jaxrs.application.base=/diagram/services/diagrams/rest"
>>> }
>>> )
>>> public final class DiagramRestApp extends Application {
>>>   @Override
>>>   public Set getSingletons() {
>>>   return Collections.singleton(this);
>>>   }
>>> }
>>> but multiple resource classes, about 25 of them, here is one
>>> @Component(
>>> service = CommonDiagramRESTService.class,
>>> property = {
>>> "osgi.jaxrs.extension=true",
>>> "osgi.jaxrs.name=CommonDiagramRESTService",
>>> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
>>> }
>>> )
>>> @Path("/common")
>>> public final class CommonDiagramRESTService {..}
>>>
>>> and another one:
>>> @Component(
>>> service = GridDiagramRESTService.class,
>>> property = {
>>>  "osgi.jaxrs.extension=true" ,
>>>  "osgi.jaxrs.name=GridDiagramRESTService",
>>>  "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
>>> }
>>> )
>>> @Path("/grid")
>>> public final class GridDiagramRESTService {...}
>>>
>>> and finally my jaxrs filter:
>>> @Component(
>>> service = {
>>> ContainerRequestFilter.class,
>>> ContainerResponseFilter.class
>>> },
>>> scope = ServiceScope.PROTOTYPE,
>>> property = {
>>> "osgi.jaxrs.extension=true",
>>> "osgi.jaxrs.name=DiagramRestFilter",
>>> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
>>> }
>>> )
>>> @PreMatching
>>> @Priority(Priorities.AUTHENTICATION)
>>> public final class DiagramRestFilter extends
>>> OsgiJaxrsBearerTokenFilterImpl implements ContainerResponseFilter {..}
>>>
>>> What I observe is that the filter got activated 25 times, although all
>>> the resource classes and the filter bind to the same jaxrs application. Is
>>> this normal?
>>>
>>> Thai
>>>
>>> On Tue, Jan 29, 2019 at 11:17 AM Nhut Thai Le 
>>> wrote:
>>>
>>>> Thank you for clarifying.
>>>>
>>>> Thai
>>>>
>>>>
>>>>
>>>> On Tue, Jan 29, 2019 at 10:24 AM Tim Ward  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As described in the JAX-RS Whiteboard spec
>>>>> <https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e133685>
>>>>>  JAX-RS
>>>>> extension instances are required to be singletons (I’m talking about the
>>>>> objects, not the services) by the JAX-RS specification itself. Therefore
>>>>> within an application you will only ever see one instance of a whiteboard
>>>>> extension service.
>>>>>
>>>>> The reason that you should make extension services prototype is
>>>>> therefore not related to per-request handling, but instead because of what
>>>>> happens when the same extension service is applied to *multiple
>>>>> applications*. In this scenario you will have multiple applications with
>>>>> different configuration and different context objects. If your extension
>>&

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Raymond Auge via osgi-dev]

I'm going to assume you are talking about:

HttpService[1] or Http Whiteboard[2] w.r.t. the reference to Servlet
AND
JAX-RS Whiteboard[3] w.r.t. the reference to ContainerRequestFilter

These 2(3) features are separate concerns and the ContainerRequestFilter of
the JAX-RS whiteboard spec doesn't apply to the Servlets of the Http
Whiteboard. You probably just want a regular old servlet Filter[4]

Now it's possible that you are talking about some other runtime that packs
all these things together. If so, you probably want to ask the implementors
about this.

Hope that helps clear things up,
- Ray

[1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.html
[2]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html
[3] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html
[4]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055

On Tue, Jan 29, 2019 at 9:59 AM Nhut Thai Le via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello,
>
> I have a component implementing ContainerRequestFilter to intercept REST
> calls and another component implements servlet.Filter. Both have PROTOTYPE
> scope, my understanding is that these filter are instantiated and activated
> for each web request but yesterday when i put some breakpoints in
> the @activate method, i did not see them get called when a web request
> arrives. Did I miss something? If they are not init/activate per request
> why are they recomeded to be prototype?
>
> Thai Le
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGi Http Client Missing Requirement

[Raymond Auge via osgi-dev]

On Mon, Jan 21, 2019 at 9:47 PM Paul F Fraser via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> On 21/01/2019 7:57 pm, Tim Ward wrote:
>
> As a separate question - is there a reason that you are trying to use the 
> Apache HttpClient? OSGi enRoute makes use of the JAX-RS Whiteboard which 
> includes a simple way to access the JAX-RS specification client 
> implementation. If it’s possible for you to use the existing JAX-RS Client 
> instead then you could avoid adding the duplicate function.
>
> R7 spec sample code
>
> Client client = clientBuilder.build(); Promise p =
> client.target(REST_SERVICE_URL) .path("/foo") .path("/{name}")
> .resolveTemplate("name", buzz) .request() .rx(PromiseRxInvoker.class)
> .get(String.class);
>
> Using
>
> Client client = ClientBuilder.newClient(); // as the first line
>
_clientBuilder_ is a reference to the `javax.ws.rs.client.ClientBuilder`
*service* provided by JAXRS Whiteboard, which you can get to satisfy the
above code example with:

@Reference
private ClientBuilder clientBuilder;

I cannot find dependecies which satisfy the rx(Promise...) line.
>

https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.client.PromiseRxInvoker

So:


  org.osgi
  org.osgi.service.jaxrs
  1.0.0


import org.osgi.service.jaxrs.client.PromiseRxInvoker;

HTH
- Ray

I have tried most of the glassfish jersey bundles and quite a few others.
>
> Is there any working code examples available or can anyone suggest the
> required dependencies?
>
> Paul
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Split-package for 3rd party jars/bundle

[Raymond Auge via osgi-dev]

We made an Uber bundle of the whole ES stack, then only exposed enough to
make one of add-on web uis work.

- Ray

On Wed, Jan 2, 2019, 11:41 Alain Picard  Raymond,
>
> I think this is a good idea but some of their comment was that they were
> not even willing to get PR for it since they would then have to support it.
>
> Curious, did you just do it via Bundle-ClassPath or via some
> Require-bundle re-export or via Export restriction and a bridge bundle or
> other mean?
>
> Alain
>
>
> On Wed, Jan 2, 2019 at 11:33 AM Raymond Auge 
> wrote:
>
>> There appears to be a lot of us who've repackaged lucene/ES (my company
>> has done so also).
>>
>> I wonder if we could perhaps exert so upstream influence and maybe some
>> contributions to make it a better OSGi citizen.
>>
>> I happen to have a friend who recently works at Elasticsearch that has a
>> lot of OSGi experience that may be willing to help.
>>
>> Thoughts?
>>
>> - Ray
>>
>> On Wed, Jan 2, 2019, 06:38 Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org wrote:
>>
>>> Mark,
>>>
>>> Thanks for the info. Just looked up  in the
>>> documentation and it does what I've done manually with Bundle-ClassPath,
>>> which is a bit what I was trying to avoid. At least if it's the way to go,
>>> using this instruction, I could still automate the process like I wanted.
>>>
>>> Alain
>>>
>>>
>>> On Wed, Jan 2, 2019 at 5:40 AM Mark Hoffmann via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 Hi Alain,

 I know that Lucene itself contains split-packages in lucene-core.jar
 and lucene-analyzer-common.jar. The split-package there is e.g.
 org.apache.lucene.analysis.standard. When OSGi-fying them, we put the two
 jars into one OSGi bundle.

 Currently we use bnd, to do that. In former times we used the
 maven-bundle-plugin with this instruction e.g.


 lucene-analyzers-common;inline=true,lucene-core;inline=true

 You also have to take care about all external dependencies of e.g.
 lucene analyzers or spatial, like morfologic, uima, spatial4j,
 jakarta-regexp. You may need to OSGi-fy these dependencies and their
 transient dependencies too.

 After OSGi-fying the jars, we executed an additional build step to
 create the p2 update site using maven-tycho. In addition to the OSGi-fied
 jars there are other transient dependencies. For Lucene we identified:

 
 com.ibm.icu
 icu4j
 
 
 org.ow2.asm
 asm
 
 
 org.ow2.asm
 asm-commons
 
 
 org.antlr
 antlr4-runtime
 
 
 commons-codec
 commons-codec
 
 
 org.apache.commons
 commons-compress
 

 We took these bundles from the standard Eclipse repository or the
 Eclipse Orbit update site.

 This belongs only to the Lucene stuff. Maybe you have to do the same
 work for the ES stuff. We never used require-bundle, it worked well out of
 the box with package ex- and imports. Using a mega-lucene bundle with all
 dependencies, was our first approach ad worked well too. But don't forget,
 to put the Java service files as well in the bundles, because Lucene uses
 the service loader.

 I hope this helps.

 Mark
 Am 31.12.18 um 12:19 schrieb Alain Picard via osgi-dev:

 I am trying to convert a bundle of ours that now simply imports jars
 for Elasticsearch and make it a p2 site with p2-maven-plugin that usesthe
 maven-bundle-plugin/bnd to wrap non-OSGi jars.

 I ended up with resolution errors since ES has about 7-8 split
 packages, most notably org.elasticsearch.client and
 org.elasticsearch.common. So I went searching for solutions that I've seen
 before but never had to use them. I cam across
 https://eclipsesource.com/blogs/2008/08/22/tip-split-packages-and-visibility/
 from Chris and http://web.ist.utl.pt/ist162500/?p=65.

 I first tried to simply create a "bridge" bundle that simply requires
 the ES bundles and re-export them and import the bridge bundle from my
 "search bundle". That didn't solve the problem, same issue with imports of
 split-packages.

 Next I added attribute and mandatory, even if here I was relying on
 require-bundle (not what I normally do). In my bridge bundle I added all
 the over 300 export-package for the 5 ES bundles, w/o any extra. This
 resulted in an error for each export of the form: Package
 'org.elasticsearch.action.admin.cluster.allocation' does not exist in this
 plug-in. In the search bundle, with a require bundle of the bridge bundle,
 w/o the export packages it would not resolve any ES package and with them
 in (even with the 

Re: [osgi-dev] Split-package for 3rd party jars/bundle

[Raymond Auge via osgi-dev]

There appears to be a lot of us who've repackaged lucene/ES (my company has
done so also).

I wonder if we could perhaps exert so upstream influence and maybe some
contributions to make it a better OSGi citizen.

I happen to have a friend who recently works at Elasticsearch that has a
lot of OSGi experience that may be willing to help.

Thoughts?

- Ray

On Wed, Jan 2, 2019, 06:38 Alain Picard via osgi-dev  Mark,
>
> Thanks for the info. Just looked up  in the
> documentation and it does what I've done manually with Bundle-ClassPath,
> which is a bit what I was trying to avoid. At least if it's the way to go,
> using this instruction, I could still automate the process like I wanted.
>
> Alain
>
>
> On Wed, Jan 2, 2019 at 5:40 AM Mark Hoffmann via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi Alain,
>>
>> I know that Lucene itself contains split-packages in lucene-core.jar and
>> lucene-analyzer-common.jar. The split-package there is e.g.
>> org.apache.lucene.analysis.standard. When OSGi-fying them, we put the two
>> jars into one OSGi bundle.
>>
>> Currently we use bnd, to do that. In former times we used the
>> maven-bundle-plugin with this instruction e.g.
>>
>>
>> lucene-analyzers-common;inline=true,lucene-core;inline=true
>>
>> You also have to take care about all external dependencies of e.g. lucene
>> analyzers or spatial, like morfologic, uima, spatial4j, jakarta-regexp. You
>> may need to OSGi-fy these dependencies and their transient dependencies
>> too.
>>
>> After OSGi-fying the jars, we executed an additional build step to create
>> the p2 update site using maven-tycho. In addition to the OSGi-fied jars
>> there are other transient dependencies. For Lucene we identified:
>>
>> 
>> com.ibm.icu
>> icu4j
>> 
>> 
>> org.ow2.asm
>> asm
>> 
>> 
>> org.ow2.asm
>> asm-commons
>> 
>> 
>> org.antlr
>> antlr4-runtime
>> 
>> 
>> commons-codec
>> commons-codec
>> 
>> 
>> org.apache.commons
>> commons-compress
>> 
>>
>> We took these bundles from the standard Eclipse repository or the Eclipse
>> Orbit update site.
>>
>> This belongs only to the Lucene stuff. Maybe you have to do the same work
>> for the ES stuff. We never used require-bundle, it worked well out of the
>> box with package ex- and imports. Using a mega-lucene bundle with all
>> dependencies, was our first approach ad worked well too. But don't forget,
>> to put the Java service files as well in the bundles, because Lucene uses
>> the service loader.
>>
>> I hope this helps.
>>
>> Mark
>> Am 31.12.18 um 12:19 schrieb Alain Picard via osgi-dev:
>>
>> I am trying to convert a bundle of ours that now simply imports jars for
>> Elasticsearch and make it a p2 site with p2-maven-plugin that usesthe
>> maven-bundle-plugin/bnd to wrap non-OSGi jars.
>>
>> I ended up with resolution errors since ES has about 7-8 split packages,
>> most notably org.elasticsearch.client and org.elasticsearch.common. So I
>> went searching for solutions that I've seen before but never had to use
>> them. I cam across
>> https://eclipsesource.com/blogs/2008/08/22/tip-split-packages-and-visibility/
>> from Chris and http://web.ist.utl.pt/ist162500/?p=65.
>>
>> I first tried to simply create a "bridge" bundle that simply requires the
>> ES bundles and re-export them and import the bridge bundle from my "search
>> bundle". That didn't solve the problem, same issue with imports of
>> split-packages.
>>
>> Next I added attribute and mandatory, even if here I was relying on
>> require-bundle (not what I normally do). In my bridge bundle I added all
>> the over 300 export-package for the 5 ES bundles, w/o any extra. This
>> resulted in an error for each export of the form: Package
>> 'org.elasticsearch.action.admin.cluster.allocation' does not exist in this
>> plug-in. In the search bundle, with a require bundle of the bridge bundle,
>> w/o the export packages it would not resolve any ES package and with them
>> in (even with the error) the only issues were with the split package. I
>> also tried in the search bundle to instead import the packages, with the
>> same result.
>>
>> I'm getting to the point where I feel I might just have to either go back
>> to the original approach or create a bundle that just handles the ES
>> dependencies with bundle-classpath and export-pacakges of all those.
>>
>> Any idea where I'm going wrong?
>>
>> Thanks
>> Alain
>>
>>
>> ___
>> OSGi Developer Mail 
>> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail 

Re: [osgi-dev] enRoute JPA example questions

[Raymond Auge via osgi-dev]

Even better, a link to the html spec javadoc:

https://osgi.org/specification/osgi.enterprise/7.0.0/service.component.html#org.osgi.service.component.runtime.ServiceComponentRuntime

- Ray

On Fri, Dec 7, 2018, 10:36 Clément Delgrange via osgi-dev <
osgi-dev@mail.osgi.org wrote:

> Thanks for the link!
>
> --
> Clément Delgrange 
>
>
> ‐‐‐ Original Message ‐‐‐
> On Friday 7 December 2018 13:08, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
> A good example for the usage of DTOs is:
>
>
> http://javadox.com/org.osgi/osgi.cmpn/6.0.0/org/osgi/service/component/runtime/ServiceComponentRuntime.html
>
> Christian
>
> Am Fr., 7. Dez. 2018 um 12:07 Uhr schrieb Clément Delgrange via osgi-dev <
> osgi-dev@mail.osgi.org>:
>
>> Hi, thanks for your response.
>>
>> As I mention above, it would be very bad for the DAO to use entity types
>> in its API as this would force the implementation decision...
>>
>>
>> I agree, I would not replace API parameters with entity types I meant
>> replacing entity types with DTOs and API parameters with plain Interface or
>> Classes.
>>
>> The REST API is actually not coupled to the DTO representation...
>>
>>
>> Yes indeed.
>>
>> It’s quite the opposite - the DTOs are the public inter-bundle
>> communication data. They are used this way in a lot of OSGi specifications.
>>
>>
>> I looked at the R7 osgi.cmpn  in the org.osgi.service.* packages but I
>> did not see services using DTOs in that way, maybe have you a link? Or
>> better a realistic project that use DTOs for service parameters and return
>> type?.
>>
>> Your response clarify a the way enRoute proposes to use DTOs but it is
>> still hard to now when to use them. For example, if the microservice
>> example change: now the REST service does not call the DAO layer directly
>> but a PersonManager service that will send events, call other services, ...
>> and finally call the DAO layer. The PersonManager service has almost the
>> same methods than the PersonDao service, do you use DTOs for the
>> PersonManager service? In this way DTOs seem less flexible than interfaces
>> for parameters/return types, if later we want to add a `getFullName` or a
>> method to filter Addresses? As mentioned in the tutorial, DTOs are not
>> immutable or thread safe, does that mean each time you call a service you
>> copy them?
>>
>> Clément.
>> --
>> Clément Delgrange 
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Friday, December 7, 2018 11:09 AM, Tim Ward 
>> wrote:
>>
>> Hi Clément,
>>
>>
>>- The de-coupling is not the fact that they are DTOs? If the API had
>>defined Interfaces or Classes the de-coupling would be the same.
>>
>> In this case the decoupling is from the data model. If the DTO types were
>> JPA entities (i.e. they had JPA annotations on them) then everyone would be
>> coupled to the JPA data model, and in turn, the database. You are correct
>> that the types don’t need to be DTOs for this to be the case, however DTOs
>> are a good choice because they force you to treat the exchanged objects as
>> pure data, rather than an implementation specific behaviour or mapping.
>> Perhaps a slightly better wording would be "*Because of the de-coupling
>> provided by the **DTO
>>  package**, all we need do
>> is re-implement **dao-impl…”*
>>
>>
>>- I understand the usage of DTOs for the REST service (as data are
>>leaving/coming) but not for the *DAO services API. The actual data leaving
>>the system are the *Entity classes in the implementation bundle (so the
>>transferable objects are converted into other transferable objects!).
>>
>>
>> As I mention above, it would be very bad for the DAO to use entity types
>> in its API as this would force the implementation decision. The
>> implementing bundle should be free to use JDBC, JPA, NoSQL or whatever it
>> wants to store and retrieve values. The moment that you start talking about
>> Entity Classes you’re already most of the way to an ORM implementation,
>> which is one heck of an implementation internals leak.
>>
>>
>>- Also the fact that the DTOs are exported and used in the service
>>contract in the API bundle, the REST-API (and so the clients) is coupled 
>> to
>>the internal representation of the Java application.
>>
>> The REST API is actually not coupled to the DTO representation - the REST
>> service implementation could do whatever transformation it chose
>> internally. For simplicity we have chosen to keep the REST responses close
>> to the DTOs, but we could have quite easily changed all of the field names
>> in the JSON. Again, the OSGi implementations communicate using an API, but
>> they can convert between internal and external representations as needed.
>> In this case the external “REST” representation doesn’t require a
>> transformation, but it could easily be transformed to if required.
>>
>> I thought the DTOs was more data-api specific to a provider bundle, such
>> as : 

Re: [osgi-dev] dependency chain split due to org.eclipse.osgi bundle

[Raymond Auge via osgi-dev]

On Wed, Dec 5, 2018 at 11:03 PM Raymond Auge 
wrote:

> It looks like you are exporting the package `javax.annotation` from the
> system bundle (say via `org.osgi.framework.system.packages.extra`, i.e.
> `-runsystempackages`), while you also have the bundle
> org.apache.servicemix.specs.annotation-api-1.3 deployed.
>

It look like org.eclipse.osgi is a uber that provide all the osgi specs
>> used by equinox and org.apache.servicemix.specs.annotation-api-1.3 is the
>> partial spec that come with the aries.jax.rs.whiteboard implementation and
>> finally the javax.annotation-api is the generic api. Should I only use the
>> API that come with the impl in my launch to avoid this kind of dependency
>> mix up?
>>
>
`org.eclipse.osgi` is the equinox framework. I'm not aware that it exports
javax.annotation on it's own. I suspect you're exporting the packages of
javax.annotation-api from the framework class path.

Choose _only one provider_ and make sure it also provides the contract and
the issue should be resolved.

- Ray



> Hope to get some insight on this
>>
>> Thai
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] dependency chain split due to org.eclipse.osgi bundle

[Raymond Auge via osgi-dev]

It looks like you are exporting the package `javax.annotation` from the
system bundle (say via `org.osgi.framework.system.packages.extra`, i.e.
`-runsystempackages`), while you also have the bundle
org.apache.servicemix.specs.annotation-api-1.3 deployed.

Hope that helps,
- Ray

On Wed, Dec 5, 2018 at 9:07 PM Nhut Thai Le via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello,
>
> I'm using equinox as osgi container and aries.jax.rs.whiteboard to host
> our rest API and recently I see the following dependency chain split when
> launching:
>
> RESOLVER: Candidate permutation failed due to a conflict between imports;
> will try another if possible. (Uses constraint violation. Unable to resolve
> resource org.apache.aries.jax.rs.whiteboard [osgi.identity;
> osgi.identity="org.apache.aries.jax.rs.whiteboard"; type="osgi.bundle";
> version:Version="1.0.1"] because it is exposed to package
> 'javax.annotation' from resources org.eclipse.osgi [osgi.identity;
> osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
> version:Version="3.12.0.v20170512-1932"; singleton:="true"] and
> org.apache.servicemix.specs.annotation-api-1.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.annotation-api-1.3";
> type="osgi.bundle"; version:Version="1.3.0.1"] via two dependency chains.
>
> Chain 1:
>   org.apache.aries.jax.rs.whiteboard [osgi.identity;
> osgi.identity="org.apache.aries.jax.rs.whiteboard"; type="osgi.bundle";
> version:Version="1.0.1"]
> import: (osgi.wiring.package=javax.annotation)
>  |
> export: osgi.wiring.package: javax.annotation
>   org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi";
> type="osgi.bundle"; version:Version="3.12.0.v20170512-1932";
> singleton:="true"]
>
> Chain 2:
>   org.apache.aries.jax.rs.whiteboard [osgi.identity;
> osgi.identity="org.apache.aries.jax.rs.whiteboard"; type="osgi.bundle";
> version:Version="1.0.1"]
> require: (&(osgi.contract=JavaAnnotation)(version=1.3.0))
>  |
> provide: osgi.contract: JavaAnnotation
>   org.apache.servicemix.specs.annotation-api-1.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.annotation-api-1.3";
> type="osgi.bundle"; version:Version="1.3.0.1"])
>
> RESOLVER: Candidate permutation failed due to a conflict between imports;
> will try another if possible. (Uses constraint violation. Unable to resolve
> resource com.castortech.iris.ba.web.filters [osgi.identity;
> osgi.identity="com.castortech.iris.ba.web.filters"; type="osgi.bundle";
> version:Version="1.0.0.qualifier"] because it is exposed to package
> 'javax.annotation' from resources
> org.apache.servicemix.specs.annotation-api-1.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.annotation-api-1.3";
> type="osgi.bundle"; version:Version="1.3.0.1"] and org.eclipse.osgi
> [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
> version:Version="3.12.0.v20170512-1932"; singleton:="true"] via two
> dependency chains.
>
> Chain 1:
>   com.castortech.iris.ba.web.filters [osgi.identity;
> osgi.identity="com.castortech.iris.ba.web.filters"; type="osgi.bundle";
> version:Version="1.0.0.qualifier"]
> require:
> (&(osgi.wiring.bundle=org.apache.servicemix.specs.annotation-api-1.3)(bundle-version>=1.3.0))
>  |
> provide: osgi.wiring.bundle:
> org.apache.servicemix.specs.annotation-api-1.3
>   org.apache.servicemix.specs.annotation-api-1.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.annotation-api-1.3";
> type="osgi.bundle"; version:Version="1.3.0.1"]
>
> Chain 2:
>   com.castortech.iris.ba.web.filters [osgi.identity;
> osgi.identity="com.castortech.iris.ba.web.filters"; type="osgi.bundle";
> version:Version="1.0.0.qualifier"]
> import: (osgi.wiring.package=org.keycloak.jaxrs)
>  |
> export: osgi.wiring.package=org.keycloak.jaxrs; uses:=javax.annotation
>   org.keycloak.jaxrs-oauth-client [osgi.identity;
> osgi.identity="org.keycloak.jaxrs-oauth-client"; type="osgi.bundle";
> version:Version="4.6.0.Final"]
> import: (osgi.wiring.package=javax.annotation)
>  |
> export: osgi.wiring.package: javax.annotation
>   org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi";
> type="osgi.bundle"; version:Version="3.12.0.v20170512-1932";
> singleton:="true"])
>
> RESOLVER: Candidate permutation failed due to a conflict between imports;
> will try another if possible. (Uses constraint violation. Unable to resolve
> resource org.apache.aries.jax.rs.whiteboard [osgi.identity;
> osgi.identity="org.apache.aries.jax.rs.whiteboard"; type="osgi.bundle";
> version:Version="1.0.1"] because it is exposed to package
> 'javax.annotation' from resources org.eclipse.osgi [osgi.identity;
> osgi.identity="org.eclipse.osgi"; type="osgi.bundle";
> version:Version="3.12.0.v20170512-1932"; singleton:="true"] and
> org.apache.servicemix.specs.annotation-api-1.3 [osgi.identity;
> osgi.identity="org.apache.servicemix.specs.annotation-api-1.3";
> type="osgi.bundle"; version:Version="1.3.0.1"] 

Re: [osgi-dev] what is way to use a Resolver and Repository together ?

[Raymond Auge via osgi-dev]

The basic idea is that you want to represent the capabilities of the
existing system as already being provided, used to support the requirements
you're searching for, but ultimately excluded from the result, such that
only missing capabilities are included in the result.

You might want to look at
https://github.com/bndtools/bnd/blob/master/biz.aQute.resolve/src/biz/aQute/resolve/BndrunResolveContext.java
and note how when using a "distro" (a predefined set of provided
capabilities) it performs exactly this logic.

Hth,
- Ray
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Disposing component instances

[Raymond Auge via osgi-dev]

Please note that up to a couple of weeks ago there was a bug in Felix SCR
managing indirect component prototype instances.

https://issues.apache.org/jira/browse/FELIX-5974

So you may want to make sure you have the latest.

- Ray

On Sun, Nov 25, 2018, 08:21 Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org wrote:

> On Sun, Nov 25, 2018 at 7:50 AM Tim Ward  wrote:
>
>> If your DS component ‘X’ is injected with a Component Service Objects
>> which it uses to get instances ‘A’, ‘B’ and ‘C' of a referenced service
>> then those service instances will be released when either:
>>
>>
>>- The component ‘X’ releases them by calling ungetService on the
>>component service objects
>>
>> or
>>
>>- The component ‘X’ is deactivated (for whatever reason) at which
>>point the Service Component Runtime will automatically release any
>>remaining instances that haven’t been released by the component before the
>>end of any deactivate method.
>>
>>
>> This is why the ComponentServiceObjects is a better choice than using a
>> ServiceObjects directly, as the ServiceObjects won’t clean up after you.
>>
>> Can I interpret this and your previous comment as meaning that within a
>> prototype scope component, a prototype required scope reference doesn't
>> need to be "unget" manually and it is just the most outer invocation that
>> should perform the “unget"
>>
>>
>> In a limited way, yes. If you get many instances over the lifetime of
>> your component ‘X’ then you should probably have a mechanism to unget them
>> manually, otherwise the memory usage of your component will grow and grow
>> over time (until it is deactivated). If you get two or three instances of
>> the prototype service which you then hold for the life of the component ‘X’
>> then feel free to let DS do all the work.
>>
> This is for a composing a UI view which itself has a defined lifespan, but
> this prototype component creates a number of other prototype scoped
> components and it would be much easier to such unget the view and not all
> its parts.
>
> Small slant to this question, let's say that X has a reference to Factory
> A (standard component) and that factory A returns a prototype scoped
> instance, will ungetting X, release the instance returned by factory A?
>
> Alain
>
>
>
>> Tim
>>
>> On 25 Nov 2018, at 12:41, Alain Picard  wrote:
>>
>> Tim,
>>
>> Circling back on this. Re-reading section 112.3.6 it says "This means
>> that if a component instance used a Component Service Objects object to
>> obtain service objects, SCR must track those service objects so that when
>> the service becomes unbound, SCR can unget any unreleased service objects".
>>
>> Can I interpret this and your previous comment as meaning that within a
>> prototype scope component, a prototype required scope reference doesn't
>> need to be "unget" manually and it is just the most outer invocation that
>> should perform the "unget"
>>
>> Thanks
>> Alain
>>
>> On Thu, Aug 23, 2018 at 9:20 AM Tim Ward  wrote:
>>
>>> If you’re using Declarative Services to consume these other dynamic
>>> references then there is no need to worry. If you’re trying to
>>> programmatically write a prototype scoped service that has service
>>> dependencies then stop and use DS instead. Trying to correctly manage the
>>> “unget” chains that need to occur when one service in a dependency tree is
>>> unregistered is just too hard to be worthwhile. Tools like the
>>> ServiceTracker can make it tractable, but it still leaves you writing huge
>>> quantities of messy lifecycle code that’s a nightmare to debug.
>>>
>>> Also, you are correct that you must not keep using a service instance
>>> when the service has been unregistered. It is your job to discard that
>>> reference :).
>>>
>>> Tim
>>>
>>> On 23 Aug 2018, at 13:31, Alain Picard  wrote:
>>>
>>> Just a small note, I should have stated that my worry is about the unget
>>> timing. I obviously have a reference to the object and this won't disappear
>>> by itself, but if that service has other dynamic references that go away
>>> and I keep using the service, I might be in trouble. But I guess the
>>> template that I used already had a bit that issue with the supplier (which
>>> we seldom use).
>>>
>>> Alain
>>>
>>> On Thu, Aug 23, 2018 at 7:43 AM Alain Picard 
>>> wrote:
>>>
 Tim,

 Based on your referenced javadoc, some more googling, I used and
 adapted from our own current tracker and supplier to create some Prototype
 versions. Tests are showing correct results, but this is not directly using
 the PrototypeServiceFactory, so I would appreciate a very quick
 confirmation that I'm not missing anything.

 Thanks

 Alain


 On Wed, Aug 22, 2018 at 11:54 AM Alain Picard 
 wrote:

> Thanks! I actually saw that being called by ComponentServiceObjects
> while perusing the code.
>
> Alain
>
>
> On Wed, Aug 22, 2018 at 11:52 AM Tim Ward 
> wrote:

Re: [osgi-dev] Usinge Cache in Karaf

[Raymond Auge via osgi-dev]

On Thu, Nov 22, 2018, 15:30 Raymond Auge  Scott, is that usable in-process, as in no remoting?
>
> - Ray
>
> On Thu, Nov 22, 2018, 14:55 Scott Lewis via osgi-dev <
> osgi-dev@mail.osgi.org wrote:
>
>> On 11/22/2018 8:19 AM, Raymond Auge via osgi-dev wrote:
>>
>> Mohamed, if I understand correctly, what you really need in order to
>> cache method calls are proxies around arbitrary services.
>>
>> First I don't think there's a OOTB solution for your problem description
>> specifically to do method caching.
>>
>> Also, OSGi doesn't natively provide a proxy mechanism.
>>
>> Forgive me if I'm misinterpreting the needs as I haven't read entire
>> thread, but OSGi Remote Service Admin does have a specified service proxing
>> [A].  ECF's implementation of RSA [B] allows one to create/use custom
>> distribution providers that could do method-level caching [B].
>> Distribution providers are typically for across-process proxies, but can be
>> in-process as well.
>>
> Oops, I see you did say that! Cool use case. I'll add that to my magic bag
of tricks 

- Ray


Scott
>>
>> [A]
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html#i1742961
>>
>> [B] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
>>
>>
>> In fact, it generally goes out of it's way to avoid needing that kind of
>> indirection. However it does provide a few technologies that give you
>> capabilities to build this. There are also some open source projects that
>> can help with this.
>>
>> In order of depth of integration:
>>
>> *1. framework weaving hooks* [1]
>> PROS
>>  - TRANSPARENT to service providers & consumers
>>  - you can control any bytecode used anywhere in the framework from
>> here
>> CONS
>> - it can be an intense journey into bytecode manipulation.. if you
>> have the heart for it you can do crazy stuff here, but it won't be trivial
>> - start ordering will be your biggest foe
>>
>> *2. framework service hooks* [2]
>> PROS
>>  - TRANSPARENT service to providers & consumers
>>  - you can intercept and modify the visibility or accessibility of
>> services before they are gotten by consumers which means you could proxy
>> here
>> CONS
>>  - still pretty low level and high degree of awareness of the OSGi
>> service registry behaviour is required
>>  - start ordering is also a complexity you need to think about
>>
>> 3. *use an injection framework* that supports proxies
>> PROS
>>  - use existing technology do to the heavy lifting (spring, CDI...
>> upcoming spec [3] ... try the RI [4] ..., etc.)
>> CONS
>>- service to providers need to use the selected framework
>>- no unobtrusive, transversal configuration
>>
>> 4. *AspecIO* [5]
>> PROS
>> - TRANSPARENT to providers & consumers
>> - unobtrusive and transversal configuration
>> - no start ordering issues? (I think Simon built a solution for this
>> ???)
>> CONS
>> - start ordering issues? (I think Simon built a solution for this ???)
>>
>> FYI, this is not a pitch for the project because I'm not involved in it
>> at all. I only know that it covers almost all your requirements (which I've
>> extrapolated from between the lines).
>>
>> Hope that helps in some way.
>>
>> - Ray
>>
>> [1]
>> https://osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html
>> [2]
>> https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html
>> [3] https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html
>> [4]
>> https://repository.apache.org/content/repositories/snapshots/org/apache/aries/cdi/org.apache.aries.cdi.extender/0.0.2-SNAPSHOT/
>> [5] https://github.com/primeval-io/aspecio
>>
>>
>> On Thu, Nov 22, 2018 at 10:34 AM Mohamed AFIF via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hi Alain,
>>>
>>> Thanks a lot for sharing  your experience, but as I've seen on
>>> documentation , I'm not sure that infinispan handles cache of methods .
>>>
>>> Regards.
>>>
>>> Mohamed.
>>>
>>>
>>> Le jeu. 22 nov. 2018 à 11:10, Alain Picard  a
>>> écrit :
>>>
>>>> If it might help, we are in the process of using Infinispan at our end.
>>>> It is OSGi compliant (almost) and for Karaf users (not us yet), it comes
>>>> with features for easy deployment.
>&g

Re: [osgi-dev] Usinge Cache in Karaf

[Raymond Auge via osgi-dev]

Scott, is that usable in-process, as in no remoting?

- Ray

On Thu, Nov 22, 2018, 14:55 Scott Lewis via osgi-dev  On 11/22/2018 8:19 AM, Raymond Auge via osgi-dev wrote:
>
> Mohamed, if I understand correctly, what you really need in order to cache
> method calls are proxies around arbitrary services.
>
> First I don't think there's a OOTB solution for your problem description
> specifically to do method caching.
>
> Also, OSGi doesn't natively provide a proxy mechanism.
>
> Forgive me if I'm misinterpreting the needs as I haven't read entire
> thread, but OSGi Remote Service Admin does have a specified service proxing
> [A].  ECF's implementation of RSA [B] allows one to create/use custom
> distribution providers that could do method-level caching [B].
> Distribution providers are typically for across-process proxies, but can be
> in-process as well.
>
> Scott
>
> [A]
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html#i1742961
>
> [B] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project
>
>
> In fact, it generally goes out of it's way to avoid needing that kind of
> indirection. However it does provide a few technologies that give you
> capabilities to build this. There are also some open source projects that
> can help with this.
>
> In order of depth of integration:
>
> *1. framework weaving hooks* [1]
> PROS
>  - TRANSPARENT to service providers & consumers
>  - you can control any bytecode used anywhere in the framework from
> here
> CONS
> - it can be an intense journey into bytecode manipulation.. if you
> have the heart for it you can do crazy stuff here, but it won't be trivial
> - start ordering will be your biggest foe
>
> *2. framework service hooks* [2]
> PROS
>  - TRANSPARENT service to providers & consumers
>  - you can intercept and modify the visibility or accessibility of
> services before they are gotten by consumers which means you could proxy
> here
> CONS
>  - still pretty low level and high degree of awareness of the OSGi
> service registry behaviour is required
>  - start ordering is also a complexity you need to think about
>
> 3. *use an injection framework* that supports proxies
> PROS
>  - use existing technology do to the heavy lifting (spring, CDI...
> upcoming spec [3] ... try the RI [4] ..., etc.)
> CONS
>- service to providers need to use the selected framework
>- no unobtrusive, transversal configuration
>
> 4. *AspecIO* [5]
> PROS
> - TRANSPARENT to providers & consumers
> - unobtrusive and transversal configuration
> - no start ordering issues? (I think Simon built a solution for this
> ???)
> CONS
> - start ordering issues? (I think Simon built a solution for this ???)
>
> FYI, this is not a pitch for the project because I'm not involved in it at
> all. I only know that it covers almost all your requirements (which I've
> extrapolated from between the lines).
>
> Hope that helps in some way.
>
> - Ray
>
> [1]
> https://osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html
> [2]
> https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html
> [3] https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html
> [4]
> https://repository.apache.org/content/repositories/snapshots/org/apache/aries/cdi/org.apache.aries.cdi.extender/0.0.2-SNAPSHOT/
> [5] https://github.com/primeval-io/aspecio
>
>
> On Thu, Nov 22, 2018 at 10:34 AM Mohamed AFIF via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi Alain,
>>
>> Thanks a lot for sharing  your experience, but as I've seen on
>> documentation , I'm not sure that infinispan handles cache of methods .
>>
>> Regards.
>>
>> Mohamed.
>>
>>
>> Le jeu. 22 nov. 2018 à 11:10, Alain Picard  a
>> écrit :
>>
>>> If it might help, we are in the process of using Infinispan at our end.
>>> It is OSGi compliant (almost) and for Karaf users (not us yet), it comes
>>> with features for easy deployment.
>>>
>>> Alain
>>>
>>>
>>> On Thu, Nov 22, 2018 at 5:02 AM Mohamed AFIF via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>>> Hello everybody,
>>>>
>>>> We need to implement a cache system in our Karaf (Felix) , our need is
>>>> especially to cache method results, but It’s hard to find a cache solution
>>>> which is OSGI compliant, Spring can do that but  it’s cache feature can be
>>>> used only over a spring managed beans, so we ‘re using Blueprint  t

Re: [osgi-dev] equinox env started notification

[Raymond Auge via osgi-dev]

... or go look at the Apache Felix (new) systemready project.

:)

- Ray

On Thu, Nov 22, 2018, 13:42 Cristiano via osgi-dev  Hi,
>
> Well, I think there are many possible solutions for that.
>
> In my opinion, the complicated thing is how the OSGi framework would know
> what is necessary to it consider your application ready. Which bundles?
> which services?
>
> A combination of the new OSGi Configurator + DeclarativeServices +
> ConfigAdmin are a great option to achieve that.
>
> One of the possible approaches using these specs is to create a Bootstrap
> DS component with configurationPolicy = ConfigurationPolicy.REQUIRE and
> configurationPid="boot.pid", meaning that an instance of it will be created
> and activated ONLY when a configuration were registered for "boot.pid".
>
> Then when you start the container you can instruct the Configurator to
> activate your bootstrap component using the system property
> "configurator.initial" pointing to a json configuration file containing all
> information needed for this bootstrap component to recognize that your
> application is ready (which bundles/services are required to be started).
> You can also embed a configurator json inside bootstrap bundle instead.
>
> In the bootstrap component implementation you will need to setup a
> BundleListener and/or ServiceListener to listen for installed bundles and
> registered services and then at each occurrence to compare with those
> provided in the json config.
>
> Once all required bundles/services were identified and their status
> matched then your application can be considered ready.
>
> best regards,
>
> Cristiano
>
>
> On 19/11/2018 18:16, Nhut Thai Le via osgi-dev wrote:
>
> Hello,
>
> We are using equinox as an osgi container to host our application which
> comprise a large number of osgi bundles. Our concern at this point is that
> when we start equinox, we don't know when all the bundles have been loaded
> and the startup has finished. Does anyone have a suggestion?
>
> Thank you in advance
>
> Thai
>
>
>
> ___
> OSGi Developer Mail 
> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Usinge Cache in Karaf

[Raymond Auge via osgi-dev]

Mohamed, if I understand correctly, what you really need in order to cache
method calls are proxies around arbitrary services.

First I don't think there's a OOTB solution for your problem description
specifically to do method caching.

Also, OSGi doesn't natively provide a proxy mechanism. In fact, it
generally goes out of it's way to avoid needing that kind of indirection.
However it does provide a few technologies that give you capabilities to
build this. There are also some open source projects that can help with
this.

In order of depth of integration:

*1. framework weaving hooks* [1]
PROS
 - TRANSPARENT to service providers & consumers
 - you can control any bytecode used anywhere in the framework from here
CONS
- it can be an intense journey into bytecode manipulation.. if you have
the heart for it you can do crazy stuff here, but it won't be trivial
- start ordering will be your biggest foe

*2. framework service hooks* [2]
PROS
 - TRANSPARENT service to providers & consumers
 - you can intercept and modify the visibility or accessibility of
services before they are gotten by consumers which means you could proxy
here
CONS
 - still pretty low level and high degree of awareness of the OSGi
service registry behaviour is required
 - start ordering is also a complexity you need to think about

3. *use an injection framework* that supports proxies
PROS
 - use existing technology do to the heavy lifting (spring, CDI...
upcoming spec [3] ... try the RI [4] ..., etc.)
CONS
   - service to providers need to use the selected framework
   - no unobtrusive, transversal configuration

4. *AspecIO* [5]
PROS
- TRANSPARENT to providers & consumers
- unobtrusive and transversal configuration
- no start ordering issues? (I think Simon built a solution for this
???)
CONS
- start ordering issues? (I think Simon built a solution for this ???)

FYI, this is not a pitch for the project because I'm not involved in it at
all. I only know that it covers almost all your requirements (which I've
extrapolated from between the lines).

Hope that helps in some way.

- Ray

[1]
https://osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html
[2]
https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html
[3] https://osgi.org/specification/osgi.enterprise/7.0.0/service.cdi.html
[4]
https://repository.apache.org/content/repositories/snapshots/org/apache/aries/cdi/org.apache.aries.cdi.extender/0.0.2-SNAPSHOT/
[5] https://github.com/primeval-io/aspecio


On Thu, Nov 22, 2018 at 10:34 AM Mohamed AFIF via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Alain,
>
> Thanks a lot for sharing  your experience, but as I've seen on
> documentation , I'm not sure that infinispan handles cache of methods .
>
> Regards.
>
> Mohamed.
>
>
> Le jeu. 22 nov. 2018 à 11:10, Alain Picard  a
> écrit :
>
>> If it might help, we are in the process of using Infinispan at our end.
>> It is OSGi compliant (almost) and for Karaf users (not us yet), it comes
>> with features for easy deployment.
>>
>> Alain
>>
>>
>> On Thu, Nov 22, 2018 at 5:02 AM Mohamed AFIF via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hello everybody,
>>>
>>> We need to implement a cache system in our Karaf (Felix) , our need is
>>> especially to cache method results, but It’s hard to find a cache solution
>>> which is OSGI compliant, Spring can do that but  it’s cache feature can be
>>> used only over a spring managed beans, so we ‘re using Blueprint  than the
>>> Spring solution could not be used, also spring has some problems to run
>>> inside a Kataf, so we’re thanking to use the AOP, with AspectJ, but we
>>> should manage by ourself the data synchronization …., Thus I would like to
>>> know if some users among this mailing list have already  been  facing this
>>> problem and which solution could be better to implement inside a
>>> Karaf/Felix,
>>>
>>>
>>>
>>> Thank you very much for your help
>>>
>>>
>>>
>>> M.AFIF
>>>
>>> --
>>>
>>> Cdt
>>> Mohamed AFIF
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] How to specify a requirements on JSR-353 (Json) implementation

[Raymond Auge via osgi-dev]

If you use this API dependency instead:


  org.apache.geronimo.specs
  geronimo-json_1.1_spec
  1.1


it will do exactly what you want.

(make sure you also have a recent Aries SpiFly in your runtime dependencies
somewhere)

- Ray

On Tue, Nov 20, 2018 at 8:26 AM Clément Delgrange via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> I have a service that uses the Json API( *javax.json.*). *My project has
> a compile dependency on :
>
> 
>  org.apache.servicemix.specs
>  org.apache.servicemix.specs.json-api-1.1
>  2.9.0
> 
>
> and a test dependency on:
>
> 
> org.apache.johnzon
> johnzon-core
> 1.1.0
> 
>
> In another project, when I resolve the bundle that contains my service,
> the johnzon-core bundle is not resolved and everything looks OK until
> runtime. I would like to add an annotation on the service that depends on
> the Json API (@Capability) but I don't know which namespace I should use
> for this? (The johnzon-core does not provide any capability except package
> exports while its description says it is an implementation of JSR-353)
>
> A similar service can be found in the OSGI enRoute example at
> https://github.com/osgi/osgi.enroute/blob/master/examples/microservice/rest-service/pom.xml
>
> Thanks!
> --
> Clément Delgrange 
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Service component resolution time

[Raymond Auge via osgi-dev]

One potential solution is for the resolver immediately deliver some
warnings with a bit of trace details when it realizes that the computation
is exceeding normal levels of complexity.

- Ray

On Sat, Nov 3, 2018, 11:45 Raymond Auge  It would be useful to make this scenario produce a louder perhaps more
> obvious error message.
>
> If you could maybe create an issue for improvement on Apache Felix JIRA,
> under Resolver project with as many details as you could provide maybe we
> can do something.
>
> These rare and complex scenarios don't have to be so time consuming
> particularly if there's very visible and useful diagnostic details provided
> when they occur.
>
> Sincerely,
> - Ray
>
> On Sat, Nov 3, 2018, 11:30 Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org wrote:
>
>> A small note if anyone happens to face the same issue. At the end after
>> adding tracing we found out that we had a few resolver chain issues:
>> RESOLVER: Candidate permutation failed due to a conflict between imports;
>> will try another if possible. via two dependency chains.
>>
>> So we had to clear that up and now there is no more startup time issue.
>>
>> Cheers,
>> Alain
>>
>> On Tue, Oct 23, 2018 at 4:45 AM Alain Picard 
>> wrote:
>>
>>> Neil,
>>>
>>> Thanks for the pointers.
>>> 2 points...as well
>>>
>>> 1. This was an RCP application that is still PDE based (can't do
>>> everything in this round of refactoring) but now running directly against
>>> OSGI (not an Eclipse application. And there are no p2 bundles selected.
>>>
>>> 2. Well retesting this morning the start time for the console to start
>>> outputting content is ~12 seconds. I say outputting since the timestamp of
>>> the messages is from about 1 second after start time. Anyway not sure
>>> exactly what was done in the last day that would have made such a
>>> difference.
>>>
>>> Cheers,
>>> Alain
>>>
>>>
>>> On Tue, Oct 23, 2018 at 4:12 AM Neil Bartlett 
>>> wrote:
>>>
 Two quick points:

 1. The Felix ResolverImpl is responsible for resolving bundle
 constaints (imports and requires). It has absolutely nothing to do with
 SCR, so it doesn't matter how many components you have.

 2. Are you building an Eclipse RCP application? If so, check whether
 the org.eclipse.equinox.p2.reconciler.dropins bundle is present. This
 bundle is part of Eclipse p2 and it supports the "drop-ins" folder
 functionality... it performs a second resolution of the complete set of
 installed bundles plus the dropins folder, and it is VERY slow. Most apps
 don't need this functionality. By removing it I cut the start time of one
 application from nearly 2 minutes (not exaggerating) down to 15 seconds
 (still not great, more work to do).

 Regards,
 Neil

 On Mon, Oct 22, 2018 at 6:43 PM Alain Picard via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

> We are experiencing some long startup time in our reafactored
> application that is now heavily using SCR.
>
> We have 125 projects with over 1200 Service Components and it takes
> about 2 minutes to get any output in the console. Some quick analysis 
> shows
> that its running the Felix ResolverImpl with something like 5-6 thread
> (that is with Equinox).
>
> I looked in that class but there doesn't seem to be any tracing code,
> only what appears to be some debugging code.
>
> Is this expected? If not what have others used to resolve this issue?
>
> Thanks
> Alain
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

 ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Service component resolution time

[Raymond Auge via osgi-dev]

It would be useful to make this scenario produce a louder perhaps more
obvious error message.

If you could maybe create an issue for improvement on Apache Felix JIRA,
under Resolver project with as many details as you could provide maybe we
can do something.

These rare and complex scenarios don't have to be so time consuming
particularly if there's very visible and useful diagnostic details provided
when they occur.

Sincerely,
- Ray

On Sat, Nov 3, 2018, 11:30 Alain Picard via osgi-dev  A small note if anyone happens to face the same issue. At the end after
> adding tracing we found out that we had a few resolver chain issues:
> RESOLVER: Candidate permutation failed due to a conflict between imports;
> will try another if possible. via two dependency chains.
>
> So we had to clear that up and now there is no more startup time issue.
>
> Cheers,
> Alain
>
> On Tue, Oct 23, 2018 at 4:45 AM Alain Picard 
> wrote:
>
>> Neil,
>>
>> Thanks for the pointers.
>> 2 points...as well
>>
>> 1. This was an RCP application that is still PDE based (can't do
>> everything in this round of refactoring) but now running directly against
>> OSGI (not an Eclipse application. And there are no p2 bundles selected.
>>
>> 2. Well retesting this morning the start time for the console to start
>> outputting content is ~12 seconds. I say outputting since the timestamp of
>> the messages is from about 1 second after start time. Anyway not sure
>> exactly what was done in the last day that would have made such a
>> difference.
>>
>> Cheers,
>> Alain
>>
>>
>> On Tue, Oct 23, 2018 at 4:12 AM Neil Bartlett 
>> wrote:
>>
>>> Two quick points:
>>>
>>> 1. The Felix ResolverImpl is responsible for resolving bundle constaints
>>> (imports and requires). It has absolutely nothing to do with SCR, so it
>>> doesn't matter how many components you have.
>>>
>>> 2. Are you building an Eclipse RCP application? If so, check whether the
>>> org.eclipse.equinox.p2.reconciler.dropins bundle is present. This bundle is
>>> part of Eclipse p2 and it supports the "drop-ins" folder functionality...
>>> it performs a second resolution of the complete set of installed bundles
>>> plus the dropins folder, and it is VERY slow. Most apps don't need this
>>> functionality. By removing it I cut the start time of one application from
>>> nearly 2 minutes (not exaggerating) down to 15 seconds (still not great,
>>> more work to do).
>>>
>>> Regards,
>>> Neil
>>>
>>> On Mon, Oct 22, 2018 at 6:43 PM Alain Picard via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 We are experiencing some long startup time in our reafactored
 application that is now heavily using SCR.

 We have 125 projects with over 1200 Service Components and it takes
 about 2 minutes to get any output in the console. Some quick analysis shows
 that its running the Felix ResolverImpl with something like 5-6 thread
 (that is with Equinox).

 I looked in that class but there doesn't seem to be any tracing code,
 only what appears to be some debugging code.

 Is this expected? If not what have others used to resolve this issue?

 Thanks
 Alain
 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org
 https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Is there already a standard for aggregating repositories?

[Raymond Auge via osgi-dev]

On Sun, Oct 21, 2018, 13:38 Raymond Auge,  wrote:

> Additionally, the OSGi repository format defines the "referral" [1]
> element which points at another index file. This way you can combine repos
> whoever you like.
>

... and yes, bnd supports this.


>
> - Ray
>
> [1]
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.repository.html#i3236527
>
>
>
> On Sun, Oct 21, 2018, 12:57 Peter Kriens via osgi-dev, <
> osgi-dev@mail.osgi.org> wrote:
>
>> The bnd code contains an AggregateRepository class that aggregates a
>> number of repositories defined by the OSGi Repository standard. It is
>> actually used in the bnd resolver API.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> > On 21 Oct 2018, at 12:26, Mark Raynsford via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>> >
>> > Hello!
>> >
>> > As the subject says: Is there already a standard for aggregating
>> > repositories?
>> >
>> > I'm putting together a small proof of concept API and application that
>> > allows a user to browse a set of bundle repositories [0], select bundles
>> > from those repositories, get all of the bundle dependencies resolved
>> > automatically, download all of the bundles, and finally start up an
>> > OSGi container with all of the selected and downloaded bundles.
>> >
>> > I have all of that working (using the Bnd resolver), but the main pain
>> > point is the need to initially specify a (possibly rather large) set of
>> > repositories. I could very easily come up with an API or an XML schema
>> > that allows a server to deliver a set of repository URLs, but before I
>> > do that: Is there already a standard for this?
>> >
>> > [0] A Compendium chapter 132 repository.
>> >
>> > --
>> > Mark Raynsford | http://www.io7m.com
>> >
>> > ___
>> > OSGi Developer Mail List
>> > osgi-dev@mail.osgi.org
>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Is there already a standard for aggregating repositories?

[Raymond Auge via osgi-dev]

Additionally, the OSGi repository format defines the "referral" [1] element
which points at another index file. This way you can combine repos whoever
you like.

- Ray

[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.repository.html#i3236527



On Sun, Oct 21, 2018, 12:57 Peter Kriens via osgi-dev, <
osgi-dev@mail.osgi.org> wrote:

> The bnd code contains an AggregateRepository class that aggregates a
> number of repositories defined by the OSGi Repository standard. It is
> actually used in the bnd resolver API.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> > On 21 Oct 2018, at 12:26, Mark Raynsford via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
> >
> > Hello!
> >
> > As the subject says: Is there already a standard for aggregating
> > repositories?
> >
> > I'm putting together a small proof of concept API and application that
> > allows a user to browse a set of bundle repositories [0], select bundles
> > from those repositories, get all of the bundle dependencies resolved
> > automatically, download all of the bundles, and finally start up an
> > OSGi container with all of the selected and downloaded bundles.
> >
> > I have all of that working (using the Bnd resolver), but the main pain
> > point is the need to initially specify a (possibly rather large) set of
> > repositories. I could very easily come up with an API or an XML schema
> > that allows a server to deliver a set of repository URLs, but before I
> > do that: Is there already a standard for this?
> >
> > [0] A Compendium chapter 132 repository.
> >
> > --
> > Mark Raynsford | http://www.io7m.com
> >
> > ___
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] How can I destroy all OSGi blueprint components before the OSGi framework is stopped?

[Raymond Auge via osgi-dev]

You probably want to actually wait for the framework to stop:

FrameworkEvent frameworkEvent = Launcher.framework.waitForStop(timeout);

if (frameworkEvent.getType() == FrameworkEvent.WAIT_TIMEDOUT) {
_log.error("OSGi framework event {} triggered after a {}ms timeout",
frameworkEvent, timeout);
}
else if (_log.isInfoEnabled()) {
_log.info(frameworkEvent);
}

HTH,
- Ray

On Mon, Oct 15, 2018 at 2:41 PM Martin Petzold via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Dear list.
>
> My aim is a graceful stop of the OSGi framework and all OSGi blueprint
> components.
>
> If I stop the OSGi framework, the OSGi blueprint components are not
> destroyed (destroy methods are not called). Why is this the case and how
> can I destroy them. I have my own OSGi launcher implementation. I'm
> using a shutdown hook and then stop the OSGi framework:
>
> Runtime.getRuntime().addShutdownHook(new Thread() {
>  @Override
>  public void run() {
>  Launcher.logService.log(LogService.LOG_WARNING, "HANDLE
> SHUTDOWN");
>  if(Launcher.framework != null) {
>  try {
>  Launcher.framework.stop();
>  } catch (BundleException e) {
>  Launcher.logService.log(LogService.LOG_ERROR,
> "Shutdown" + ((Launcher.framework != null) ? " of " +
> Launcher.framework.getSymbolicName() + " " : " ") + "failed!", e);
>  System.exit(-1);
>  }
>  }
>  }
> });
>
> Thanks and kind regards,
>
> Martin
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Servlet Context in OSGi

[Raymond Auge via osgi-dev]

On top of this design we've been able to model full blown WAB support, each
WAR get's it's own "servlet context" against which every other
resource/servlet/filter in the WAR is targeted.

Another common case is re-use of exactly the same pre-built servlet &
filter based features with different configurations, for instance N
different JSF applications.

- Ray

On Wed, Oct 10, 2018 at 4:04 AM David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Ok, fair enough. Thanks for these thoughts.
>
> Cheers,
> =David
>
>
>
> > On Oct 10, 2018, at 16:11, Tim Ward  wrote:
> >
> > It also provides a way to have separate user sessions (useful),
> different security configurations (useful), management of static resource
> mappings (useful), isolation of redirection to named servlets (less useful)
> and I’m sure a bunch of other things.
> >
> > Tim
> >
> > Sent from my iPhone
> >
> >> On 9 Oct 2018, at 22:48, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
> >>
> >>
> >> Hi!
> >>
> >> From what I understand, ServletContext is not really thought about much
> in a non-OSGi application because there is basically one ServletContext per
> app. I never really gave it much thought before.
> >>
> >> In OSGi, we have more flexibility.
> >>
> >> So my question: when should I consider using a ServletContext other
> than the default context? I suspect that it could be useful as a cognitive
> division, but that’s about the only use I can see. And the advantage is not
> that great because users don’t see any difference at all, as far as I can
> tell.
> >>
> >>
> >> Any thoughts?
> >>
> >>
> >> Cheers,
> >> =David
> >>
> >>
> >> ___
> >> OSGi Developer Mail List
> >> osgi-dev@mail.osgi.org
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] many bundles with the same propeties file : infinite loop

[Raymond Auge via osgi-dev]

On Mon, Oct 8, 2018 at 9:46 AM Mohamed AFIF via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Hello,
>
> I had in my project a random behaviour of some bundles who  Swing between
> Active and Starting state, but finally  I found out the root cause,
> indeed those bundles  share the same cm:property-placeholder
>

Hello Afif,

Are you talking about blueprint?

If so, you may want to check the Apache Aries user/dev mailing lists. There
might be more people who maintain the Aries blueprint impl there who might
be able help.

Sincerely,
- Ray


> with the same persistent-id, and as every property file is associated to
> only one   ManageService , when anotherbundle sharing  same file starts,
> it goes around in circles.
> I would like to know if there is a workaroud to allow using the same file
> for all maven project modules.
>
> Many thanks.
>
> Mohamed.
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] replace session-config in web.xml with whiteboard

[Raymond Auge via osgi-dev]

Please feel free to submit an issue about this to the OSGi bug tracker [1].

- Ray
[1] https://osgi.org/bugzilla/

On Thu, Oct 4, 2018 at 11:40 AM Nhut Thai Le via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Thank you for the link; unfortunately i'm using paxweb http service so
> that config property is not applicable. Not sure why the osgi spec does not
> cover session config, it should be part of the servlet context helper
> config IMHO
>
> Thai
>
> On Mon, Oct 1, 2018 at 3:59 PM Julian Sedding  wrote:
>
>> Hello Thai
>>
>> If you are using the Felix HTTP Service, the documentation has a
>> Configuration Properties section[0]. This describes that you can set a
>> property called "org.apache.felix.http.session.timeout". It is
>> documented as follows:
>>
>> """
>> Allows for the specification of the Session life time as a number of
>> minutes. This property serves the same purpose as the session-timeout
>> element in a Web Application descriptor. The default is "0" (zero) for
>> no timeout at all.
>> """
>>
>> I think that's what you may be looking for.
>>
>> Regards
>> Julian
>>
>> [0]
>> https://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#configuration-properties
>> On Wed, Sep 26, 2018 at 8:04 PM Nhut Thai Le via osgi-dev
>>  wrote:
>> >
>> > Hello,
>> >
>> > I'm replacing servlets, servlet filters registration in web.xml with
>> whiteboard DS, however, in my web.xml i have a section:
>> > 
>> > 1800
>> > 
>> > which i dont know how to port to whiteboard. I didnt see any property
>> for session to be set on ServletContextHelper in osgi compendium 7 does
>> anyone have an idea?
>> >
>> > Thai
>> > ___
>> > OSGi Developer Mail List
>> > osgi-dev@mail.osgi.org
>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
> --
> Castor Technologies Inc
> 460 rue St-Catherine St Ouest, Suite 613
> Montréal, Québec H3B-1A7
> (514) 360-7208 o
> (514) 798-2044 f
> n...@castortech.com
> www.castortech.com
>
> CONFIDENTIALITY NOTICE: The information contained in this e-mail is
> confidential and may be proprietary information intended only for the use
> of the individual or entity to whom it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that any
> viewing, dissemination, distribution, disclosure, copy or use of the
> information contained in this e-mail message is strictly prohibited. If you
> have received and/or are viewing this e-mail in error, please immediately
> notify the sender by reply e-mail, and delete it from your system without
> reading, forwarding, copying or saving in any manner. Thank you.
> AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est
> confidentiel, peut être protégé par le secret professionnel et est réservé
> à l'usage exclusif du destinataire. Toute autre personne est par les
> présentes avisée qu'il lui est strictement interdit de diffuser, distribuer
> ou reproduire ce message. Si vous avez reçu cette communication par erreur,
> veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Best practices for providing configs in cloud setups?

[Raymond Auge via osgi-dev]

I thought this is exactly what the new Configurator Specification [1] is
all about.

- Ray

[1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.configurator.html


On Thu, Sep 13, 2018 at 8:30 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> I am looking into good ways to provide configuration to OSGi bundles for
> cloud setups.
>
> So my prototypical application would be a self running jar created by
> bndtools. This is then packaged into a docker image that simply runs the
> jar. The docker image is then deployed using kubernetes. I got an example
> of such an application from my adaptto talk about felix systemready. See
> https://github.com/cschneider/osgi-example-systemready
>
> This is all well as long as all your config is inside the application
> already or can be read using existing means like the hostnames provided by
> kubernetes. For many cases this is not enough though.
>
> I can imagine to use env variables to override key/values of configs like
> provided by the old configurer by Peter. I just created an issue to look
> into this: https://issues.apache.org/jira/browse/FELIX-5924
>
> There are other possible ways though. For example kubernetes allows to map
> configMaps to files which then could be fed into config admin. Did anyone
> try this and ideally maybe has an example?
>
> Some interesting possible requirements:
> - The config should be applied in a way that avoids oscillation of
> services. So ideally config should be applied in one step
> - Secrets should be protected in some way
> - Kubernetes seems to be able to reflect updates to configMaps in a live
> system. So this might be a case where we want to update config inside a
> running app even in the cloud.
>
> So what are your ideas and approaches with applying configs to OSGi cloud
> applications?
>
> Christian
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] How can I reuse servlet filter across bundles

[Raymond Auge via osgi-dev]

Thai, what you described sounds like a bug in the http whiteboard
implementation. Which do you use and could you file a bug against it?

- Ray

On Wed, Sep 12, 2018, 17:38 Nhut Thai Le,  wrote:

> Thank you Raymond,
>
> I called the  HttpServiceRuntim.calculateRequestInfoDTO("/token") inside
> my servlet and i see my filter listed as filterDTOs:
> {"path":"/token", "servletContextId":125,
> "filterDTOs":[{"name":"AuthenticationFilter", "patterns":["/*"],
> "servletNames":null, "regexs":null, "asyncSupported":false,
> "dispatcher":[], "initParams":{"component.id":"33", 
> "component.name":"com.casto...ionFilter",
> "service.id":"117", "objectClass":"[Ljava.la...@5891e480",
> "filterRank":"10", "service.scope":"prototype",
> "osgi.http.whiteboard.filter.pattern":"/*", "
> osgi.http.whiteboard.filter.name":"AuthenticationFilter",
> "osgi.http.whiteboard.context.select":"(osgi.htt...xtHelper)",
> "service.ranking":"10", "service.bundleid":"136"}, "serviceId":117,
> "servletContextId":125}], "servletDTO":{"patterns":["/token"], "name":null,
> "servletInfo":"", "asyncSupported":false, "initParams":{},
> "servletContextId":125, "serviceId":127}, "resourceDTO":null}
>
> However, the filter is still not triggered. If i manually create a
> ServletContextHelper and add "osgi.http.whiteboard.context.select=(
> osgi.http.whiteboard.context.name=SharedServletContextHelper)" to both
> the filter and the servlet then i can see the filter kick in before the
> request hit the servlet. So I think shared servlet context is required to
> have the filters works across bundles. My concern is that i cannot use the
> SharedServletContextHelper on the resource service because it will not see
> the icons folder in my bundle. Here is the debug log if i use the
> SharedServletContextHelper with the resource service:
>
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler - servlet
> |/static/icons|/bundle1.png -> /static/icons/*:/icons@d606ba18
> ==org.ops4j.pax.web.service.jetty.internal.ResourceServlet,jsp=null,order=-1,inst=true
> [qtp345379538-59] DEBUG
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext - Handling
> request for [/static/icons/bundle1.png] using http context
> [org.ops4j.pax.web.extender.whiteboard.internal.WebApplication$1@1b9ac962]
> [qtp345379538-59] DEBUG
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler -
> handling request
> org.ops4j.pax.web.service.jetty.internal.HttpServiceRequestWrapper@5b1bfc6,
> org.ops4j.pax.web.service.jetty.internal.HttpServiceResponseWrapper@b765100
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler -
> chain=org.ops4j.pax.web.service.spi.model.FilterModel-13->/static/icons/*:/icons@d606ba18
> ==org.ops4j.pax.web.service.jetty.internal.ResourceServlet,jsp=null,order=-1,inst=true
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler - call
> filter org.ops4j.pax.web.service.spi.model.FilterModel-13
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler - call
> servlet 
> /static/icons/*:/icons@d606ba18==org.ops4j.pax.web.service.jetty.internal.ResourceServlet,jsp=null,order=-1,inst=true
>  [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ErrorPageErrorHandler -
> getErrorPage(GET /static/icons/bundle1.png) => error_page=null (from global
> default)
>
> So now the question really is how to hook my servlet filter to a resource
> service.
>
> Thai
>
> On Wed, Sep 12, 2018 at 3:01 PM, Raymond Auge 
> wrote:
>
>> Hello Thai,
>>
>> I don't see anything wrong.
>>
>> It looks like they all "target" the default "ServletContextHelper" (i.e.
>> the same context) and so the filter should apply to each.
>>
>> You should be able to check by getting the HttpServiceRuntime [1] service
>> and calling the method `calculateRequestInfoDTO(String path)` to see what
>> the runtime thinks is wired up for that path.
>>
>> Sincerely,
>> - Ray
>>
>> [1]
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#org.osgi.service.http.runtime.HttpServiceRuntime
>>
>> On Wed, Sep 12, 2018 at 2:39 PM, Nhut Thai Le via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hello,
>>>
>>> I want to have a filter at the root of my application where all http
>>> requests must pass through, so I make a Servlet filter:
>>> @Component(
>>> service=Filter.class,
>>> scope=ServiceScope.PROTOTYPE,
>>> property= {
>>> "osgi.http.whiteboard.filter.name=AuthenticationFilter",
>>> "osgi.http.whiteboard.filter.pattern=/*",
>>> "service.ranking:Integer=10"
>>> }
>>> )
>>> public final class AuthenticationFilter implements Filter {...}
>>> -
>>> Then I have some servlets (in other bundles) defined like this:
>>> @Component(
>>> service = Servlet.class,
>>> property= {
>>> "osgi.http.whiteboard.servlet.pattern=/token"
>>> }
>>> )
>>> public class AccessTokenServlet extends HttpServlet{...}
>>> ---
>>> I also have some resource services in other bundles:
>>> 

Re: [osgi-dev] How can I reuse servlet filter across bundles

[Raymond Auge via osgi-dev]

Hello Thai,

I don't see anything wrong.

It looks like they all "target" the default "ServletContextHelper" (i.e.
the same context) and so the filter should apply to each.

You should be able to check by getting the HttpServiceRuntime [1] service
and calling the method `calculateRequestInfoDTO(String path)` to see what
the runtime thinks is wired up for that path.

Sincerely,
- Ray

[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#org.osgi.service.http.runtime.HttpServiceRuntime

On Wed, Sep 12, 2018 at 2:39 PM, Nhut Thai Le via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello,
>
> I want to have a filter at the root of my application where all http
> requests must pass through, so I make a Servlet filter:
> @Component(
> service=Filter.class,
> scope=ServiceScope.PROTOTYPE,
> property= {
> "osgi.http.whiteboard.filter.name=AuthenticationFilter",
> "osgi.http.whiteboard.filter.pattern=/*",
> "service.ranking:Integer=10"
> }
> )
> public final class AuthenticationFilter implements Filter {...}
> -
> Then I have some servlets (in other bundles) defined like this:
> @Component(
> service = Servlet.class,
> property= {
> "osgi.http.whiteboard.servlet.pattern=/token"
> }
> )
> public class AccessTokenServlet extends HttpServlet{...}
> ---
> I also have some resource services in other bundles:
> @Component(service = IconsResourceService.class,
> property = {
> "osgi.http.whiteboard.resource.pattern=/static/icons/*",
> "osgi.http.whiteboard.resource.prefix=/icons"
> }
> )
> public class IconsResourceService {}
> ---
> However, my filter never trigger when i request the icon (static resource)
> or token (servlet). My understanding is that the 3 components above reside
> in different bundles thus they have different servlet contexts so the
> filter wont trigger. I can created a ServletContextHelper and select it in
> the Servlet component annotation but this wont help in the case of the
> resource service. Is there other way to share filter across bundles?
>
> Thai
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Logger at startup

[Raymond Auge via osgi-dev]

On Tue, Aug 28, 2018 at 3:13 AM, Peter Kriens 
wrote:

> On 27 Aug 2018, at 22:40, Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
> On Mon, Aug 27, 2018 at 4:19 PM, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>>
>> Hi Peter and Ray,
>> Thank you very much for the suggestions!
>> I’ll take a look at the code. It is my hope that I don’t need to pull in
>> any additional dependencies. Maybe I’ll get some hints in the code as to
>> how not to lose any logs.
>> If I am reading the Felix Logback page correctly, It’s a bit odd that the
>> OSGi log service, when started up normally, misses some information during
>> startup. In my mind, that seems like a problem with the spec.
>>
> It's not a problem with the spec. The problem is with the buffering which
> the spec cannot avoid.
> You can't accurately predict how much buffer is needed
> If you buffer to much you _may_ have memory issues
>
> Yes, but if you limit the buffering to the framework start and the log
> service up and running you can make a reasonable guess how long the buffer
> is. Only when out of the ordinary stuff happens you need a large buffer.
> However, than almost invariably the early records contain sufficient
> information to diagnose wtf happened. Second, once the log service is up
> and running the buffer can be flushed.
>
> If you buffer to little you _may_ lose records
> If you buffer you always have temporal inconsistency, no matter what.
>
> That I do not understand?
>

I don't see what is hard to understand. The log record arrives at the
appender long after it was reported. Which you may not care too much about.
But sometimes it's a pain in the backside.


>
>
> The solution I like is DON'T buffer.
>
> Then you have ordering problems.
>

There's no ordering issue when logging is setup with the framework.


>
> The only way NOT to buffer is make sure the log service starts with an
> appender immediately. That's what the "immediate" logging approach
> provides. It puts the log service setup and configuration immediately at
> the framework level so that no buffering is used or required.
>
> That is a good solution but it makes logging extremely 'special'. Agree
> this is a very foundational service but losing the possibility to have
> appenders in bundles is a pretty big thing.
>

Logging IS special. We all know that and there's no use pretending,
otherwise, we WOULD have solved this long ago.


>
> Logging is an infrastructure detail unlike any other. It really must be
> bootstrapped with the runtime as early as possible. It's not ideal to
> handle it at the module layer, so I propose not to (thought it still
> integrates nicely with any bundle based logging APIs as demonstrated in the
> Felix logback integration tests).
>
> The problem with this approach is that it is also true for configuration
> admin, and DS, and event admin, etc. etc. They are all infrastructure and
> they all have ordering issues. Going down your route is imho a slippery
> slope. Before you know you're back to a completely static model. And maybe
> that is not bad, I just prefer a solution where I can debug all day on the
> same framework that is never restarted. I also dislike hybrids since they
> tend to become quite complex to handle on other levels.
>

There's nothing in the immediate model that prevents from debugging all day
without restarts, that's just hyperbole. Logback supports configuration
file updates (if you like), so you can tweak and flex those
loggers/appenders any way you like at runtime (if you like).

Sincerely,
- Ray


>
> Kind regards,
>
> Peter Kriens
>
>
>
> Sincerely,
> - Ray
>
>
>>
>> This issue, the problem of startup dependencies and configuration… Maybe
>> there is something missing in the spec in terms of some kind of "boot
>> service” that would handle these “common” problems. If the problems are so
>> common, then maybe it is a sign of a gap in the specs… Just a thought.
>>
>>
>> Anyway, thanks!
>> =David
>>
>>
>>
>> On Aug 27, 2018, at 22:19, Raymond Auge  wrote:
>>
>> There's setup details in the integration tests [1]
>>
>> HTH
>> - Ray
>>
>> [1] https://github.com/apache/felix/tree/trunk/logback/itests
>>
>> On Mon, Aug 27, 2018 at 9:15 AM, Raymond Auge 
>> wrote:
>>
>>> My personal favourite is the Apache Felix Logback [1] integration which
>>> supports immediate logging when follow the correct steps. I feel it's the
>>> best logging solution available.
>>>
>>> There are a couple of prerequisites as outlined in the documentation.
>>&

Re: [osgi-dev] Logger at startup

[Raymond Auge via osgi-dev]

On Mon, Aug 27, 2018 at 4:19 PM, David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Hi Peter and Ray,
>
> Thank you very much for the suggestions!
>
> I’ll take a look at the code. It is my hope that I don’t need to pull in
> any additional dependencies. Maybe I’ll get some hints in the code as to
> how not to lose any logs.
>
> If I am reading the Felix Logback page correctly, It’s a bit odd that the
> OSGi log service, when started up normally, misses some information during
> startup. In my mind, that seems like a problem with the spec.
>

It's not a problem with the spec. The problem is with the buffering which
the spec cannot avoid.

You can't accurately predict how much buffer is needed
If you buffer to much you _may_ have memory issues
If you buffer to little you _may_ lose records
If you buffer you always have temporal inconsistency, no matter what.

The solution I like is DON'T buffer.

The only way NOT to buffer is make sure the log service starts with an
appender immediately. That's what the "immediate" logging approach
provides. It puts the log service setup and configuration immediately at
the framework level so that no buffering is used or required.

Logging is an infrastructure detail unlike any other. It really must be
bootstrapped with the runtime as early as possible. It's not ideal to
handle it at the module layer, so I propose not to (thought it still
integrates nicely with any bundle based logging APIs as demonstrated in the
Felix logback integration tests).

Sincerely,
- Ray


>
> This issue, the problem of startup dependencies and configuration… Maybe
> there is something missing in the spec in terms of some kind of "boot
> service” that would handle these “common” problems. If the problems are so
> common, then maybe it is a sign of a gap in the specs… Just a thought.
>
>
> Anyway, thanks!
> =David
>
>
>
> On Aug 27, 2018, at 22:19, Raymond Auge  wrote:
>
> There's setup details in the integration tests [1]
>
> HTH
> - Ray
>
> [1] https://github.com/apache/felix/tree/trunk/logback/itests
>
> On Mon, Aug 27, 2018 at 9:15 AM, Raymond Auge 
> wrote:
>
>> My personal favourite is the Apache Felix Logback [1] integration which
>> supports immediate logging when follow the correct steps. I feel it's the
>> best logging solution available.
>>
>> There are a couple of prerequisites as outlined in the documentation. But
>> it's very simple to achieve your goal (NO BUFFERING OR MISSED LOG RECORDS)!
>>
>> [1] http://felix.apache.org/documentation/subprojects/apache-
>> felix-logback.html
>>
>> - Ray
>>
>> On Mon, Aug 27, 2018 at 7:50 AM, BJ Hargrave via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Equinox has the LogService implementation built into the framework, so
>>> it starts logging very early.
>>>
>>> In the alternate, for framework related information, you can write your
>>> own launcher and it can add listeners for the framework event types.
>>> --
>>>
>>> BJ Hargrave
>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>>> hargr...@us.ibm.com
>>>
>>>
>>>
>>> - Original message -
>>> From: David Leangen via osgi-dev 
>>> Sent by: osgi-dev-boun...@mail.osgi.org
>>> To: osgi-dev@mail.osgi.org
>>> Cc:
>>> Subject: [osgi-dev] Logger at startup
>>> Date: Sun, Aug 26, 2018 3:06 PM
>>>
>>> Hi!
>>>
>>> I’m sure that this question has been asked before, but I did not
>>> successfully find an answer anywhere. It applies to both R6 and R7 logging.
>>>
>>> I would like to set up diagnostics so I can figure out what is happening
>>> during system startup. however, by the time the logger starts, I have
>>> already missed most of the messages that I needed to receive and there is
>>> no record of the things I want to see. Another oddity is that even after
>>> the logger has started, some messages are not getting logged. I can only
>>> assume that there is some concurrency/dynamics issue at play.
>>>
>>> In any case, other than using start levels, is there a way of ensuring
>>> that the LogService (or Logger) is available when I need it?
>>>
>>>
>>> Thanks!
>>> =David
>>>
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>>
>>>
>>>
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi 

Re: [osgi-dev] Logger at startup

[Raymond Auge via osgi-dev]

There's setup details in the integration tests [1]

HTH
- Ray

[1] https://github.com/apache/felix/tree/trunk/logback/itests

On Mon, Aug 27, 2018 at 9:15 AM, Raymond Auge 
wrote:

> My personal favourite is the Apache Felix Logback [1] integration which
> supports immediate logging when follow the correct steps. I feel it's the
> best logging solution available.
>
> There are a couple of prerequisites as outlined in the documentation. But
> it's very simple to achieve your goal (NO BUFFERING OR MISSED LOG RECORDS)!
>
> [1] http://felix.apache.org/documentation/subprojects/
> apache-felix-logback.html
>
> - Ray
>
> On Mon, Aug 27, 2018 at 7:50 AM, BJ Hargrave via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Equinox has the LogService implementation built into the framework, so it
>> starts logging very early.
>>
>> In the alternate, for framework related information, you can write your
>> own launcher and it can add listeners for the framework event types.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com
>>
>>
>>
>> - Original message -
>> From: David Leangen via osgi-dev 
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: osgi-dev@mail.osgi.org
>> Cc:
>> Subject: [osgi-dev] Logger at startup
>> Date: Sun, Aug 26, 2018 3:06 PM
>>
>> Hi!
>>
>> I’m sure that this question has been asked before, but I did not
>> successfully find an answer anywhere. It applies to both R6 and R7 logging.
>>
>> I would like to set up diagnostics so I can figure out what is happening
>> during system startup. however, by the time the logger starts, I have
>> already missed most of the messages that I needed to receive and there is
>> no record of the things I want to see. Another oddity is that even after
>> the logger has started, some messages are not getting logged. I can only
>> assume that there is some concurrency/dynamics issue at play.
>>
>> In any case, other than using start levels, is there a way of ensuring
>> that the LogService (or Logger) is available when I need it?
>>
>>
>> Thanks!
>> =David
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Logger at startup

[Raymond Auge via osgi-dev]

My personal favourite is the Apache Felix Logback [1] integration which
supports immediate logging when follow the correct steps. I feel it's the
best logging solution available.

There are a couple of prerequisites as outlined in the documentation. But
it's very simple to achieve your goal (NO BUFFERING OR MISSED LOG RECORDS)!

[1]
http://felix.apache.org/documentation/subprojects/apache-felix-logback.html

- Ray

On Mon, Aug 27, 2018 at 7:50 AM, BJ Hargrave via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Equinox has the LogService implementation built into the framework, so it
> starts logging very early.
>
> In the alternate, for framework related information, you can write your
> own launcher and it can add listeners for the framework event types.
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: David Leangen via osgi-dev 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: osgi-dev@mail.osgi.org
> Cc:
> Subject: [osgi-dev] Logger at startup
> Date: Sun, Aug 26, 2018 3:06 PM
>
> Hi!
>
> I’m sure that this question has been asked before, but I did not
> successfully find an answer anywhere. It applies to both R6 and R7 logging.
>
> I would like to set up diagnostics so I can figure out what is happening
> during system startup. however, by the time the logger starts, I have
> already missed most of the messages that I needed to receive and there is
> no record of the things I want to see. Another oddity is that even after
> the logger has started, some messages are not getting logged. I can only
> assume that there is some concurrency/dynamics issue at play.
>
> In any case, other than using start levels, is there a way of ensuring
> that the LogService (or Logger) is available when I need it?
>
>
> Thanks!
> =David
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Enabling debug of SCR with Equinox

[Raymond Auge via osgi-dev]

Here's a few additional comments to Critiano's suggestion:


On Mon, Aug 6, 2018 at 8:38 PM, Cristiano via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> hi,
>
> if you are using the latest equinox, one good alternative is to use the
> recently released org.apache.felix.logback.
>
You can even use it now with the latest Felix + latest Felix Log Service
(1.2.0).

See these integration tests [1] & [2]

>
> you just need to set a proper logback configuration file defining the
> appenders and log level and then use the vm argument as below (I used to
> debug inside eclipse ide):
>
> -Dlogback.configurationFile=${workspace_loc:your_project}/logback-test.xml
>
>
> Also, it is better to set org.apache.felix.logback's start level to one,
> so you won't miss any log entry.
>

You don't need to use start levels at all if you place felix.logback onto
the classpath of the framework. For equinox see [3] and for felix (you need
the org.apache.felix.log.extension bundle installed) see [2].

Sincerely,
- Ray

[1]
https://github.com/apache/felix/blob/trunk/logback/itests/standard-felix-logservice/itest.bndrun
[2]
https://github.com/apache/felix/blob/trunk/logback/itests/immediate-felix-logservice/itest.bndrun
[3]
https://github.com/apache/felix/blob/trunk/logback/itests/immediate-equinox-logservice/itest.bndrun



> See an example:
>
> 21:23:29,959 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction -
> Setting level of logger [Events.Service.org.eclipse.osgi] to DEBUG
>
> 21:36:13||DEBUG|bundle org.apache.felix.scr:2.1.2 (20)bundle
> org.eclipse.equinox.console:1.3.0.v20180119-0630 (22) : Starting
> extension synchronously|L.org.apache.felix.scr||L.o.a.f.scr@?[main]
>
> 21:36:13||INFO|BundleEvent STARTED|E.B.o.e.equinox.
> console||E.B.o.e.e.console@?[Framework Event Dispatcher: Equinox
> Container: f558dbee-500a-4400-ae8a-0e68b1b46f2e]
>
> 21:36:18||DEBUG|ServiceEvent MODIFIED {org.osgi.service.component.runtime.
> ServiceComponentRuntime}={service.changecount=19, service.id=39,
> service.bundleid=20, service.scope=singleton}|E.S.
> org.apache.felix.scr||E.S.o.a.f.scr@?[Timer-1]
>
>
>

>
> regards,
>
> Cristiano
>
>
> On 06/08/2018 12:28, Alain Picard via osgi-dev wrote:
>
> I want to enable debug logging / tracing of SCR when running with Equinox.
> I tried to use config admin to configure "org.apache.felix.scr.ScrService"
> but to no avail. Not sure if even if Eclipse now uses felix scr if that is
> the way to go. Or it is the whole log redirection thing (
> https://io7m.com/documents/brutal-felix-logging/). Just looking for
> console debug.
>
> Thanks
> Alain
>
>
>
> ___
> OSGi Developer Mail 
> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Liferay Portlet created with BndTools and Gradle not outputting the right package versioning when building the JAR file

[Raymond Auge via osgi-dev]

Forgive me for misspelling your name Ramazan.

Sincerely,
- Ray

On Tue, Aug 7, 2018 at 9:01 AM, Raymond Auge 
wrote:

> Hello Raman,
>
> Since many of the aspects could be related to Liferay specifics, you may
> have better luck asking on the Liferay forums here [1] or even on the
> Liferay community slack group here [2].
>
> Sincerely,
> - Ray
>
> [1] https://community.liferay.com/forums
> [2] https://liferay-community.slack.com
>
> On Mon, Aug 6, 2018 at 10:56 AM, Ramazan Bekrek (Extern) via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> I would like to know why when I’m running an OSGi compiled JAR Bundle
>> inside of Liferay OSGi environment I get this error:
>>
>>
>>
>> *This is the bnd.bnd file*
>>
>>
>>
>> Bundle-Name: Liferay Portal Portlet Bridge Soy
>>
>> Bundle-SymbolicName: com.liferay.portal.portlet.bridge.soy
>>
>> Bundle-Version: 3.2.0
>>
>> Export-Package: com.liferay.portal.portlet.bridge.soy
>>
>> Liferay-Releng-Module-Group-Description:
>>
>> Liferay-Releng-Module-Group-Title:
>>
>> Web-ContextPath: /portal-portlet-bridge-soy
>>
>>
>>
>> *This ist he build.gradle file*
>>
>>
>>
>> sourceCompatibility = "1.8"
>>
>> targetCompatibility = "1.8"
>>
>>
>>
>> configJSModules {
>>
>> include "**/*.js*"
>>
>> }
>>
>>
>>
>> dependencies {
>>
>> compileOnly group: "com.liferay", name:
>> "com.liferay.osgi.util", version: "3.2.0"
>>
>> compileOnly group: "com.liferay", name:
>> "com.liferay.petra.function", version: "1.0.0"
>>
>> compileOnly group: "com.liferay", name:
>> "com.liferay.petra.string", version: "1.0.0"
>>
>> compileOnly group: "com.liferay.portal", name:
>> "com.liferay.portal.impl", version: "2.0.0"
>>
>> compileOnly group: "com.liferay.portal", name:
>> "com.liferay.portal.kernel", version: "2.13.0"
>>
>> compileOnly group: "com.liferay.portal", name:
>> "com.liferay.util.bridges", version: "2.0.0"
>>
>> compileOnly group: "javax.portlet", name: "portlet-api",
>> version: "2.0"
>>
>> compileOnly group: "javax.servlet", name:
>> "javax.servlet-api", version: "3.0.1"
>>
>> compileOnly group: "org.osgi", name: "org.osgi.core",
>> version: "6.0.0"
>>
>> // Added this
>>
>> compileOnly project(":modules:portal-template-soy-api")
>>
>> // commented this provided project(":apps:foundation:port
>> al-template:portal-template-soy-api")
>>
>>
>>
>> testCompile group: "com.liferay", name:
>> "com.liferay.petra.lang", version: "1.0.0"
>>
>> testCompile group: "com.liferay", name:
>> "com.liferay.registry.api", version: "1.1.0"
>>
>> testCompile group: "com.liferay", name: "org.jabsorb",
>> version: "1.3.1.LIFERAY-PATCHED-1"
>>
>> testCompile group: "com.redhat.qe", name: "json-java",
>> version: "20110202"
>>
>> testCompile group: "org.jodd", name: "jodd-bean",
>> version: "3.6.4"
>>
>> testCompile group: "org.jodd", name: "jodd-json",
>> version: "3.6.4"
>>
>> testCompile group: "org.slf4j", name: "slf4j-api",
>> version: "1.7.2"
>>
>> }
>>
>>
>>
>> transpileJS {
>>
>> srcIncludes = "**/*.js"
>>
>> }
>>
>>
>>
>> *What comes out in the MANIFEST.MF in the compiled JAR is *
>>
>>
>>
>> Manifest-Version: 1.0
>>
>> Bnd-LastModified: 1533564551530
>>
>> Bundle-ManifestVersion: 2
>>
>> Bundle-Name: Liferay Portal Portlet Bridge Soy
>>
>> Bundle-SymbolicName: com.liferay.portal.portlet.bridge.soy
>>
>> Bundle-Version: 3.2.0
>>
>> Created-By: 1.8.0_171 (Oracle Corporation)
>>
>> Export-Package: com.liferay.portal.portlet.bridge.soy;version="2.2.0";
>>
>> uses:="com.liferay.portal.kernel.portlet.bridges.mvc,com.liferay.port
>>
>> al.kernel.template,javax.portlet"
>>
>> Import-Package: com.liferay.osgi.util.service;version="[2.1,3)",com.li
>>
>> feray.petra.function;version="[1.0,2)",com.liferay.portal.kernel.io.u
>>
>> nsync;version="[6.2,7)",com.liferay.portal.kernel.json;version="[7.0,
>>
>> 8)",com.liferay.portal.kernel.log;version="[7.0,8)",com.liferay.porta
>>
>> l.kernel.model;version="[1.0,2)",com.liferay.portal.kernel.portlet;ve
>>
>> rsion="[7.5,8)",com.liferay.portal.kernel.portlet.bridges.mvc;version
>>
>> ="[1.4,2)",com.liferay.portal.kernel.service;version="[1.5,2)",com.li
>>
>> feray.portal.kernel.servlet;version="[7.2,8)",com.liferay.portal.kern
>>
>> el.servlet.taglib.aui;version="[7.0,8)",com.liferay.portal.kernel.tem
>>
>> plate;version="[7.1,8)",com.liferay.portal.kernel.theme;version="[1.1
>>
>> ,2)",com.liferay.portal.kernel.util;version="[7.10,8)",com.liferay.po
>>
>> rtal.template.soy.utils;version="[2.0,3)",com.liferay.portlet;version
>>
>> ="[1.0,2)",javax.portlet;version="[2.0,3)",javax.servlet;version="[3.
>>
>> 0,4)",javax.servlet.http;version="[3.0,4)",org.osgi.framework;version
>>
>> ="[1.8,2)"
>>
>> Javac-Debug: on
>>
>> Javac-Deprecation: 

Re: [osgi-dev] How would you implement SLF4J binding ?

[Raymond Auge via osgi-dev]

You probably want to use Java SE ServiceLoader, and then on the provider
and consumer bundles apply Service Loader Mediator [1] metadata.

This means your code is Java SE compliant as a library, but when deployed
in OSGi will get treated and backed by service registry and be wired in a
OSGi safe manner.

Check the Apache Aries SpiFly implementation of SLM [2].

[1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html
[2] http://aries.apache.org/modules/spi-fly.html

On Thu, Jul 12, 2018 at 11:03 AM, João Assunção via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello all,
>
> I'm currently trying to implement a facade for a metrics library and one
> of the objectives is to make its usage agnostic of the runtime environment.
> At my place, we have some components that are mainly used in the context of
> an OSGi container but can also be used in plain Java applications. I want
> to have three implementations of the facade where one makes use of an
> OSGi service, the other is a plain java library and the third a no-op.  In
> essence, I want the usage of this facade to be similar to SLF4J. While
> replicating the mechanism used in SLF4J I remembered someone in this
> mailing list saying that the way SLF4J binds to the implementations is a
> hack and not recommended. I agree with the hack part but to me, as a user,
> it works quite well.
> If anyone could suggest better approaches I would be very grateful.
>
> PS:
> This is what I'm trying to achieve:
>
> 
>> private final Counter aCounter = MetricsFactory.getCounter("aCounter");
>> ...
>
>
>
> Thank you.
>
> João Assunção
>
> Email: joao.assun...@exploitsys.com
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGi Logging

[Raymond Auge via osgi-dev]

Apache Felix just recently released a new feature (bundle) which sets up
OSGi Log Service and new Loggers using Logback backend. Logback can then be
used to manage all the log levels and appenders which can go to console if
you wish.

You can get a feel for what this does and how it works here [1].

Note that the Felix logback has integration tests for:

   - JBoss Logging 3.3.x
   - Commons Logging 1.2
   - JUL (Java Util Logging)
   - Log4j 1
   - Log4j 2
   - Slf4j

and obviously the OSGi Log Service.


I also plan to add this to enroute (which already uses a partial logback
solution which handles most other logging APIs.)

[1]
http://felix.apache.org/documentation/subprojects/apache-felix-logback.html

On Wed, Jul 11, 2018 at 8:20 AM, Łukasz Dywicki via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Karaf and pax logging does all what is possible in order to hide a
> LogService existence from its consumers. It’s not the best way to get
> logging right under OSGi, but definitely its a simplest one. All you need
> to do is just use slf4j as you used before. Under the hood pax provides
> slf4j package which delegates all calls to its binding.
>
> That’s why you won’t see a slf4j bundle when you list bundles under Karaf
> - its packages (among few other for commons and jul) are provided via
> pax-logging. One of ways to get logs printed to console without even a
> console appender is via log:tail command available in shell. Under the hood
> it uses a list to keep last N-th log entries received by pax.
>
> Cheers,
> Lukasz
>
> > On 11 Jul 2018, at 04:40, Paul F Fraser via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
> >
> > Somewhere in an Eclipsecon video or some other source I came across some
> info on the new logging setup which I cannot find now. It might have been
> David and Carsten, but not sure.
> >
> > The spec will be most valuable once I understand what is going on!
> >
> > Anyway, to the point, is there an approach which has a console output
> like slf4j.simple. If so, how?
> >
> > The only references I have found so far uses either Karaf and/or pax
> logging.
> >
> > Mike Francis asked for suggestions for examples and I think logging
> would be a good one. It is generally overlooked in most presentations.
> >
> > Paul Fraser
> >
> >
> > ___
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Multi-Tenancy with OSGI

[Raymond Auge via osgi-dev]

link to coordinator spec for reference

https://osgi.org/specification/osgi.cmpn/7.0.0/service.coordinator.html

- Ray

On Mon, Jul 2, 2018 at 3:33 PM, Raymond Auge 
wrote:

> Could this be handled by the coordinator? This API provides an out of band
> scope which allows "coordination" of operations, which is largely what
> multi-tenancy is about, although coordination is most commonly associated
> with something like transactions, but the axis is pretty much the same.
>
> - Ray
>
> On Mon, Jul 2, 2018 at 2:58 PM, Clément Delgrange via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>>
>>
>>
>> Hi,
>>
>> Thanks for your reply.
>>
>> Reason why I’m saying that there is very little OSGi can do is because
>> you need to decide how tenant information gets into system and how requests
>> (if any) are matched with them. In our case we had bunch of http endpoints,
>> messaging queues and databases linked together.
>> One of places which worked quite stable was powered by chain of service
>> trackers. For every configured database connection which had tenant id set
>> we published new http endpoint (daos-> services -> http endpoint to be
>> precise) which was then called by 3rd party system.
>>
>>
>> Maybe OSGI could define a standard approach for this like it does for
>> many common patterns (event, configuration, dependency injection, ...)?
>>
>> In your chain daos-> *services* -> http an ideal case would be that *services
>> *should not be aware of the tenant context and free to use any component
>> life cycle they want. If tenant specific services such as "daos" can be
>> registered by a proxy instead of the real service that implements what
>> David does in its *services *layer (a map tenant -> daos and thread
>> context) the *services *providers could be "unconscious" of the tenant
>> context.
>>
>> Cheers,
>> Clément.
>>
>>
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>>
>> On July 2, 2018 1:09 PM, Łukasz Dywicki luk...@dywicki.pl wrote:
>>
>>
>> Last year I been working for 6 months on a project to turn a system built
>> on top of osgi from single to multi tenant.
>> We used mixed approach and I can share what worked well and what caused
>> troubles.
>> First of all, there is very little OSGi itself can do for you in order to
>> support multi tenancy if your application is not handling this kind of
>> deployment scenario already.
>> I had a bunch of implicit and explicit correlations spread over codebase
>> which got documented and used properly over time. Main trouble is
>> connecting values set in configuration with data and authentication.
>> Remember that our system was a single tenant and idea to have multiple
>> entities accessing same system instance was first of all brave and second
>> of all tricky to handle properly. Additionally we were forced to keep a
>> single tenant behavior, meaning access to all data, for limited set of
>> power users.
>> Reason why I’m saying that there is very little OSGi can do is because
>> you need to decide how tenant information gets into system and how requests
>> (if any) are matched with them. In our case we had bunch of http endpoints,
>> messaging queues and databases linked together.
>> One of places which worked quite stable was powered by chain of service
>> trackers. For every configured database connection which had tenant id set
>> we published new http endpoint (daos-> services -> http endpoint to be
>> precise) which was then called by 3rd party system.
>> In other places we had a static http endpoints used by user interface
>> which, based on authentication information, was pushing this information
>> down the hill to lower layers of system. Parts of systems which were built
>> before multi tenancy got few changes in order to propagate user/tenant
>> context (thread local but not only).
>> Most difficult part was cache management which took us over a month to
>> stabilize. I think that from time perspective it would be much better to
>> write some parts of system from scratch and follow above scenario with db
>> connection because at some point we really got quite magic setup.
>> Depending on assembly/distribution we had a different set of persistence
>> and cache implementation bundles which were aware of tenant context. Thanks
>> to that we had a physical data separation.
>> Whole thing worked, and I believe it still works, but debugging and
>> maintenance of it become quite difficult.
>> Because amount of static endpoints was quite high - I think we reached
>> about 200 if not more different operations where some of them had several
>> hundred lines of code to join and analyze data before returning it to ui we
>> couldn’t manage them easily. We thought that pushing tenant context will
>> save us a time, but in the end it still requires a lot of work. Some
>> operations worked out of the box, quite many required tweaking. Some we had
>> to write from scratch using higher level apis instead of raw db access in
>> order to propagate tenant information to 

Re: [osgi-dev] Multi-Tenancy with OSGI

[Raymond Auge via osgi-dev]

Could this be handled by the coordinator? This API provides an out of band
scope which allows "coordination" of operations, which is largely what
multi-tenancy is about, although coordination is most commonly associated
with something like transactions, but the axis is pretty much the same.

- Ray

On Mon, Jul 2, 2018 at 2:58 PM, Clément Delgrange via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
>
>
> Hi,
>
> Thanks for your reply.
>
> Reason why I’m saying that there is very little OSGi can do is because you
> need to decide how tenant information gets into system and how requests (if
> any) are matched with them. In our case we had bunch of http endpoints,
> messaging queues and databases linked together.
> One of places which worked quite stable was powered by chain of service
> trackers. For every configured database connection which had tenant id set
> we published new http endpoint (daos-> services -> http endpoint to be
> precise) which was then called by 3rd party system.
>
>
> Maybe OSGI could define a standard approach for this like it does for many
> common patterns (event, configuration, dependency injection, ...)?
>
> In your chain daos-> *services* -> http an ideal case would be that *services
> *should not be aware of the tenant context and free to use any component
> life cycle they want. If tenant specific services such as "daos" can be
> registered by a proxy instead of the real service that implements what
> David does in its *services *layer (a map tenant -> daos and thread
> context) the *services *providers could be "unconscious" of the tenant
> context.
>
> Cheers,
> Clément.
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
>
> On July 2, 2018 1:09 PM, Łukasz Dywicki luk...@dywicki.pl wrote:
>
>
> Last year I been working for 6 months on a project to turn a system built
> on top of osgi from single to multi tenant.
> We used mixed approach and I can share what worked well and what caused
> troubles.
> First of all, there is very little OSGi itself can do for you in order to
> support multi tenancy if your application is not handling this kind of
> deployment scenario already.
> I had a bunch of implicit and explicit correlations spread over codebase
> which got documented and used properly over time. Main trouble is
> connecting values set in configuration with data and authentication.
> Remember that our system was a single tenant and idea to have multiple
> entities accessing same system instance was first of all brave and second
> of all tricky to handle properly. Additionally we were forced to keep a
> single tenant behavior, meaning access to all data, for limited set of
> power users.
> Reason why I’m saying that there is very little OSGi can do is because you
> need to decide how tenant information gets into system and how requests (if
> any) are matched with them. In our case we had bunch of http endpoints,
> messaging queues and databases linked together.
> One of places which worked quite stable was powered by chain of service
> trackers. For every configured database connection which had tenant id set
> we published new http endpoint (daos-> services -> http endpoint to be
> precise) which was then called by 3rd party system.
> In other places we had a static http endpoints used by user interface
> which, based on authentication information, was pushing this information
> down the hill to lower layers of system. Parts of systems which were built
> before multi tenancy got few changes in order to propagate user/tenant
> context (thread local but not only).
> Most difficult part was cache management which took us over a month to
> stabilize. I think that from time perspective it would be much better to
> write some parts of system from scratch and follow above scenario with db
> connection because at some point we really got quite magic setup.
> Depending on assembly/distribution we had a different set of persistence
> and cache implementation bundles which were aware of tenant context. Thanks
> to that we had a physical data separation.
> Whole thing worked, and I believe it still works, but debugging and
> maintenance of it become quite difficult.
> Because amount of static endpoints was quite high - I think we reached
> about 200 if not more different operations where some of them had several
> hundred lines of code to join and analyze data before returning it to ui we
> couldn’t manage them easily. We thought that pushing tenant context will
> save us a time, but in the end it still requires a lot of work. Some
> operations worked out of the box, quite many required tweaking. Some we had
> to write from scratch using higher level apis instead of raw db access in
> order to propagate tenant information to persistence layer.
> Given past experiences I got in this field I would recommend you to select
> dynamically a backend service for tenant as early as possible and dispatch
> request to it.
> Sadly OSGi service factories will not help much in this area because they
> are 

[osgi-dev] Draft of OSGi R7 CDI Specification

[Raymond Auge via osgi-dev]

(Note this message is cross-posted to several select lists.)

Hello everyone,

I wanted to announce the very first public draft of the new OSGi Enterprise
R7 CDI Integration Specification (Chapter 152) [1].

This specification, obviously, intends to bring CDI to OSGi so that one
complements the other.

CDI is of particular importance in Java because of its increasingly
intrinsic nature (just look at MicroProfile and beyond.)

OSGi CDI Integration builds from all the knowledge that has been gained
through earlier OSGi excursions into DI and IoC like blueprint [2] and
Declarative Services [3] along with CDI's powerful SPI and widely
recognized feature set to provide an uncompromising set of essential
features.

I would highly appreciate your feedback so we can take int into account
before the spec goes final.

Sincerely,
- Ray


[1] https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2018-06.pdf
[2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.blueprint.html
[3] https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Adding a Vaadin dependency causes trouble

[Raymond Auge via osgi-dev]

Regarding Vaadin, I believe that any jar which has java classes in the root
(i.e. no package) are malformed in the eyes of OSGi and bnd will complain
about them until you find a way to silence bnd (which may only be possible
using the `-fixupmessages` directive).

Sincerely,
- Ray

On Mon, Jun 18, 2018 at 7:32 AM, Paul F Fraser via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> On further investigation
> It is not related to dependencies in the reactor. It happens in modules as
> well.
> jsoup seems ok
> vaadin server 8.4.3 causes errors
> vaadin osgi integration bundle 8.4.3 causes errors
> all other vaadin bundles seem ok.
>
> Paul
>
>
> On 18/06/2018 7:05 PM, Paul F Fraser via osgi-dev wrote:
>
>> jsoup does the same thing.
>> Is there a reason some bundles can not be added as dependencies in the
>> project (reactor) pom?
>>
>> Paul
>>
>> On 17/06/2018 8:36 PM, Paul F Fraser via osgi-dev wrote:
>>
>>> Hi,
>>>
>>> Building with (new) enRoute, all is well until I add a Vaadin dependency.
>>>
>>> Video of problem https://youtu.be/MQX8ICmUHdc
>>>
>>> Part of error report 
>>>
>>> The default package '.' is not permitted by the Import-Package syntax.
>>>  This can be caused by compile errors in Eclipse because Eclipse creates
>>> valid class files regardless of compile errors.
>>> The following package(s) import from the default package
>>> [net.qnenet.qVaadinOSGi] (biz.aQute.bnd:bnd-maven-plugi
>>> n:4.0.0:bnd-process:default:process-classes)
>>>
>>> more details in attachment.
>>>
>>> Any ideas as to cause of problem?
>>>
>>> Paul Fraser
>>>
>>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Migrating existing projects to OSGi, ServiceLoader

[Raymond Auge via osgi-dev]

One other thing you could check is the starting order of your bundles. Most
things that use weaving hooks (SpiFly does) is subject to start ordering.

so make sure SpiFly is started before the bundles it weaves.

Sincerely,
- Ray

On Thu, Jun 14, 2018 at 5:57 AM, Raffaele Gambelli <
r.gambe...@hitachi-systems-cbt.com> wrote:

> Hello Raymond and thank you,
>
> yes we know exactly that it is used the  single argument ServiceLoader
> constructor and yes we think to have followed all steps showed in Apache
> Aries SPI Fly doc.
> Felix console shows our bundles and their services, so it seems all right,
> but when invoking the constructor it logs error not finding any
> implementation, here follows the ServiceLoader invocation made in the third
> party library:
>
> static {
> ServiceLoader loader = ServiceLoader.load(IUtils.class);
> Iterator iterator = loader.iterator();
> if (!iterator.hasNext()) {
> throw new ExceptionInInitializerError(
> "No implementation found for IUtils in classpath, please choose between
> dss-utils-apache-commons or dss-utils-google-guava");
> }
> impl = iterator.next();
> }
>
> Thanks, bye
>
> Raffaele Gambelli
> WebRainbow® Software Analyst & Developer
>
> Hitachi Systems CBT
> r.gambe...@hitachi-systems-cbt.com | Phone +39 051 8550 576
> 
> Via Ettore Cristoni, 84 | 40033 Casalecchio Di Reno
> www.hitachi-systems-cbt.com
>
> This email for the D.Lgs n.196/2003 (Privacy Code), may contain
> confidential and/or privileged information for the sole use of the intended
> recipient. Any review or distribution by others is strictly prohibited. If
> you are not the intended recipient, you must not use, copy, disclose or
> take any action based on this message or any information here. If you have
> received this email in error, please contact us (e-mail:
> priv...@hitachi-systems-cbt.com) by reply e-mail and delete all copies.
> Legal privilege is not waived because you have read this e-mail. Thank you
> for your cooperation.
>
>
> -Raymond Auge  ha scritto: -
> Per: Raffaele Gambelli , OSGi
> Developer Mail List 
> Da: Raymond Auge 
> Data: 13/06/2018 03.48PM
> Oggetto: Re: [osgi-dev] Migrating existing projects to OSGi, ServiceLoader
>
> Hello Raffaele,
>
> Have you read through the this page starting with http://aries.apache.org/
> modules/spi-fly.html#making-it-work
>
> Also, do you know exactly which ServiceLoader method is used in the
> Service Interface bundle? (it has to be the single argument
> ServiceLoader.load(Class) method to work with the OSGi standardized
> approach).
>
> Sincerely,
> - Ray
>
> On Wed, Jun 13, 2018 at 5:50 AM, Raffaele Gambelli via osgi-dev <
> osgi-dev@mail.osgi.org > wrote:
>
>> Hi all,
>>
>> I would like to use a third party library in my Equinox, it makes use of
>> ServiceLoader to loade an implementation coming from a different jar.
>>
>> I created a bundle containing:
>> - my code which calls third party jar
>> - the third party jar containing the Service interface
>> - the third party jar containing the Service implementation
>> - the require and provide capability as suggested in Aries SPI Fly
>>
>> I can see in my Felix console that bundle is active and I can see its
>> service id, nevertheless when I invoke the getInstance of my class which in
>> turn calls the third party code which calls ServiceLoader.load, the
>> concrete class is not found :-(
>>
>> Any help woulb be appreciated, thanks in advance, bye
>>
>> Raffaele Gambelli
>> WebRainbow® Software Analyst & Developer
>>
>> Hitachi Systems CBT
>> r.gambelli@hitachi-systems- cbt.com 
>> | Phone +39 051 8550 576
>> 
>> Via Ettore Cristoni
>> ,
>> 84 | 40033 Casalecchio Di Reno
>> www.hitachi-systems-cbt.com
>>
>> This email for the D.Lgs n.196/2003 (Privacy Code), may contain
>> confidential and/or privileged information for the sole use of the intended
>> recipient. Any review or distribution by others is strictly prohibited. If
>> you are not the intended recipient, you must not use, copy, disclose or
>> take any action based on this message or any information here. If you have
>> received this email in error, please contact us (e-mail:
>> priv...@hitachi-systems-cbt.com) by reply e-mail and delete all copies.
>> Legal privilege is not waived because you have read this e-mail. Thank you
>> for your cooperation.
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect  *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
*Raymond Augé* 
 

Re: [osgi-dev] Migrating existing projects to OSGi, ServiceLoader

[Raymond Auge via osgi-dev]

Hello Raffaele,

Have you read through the this page starting with
http://aries.apache.org/modules/spi-fly.html#making-it-work

Also, do you know exactly which ServiceLoader method is used in the Service
Interface bundle? (it has to be the single argument
ServiceLoader.load(Class) method to work with the OSGi standardized
approach).

Sincerely,
- Ray

On Wed, Jun 13, 2018 at 5:50 AM, Raffaele Gambelli via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi all,
>
> I would like to use a third party library in my Equinox, it makes use of
> ServiceLoader to loade an implementation coming from a different jar.
>
> I created a bundle containing:
> - my code which calls third party jar
> - the third party jar containing the Service interface
> - the third party jar containing the Service implementation
> - the require and provide capability as suggested in Aries SPI Fly
>
> I can see in my Felix console that bundle is active and I can see its
> service id, nevertheless when I invoke the getInstance of my class which in
> turn calls the third party code which calls ServiceLoader.load, the
> concrete class is not found :-(
>
> Any help woulb be appreciated, thanks in advance, bye
>
> Raffaele Gambelli
> WebRainbow® Software Analyst & Developer
>
> Hitachi Systems CBT
> r.gambe...@hitachi-systems-cbt.com | Phone +39 051 8550 576
> Via Ettore Cristoni, 84 | 40033 Casalecchio Di Reno
> www.hitachi-systems-cbt.com
>
> This email for the D.Lgs n.196/2003 (Privacy Code), may contain
> confidential and/or privileged information for the sole use of the intended
> recipient. Any review or distribution by others is strictly prohibited. If
> you are not the intended recipient, you must not use, copy, disclose or
> take any action based on this message or any information here. If you have
> received this email in error, please contact us (e-mail:
> priv...@hitachi-systems-cbt.com) by reply e-mail and delete all copies.
> Legal privilege is not waived because you have read this e-mail. Thank you
> for your cooperation.
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Where is repo01

[Raymond Auge via osgi-dev]

It's just the synthetic name given to the repo created from that index
file. We could probably clean that up to make the name more insightful.
Maybe create an issue so we don't forget?

- Ray

On Thu, Jun 7, 2018, 21:27 Paul F Fraser via osgi-dev, <
osgi-dev@mail.osgi.org> wrote:

> enRoute app module has a standalone repo called repo01.
>
> I cannot find where the relationship between rep01 and target/index.xml is
> established.
>
> Any clues?
>
> Paul
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Script for auto-generations standalone enRoute application executable

[Raymond Auge via osgi-dev]

1) if you are in a bndtools workspace:

say you have a project with a bndrun file like so:

workspace-root/projectA/my.bndrun

then execute the gradle command:

cd workspace-root
./gradlew :projectA:export.my

2) if you are in a maven project using the bnd-export-maven-plugin [1]:

then execute the following:

mvn bnd-export:export

3) if you are in a gradle project using the none-workspace bnd gradle
plugin [2]:

Create and execute an export [3] task

Sincerely,
- Ray

[1]
https://github.com/bndtools/bnd/blob/master/maven/bnd-export-maven-plugin/README.md
[2]
https://github.com/bndtools/bnd/tree/master/biz.aQute.bnd.gradle#gradle-plugin-for-non-workspace-builds
[3]
https://github.com/bndtools/bnd/tree/master/biz.aQute.bnd.gradle#create-a-task-of-the-export-type


On Mon, Mar 5, 2018 at 12:49 PM, Randy Leonard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> To all:
>
> Regarding the creation of standalone executables for enRoute projects:
>
>- Documentation is given here: http://enroute.osgi.org/
>tutorial_base/700-deploy.html
>- Unfortunately, these are manual instructions for exporting from
>within Eclipse
>
>
> My request is for instructions to generate standalone executables via
> command line script.  It would be great to automate this task.
>
> Thanks in advance
> Randy
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Apache cxf: add authorization header in Client

[Raymond Auge via osgi-dev]

On Mar 1, 2018 3:49 PM, "Łukasz Dywicki" <luk...@dywicki.pl> wrote:

While this mailing list is not CXF specific, there are other OSGI-related
things which are discussed here such enroute.


Granted! I'm just trying to manage expectations. :)

Sincerely,
- Ray


@Michael - it really depends on how you create client - if you have any
factory bean? Maybe a bus instance? In general all CXF invocations, whether
its server or client side, are surrounded by interceptors and you can
modify request/response using them. If you use JAX-RS stub you can also use
client side filter to append headers (using jaxrs providers).

For more detailed answers - you may need to look cxf mailing list. Hope
that this helps you to move forward.

Cheers,
Lukasz


On 1 Mar 2018, at 20:45, Raymond Auge via osgi-dev <osgi-dev@mail.osgi.org>
wrote:

In an effort to not let your question go unanswered I'm going to just say
that this list is unlikely to be the place to find your answer.

This sounds like a CXF specific question. Have you asked this over at the
CXF user mailing list?

Sincerely,
- Ray

On Thu, Mar 1, 2018 at 1:43 PM, Michael Wirth via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I’m using Apache CXF in an OSGi-Application to call REST-Services provided
> from another (spring) application.
> I give the path-interface (generated with swagger) to my
> osgi-client-appliation. While runtime, Apache CXF generates the client
> proxy interface, calls the REST-Service and deserialize the returned json
> to the swagger generated objects. All works fine :-)
> Now I miss one thing. For Authorization I have to add a header. Because I
> do not have the ‚Client‘-Instanze (WebTarget for instance) I’m not able to
> add an header. Is there some property, configuration or a service which can
> be used?
>
> Best Regards,
> Michael
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev




-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
(@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Apache cxf: add authorization header in Client

[Raymond Auge via osgi-dev]

In an effort to not let your question go unanswered I'm going to just say
that this list is unlikely to be the place to find your answer.

This sounds like a CXF specific question. Have you asked this over at the
CXF user mailing list?

Sincerely,
- Ray

On Thu, Mar 1, 2018 at 1:43 PM, Michael Wirth via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I’m using Apache CXF in an OSGi-Application to call REST-Services provided
> from another (spring) application.
> I give the path-interface (generated with swagger) to my
> osgi-client-appliation. While runtime, Apache CXF generates the client
> proxy interface, calls the REST-Service and deserialize the returned json
> to the swagger generated objects. All works fine :-)
> Now I miss one thing. For Authorization I have to add a header. Because I
> do not have the ‚Client‘-Instanze (WebTarget for instance) I’m not able to
> add an header. Is there some property, configuration or a service which can
> be used?
>
> Best Regards,
> Michael
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev




-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Proliferation of DS Components and References

[Raymond Auge via osgi-dev]

If you have thousands of DS components in one bundle you are probably doing
something wrong. Clearly your bundle is not a cohesive unit of modularity.

The largest DS based bundles I've seen tend to max out at around 50
components (even that is extreme).

Our largest bundle, a bundle which provides a search engine implementation,
based on Elastic Search, which is a complex bundle due to tons of touch
points in configuring elastic search is 57 components. It can be argued
that this bundle is a case to be modularized even more... but alas the
problem is elastic search internals.

Of the hundreds and hundreds (i'm not even kidding) of bundles we produce
the vast majority contain about 3-5 components.

- Ray

On Mon, Jan 22, 2018 at 3:45 PM, Christian Schneider via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I always simply use slf4j and a suitable logger implementation.
> Pax logging works quite well. The main advantage is that your logging
> works exactly like outside of OSGi.
>
> Internally it is maybe not the cleanest way but as a user this works
> really nicely.
>
> Christian
>
> 2018-01-22 7:06 GMT+01:00 Tanvir via osgi-dev :
>
>>
>> In DS, for accessing a service reference, the class has to be a
>> Component. That means to access common  services, such as log service,
>> all classes becomes Components. In the following example, to access log
>> service all classes in Emp bundle became Components.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *@Component public class Emp implements EmpService {   LogService log
>> @Reference (cardinality = ReferenceCardinality.MANDATORY)   void
>> setLogService(LogService log) { this.log = log; }   } @Component public
>> class EmpAddress  {   LogService log   @Reference (cardinality =
>> ReferenceCardinality.MANDATORY)   void setLogService(LogService log) {
>> this.log = log; } } @Component public class EmpPayroll  {   LogService log
>>   @Reference (cardinality = ReferenceCardinality.MANDATORY)   void
>> setLogService(LogService log) { this.log = log; } }*
>>  
>>
>> *Question: *Is there a way to solve this proliferation of DS Components
>> and References?
>>
>> *Solution A*: We can factor out reference code and move them to a
>> RefManager Component. Also maintain a shared static variable to LogService
>> for all other classes.
>>
>> @Component
>> public class RefManager {
>>   *static *LogService log
>>   @Reference (cardinality = ReferenceCardinality.MANDATORY)
>>   void setLogService(LogService log) { this.log = log; }
>>  *static* LogService  getLogger() { return log;}}
>>
>> @Component
>> public class Emp implements EmpService {
>>..
>>RefManager. getLogger.log();
>> }
>>
>> public class EmpAddress  {
>>  ..
>>RefManager. getLogger.log();
>> }
>> public class EmpPayroll  {
>>..
>>RefManager. getLogger.log();
>> }
>>
>>
>> *Problem:* Now we can end up with null LogService reference even though
>> LogService ref  is MANDATORY . E.g. if EmpService  is activated before
>> RefManager  or LogService, it gets null LogService ref.
>>
>> *Question:* If we set LogService and RefManager as immediate components
>> (RefManager  is immediate  by default for  being a Component), is it
>> guaranteed that  they will be activated before EmpService?
>>
>> *Solution B: *
>> Another solution for the above problem is to view LogService as OPTIONAL.
>> However, an optional reference can be null requiring a null check. That
>> means each use of Log Service  api require the following null check.
>>
>> If (log!=null) log.log(..);
>>
>> *Problem: * Considering that log apis are heavily used, this seems
>> tedious and error-prone. Is there a better way of using OPTIONAL reference?
>>
>>
>>
>>
>> --
>> Best,
>> Tanvir
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGI bundles install on IBM Liberty

[Raymond Auge via osgi-dev]

t;
>
>
>
>
> On Tue, Dec 5, 2017 at 12:09 PM, Peter Kriens <peter.kri...@aqute.biz>
> wrote:
>
> I’ve added these points to the Resolve App Note. https://github.com/osgi/
> osgi.enroute.site/blob/gh-pages/_appnotes/resolving.md
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osgi_osgi.enroute.site_blob_gh-2Dpages_-5Fappnotes_resolving.md=DwMFaQ=ewHkv9vLloTwhsKn5d4bTdoqsmBfyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U=wKHHp1xupEN1UoR2CPDlg9US2Vs3om5ld5YqSsWMQX8=HH8Gw-cn_T-kd6gx_j2BbQ-yDw3Q20TuuUT5AHmRGgs=5dgDiilIAAv4T5Pi2QAhoAIKfDx6C4voPPFXS-SftOE=>
>
>
>
> Awesome!
>
>
>
> Thanks Peter!
>
> - Ray
>
>
>
>
>
> Kind regards,
>
>
>
> Peter Kriens
>
>
>
>
>
> On 5 Dec 2017, at 15:46, Raymond Auge via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
>
>
>
>
>
>
> On Tue, Dec 5, 2017 at 9:42 AM, Raymond Auge <raymond.a...@liferay.com>
> wrote:
>
> Hey Kevin,
>
> Here's what I could find: "Deploying OSGi applications to Liberty" [1]
>
> Now, this may be a little complicated by the fact that the enroute model
> tends to guide you to resolve a whole runtime. Meanwhile with openliberty
> or WebSphere Liberty you are deploying into a container which already
> "contains a lot of features".
>
> The crux of the issue becomes "resolving only what you need to deploy".
> This is were the complication comes in. What you need at that point is a
> way to "find out what the container provides in a way that you can use this
> during resolve time".
>
> Currently the way to do that is to create what's called a "distro" jar of
> the target container. This distro is a JAR file which provides all the
> capabilities that the target container provides at one point in time.
>
> How do you create a distro?
>
> *1)* install the bnd remote agent bundle [2] in the target container
> runtime. This will automatically open a local socket on a default port used
> to the remote cli next.
>
> *2)* execute the following command using the bnd cli [3]:
>
>
>
> bnd remote distro -o ws.liberty-5.6.7.jar ws.liberty 5.6.7
>
>
>
> FYI, this "bnd" command is just an alias for invoking the executable bnd
> jar: "java -jar  remote distro ..."
>
>
>
>
>
> *3)* take the jar "ws.liberty-5.6.7.jar" create by that and place it into
> the maybe the directory containing the bndrun file which is used to resolve
> your deployment jars.
>
> *4)* in the bndrun file add:
>
> -distro: file:${.}/ws.liberty-5.6.7.jar
>
> *5)* resolve... the result of the resolve should be the set of bundles
> you need to install to openliberty.
>
> What you need to bare in mind is that the distro file needs to be
> regenerated each time the liberty installation changes in any significant
> way otherwise you won't get the real state of the system needed to resolve
> against.
>
>
>
> I hope that makes some sense.
>
>
>
> Let me know if the instructions were clear and if it worked.
>
>
>
> - Ray
>
>
> [1] https://www.ibm.com/support/knowledgecenter/en/SSEQTP_
> liberty/com.ibm.websphere.wlp.doc/ae/twlp_dep_osgi.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEQTP-5Fliberty_com.ibm.websphere.wlp.doc_ae_twlp-5Fdep-5Fosgi.html=DwMFaQ=ewHkv9vLloTwhsKn5d4bTdoqsmBfyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U=wKHHp1xupEN1UoR2CPDlg9US2Vs3om5ld5YqSsWMQX8=HH8Gw-cn_T-kd6gx_j2BbQ-yDw3Q20TuuUT5AHmRGgs=nvLyZLi-u2zZxyZDABhidNPzNiG4CP48UqizxJvO0uM=>
>
> [2] http://search.maven.org/remotecontent?filepath=biz/
> aQute/bnd/biz.aQute.remote.agent/3.5.0/biz.aQute.remote.agent-3.5.0.jar
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__search.maven.org_remotecontent-3Ffilepath-3Dbiz_aQute_bnd_biz.aQute.remote.agent_3.5.0_biz.aQute.remote.agent-2D3.5.0.jar=DwMFaQ=ewHkv9vLloTwhsKn5d4bTdoqsmBfyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U=wKHHp1xupEN1UoR2CPDlg9US2Vs3om5ld5YqSsWMQX8=HH8Gw-cn_T-kd6gx_j2BbQ-yDw3Q20TuuUT5AHmRGgs=x12qd0weK3DYeQDv9V-GpTsZU5_Ms2xgIfXtjlSHFNY=>
>
> [3] http://search.maven.org/remotecontent?filepath=biz/
> aQute/bnd/biz.aQute.bnd/3.5.0/biz.aQute.bnd-3.5.0.jar
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__search.maven.org_remotecontent-3Ffilepath-3Dbiz_aQute_bnd_biz.aQute.bnd_3.5.0_biz.aQute.bnd-2D3.5.0.jar=DwMFaQ=ewHkv9vLloTwhsKn5d4bTdoqsmBfyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U=wKHHp1xupEN1UoR2CPDlg9US2Vs3om5ld5YqSsWMQX8=HH8Gw-cn_T-kd6gx_j2BbQ-yDw3Q20TuuUT5AHmRGgs=ha4v1OTeYF5iWCrc47eylrZCM6UuAAFW5cVwrALmI8Q=>
>
>
>
> On Tue, Dec 5, 2017 at 9:11 AM, Matthews, Kevin via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi Tim,

Re: [osgi-dev] Component Life Cycle: When are DS components/services registered

[Raymond Auge via osgi-dev]

On Sun, Dec 10, 2017 at 11:45 AM, Konrad Windszus  wrote:

> Hi Ray,
> thanks for confirming. So the relation between bundle life cycle and
> component lifecycle is clear now.
> The only remaining question is now:
>
> Is it valid to assume that once a DS component is registered, the services
>> which are implemented by this component are registered as well or does it
>> happen only afterwards?
>
> Can you quickly comment on that one as well?
>

If the component is enabled and it's references are satisfied, then its
service will be published, even if it is lazy, because it is published
using a service factory which instantiates the service instance only when
requested.


>
> Now when you're talking about "remote" is it that you can't use RSA
> (Remote Service Admin)? Because your description is what RSA is intended to
> address.
>
> Basically I need that in an IT being executed with maven-failsafe-plugin.
> That IT connects to an OSGi container via HTTP. It also starts the OSGi
> container beforehand. Now the only missing piece is the trigger, which
> tells me that all necessary services are registered for the HTTP-based IT
> to execute.
> I am relying on the ReST interface being provided by the Felix Web Console
> to check for bundle and component state.
>

I'm not familiar with what rest services are provided by webconsole, but if
you can observe "services" then you should see a service reference for the
component and when you see that, the component should be ready for use.
However, do note that a lazy component doesn't activate until first
requested... and it may fail during activation. So take note of that.

Sincerely,
- Ray


>
> Konrad
>
>
> Now when you're talking about "remote" is it that you can't use RSA
> (Remote Service Admin)? Because your description is what RSA is intended to
> address.
>
> Sincerely,
> - Ray
>
> On Sun, Dec 10, 2017 at 5:55 AM, Konrad Windszus via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> And one more related question:
>> Is it valid to assume that once a DS component is registered, the
>> services which are implemented by this component are registered as well or
>> does it happen only afterwards?
>>
>> > On 10. Dec 2017, at 11:52, Konrad Windszus via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>> >
>> > Hi,
>> > I have a question about the component life cycle of DS components and
>> the relation to the containing bundle's life cycle.
>> >
>> > According to OSGi Comp R6, 112.5.1 "the life cycle of a component is
>> contained within the life cycle of its bundle". But is it a valid
>> assumption that all enabled components are registered before the containing
>> bundle becomes active? Is the same true for services? Or does the
>> registration of the services/components only happen after the bundle has
>> switched to state active?
>> >
>> > The life cycle example at 112.5.17 unfortunately is also very vague in
>> that regard as it only talks about "bundle started" event.
>> >
>> > I need to know this information in the context of executing an IT
>> against a remote OSGi container. The IT should only start to execute, once
>> a particular (lazy) component is registered. Is it enough to wait for the
>> Bundle status "Active", or do I really have to check the status of this
>> particular component?
>> >
>> > Thanks in advance,
>> > Konrad
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > OSGi Developer Mail List
>> > osgi-dev@mail.osgi.org
>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Component Life Cycle: When are DS components/services registered

[Raymond Auge via osgi-dev]

Compendium Section 112.5.1 states:

> A component must first be enabled before it can be used. A component
cannot be enabled unless the
> component's bundle is started. See Starting Bundles in OSGi Core Release
6. All components in a bun-
> dle become disabled when the bundle is stopped.

Core Section 4.4.5 states:

> Once a bundle is started, a bundle must be activated, see Activation on
page 109, to give control
> to the bundle so that it can initialize.

Note that SCR is not required to do work in a "synchronous" way. It simply
cannot do anything before the bundle has started. So you can't know that a
"component is active" when the bundle is "started". You have to check the
component itself because there are other factors involved in enabling a
component. There's the service
"org.osgi.service.component.runtime.ServiceComponentRuntime" which lets you
introspect components.

Now when you're talking about "remote" is it that you can't use RSA (Remote
Service Admin)? Because your description is what RSA is intended to address.

Sincerely,
- Ray

On Sun, Dec 10, 2017 at 5:55 AM, Konrad Windszus via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> And one more related question:
> Is it valid to assume that once a DS component is registered, the services
> which are implemented by this component are registered as well or does it
> happen only afterwards?
>
> > On 10. Dec 2017, at 11:52, Konrad Windszus via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
> >
> > Hi,
> > I have a question about the component life cycle of DS components and
> the relation to the containing bundle's life cycle.
> >
> > According to OSGi Comp R6, 112.5.1 "the life cycle of a component is
> contained within the life cycle of its bundle". But is it a valid
> assumption that all enabled components are registered before the containing
> bundle becomes active? Is the same true for services? Or does the
> registration of the services/components only happen after the bundle has
> switched to state active?
> >
> > The life cycle example at 112.5.17 unfortunately is also very vague in
> that regard as it only talks about "bundle started" event.
> >
> > I need to know this information in the context of executing an IT
> against a remote OSGi container. The IT should only start to execute, once
> a particular (lazy) component is registered. Is it enough to wait for the
> Bundle status "Active", or do I really have to check the status of this
> particular component?
> >
> > Thanks in advance,
> > Konrad
> >
> >
> >
> >
> >
> > ___
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGI bundles install on IBM Liberty

[Raymond Auge via osgi-dev]

On Tue, Dec 5, 2017 at 12:41 PM, Matthews, Kevin <
kevin.matth...@firstdata.com> wrote:

> Hi Raymond, I see you work for liferay. I actually build an document
> management application using liferay 7.0 GA3 to replace our existing
> Repsoitory Manager. Using Liferay 7.0 gave me the inspiration in learning
> more about OSGI. I like also the fact Liferay uses gradle to build bundle
> with or without blade :)  . I am trying to emulate the same thing I did
> with Liferay with our other Java/Spring applications .
>

Glad to be of inspiration! ;)

> "... standing on ye sholders of Giants." - Isaac Newton

- Ray


>
>
> *From:* Raymond Auge [mailto:raymond.a...@liferay.com]
> *Sent:* Tuesday, December 05, 2017 12:32 PM
> *To:* Peter Kriens
> *Cc:* OSGi Developer Mail List; Matthews, Kevin
> *Subject:* Re: [osgi-dev] OSGI bundles install on IBM Liberty
>
>
>
> I had actually made a mistake in the suggested `-distro` instruction.
>
>
>
> I've corrected it in the app note.
>
> - Ray
>
>
>
> On Tue, Dec 5, 2017 at 12:19 PM, Raymond Auge <raymond.a...@liferay.com>
> wrote:
>
>
>
>
>
> On Tue, Dec 5, 2017 at 12:09 PM, Peter Kriens <peter.kri...@aqute.biz>
> wrote:
>
> I’ve added these points to the Resolve App Note. https://github.com/osgi/
> osgi.enroute.site/blob/gh-pages/_appnotes/resolving.md
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osgi_osgi.enroute.site_blob_gh-2Dpages_-5Fappnotes_resolving.md=DwMFaQ=ewHkv9vLloTwhsKn5d4bTdoqsmBfyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U=wKHHp1xupEN1UoR2CPDlg9US2Vs3om5ld5YqSsWMQX8=HH8Gw-cn_T-kd6gx_j2BbQ-yDw3Q20TuuUT5AHmRGgs=5dgDiilIAAv4T5Pi2QAhoAIKfDx6C4voPPFXS-SftOE=>
>
>
>
> Awesome!
>
>
>
> Thanks Peter!
>
> - Ray
>
>
>
>
>
> Kind regards,
>
>
>
> Peter Kriens
>
>
>
>
>
> On 5 Dec 2017, at 15:46, Raymond Auge via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
>
>
>
>
>
>
> On Tue, Dec 5, 2017 at 9:42 AM, Raymond Auge <raymond.a...@liferay.com>
> wrote:
>
> Hey Kevin,
>
> Here's what I could find: "Deploying OSGi applications to Liberty" [1]
>
> Now, this may be a little complicated by the fact that the enroute model
> tends to guide you to resolve a whole runtime. Meanwhile with openliberty
> or WebSphere Liberty you are deploying into a container which already
> "contains a lot of features".
>
> The crux of the issue becomes "resolving only what you need to deploy".
> This is were the complication comes in. What you need at that point is a
> way to "find out what the container provides in a way that you can use this
> during resolve time".
>
> Currently the way to do that is to create what's called a "distro" jar of
> the target container. This distro is a JAR file which provides all the
> capabilities that the target container provides at one point in time.
>
> How do you create a distro?
>
> *1)* install the bnd remote agent bundle [2] in the target container
> runtime. This will automatically open a local socket on a default port used
> to the remote cli next.
>
> *2)* execute the following command using the bnd cli [3]:
>
>
>
> bnd remote distro -o ws.liberty-5.6.7.jar ws.liberty 5.6.7
>
>
>
> FYI, this "bnd" command is just an alias for invoking the executable bnd
> jar: "java -jar  remote distro ..."
>
>
>
>
>
> *3)* take the jar "ws.liberty-5.6.7.jar" create by that and place it into
> the maybe the directory containing the bndrun file which is used to resolve
> your deployment jars.
>
> *4)* in the bndrun file add:
>
> -distro: file:${.}/ws.liberty-5.6.7.jar
>
> *5)* resolve... the result of the resolve should be the set of bundles
> you need to install to openliberty.
>
> What you need to bare in mind is that the distro file needs to be
> regenerated each time the liberty installation changes in any significant
> way otherwise you won't get the real state of the system needed to resolve
> against.
>
>
>
> I hope that makes some sense.
>
>
>
> Let me know if the instructions were clear and if it worked.
>
>
>
> - Ray
>
>
> [1] https://www.ibm.com/support/knowledgecenter/en/SSEQTP_
> liberty/com.ibm.websphere.wlp.doc/ae/twlp_dep_osgi.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSEQTP-5Fliberty_com.ibm.websphere.wlp.doc_ae_twlp-5Fdep-5Fosgi.html=DwMFaQ=ewHkv9vLloTwhsKn5d4bTdoqsmBfyfooQX5O7EQLv5TtBZ1CwcvjU063xndfqI8U=wKHHp1xupEN1UoR2CPDlg9US2Vs3om5ld5YqSsWMQX8=HH8Gw-cn_T-kd6gx_j2BbQ-yDw3Q20TuuUT5AHmRGgs=nvLyZLi-u2zZxyZDAB

Re: [osgi-dev] OSGI bundles install on IBM Liberty

[Raymond Auge via osgi-dev]

I had actually made a mistake in the suggested `-distro` instruction.

I've corrected it in the app note.

- Ray

On Tue, Dec 5, 2017 at 12:19 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:

>
>
> On Tue, Dec 5, 2017 at 12:09 PM, Peter Kriens <peter.kri...@aqute.biz>
> wrote:
>
>> I’ve added these points to the Resolve App Note. https://github.com/osgi/
>> osgi.enroute.site/blob/gh-pages/_appnotes/resolving.md
>>
>
> Awesome!
>
> Thanks Peter!
> - Ray
>
>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 5 Dec 2017, at 15:46, Raymond Auge via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>
>>
>> On Tue, Dec 5, 2017 at 9:42 AM, Raymond Auge <raymond.a...@liferay.com>
>> wrote:
>>
>>> Hey Kevin,
>>>
>>> Here's what I could find: "Deploying OSGi applications to Liberty" [1]
>>>
>>> Now, this may be a little complicated by the fact that the enroute model
>>> tends to guide you to resolve a whole runtime. Meanwhile with openliberty
>>> or WebSphere Liberty you are deploying into a container which already
>>> "contains a lot of features".
>>>
>>> The crux of the issue becomes "resolving only what you need to deploy".
>>> This is were the complication comes in. What you need at that point is a
>>> way to "find out what the container provides in a way that you can use this
>>> during resolve time".
>>>
>>> Currently the way to do that is to create what's called a "distro" jar
>>> of the target container. This distro is a JAR file which provides all the
>>> capabilities that the target container provides at one point in time.
>>>
>>> How do you create a distro?
>>>
>>> *1)* install the bnd remote agent bundle [2] in the target container
>>> runtime. This will automatically open a local socket on a default port used
>>> to the remote cli next.
>>> *2)* execute the following command using the bnd cli [3]:
>>>
>>> bnd remote distro -o ws.liberty-5.6.7.jar ws.liberty 5.6.7
>>>
>>
>> FYI, this "bnd" command is just an alias for invoking the executable bnd
>> jar: "java -jar  remote distro ..."
>>
>>
>>>
>>> *3)* take the jar "ws.liberty-5.6.7.jar" create by that and place it
>>> into the maybe the directory containing the bndrun file which is used to
>>> resolve your deployment jars.
>>> *4)* in the bndrun file add:
>>>
>>> -distro: file:${.}/ws.liberty-5.6.7.jar
>>>
>>> *5)* resolve... the result of the resolve should be the set of bundles
>>> you need to install to openliberty.
>>>
>>> What you need to bare in mind is that the distro file needs to be
>>> regenerated each time the liberty installation changes in any significant
>>> way otherwise you won't get the real state of the system needed to resolve
>>> against.
>>>
>>> I hope that makes some sense.
>>>
>>> Let me know if the instructions were clear and if it worked.
>>>
>>> - Ray
>>>
>>> [1] https://www.ibm.com/support/knowledgecenter/en/SSEQTP_libert
>>> y/com.ibm.websphere.wlp.doc/ae/twlp_dep_osgi.html
>>> [2] http://search.maven.org/remotecontent?filepath=biz/aQute/bnd
>>> /biz.aQute.remote.agent/3.5.0/biz.aQute.remote.agent-3.5.0.jar
>>> [3] http://search.maven.org/remotecontent?filepath=biz/aQute/bnd
>>> /biz.aQute.bnd/3.5.0/biz.aQute.bnd-3.5.0.jar
>>>
>>>
>>> On Tue, Dec 5, 2017 at 9:11 AM, Matthews, Kevin via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>>> Hi Tim, a quick question. I am learning OSGI from osgi en route
>>>> samples. In our environment, our monolithic application runs on  IBM
>>>> Websphere Liberty but I am doing a POC to convert to modular architecture
>>>> then bundles to run on Websphere Liberty. Can I build bundles using BND en
>>>> route from my eclipse and install these bundles on a Liberty server? I know
>>>> liberty uses the equinox OSGI container.
>>>> The information in this message may be proprietary and/or confidential,
>>>> and protected from disclosure. If the reader of this message is not the
>>>> intended recipient, or an employee or agent responsible for delivering this
>>>> message to the intended recipient, you are hereby notified that any
>>>> dissemination, distribution or co

Re: [osgi-dev] OSGI bundles install on IBM Liberty

[Raymond Auge via osgi-dev]

On Tue, Dec 5, 2017 at 9:42 AM, Raymond Auge 
wrote:

> Hey Kevin,
>
> Here's what I could find: "Deploying OSGi applications to Liberty" [1]
>
> Now, this may be a little complicated by the fact that the enroute model
> tends to guide you to resolve a whole runtime. Meanwhile with openliberty
> or WebSphere Liberty you are deploying into a container which already
> "contains a lot of features".
>
> The crux of the issue becomes "resolving only what you need to deploy".
> This is were the complication comes in. What you need at that point is a
> way to "find out what the container provides in a way that you can use this
> during resolve time".
>
> Currently the way to do that is to create what's called a "distro" jar of
> the target container. This distro is a JAR file which provides all the
> capabilities that the target container provides at one point in time.
>
> How do you create a distro?
>
> *1)* install the bnd remote agent bundle [2] in the target container
> runtime. This will automatically open a local socket on a default port used
> to the remote cli next.
> *2)* execute the following command using the bnd cli [3]:
>
> bnd remote distro -o ws.liberty-5.6.7.jar ws.liberty 5.6.7
>

FYI, this "bnd" command is just an alias for invoking the executable bnd
jar: "java -jar  remote distro ..."


>
> *3)* take the jar "ws.liberty-5.6.7.jar" create by that and place it into
> the maybe the directory containing the bndrun file which is used to resolve
> your deployment jars.
> *4)* in the bndrun file add:
>
> -distro: file:${.}/ws.liberty-5.6.7.jar
>
> *5)* resolve... the result of the resolve should be the set of bundles
> you need to install to openliberty.
>
> What you need to bare in mind is that the distro file needs to be
> regenerated each time the liberty installation changes in any significant
> way otherwise you won't get the real state of the system needed to resolve
> against.
>
> I hope that makes some sense.
>
> Let me know if the instructions were clear and if it worked.
>
> - Ray
>
> [1] https://www.ibm.com/support/knowledgecenter/en/SSEQTP_
> liberty/com.ibm.websphere.wlp.doc/ae/twlp_dep_osgi.html
> [2] http://search.maven.org/remotecontent?filepath=biz/
> aQute/bnd/biz.aQute.remote.agent/3.5.0/biz.aQute.remote.agent-3.5.0.jar
> [3] http://search.maven.org/remotecontent?filepath=biz/
> aQute/bnd/biz.aQute.bnd/3.5.0/biz.aQute.bnd-3.5.0.jar
>
>
> On Tue, Dec 5, 2017 at 9:11 AM, Matthews, Kevin via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hi Tim, a quick question. I am learning OSGI from osgi en route samples.
>> In our environment, our monolithic application runs on  IBM Websphere
>> Liberty but I am doing a POC to convert to modular architecture then
>> bundles to run on Websphere Liberty. Can I build bundles using BND en route
>> from my eclipse and install these bundles on a Liberty server? I know
>> liberty uses the equinox OSGI container.
>> The information in this message may be proprietary and/or confidential,
>> and protected from disclosure. If the reader of this message is not the
>> intended recipient, or an employee or agent responsible for delivering this
>> message to the intended recipient, you are hereby notified that any
>> dissemination, distribution or copying of this communication is strictly
>> prohibited. If you have received this communication in error, please notify
>> First Data immediately by replying to this message and deleting it from
>> your computer.
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] making an existing interface method default causes MINOR baseline change

[Raymond Auge via osgi-dev]

Thanks All!

- Ray

On Tue, Dec 5, 2017 at 9:03 AM, Timothy Ward <tim.w...@paremus.com> wrote:

> No, because other people may be implementing the Foo interface in their
> bundles.
>
> Tim
>
>
> On 5 Dec 2017, at 12:42, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> Does it matter that I'm getting a MINOR change while Foo and Bar are in
> the same, exported package?
>
> - Ray
>
> On Dec 5, 2017 03:05, "Peter Kriens via osgi-dev" <osgi-dev@mail.osgi.org>
> wrote:
>
>> Great minds think alike (and it helped we were both in this discussion)
>> :-)
>>
>> P
>>
>> On 5 Dec 2017, at 09:03, Timothy Ward via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> Ray - I assume that you’re asking why this is a MINOR change, rather than
>> a MICRO change? It’s obviously not a major change because the method exists
>> with the same signature everywhere both before and after.
>>
>> The reason that it’s a MINOR change is to do with the forward (rather
>> than backward) guarantees that the semantic versioning rules must make.
>>
>> In your example you end up deleting the original doFoo() implementation
>> from the Bar class. From this point on the Bar class has no knowledge of
>> this method, and the implementation *must* come from either a super type
>> (there aren’t any) or as a default method on the implemented interface. If
>> this doesn’t happen then the whole type hierarchy of Bar is broken - the
>> concrete types which subclass Bar simply don’t have an implementation of
>> the interface method that the contract says they must have!
>>
>> The only way to enforce this is to ensure that the updated Bar class
>> imports a version of Foo which is guaranteed to have the “default doFoo()
>> feature”. In semantic versioning new features always require at least a
>> MINOR bump so that people can reliably depend on them (depending on a MICRO
>> is not a good idea). That is what is happening here.
>>
>> Tim
>>
>> PS - I have just seen Peter’s email come in, which thankfully agrees with
>> what I’m saying!
>>
>> On 5 Dec 2017, at 06:43, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> Hi,
>>
>> IMHO it is a MINOR change because it is not a breaking change. J
>>
>> With that change neither implementations of the Foo interface, nor
>> classes that extend the abstract Bar class will break.
>>
>> Implementations of the Foo interface can still implement the doFoo()
>> method and by doing this override the default behavior. Overriding a
>> default is not a breaking change as you neither add a new public method or
>> field, you just give a default implementation.
>>
>> Classes that extend Bar did not need to implement doFoo() before, as it
>> was implemented in Bar. Removing that method would be typically a breaking
>> change. But you are moving it as default method to the Foo interface.
>> Therefore Bar still has the doFoo() method implemented, as it is provided
>> by the Foo interface.
>>
>> I have to admit that I am not 100% sure about the byte code in the end
>> and if that matters. But as a user of the interface and abstract class,
>> nothing breaks.
>>
>> Mit freundlichen Grüßen / Best regards
>>
>>
>> *Dirk Fauth*
>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
>> www.bosch.com
>> Tel. +49 7153 666-1155 <+49%207153%206661155> | dirk.fa...@de.bosch.com
>>
>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr.
>> Volkmar Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
>> Dr. Markus Heyn, Dr. Dirk Hoheisel,
>> Christoph Kübel, Uwe Raschke, Peter Tyroller
>>
>>
>> *Von:* osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail.
>> osgi.org <osgi-dev-boun...@mail.osgi.org>] *Im Auftrag von *Raymond Auge
>> via osgi-dev
>> *Gesendet:* Dienstag, 5. Dezember 2017 00:26
>> *An:* OSGi Developer Mail List <osgi-dev@mail.osgi.org>
>> *Betreff:* [osgi-dev] making an existing interface method default causes
>> MINOR baseline change
>>
>>
>> Hey All,
>> I think the answer is "Yes it's a MINOR change", but I wanted to clarify.
>>
>> Assume I have the following interface in an exported package:
>>
>> public interface Foo {
>>public void do

Re: [osgi-dev] making an existing interface method default causes MINOR baseline change

[Raymond Auge via osgi-dev]

Does it matter that I'm getting a MINOR change while Foo and Bar are in the
same, exported package?

- Ray

On Dec 5, 2017 03:05, "Peter Kriens via osgi-dev" <osgi-dev@mail.osgi.org>
wrote:

> Great minds think alike (and it helped we were both in this discussion) :-)
>
> P
>
> On 5 Dec 2017, at 09:03, Timothy Ward via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
> Ray - I assume that you’re asking why this is a MINOR change, rather than
> a MICRO change? It’s obviously not a major change because the method exists
> with the same signature everywhere both before and after.
>
> The reason that it’s a MINOR change is to do with the forward (rather than
> backward) guarantees that the semantic versioning rules must make.
>
> In your example you end up deleting the original doFoo() implementation
> from the Bar class. From this point on the Bar class has no knowledge of
> this method, and the implementation *must* come from either a super type
> (there aren’t any) or as a default method on the implemented interface. If
> this doesn’t happen then the whole type hierarchy of Bar is broken - the
> concrete types which subclass Bar simply don’t have an implementation of
> the interface method that the contract says they must have!
>
> The only way to enforce this is to ensure that the updated Bar class
> imports a version of Foo which is guaranteed to have the “default doFoo()
> feature”. In semantic versioning new features always require at least a
> MINOR bump so that people can reliably depend on them (depending on a MICRO
> is not a good idea). That is what is happening here.
>
> Tim
>
> PS - I have just seen Peter’s email come in, which thankfully agrees with
> what I’m saying!
>
> On 5 Dec 2017, at 06:43, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
> IMHO it is a MINOR change because it is not a breaking change. J
>
> With that change neither implementations of the Foo interface, nor classes
> that extend the abstract Bar class will break.
>
> Implementations of the Foo interface can still implement the doFoo()
> method and by doing this override the default behavior. Overriding a
> default is not a breaking change as you neither add a new public method or
> field, you just give a default implementation.
>
> Classes that extend Bar did not need to implement doFoo() before, as it
> was implemented in Bar. Removing that method would be typically a breaking
> change. But you are moving it as default method to the Foo interface.
> Therefore Bar still has the doFoo() method implemented, as it is provided
> by the Foo interface.
>
> I have to admit that I am not 100% sure about the byte code in the end and
> if that matters. But as a user of the interface and abstract class, nothing
> breaks.
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dirk Fauth*
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
> www.bosch.com
> Tel. +49 7153 666-1155 <+49%207153%206661155> | dirk.fa...@de.bosch.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung,
> Dr. Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
>
>
> *Von:* osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-bounces@mail.
> osgi.org <osgi-dev-boun...@mail.osgi.org>] *Im Auftrag von *Raymond Auge
> via osgi-dev
> *Gesendet:* Dienstag, 5. Dezember 2017 00:26
> *An:* OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> *Betreff:* [osgi-dev] making an existing interface method default causes
> MINOR baseline change
>
>
> Hey All,
> I think the answer is "Yes it's a MINOR change", but I wanted to clarify.
>
> Assume I have the following interface in an exported package:
>
> public interface Foo {
>public void doFoo();
> }
>
> And in the same package I have abstract class Bar which implements Foo:
>
> public abstract class Bar implements Foo {
>public void doFoo() {...}
>public abstract void doBar();
> }
>
> And I want to migrate to a default method because doFoo() logic rarely
> changes:
>
> public interface Foo {
>public default void doFoo() {...}
> }
>
> public abstract class Bar implements Foo {
>//public void doFoo() {...}
>public abstract void doBar();
> }
>
> Can someone explain why this is a MINOR change?
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Se

[osgi-dev] making an existing interface method default causes MINOR baseline change

[Raymond Auge via osgi-dev]

Hey All,

I think the answer is "Yes it's a MINOR change", but I wanted to clarify.

Assume I have the following interface in an exported package:

public interface Foo {
   public void doFoo();
}

And in the same package I have abstract class Bar which implements Foo:

public abstract class Bar implements Foo {
   public void doFoo() {...}
   public abstract void doBar();
}

And I want to migrate to a default method because doFoo() logic rarely
changes:

public interface Foo {
   public default void doFoo() {...}
}

public abstract class Bar implements Foo {
   //public void doFoo() {...}
   public abstract void doBar();
}

Can someone explain why this is a MINOR change?


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Declarative services and optional imports

[Raymond Auge via osgi-dev]

Hey Robert,

We had the same use case and solved it the following way:

Given your component which has the optional import package (doesn't matter
how it's used):

import com.liferay.demo.foo.Foo; // The optional package
@Component(
enabled = false // disable by default so DS ignores it)public
class OptionalPackageConsumer implements Foo {...}

Make sure the component is *disabled* by default. This will prevent
SCR from classloading the component class.

Second, you construct a "starter" component who's job it is to check
for the available package:

@Componentpublic class OptionalPackageConsumerStarter {
   @Activate
void activate(ComponentContext componentContext) {
try {
Class.forName(com.liferay.demo.foo.Foo.class.getName());


componentContext.enableComponent(OptionalPackageConsumer.class.getName());
}
catch (Throwable t) {
_log.warn("Could not find {}", t.getMessage());
}
}
}

Sure, it's more work and the logic above is not perfect because you
may not want the "starter" component to start when the package is
unavailable. But this basic idea has worked for us.

- Ray


On Tue, Nov 21, 2017 at 9:16 AM, Robert Munteanu via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> On Tue, Nov 21, 2017 at 4:00 PM, Christian Schneider
>  wrote:
> > I think it can not work with a simple optional import. What could work
> is a
> > separate component that has
> > the optional class as a mandatory reference.
> >
> > This component could then be injected into your component with an
> optional
> > reference and with an interface that is independent of the optional
> import.
>
> That's a good point. Sadly I can't use this approach since it's going
> to generate a warning in the logs and we have a strict policy against
> that.
>
> > I think declarative services do not yet support this but it would be a
> very
> > valuable feature as it allows to handle optional imports without any
> class
> > loading magic on the user side.
>
> +1
>
> Robert
> >
> > Christian
> >
> > 2017-11-21 14:53 GMT+01:00 Robert Munteanu via osgi-dev
> > :
> >>
> >> Hi Carsten,
> >>
> >> On Tue, Nov 21, 2017 at 3:50 PM, Carsten Ziegeler  >
> >> wrote:
> >> > Hi,
> >> >
> >> > if I understand you correctly you have an optional package import to
> the
> >> > package providing BarService?
> >>
> >> Yes, that is correct.
> >>
> >> > In that case your class SomeComponent can't be loaded if that package
> is
> >> > not available and there is no magic to get around this.
> >>
> >> I was afraid of that. I'll try using a ServiceTracker, guess that's
> >> the next best thing.
> >>
> >> Thanks,
> >>
> >> Robert
> >> ___
> >> OSGi Developer Mail List
> >> osgi-dev@mail.osgi.org
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>
>
>
> --
> http://robert.muntea.nu/
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Apache Felix Web Console Components view

[Raymond Auge via osgi-dev]

Hi Jesse,

This question is better posted over on the Apache Felix user mailing list.
That's the appropriate forum for your question and where you'll find the
Felix experts who can answer your question.

Sincerely,
- Ray


On Nov 16, 2017 15:55, "Jesse Rao via osgi-dev" 
wrote:

Simple question about Apache Felix Web Console: Are any special steps
required to use it to view / manage DS components?

My application is using DS components and I can see that the
org.apache.felix.scr bundle is active. However, when I hit the URL
http://localhost:8080/system/console/components I get a 404 and am
redirected to http://localhost:8080/system/console/bundles.

The felix web console docs here

say "If your framework uses the Apache Felix Declarative Services
implementation, you can use to the Web Console to inspect the declared
components available from the various bundles and managed by the Service
Component Runtime."

-- 
Jesse Rao
Software Engineer
Liferay, Inc.
Visit Us: www.liferay.com  |  Like Us: www.facebook.com/liferay  |  Follow
Us: www.twitter.com/liferay | Share Us: www.instagram.com/liferayinc

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev