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-OS

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 // mobil

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 vo

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
>>>
>>&g

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

[Raymond Auge via osgi-dev]

t;>>>>
>>>>>> 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 regards,
>>>>>>
>>>>>> Martin
>>>>>> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> see comments inline.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Mark
>>>>>> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>>>>>>
>>>>>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"?
>>>>>> Should I remove this dependency too? Should I add
>>>>>> "org.eclipse.osgi.services" or the individual "org.osgi.service.*" to my
>>>>>> (parent) POM? Are the individual "org.osgi.service.*" also required at
>>>>>> runtime (on classpath or installed to osgi?). Will "org.eclipse.osgi" 
>>>>>> start
>>>>>> without "org.eclipse.osgi.services" on the classpath or installation as
>>>>>> bundle?
>>>>>>
>>>>>> You have to distinguish between the packages you want to resolve and
>>>>>> the artifacts/bundles that contain the the packages/implementations.
>>>>>>
>>>>>> In your case org.eclipse.osgi.services is the bundle that exports the
>>>>>> packages org.osgi.service.* packages.
>>>>>>
>>>>>> Because Maven just resolves artifacts, you need to provide the bundle
>>>>>> org.eclipse.osgi.services as dependency.
>>>>>>
>>>>>> Yes, org.eclipse.osgi will start without org.eclipse.osgi.services
>>>>>>
>>>>>> I have now added "org.eclipse.osgi.services". However, it now cannot
>>>>>> requires "org.osgi.util.promise". What should I add to my POM in order to
>>>>>> resolve the core Eclipse OSGi implementation (only OSGi core
>>>>>> implementation)?
>>>>>>
>>>>>> You should find the promises and functions in the bundle
>>>>>> org.eclipse.osgi.util
>>>>>>
>>>>>> btw I have removed the runtime scope for "org.eclipse.osgi".
>>>>>> Am 02.01.20 um 19:00 schrieb Raymond Auge:
>>>>>>
>>>>>> 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.
>>>>>>
&g

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é* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>>
>>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>


-- 
*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

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é* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
>
>

-- 
*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

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é* <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

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é* <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)
>>
>

-- 
*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

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 a

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é* <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)
>


-- 
*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

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:
>>
>

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
>>>
>>>
>>

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é* <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)
>



-- 
*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

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
>

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 stat

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
> <https://maps.google.com/?q=576+%0D%0AVia+Ettore+Cristoni=gmail=g>
> 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
>> <https://maps.google.com/?q=576+Via+Ettore+Cristoni=gmail=g>
>> Via Ettore Cristoni
>> <https://maps.google.com/?q=576+Via+Ettore+Cristoni=gmail=g>,
>> 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.
>> _

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]

I'll try to not be overly Liferay specific because I don't feel I need too
in order to give decent answers.


On Sun, Dec 10, 2017 at 4:27 PM, Matthews, Kevin <
kevin.matth...@firstdata.com> wrote:

> Hi Ray, I read the app note but I need some clarification. Couple of
> questions:
>
>
>
> 1.   In Liferay, we hot deploy bundles to the deploy folder in
> Wildfly/Jboss container or appserver using the gradle build script provided
> by liferay. I thought we could do the same on the liberty server since it
> already has an OSGI container.  Is the usage of the bnd agent running in
> the application server with a specific port the same concept as how it’s
> done in liferay 7.0 where gogo shell runs on *port 11311*?
>

There are some parallels but let me explain the related use-cases in
Liferay:

- localhost:11311 is the telnet socket/port of the Apache Felix gogo shell
that Liferay comes pre-configured with. Though gogo can be used to install
bundles, it's not what Liferay uses for installing (telnet is provided by
Eclipse Equinox console bundle).

- Liferay uses Apache Felix fileinstall which scans directories for bundles
to install (hot deploy). There's some extensions using the fileinstall SPI
to support some Liferay proprietary packages and WAR files (to support
WABs).


> Do we have bnd agent running on the liferay 7.0 server?
>
I don't believe it is installed OOTB, you'd have to drop the bundle into
the deploy dir.


> I believe the Jetty container out of the box comes with a OSGI container,
> is this true?
>
Which instance of jetty are you referring to? A pure jetty Http Servlet
container I don't believe runs an OSGi framework (even though Jetty is
largely made of OSGi bundles).


>
>
> 2.   You mention the distro jar should be re-created in case there
> are changes in the application server.  What are some examples of changes
> in the app server that will need the distro jar to re-created?
>
For example, let's imagine you install a "release" of container X (e.g.
Liferay 7.0 ga2),

- you might generate a distro at this stage to resolve against

Later you install, using some management tool that comes with container X,
(e.g. Liferay marketplace) some additional features (e.g. Audience
Targeting Suite).

- you may want to re-generate a distro here because you might want to code
against the new feature's capabilities (APIs).


>
>
> 3.   What’s the difference between osgi en route bundle jars running
> in jetty container we have in the tutorial
>
What you get in enroute is not a "jetty container in which your app runs".
It's your app's bundles which happen to depend on some http stuff which the
resolver resolved to jetty bundles to provide the http parts.

The bundles YOU make have a clean, pure dependency on http stuff. So
enroute could resolve ANY provider, it just so happens to be jetty bundles.


> versus the bundle jars we build/deploy in liferay 7 running on
> Windows/Wildfly/tomcat etc?
>
Let's say Liferay is running in Wildfly, it provides the http stuff OOTB as
a function of the container (Wildfly) so when you resolve against the
Liferay distro, the resolve would say:

"The http stuff is already provided by this distro, we don't need to
resolve another provider."

The very same bundles you built above which have a clean, pure dependency
on http stuff could run with zero modification on Liferay.


>
>
> 4.   I see couple of osgi-liberty maven plugins when I go to create a
> maven project in Eclipse . Do you know what these maven plugins usage?
>
>
>
>
>
These just look like versions of the Servlet API, probably so you can write
your code against whatever lowest common denominator your product policy
has set.



> 5.   When I read the OSGI in IBM they don’t see they show usage of
> declarative service @Component instead they use  blueprint for registering
> the osgi services. Also, when generating an OSGI IBM project through
> eclipse doesn’t seem to use the @Active annotation for bundle activation.
>   Is IBM 100% on board with the OSGI Specification. ?
>
IBM is 100% on board with OSGi! :) Beyond that I won't make any comments
regarding their product(s). There are plenty of IBMers around who can
answer this.

Sincerely,
- Ray


>
>
> Thanks,
>
> Kevin
>
>
>
>
>
> *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:
&g

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 <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
> [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é* <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)
>



-- 
*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

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

Re: [osgi-dev] Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxrs]

[Raymond Auge]

Have you made this inquiry with the CXF community? I think you may get
better results as CXF experts should have more understanding of these
issues.

Sincerely,
- Ray

On Thu, Aug 31, 2017 at 5:23 AM, Raffaele Gambelli <
r.gambe...@hitachi-systems-cbt.com> wrote:

> I'm running on OSGI Equinox environment and when I start Equinox I receive
> the following exception:
>
> Offending resource: class path resource [application-context.xml]; nested
> exception is org.springframework.beans.factory.parsing.
> BeanDefinitionParsingException: Configuration problem: Unable to locate
> Spring NamespaceHandler for XML schema namespace [
> http://cxf.apache.org/jaxrs]
> I have the following situation:
>
> One web-application, say A, having only one embedded dependency which is
> located in WEB-INF/lib, say B
> B is a jar containing a spring configuration file with some bean
> definitions
> All the dependencies of A and B exist as OSGI bundles,
> cxf-rt-frontend-jaxrs exists and it is in resolved status
> So, why am I receiving that exception in your opinion? Thanks
>
> Raffaele Gambelli
> ___
> 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] Questions about JAX-RS Extension services

[Raymond Auge]

The spec states ".. static extensions being ranked below all whiteboard
services".

- Ray

On Fri, Aug 25, 2017 at 9:51 AM, Bram Pouwelse <b...@pouwelse.com> wrote:

> I think the service ranking trick could work but .. what about an
> application that has a custom one defined in the application itself?
>
> On Fri, Aug 25, 2017 at 3:46 PM Tim Ward <tim.w...@paremus.com> wrote:
>
>> In that case register the custom one targeting that exact application,
>> and give it a higher service ranking than the default writer.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 25 Aug 2017, at 14:26, Bram Pouwelse <b...@pouwelse.com> wrote:
>>
>> I was more woried about  conflicts, for example a default "*MessageBodyWriter
>> to provide JSON serialization*" I could register that targeting all
>> applications but some application could need a customized one?
>>
>> Bram
>>
>> On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge <raymond.a...@liferay.com>
>> wrote:
>>
>>> Binding an extension to every app is pretty much free since only those
>>> resources/applications/extensions having a dependency on it can/will
>>> use it! Right?
>>>
>>> - Ray
>>>
>>> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse <b...@pouwelse.com>
>>> wrote:
>>>
>>>> I was mainly looking for the possibility to register extensions
>>>> available for multiple applications to use but not bind them to all. The
>>>> extend.me example in Tim's answer didn't cross my mind but I guess
>>>> that should do the trick :)
>>>>
>>>> Thanks guys!
>>>>
>>>> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward <tim.w...@paremus.com>
>>>> wrote:
>>>>
>>>>> Hi Bram,
>>>>>
>>>>> It sounds like you have something of an advanced use case in that you
>>>>> want to selectively provide a whiteboard extension (which is achieved 
>>>>> using
>>>>> the application select property) and you want to prevent certain
>>>>> applications from being deployed until a suitable extension is available
>>>>> (which is achieved using the extension select property).
>>>>>
>>>>> The way I would do this is as follows:
>>>>>
>>>>>
>>>>>- All applications that need the extension must express their
>>>>>dependency using the *osgi.jaxrs.extension.select* filter to
>>>>>prevent them being picked up by the whiteboard too early. For example 
>>>>> by
>>>>>using the filter “(osgi.jaxrs.name=myWhiteboardExtension)”
>>>>>- The applications that need the extension must also provide a
>>>>>property for the extension service to recognise so that it can target 
>>>>> them
>>>>>using the *osgi.jaxrs.application.select* filter, for example 
>>>>> *extend.me
>>>>><http://extend.me>=true*
>>>>>- The extension service must then target only these applications
>>>>>using the *osgi.jaxrs.application.select* filter “(extend.me=true)”
>>>>>
>>>>>
>>>>> This sets up the bi-directional targeting that you’re after, while
>>>>> also guaranteeing that there are no start-up ordering issues. It is a
>>>>> pretty odd situation though.
>>>>>
>>>>> More typically a whiteboard extension would just be applied to all of
>>>>> the applications in the whiteboard, or just target specific applications.
>>>>> You would then place extension requirements on specific whiteboard
>>>>> resources that need the extension, not blocking the whole application. 
>>>>> This
>>>>> is doubly true because whiteboard applications should normally contain
>>>>> their mandatory extensions as part of the application, not as whiteboard
>>>>> additions.
>>>>>
>>>>> Anyway, I hope this helps to clear things up!
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>> On 22 Aug 2017, at 18:34, Bram Pouwelse <b...@pouwelse.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge <raymond.a...@liferay.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Aug 22, 2017 at 8:50 AM, B

Re: [osgi-dev] Questions about JAX-RS Extension services

[Raymond Auge]

Simply publish your "shared" extension with a low service ranking!

Finally, if an application needs a specific one, they need to depend on it
anyway!

- Ray

On Fri, Aug 25, 2017 at 9:26 AM, Bram Pouwelse <b...@pouwelse.com> wrote:

> I was more woried about  conflicts, for example a default "*MessageBodyWriter
> to provide JSON serialization*" I could register that targeting all
> applications but some application could need a customized one?
>
> Bram
>
> On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge <raymond.a...@liferay.com>
> wrote:
>
>> Binding an extension to every app is pretty much free since only those
>> resources/applications/extensions having a dependency on it can/will use
>> it! Right?
>>
>> - Ray
>>
>> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse <b...@pouwelse.com> wrote:
>>
>>> I was mainly looking for the possibility to register extensions
>>> available for multiple applications to use but not bind them to all. The
>>> extend.me example in Tim's answer didn't cross my mind but I guess that
>>> should do the trick :)
>>>
>>> Thanks guys!
>>>
>>> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward <tim.w...@paremus.com>
>>> wrote:
>>>
>>>> Hi Bram,
>>>>
>>>> It sounds like you have something of an advanced use case in that you
>>>> want to selectively provide a whiteboard extension (which is achieved using
>>>> the application select property) and you want to prevent certain
>>>> applications from being deployed until a suitable extension is available
>>>> (which is achieved using the extension select property).
>>>>
>>>> The way I would do this is as follows:
>>>>
>>>>
>>>>- All applications that need the extension must express their
>>>>dependency using the *osgi.jaxrs.extension.select* filter to
>>>>prevent them being picked up by the whiteboard too early. For example by
>>>>using the filter “(osgi.jaxrs.name=myWhiteboardExtension)”
>>>>- The applications that need the extension must also provide a
>>>>property for the extension service to recognise so that it can target 
>>>> them
>>>>using the *osgi.jaxrs.application.select* filter, for example *extend.me
>>>><http://extend.me>=true*
>>>>- The extension service must then target only these applications
>>>>using the *osgi.jaxrs.application.select* filter “(extend.me=true)”
>>>>
>>>>
>>>> This sets up the bi-directional targeting that you’re after, while also
>>>> guaranteeing that there are no start-up ordering issues. It is a pretty odd
>>>> situation though.
>>>>
>>>> More typically a whiteboard extension would just be applied to all of
>>>> the applications in the whiteboard, or just target specific applications.
>>>> You would then place extension requirements on specific whiteboard
>>>> resources that need the extension, not blocking the whole application. This
>>>> is doubly true because whiteboard applications should normally contain
>>>> their mandatory extensions as part of the application, not as whiteboard
>>>> additions.
>>>>
>>>> Anyway, I hope this helps to clear things up!
>>>>
>>>> Tim
>>>>
>>>>
>>>> On 22 Aug 2017, at 18:34, Bram Pouwelse <b...@pouwelse.com> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge <raymond.a...@liferay.com>
>>>> wrote:
>>>>
>>>>> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse <b...@pouwelse.com> w
>>>>> rote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have some questions about the "Additional JAX-RS types" section of
>>>>>> the JAX-RS-Services RFC (rfc-217).
>>>>>>
>>>>>> 5.2 Additional JAX-RS types:
>>>>>> …​
>>>>>> *"Extensions should provide an osgi.jaxrs.application.select property
>>>>>> with a filter that will match application to which this extensions will 
>>>>>> be
>>>>>> registered. If no such filter is provided the extension will affect the
>>>>>> default application." *
>>>>>> …​
>>>>>>
>>>>>&g

Re: [osgi-dev] Questions about JAX-RS Extension services

[Raymond Auge]

Binding an extension to every app is pretty much free since only those
resources/applications/extensions having a dependency on it can/will use
it! Right?

- Ray

On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse <b...@pouwelse.com> wrote:

> I was mainly looking for the possibility to register extensions available
> for multiple applications to use but not bind them to all. The extend.me
> example in Tim's answer didn't cross my mind but I guess that should do the
> trick :)
>
> Thanks guys!
>
> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward <tim.w...@paremus.com>
> wrote:
>
>> Hi Bram,
>>
>> It sounds like you have something of an advanced use case in that you
>> want to selectively provide a whiteboard extension (which is achieved using
>> the application select property) and you want to prevent certain
>> applications from being deployed until a suitable extension is available
>> (which is achieved using the extension select property).
>>
>> The way I would do this is as follows:
>>
>>
>>- All applications that need the extension must express their
>>dependency using the *osgi.jaxrs.extension.select* filter to prevent
>>them being picked up by the whiteboard too early. For example by using the
>>filter “(osgi.jaxrs.name=myWhiteboardExtension)”
>>- The applications that need the extension must also provide a
>>property for the extension service to recognise so that it can target them
>>using the *osgi.jaxrs.application.select* filter, for example *extend.me
>><http://extend.me>=true*
>>- The extension service must then target only these applications
>>using the *osgi.jaxrs.application.select* filter “(extend.me=true)”
>>
>>
>> This sets up the bi-directional targeting that you’re after, while also
>> guaranteeing that there are no start-up ordering issues. It is a pretty odd
>> situation though.
>>
>> More typically a whiteboard extension would just be applied to all of the
>> applications in the whiteboard, or just target specific applications. You
>> would then place extension requirements on specific whiteboard resources
>> that need the extension, not blocking the whole application. This is doubly
>> true because whiteboard applications should normally contain their
>> mandatory extensions as part of the application, not as whiteboard
>> additions.
>>
>> Anyway, I hope this helps to clear things up!
>>
>> Tim
>>
>>
>> On 22 Aug 2017, at 18:34, Bram Pouwelse <b...@pouwelse.com> wrote:
>>
>>
>>
>> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge <raymond.a...@liferay.com>
>> wrote:
>>
>>> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse <b...@pouwelse.com> w
>>> rote:
>>>
>>>> Hi all,
>>>>
>>>> I have some questions about the "Additional JAX-RS types" section of
>>>> the JAX-RS-Services RFC (rfc-217).
>>>>
>>>> 5.2 Additional JAX-RS types:
>>>> …​
>>>> *"Extensions should provide an osgi.jaxrs.application.select property
>>>> with a filter that will match application to which this extensions will be
>>>> registered. If no such filter is provided the extension will affect the
>>>> default application." *
>>>> …​
>>>>
>>>>
>>>> 5.2.5 Depending on Extension Services:
>>>>
>>>>
>>>> *"When writing and configuring a JAX-RS resource or extension it is
>>>> possible for one extension to depend on another. For example a JAX-RS
>>>> resource may have a dependency upon a MessageBodyWriter to provide JSON
>>>> serialization, or a ContainerRequestFilter may depend on a ContextResolver
>>>> to provide injected configuration.*
>>>>
>>>>
>>>> *In these cases it is necessary to express a dependency on the
>>>> existence of an extension within the JAX-RS container. This can be
>>>> expressed on any JAX-RS whiteboard service using the
>>>> osgi.jaxrs.extension.select property. This property has type String+ and
>>>> contains a list of LDAP filters. These filters will be run against the
>>>> service properties of each extension service registered with the container.
>>>> If all of the supplied filters pass then the whiteboard service will
>>>> registered. This extension checking should be done per Application.*
>>>> *If at some point later a necessary extension service dependenc

Re: [osgi-dev] Questions about JAX-RS Extension services

[Raymond Auge]

On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse  wrote:

> Hi all,
>
> I have some questions about the "Additional JAX-RS types" section of the
> JAX-RS-Services RFC (rfc-217).
>
> 5.2 Additional JAX-RS types:
> …​
> *"Extensions should provide an osgi.jaxrs.application.select property with
> a filter that will match application to which this extensions will be
> registered. If no such filter is provided the extension will affect the
> default application." *
> …​
>
>
> 5.2.5 Depending on Extension Services:
>
>
> *"When writing and configuring a JAX-RS resource or extension it is
> possible for one extension to depend on another. For example a JAX-RS
> resource may have a dependency upon a MessageBodyWriter to provide JSON
> serialization, or a ContainerRequestFilter may depend on a ContextResolver
> to provide injected configuration.*
>
>
> *In these cases it is necessary to express a dependency on the existence
> of an extension within the JAX-RS container. This can be expressed on any
> JAX-RS whiteboard service using the osgi.jaxrs.extension.select property.
> This property has type String+ and contains a list of LDAP filters. These
> filters will be run against the service properties of each extension
> service registered with the container. If all of the supplied filters pass
> then the whiteboard service will registered. This extension checking should
> be done per Application.*
> *If at some point later a necessary extension service dependency becomes
> unavailable then the whiteboard service will become ineligible for
> inclusion in the JAX-RS container until a suitable replacement is found."*
>
>
> Questions:
>
>- Is there a way to register extension services without actively
>adding them to an application (just have them ready to use for those who
>need them)?
>
> Use an `*osgi.jaxrs.application.select` filter than matches all
applications:*
*e.g. **osgi.jaxrs.application.select=*(osgi.jaxrs.name=*)

>
>-
>- Is it possible to use an extension service from an application that
>doesn’t match the extension service’s osgi.jaxrs.application.select filter?
>
> No, since the jax-rs service's extension bindings must come from within
those bound to the same application!

>
>-
>- The "This extension checking should be done per Application" remark
>shoud that also apply to the default application? Sounds ok to me for
>JAX-RS applications that are registered as such but for the default
>application this is kind of strange as a single resource depending on an
>unavailable extension could make the whiteboard go down for all JAX-RS
>resources (that are not part of an application)?
>
> Resources which are static need to use static extensions. The spec is only
talking about jaxrs "services". Otherwise statically wired resources within
a given application are not subject to OSGi services, except from purely
the shadowing perspective, not from the wiring/class space perspective. If
you're talking about something else could you please elaborate?


>
>- I think for the default application just excluding the resource with
>unstatisfied dependencies would be better than taking the default
>application down.
>
> At no point does an application get taken down due to a resource/extension
not being satisfied... unless it's the application itself has the extension
dependency. But the default application has no such dependencies, in fact
it may have no resources either.

HTH
- Ray


>
>-
>
> Regards,
> Bram
>
> ___
> 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] Names in the presence of multiple bundle versions

[Raymond Auge]

I hate to say it because I've done exactly this on several occasions...

But that is a bad design for the reasons you mentioned! However it happens
enough that DS has something that can get your pretty close.

The most recent version of the DS spec which added Field injection and in
particular tuples. If you create a injected field like so:

@Reference(
cardinality = ReferenceCardinality.MULTIPLE,
policy = ReferencePolicy.DYNAMIC,
policyOption = ReferencePolicyOption.GREEDY
)
private volatile List, ImageFormat>>
_formats;

you get a List of tuples you can iterate over which will hold true to the
natural ordering of the services (via ServiceReference.compareTo)

Then using a Filter (yes this part pulls in OSGi API, but very little) you
can use the streaming API to find "the best" match in the List (if one
exists):

Filter filter = FrameworkUtil.createFilter("(format=PNG)");

Optional bestMatch = _formats.stream().sorted(
Collections.reverseOrder() // not totally sure you need this,
but I think so
).filter(
entry -> filter.matches(entry.getKey())
).map(
Map.Entry::getValue
).findFirst();

- Ray

On Fri, Jul 21, 2017 at 2:26 PM, Mark Raynsford 
wrote:

> Hello.
>
> Consider an API like ImageIO. To write an image in the PNG format, one
> calls:
>
>   ImageIO.write(image, "PNG", output);
>
> The implementation of the write() method gets a list of the available
> formats via ServiceLoader and picks the one named "PNG". The "PNG"
> value is the sole criteria used to pick an image format provider.
>
> In OSGi, we'd use the whiteboard pattern (probably with declarative
> services) to implement this. The implementation might look something
> like:
>
>   interface ImageFormat
>   {
> String name();
> ...
>   }
>
>   @Component
>   public final class ImageFormats
>   {
> private final ConcurrentHashMap formats =
>   new ConcurrentHashMap();
>
> @Reference(
>   cardinality = ReferenceCardinality.MULTIPLE,
>   policy = ReferencePolicy.DYNAMIC,
>   unbind = "onFormatUnregister")
> public void onFormatRegister(
>   final ImageFormat format)
> {
>   this.formats.put(format.name(), format);
> }
>
> public void onFormatUnregister(
>   final ImageFormat format)
> {
>   this.formats.remove(format.name(), format);
> }
>
> ...
>   }
>
> This would work perfectly well, but what happens if two bundles
> try to register a format with the same name? We could check for
> and reject registrations with overlapping names, but that might
> leave developers/users stuck with a format implementation that
> they don't like. What if two different versions of the same bundle
> are installed, and both try to register themselves?
>
> This is a problem that seems to come up in various guises each
> time I work with OSGi, and I've not really seen a satisfactory
> solution to it. Many solutions involve bubbling up the entirely
> internal concern of there being multiple versions of a format
> provider present to the API, and although this can work, it does
> mean that users are then forced to intelligently pick providers
> ("I just want PNG, why do I have to care which of the providers
> I end up with?! Isn't the ImageFormats class supposed to pick
> for me?!"). Part of this problem is caused by the fact that the
> ImageFormats class exists at all; users could, for example,
> search for services providing ImageFormat themselves via DS or
> the OSGi APIs. Sometimes, though, a class analogous to ImageFormats
> is necessary, particularly when you expect callers to be OSGi-unaware
> and/or you only have very simple selection criteria (like a "PNG"
> string).
>
> How do people that know more about OSGi than I do usually handle
> this?
>
> --
> Mark Raynsford | http://www.io7m.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] (no subject)

[Raymond Auge]

Cross bundle communication should happen via the service registry.

So bundle A should register the SessionDao bean as a service and bundle B
should use that service using something like a service tracker instead of
from the spring context.

Sincerely,
- Ray

On Wed, Jul 19, 2017 at 5:50 AM, Raffaele Gambelli <
r.gambe...@hitachi-systems-cbt.com> wrote:

> Hi all, this is my first question in this list.
>
> I'm trying to adjust a quite complex system, made with OSGI but which was
> made quite badly, in addition I have to say that I have no so much
> experience with OSGI.
>
> Briefly, I have four webapps on jetty which should live inside the same
> Equinox runtime, till today they and their needed bundles have been
> deployed in a such a way that quite all bundles embedded all their
> dependencies, so there is a huge confusion while I'm hardly working to
> create very smaller bundles, emptying them from the embedded dependencies
> and making them work together in what I believe be the OSGI paradygm.
>
> Just to let you know some other elements helping to understand my problems
> and knowledge here it is a question posted some weeks ago
> https://stackoverflow.com/questions/44897956/deploy-
> webapp-in-jetty-in-osgi where a very kind person exhaustively  answered.
>
> Now i explain my current problem, I'm finally arrived to have a running
> webapplication, but as soon as it accesses Spring bean, it is not found, so
> for example I have a NPE in a row like this:
>
> SessionDao sessionDao = (SessionDao) SpringContextProvider.
> getApplicationContext().getBean("sessionDao");
>
> That bean is configured in a different bundle and for what I'm
> undestanding that is the matter, so after some research I arrived to
> "Spring Dynamic Modules", so I'm reading this http://docs.spring.io/
> osgi/docs/current/reference/html-single/#why-Spring DM
>
> so my question is, am I on the right path? Should I go deeply with Spring
> DM to configure bean in bundle A and make it available on bundle B?
>
> Thanks very much, bye
>
> Raffaele Gambelli
>
> element
> Font
> font-family
> font-size
> font-style
> font-variant
> font-weight
> letter-spacing
> line-height
> text-decoration
> text-align
> text-indent
> text-transform
> white-space
> word-spacing
> color
> Background
> bg-attachment
> bg-color
> bg-image
> bg-position
> bg-repeat
> Box
> width
> height
> border-top
> border-right
> border-bottom
> border-left
> margin
> padding
> max-height
> min-height
> max-width
> min-width
> outline-color
> outline-style
> outline-width
> Positioning
> position
> top
> bottom
> right
> left
> float
> display
> clear
> z-index
> List
> list-style-image
> list-style-type
> list-style-position
> Table
> vertical-align
> border-collapse
> border-spacing
> caption-side
> empty-cells
> table-layout
> Effects
> text-shadow
> -webkit-box-shadow
> border-radius
> Other
> overflow
> cursor
> visibility
>
> ___
> 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] Can bnd-export-maven-plugin resolve reactor modules?

[Raymond Auge]

I did forget the "resolve" step!

In the configuration of the maven plugin add:

true

- Ray

On Thu, Jun 22, 2017 at 9:56 AM, Mark Raynsford <list+org.o...@io7m.com>
wrote:

> On 2017-06-21T18:32:35 -0400
> Raymond Auge <raymond.a...@liferay.com> wrote:
> >
> > 
>
> 'Ello!
>
> Thanks for the detailed instructions. I'll give this a go shortly.
>
> M
>
> ___
> 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

Re: [osgi-dev] Can bnd-export-maven-plugin resolve reactor modules?

[Raymond Auge]

1) create a new module in your reactor tree

2) add all the top level dependencies you wish to put in your deployment in
this new module's pom (you CAN refer to other maven modules in the reactor
as expected)

3) add this [1] maven repository since some of what you need is provided by
the yet-to-be-released bnd 3.4.0-RC

4) configure the pom with the following bnd-export-maven-plugin [2]:


biz.aQute.bnd
bnd-export-maven-plugin
3.4.0-SNAPSHOT

false

main.bndrun

true




export





5) in `main.bndrun` make sure to populate the property `-runrequires` with
the set of top level bundles your deployment requires which won't
transitively be added purely through resolution of requirements and
capabilities: e.g.

-runrequires: \

osgi.identity;filter:='(osgi.identity=org.apache.aries.cdi.extension.http)',\
  osgi.identity;filter:='(osgi.identity=org.apache.felix.configadmin)',\
  osgi.identity;filter:='(osgi.identity=slf4j.log4j12)'

6) remove the following lines from your main.bndrun:

-standalone:

-plugin.examples.eval = \
 aQute.bnd.repository.maven.pom.provider.BndPomRepository; \
 snapshotUrls=https://oss.sonatype.org/content/repositories/osgi/; \
 releaseUrls=https://repo1.maven.org/maven2/; \
 pom=${.}/pom.xml; \
 name=examples.eval; \
 location=${.}/target/cached.xml

7) execute `mvn bnd-export:export`

8) if resolve fails then you've missed a dependency in the pom, add it and
try 7) again.

All the resolved bundles should be placed in `*${project.build.directory}*`

HTH,
- Ray

[1]
https://bndtools.ci.cloudbees.com/job/bnd.next/599/artifact/dist/bundles/
[2]
https://github.com/bndtools/bnd/tree/master/maven/bnd-export-maven-plugin


On Wed, Jun 21, 2017 at 11:49 AM, Mark Raynsford 
wrote:

> Hello.
>
> I put together a small project a while back to experiment with various
> aspects of OSGi (such as independent module versioning, and producing
> a runnable distribution zip containing an OSGi framework and a set of
> bundles).
>
> I'm currently using Maven for all of my projects (and have been for
> close to ten years), and am currently using the maven-bundle-plugin
> to produce OSGi bundles.
>
>   https://github.com/io7m/thoth
>
> The com.io7m.thoth.distribution module solely exists to aggregate
> dependencies and to produce a runnable distribution.
>
> I've had various issues creating a runnable distribution of the project,
> the latest of which seems to be that the Assembly plugin can't
> really seem to do what I'm asking it to do:
>
>   https://issues.apache.org/jira/browse/MASSEMBLY-848
>
> Basically, what I'm trying to do is produce a zip file containing a
> specific directory hierarchy. The directory hierarchy contains a set of
> Apache Felix bundles (the framework and service implementations), some
> configuration files, and the bundles that make up the thoth project. I
> don't want to produce a single executable jar; I want to keep all of
> the bundles separate so that they can be easily upgraded individually
> after deployment.
>
> As the subject of the bnd-maven-export-plugin came up a few hours ago,
> I thought I'd try it having never actually used Bnd directly, or any
> of the bnd-* Maven plugins. My thinking is that I can get the export
> plugin to intelligently decide what bundles are needed, to
> intelligently fetch framework bundles, and to dump all of those into a
> single directory. I can then use the Assembly plugin to package them up
> into the directory layout that I need, and won't need to depend on the
> problematic artifact resolution mechanism the Assembly plugin
> apparently uses.
>
> I'm following the enRoute runtime tutorial:
>
>   http://enroute.osgi.org/tutorial_eval/380-run.html
>
> Using a somewhat incomplete main.bndrun file, I have something that I
> think should effectively not do very much:
>
>   https://github.com/io7m/thoth/commit/a9f58c11daeba94f5d79878cd23a68
> bef7955195
>
> In other words, unless I'm misunderstanding the documentation, the
> export plugin should grab some Felix bundles and put them into the
> target directory. It hasn't been asked to do anything else, so it
> shouldn't.
>
> Unfortunately, what actually happens is this:
>
> [INFO] --- bnd-export-maven-plugin:3.3.0:export (default) @
> com.io7m.thoth.distribution --- [INFO] cached
> file:/home/someone/git/com.github/io7m/thoth/com.io7m.
> thoth.distribution/pom.xml
> [INFO] Unlocking url cache
> file:/home/someone/git/com.github/io7m/thoth/com.io7m.
> thoth.distribution/pom.xml
> [INFO] cached
> https://repo1.maven.org/maven2/com/io7m/thoth/com.
> io7m.thoth/1.0.0/com.io7m.thoth-1.0.0.pom
> [INFO] Proxy handlers [] [INFO] No match for
> https://repo1.maven.org/maven2/com/io7m/thoth/com.
> io7m.thoth/1.0.0/com.io7m.thoth-1.0.0.pom,
> handler Server [ 

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

Good points BJ! I'll put an App Note together for this.

- Ray

On Mon, May 1, 2017 at 2:07 PM, BJ Hargrave <hargr...@us.ibm.com> wrote:

> Also, the controller component should not register a service.
> "@Component(service={})". If you say "service={}" then you are
> "immediate=true".
>
> Maybe you should make an enroute app note for this?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> <(386)%20848-1781>
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> <(386)%20848-3788>
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Raymond Auge <raymond.a...@liferay.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] handling optional/dynamic imports in DS
> Date: Mon, May 1, 2017 2:04 PM
>
> Good one Tim!
>
> Oh, and I forgot to show that the "controller" component should be
> immediate otherwise it will never activate since nothing should "use" it.
>
> - Ray
>
> On Mon, May 1, 2017 at 1:31 PM, Tim Ward <tim.w...@paremus.com> wrote:
>
> For a dynamic import your controller could register a listener so that
> when a suitable package appears in the runtime your disabled component gets
> activated without needing to restart the controller.
>
> Tim
>
> Sent from my iPhone
>
> On 1 May 2017, at 17:41, Raymond Auge <raymond.a...@liferay.com> wrote:
>
>
> Hey All,
> I managed to find a relatively elegant solution to this with pure DS.
>
> Given a component using an optional/dynamic package(s):
>
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable so that DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
>
> A controller is created which does the classloader check:
>
> @Component
> public 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());
> }
> }
> }
>
> If successful, the component is enabled, otherwise, don't!
>
> - Ray
>
>
>
> On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) <
> dirk.fa...@de.bosch.com> wrote:
>
> I totally agree that a clean solution would be to extract the service in
> another bundle with a non optional dependency, as this avoids any runtime
> issues at the beginning by not starting the bundle. Will think about that
> for the Platform Runtime after Oxygen, as such a change is not allowed at
> the current state of the development.
>
>
>
> Nevertheless I created https://bugs.eclipse.org/bugs/
> show_bug.cgi?id=515873 because the NPE is misleading. Whether an
> exception should be shown or not is discussable. Felix is not showing
> anything at all, which also makes it hard to find the reason why the
> service is not activated. Therefore logging the exception is perfectly fine
> in my opinion. But the NPE when using the field strategy looks incorrect to
> me. It doesn’t help anyway to find the real cause.
>
>
>
> 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] *Im Auftrag von *Thomas Watson
> *Gesendet:* Mittwoch, 26. April 2017 14:38
> *An:* osgi-dev@mail.osgi.org
>
> *Betreff:* Re: [osgi-dev] handling optional/dynamic imports in DS
>
>
>
>
>
> By Private-Package Peter means he packages the optional package internally
> in the bundle but also optionally imports it so that if it is resolved to
> an external provider then that will be used over the internal copy.  The
> Private-Package header in bnd will instruct bnd to package the package
> internally in the jar.

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

Good one Tim!

Oh, and I forgot to show that the "controller" component should be
immediate otherwise it will never activate since nothing should "use" it.

- Ray

On Mon, May 1, 2017 at 1:31 PM, Tim Ward <tim.w...@paremus.com> wrote:

> For a dynamic import your controller could register a listener so that
> when a suitable package appears in the runtime your disabled component gets
> activated without needing to restart the controller.
>
> Tim
>
> Sent from my iPhone
>
> On 1 May 2017, at 17:41, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> Hey All,
> I managed to find a relatively elegant solution to this with pure DS.
>
> Given a component using an optional/dynamic package(s):
>
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable so that DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
>
> A controller is created which does the classloader check:
>
> @Component
> public 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());
> }
> }
> }
>
> If successful, the component is enabled, otherwise, don't!
>
> - Ray
>
>
>
> On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU) <
> dirk.fa...@de.bosch.com> wrote:
>
>> I totally agree that a clean solution would be to extract the service in
>> another bundle with a non optional dependency, as this avoids any runtime
>> issues at the beginning by not starting the bundle. Will think about that
>> for the Platform Runtime after Oxygen, as such a change is not allowed at
>> the current state of the development.
>>
>>
>>
>> Nevertheless I created https://bugs.eclipse.org/bugs/
>> show_bug.cgi?id=515873 because the NPE is misleading. Whether an
>> exception should be shown or not is discussable. Felix is not showing
>> anything at all, which also makes it hard to find the reason why the
>> service is not activated. Therefore logging the exception is perfectly fine
>> in my opinion. But the NPE when using the field strategy looks incorrect to
>> me. It doesn’t help anyway to find the real cause.
>>
>>
>>
>> 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] *Im Auftrag von *Thomas Watson
>> *Gesendet:* Mittwoch, 26. April 2017 14:38
>> *An:* osgi-dev@mail.osgi.org
>>
>> *Betreff:* Re: [osgi-dev] handling optional/dynamic imports in DS
>>
>>
>>
>> By Private-Package Peter means he packages the optional package
>> internally in the bundle but also optionally imports it so that if it is
>> resolved to an external provider then that will be used over the internal
>> copy.  The Private-Package header in bnd will instruct bnd to package the
>> package internally in the jar.
>>
>>
>>
>> Personally, if I had this scenario I would extract the service component
>> out to a new bundle that has a non-optional import for the package and be
>> done with the magic of dynamic or optional imports.  Or if that is not what
>> you want I would make it a fragment the that has a non-optional import.
>> That way the bundle with the service component cannot possibly provide its
>> service component until it is resolved.
>>
>>
>>
>> I'm not sure I follow your example that is failing in equinox, but open a
>> bug if you find it is an Equinox bug.
>>
>>
>> Tom
>>
>>
>>
>>
>>
>>
>> - Original message -
>> From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bo

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

9*)
>
>at org.apache.felix.scr.impl.inject.FieldHandler.access$500(
> *FieldHandler.java:51*)
>
>at org.apache.felix.scr.impl.inject.FieldHandler$
> NotResolved.resolve(*FieldHandler.java:839*)
>
>at org.apache.felix.scr.impl.inject.FieldHandler$
> NotResolved.fieldExists(*FieldHandler.java:864*)
>
>at org.apache.felix.scr.impl.inject.FieldHandler.fieldExists(
> *FieldHandler.java:918*)
>
>at org.apache.felix.scr.impl.inject.FieldHandler$3.init(
> *FieldHandler.java:1018*)
>
>at org.apache.felix.scr.impl.manager.DependencyManager.
> invokeInitMethod(*DependencyManager.java:1657*)
>
>at org.apache.felix.scr.impl.manager.DependencyManager.open(
> *DependencyManager.java:1533*)
>
>at org.apache.felix.scr.impl.manager.SingleComponentManager.
> createImplementationObject(*SingleComponentManager.java:261*)
>
>at org.apache.felix.scr.impl.manager.SingleComponentManager.
> createComponent(*SingleComponentManager.java:109*)
>
>at org.apache.felix.scr.impl.manager.SingleComponentManager.
> getService(*SingleComponentManager.java:906*)
>
>at org.apache.felix.scr.impl.manager.SingleComponentManager.
> getServiceInternal(*SingleComponentManager.java:879*)
>
>at org.apache.felix.scr.impl.manager.SingleComponentManager.
> getService(*SingleComponentManager.java:823*)
>
>at org.eclipse.osgi.internal.serviceregistry.
> ServiceFactoryUse$1.run(*ServiceFactoryUse.java:212*)
>
>at java.security.AccessController.doPrivileged(*Native Method*)
>
>at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.
> factoryGetService(*ServiceFactoryUse.java:210*)
>
>... 46 more
>
>
>
> 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 *Peter Kriens
> *Gesendet:* Mittwoch, 26. April 2017 09:14
> *An:* OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> *Betreff:* Re: [osgi-dev] handling optional/dynamic imports in DS
>
>
>
> I used to import the package optional and then provide it as an internal
> Private-Package. The import has priority but the internal package is used
> when the import fails to resolve. Since you’re then always wired to a
> package you can handle dependencies on the place they should be handled:
> services.
>
>
>
> This keeps everybody happy internally for very little cost. I’ve included
> a bndtools/enRoute example.
>
>
>
> Kind regards,
>
>
>
> Peter Kriens
>
>
>
>
>
> — bnd.bnd
>
> Private-Package: \
>
> org.osgi.service.cm,\
>
> com.foo.provider
>
>
>
> Import-Package: \
>
> org.osgi.service.cm;resolution:=optional,\
>
> *
>
>
>
> -buildpath: \
>
> osgi.enroute.base.api
>
> -runrequires: \
>
> osgi.identity;filter:='(osgi.identity=com.foo.provider)',\
>
> osgi.identity;filter:='(osgi.identity=org.apache.felix.
> gogo.runtime)',\
>
> osgi.identity;filter:='(osgi.identity=org.apache.felix.
> gogo.shell)',\
>
> osgi.identity;filter:='(osgi.identity=org.apache.felix.
> gogo.command)'
>
> -runbundles: \
>
> com.foo.provider;version=snapshot,\
>
> org.apache.felix.log;version='[1.0.1,1.0.2)',\
>
> org.apache.felix.scr;version='[2.0.2,2.0.3)',\
>
> org.apache.felix.gogo.runtime,\
>
> org.apache.felix.gogo.shell;version=0.16
>
>
>
> — com.foo.provider.Optional
>
> @Component
>
> public class Optional
>
> {
>
>@Reference(cardinality=ReferenceCardinality.OPTIONAL)
>
>ConfigurationAdmin admin;
>
>
>
>@Activate
>
>void activate() {
>
>   System.out.println("activate " + admin);
>
>}
>
> }
>
>
>
> On 25 Apr 2017, at 23:10, 

Re: [osgi-dev] handling optional/dynamic imports in DS

[Raymond Auge]

On Tue, Apr 25, 2017 at 6:16 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> Not sure if that is possible...
>
> I think it would be awesome if the DS runtime could try to load the
> component class and if it fails because of an unwired package
> it could simply choose to not instantiate the component. It could also
> report this problem when you look into the components from the shell.
>
> When the bundle is then refreshed later it could try the same again and
> maybe succeed if the package is wired now.
> The big advantage would be that the user would not have to code anything
> to make this work.
> Currently handling optional imports using an Activator is quite difficult
> and error prone.
>
> Does that make sense?
>

I totally agree!

- Ray


>
> Christian
>
>
>
> On 26.04.2017 00:06, Raymond Auge wrote:
>
> You're not far off,
>
> but clearly the component could not be implementing the missing package...
>
> Let's say we have an API:
>
> interface com.foo.Provider {
> public void provide();
> }
>
> a bundle wants to provide an implementation of this API:
>
> @Component
> class FancyProviderImpl implements com.foo.Provider { ... }
>
> However the goal of FancyProviderImpl is to deliver functionality by using
> fancy-lib.jar which is a second bundle.
>
> e.g.
>
> import fancy.lib.Thing;
> @Component
> class FancyProviderImpl implements com.foo.Provider {
> public void provide() {
> new Thing().doSomethingFancy();
> }
> }
>
> I'd like for the bundle containing FancyProviderImpl to have an optional
> import on `fancy.lib`, and not blow up when `fancy-lib.jar` is not
> deployed. Exactly the same scenario you mentioned with configAdmin,
> metatype and SCR.
>
> I hope that makes sense,
> - Ray
>
>
> On Tue, Apr 25, 2017 at 5:51 PM, Felix Meschberger <fmesc...@adobe.com>
> wrote:
>
>> Hi Ray
>>
>> I am not sure, I understand the question.
>>
>> Are you asking that the component dynamically decides to register as a
>> certain service depending on the whether a certain package is wired ?
>>
>> I think that does not work as the component implements an interface which
>> is the service name and the component class can only be loaded if the class
>> object representing the interface being implemented is accessible,
>> otherwise a Linkage error occurrs.
>>
>> Or may I am on the wrong track alltogether.
>>
>> Regards
>> Felix
>>
>> Am 25.04.2017 um 14:46 schrieb Raymond Auge <raymond.a...@liferay.com>:
>>
>> Thank you Felix, I agree and understand all of what you are saying.
>>
>> However, what I'm wondering though is if anyone has come up with a design
>> pattern where a DS component can determine programmatically whether it (or
>> a peer component it controls) should be provided as a service based on the
>> check for some optional package.
>>
>> Sincerely,
>> - Ray
>>
>> On Tue, Apr 25, 2017 at 5:33 PM, Felix Meschberger <fmesc...@adobe.com>
>> wrote:
>>
>>> Hi
>>>
>>> You mean dynamic imports due to optional dependencies ?
>>>
>>> I think the key is to limit them. If I remember correctly I have (or
>>> had) some of this in the Apache Felix SCR implementation around the
>>> Metatype and Configuration Admin dependencies.
>>>
>>> What I do is I hand-craft a DynamicImport-Package statement for the
>>> exact package along with the packages import version range. Then, unless
>>> the service is provided, the package may not be resolved.
>>>
>>> I generally also have fields, but as long as I don’t access that field
>>> other than checking for null, the dependency is not needed either.
>>>
>>> This works great, but I try to reduce such uses to the absolute minimum
>>> because it involves manual work.
>>>
>>> Hope this helps
>>>
>>> Regards
>>> Felix
>>>
>>> Am 25.04.2017 um 14:10 schrieb Raymond Auge <raymond.a...@liferay.com>:
>>>
>>> I'm wondering if there is a reasonable model for handling optional or
>>> dynamic package imports in DS.
>>>
>>> While optionality at the package level is not an ideal model, sometimes
>>> it can't be avoided.
>>>
>>> I'd like to know if others have come across a "reasonable" way to model
>>> this in DS.
>>>
>>> Sincerely,
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>&