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

2019-01-30 Thread Nhut Thai Le via osgi-dev
Thank you Raymond,

Turn out eclipse oxygen doesn't support DS 1.4 yet so i'll stick with the
Component property for now

Thai

On Wed, Jan 30, 2019 at 1:50 PM Raymond Auge 
wrote:

> You need to make sure that the build tool you are using supports the
> handling of bundle annotations.
>
> This is at minimum bnd 4.1.0 (so maven-bundle-plugin 4.1.0,, Bndtools
> 4.1.0, bnd-maven-plugin 4.1.0). You may be able to get away with bnd 4.0.0
> in some cases, but the support for bundle annotations wasn't quite complete
> yet.
>
> - Ray
>
> On Wed, Jan 30, 2019 at 1:40 PM Nhut Thai Le  wrote:
>
>> Tim,
>>
>> I changed the text properties to annotations:
>>
>> @Component(service = Application.class)
>> @JaxrsName(DiagramConstants.REST_APP)
>> @JaxrsApplicationBase("diagram/services/diagrams/rest")
>> public final class DiagramRestApp extends Application {}
>>
>> But i now see the service xml regenerated in my OSGI-INF folder lost the
>> application base and name properties:
>> 
>> http://www.osgi.org/xmlns/scr/v1.1.0;
>> activate="activate"
>> name="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp">
>>
>>   
>>
>>> class="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp"/>
>> 
>>
>> Inspecting the service also yield that the properties are missing:
>> se javax.ws.rs.core.Application
>> ...
>> {javax.ws.rs.core.Application}={service.id=580, service.bundleid=454,
>> service.scope=bundle, 
>> component.name=com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp,
>> component.id=1113}
>>   "Registered by bundle:"
>> com.castortech.iris.ba.diagrams.provider_1.0.0.qualifier [454]
>>   "No bundles using service."
>> ...
>>
>> Thus when i make a request to the REST api, i got 404.
>>
>> Is the missing properties causes aries jaxrs not pickup the service ? If
>> it is, then do you have an idea why the properties is missing when using
>> jaxrs annotations?
>>
>> Thai
>>
>>
>> On Wed, Jan 30, 2019 at 11:56 AM Tim Ward  wrote:
>>
>>>
>>>
>>> On 30 Jan 2019, at 16:52, Nhut Thai Le  wrote:
>>>
>>> Tim,
>>>
>>> Thank you for quickly identify my problems :D, please see my comments
>>> inline
>>>
>>> On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  wrote:
>>>
 Hi,

 Firstly:

 Why does DiagramRestApp do this?

   @Override
   public Set getSingletons() {
   return Collections.singleton(this);
   }


 That is just all kinds of wrong!

>>> i'm using aries-jaxrs-whiteboard for our REST api and i was was looking
 at the test to see how to build the Application class, i think this is what
 i was following:
 https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java.
 I got some errors at that time without the getSingletons() so i left it
 there. Now i just removed it and it seem fine.

>>>
>>> In this case the TestApplication class is a resource class (it declares
>>> resource methods). It’s still horrible to do this, but it’s being done to
>>> reduce the number of types in the test.
>>>
>>>
 Secondly, you’re using String properties everywhere rather than the
 annotations. This is asking for trouble with typos and inconsistencies.
 You are right, i should change to annotations

 Next:

 The following:

 @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

 @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 {...}


 These types declare that they are extensions - why? They don’t
 advertise any extension interfaces. They should advertise themselves as
 resources (which is what they are). I would not expect these to be picked
 up properly by the whiteboard as they are not extensions and they don’t
 advertise being resources.

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

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

2019-01-30 Thread Raymond Auge via osgi-dev
You need to make sure that the build tool you are using supports the
handling of bundle annotations.

This is at minimum bnd 4.1.0 (so maven-bundle-plugin 4.1.0,, Bndtools
4.1.0, bnd-maven-plugin 4.1.0). You may be able to get away with bnd 4.0.0
in some cases, but the support for bundle annotations wasn't quite complete
yet.

- Ray

On Wed, Jan 30, 2019 at 1:40 PM Nhut Thai Le  wrote:

> Tim,
>
> I changed the text properties to annotations:
>
> @Component(service = Application.class)
> @JaxrsName(DiagramConstants.REST_APP)
> @JaxrsApplicationBase("diagram/services/diagrams/rest")
> public final class DiagramRestApp extends Application {}
>
> But i now see the service xml regenerated in my OSGI-INF folder lost the
> application base and name properties:
> 
> http://www.osgi.org/xmlns/scr/v1.1.0;
> activate="activate"
> name="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp">
>
>   
>
> class="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp"/>
> 
>
> Inspecting the service also yield that the properties are missing:
> se javax.ws.rs.core.Application
> ...
> {javax.ws.rs.core.Application}={service.id=580, service.bundleid=454,
> service.scope=bundle, 
> component.name=com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp,
> component.id=1113}
>   "Registered by bundle:"
> com.castortech.iris.ba.diagrams.provider_1.0.0.qualifier [454]
>   "No bundles using service."
> ...
>
> Thus when i make a request to the REST api, i got 404.
>
> Is the missing properties causes aries jaxrs not pickup the service ? If
> it is, then do you have an idea why the properties is missing when using
> jaxrs annotations?
>
> Thai
>
>
> On Wed, Jan 30, 2019 at 11:56 AM Tim Ward  wrote:
>
>>
>>
>> On 30 Jan 2019, at 16:52, Nhut Thai Le  wrote:
>>
>> Tim,
>>
>> Thank you for quickly identify my problems :D, please see my comments
>> inline
>>
>> On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  wrote:
>>
>>> Hi,
>>>
>>> Firstly:
>>>
>>> Why does DiagramRestApp do this?
>>>
>>>   @Override
>>>   public Set getSingletons() {
>>>   return Collections.singleton(this);
>>>   }
>>>
>>>
>>> That is just all kinds of wrong!
>>>
>> i'm using aries-jaxrs-whiteboard for our REST api and i was was looking
>>> at the test to see how to build the Application class, i think this is what
>>> i was following:
>>> https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java.
>>> I got some errors at that time without the getSingletons() so i left it
>>> there. Now i just removed it and it seem fine.
>>>
>>
>> In this case the TestApplication class is a resource class (it declares
>> resource methods). It’s still horrible to do this, but it’s being done to
>> reduce the number of types in the test.
>>
>>
>>> Secondly, you’re using String properties everywhere rather than the
>>> annotations. This is asking for trouble with typos and inconsistencies.
>>> You are right, i should change to annotations
>>>
>>> Next:
>>>
>>> The following:
>>>
>>> @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
>>>
>>> @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 {...}
>>>
>>>
>>> These types declare that they are extensions - why? They don’t advertise
>>> any extension interfaces. They should advertise themselves as resources
>>> (which is what they are). I would not expect these to be picked up properly
>>> by the whiteboard as they are not extensions and they don’t advertise being
>>> resources.
>>>
>> 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:
>>> 

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

2019-01-30 Thread Tim Ward via osgi-dev


> On 30 Jan 2019, at 16:52, Nhut Thai Le  wrote:
> 
> Tim, 
> 
> Thank you for quickly identify my problems :D, please see my comments inline
> 
> On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  > wrote:
> Hi,
> 
> Firstly:
> 
> Why does DiagramRestApp do this?
> 
>>   @Override
>>   public Set getSingletons() {
>>   return Collections.singleton(this);
>>   }
> 
> That is just all kinds of wrong!
> i'm using aries-jaxrs-whiteboard for our REST api and i was was looking at 
> the test to see how to build the Application class, i think this is what i 
> was following: 
> https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java
>  
> .
>  I got some errors at that time without the getSingletons() so i left it 
> there. Now i just removed it and it seem fine.

In this case the TestApplication class is a resource class (it declares 
resource methods). It’s still horrible to do this, but it’s being done to 
reduce the number of types in the test.

> 
> Secondly, you’re using String properties everywhere rather than the 
> annotations. This is asking for trouble with typos and inconsistencies.
> You are right, i should change to annotations
> 
> Next:
> 
> The following:
> 
>> @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
> 
>> @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 {...}
> 
> 
> These types declare that they are extensions - why? They don’t advertise any 
> extension interfaces. They should advertise themselves as resources (which is 
> what they are). I would not expect these to be picked up properly by the 
> whiteboard as they are not extensions and they don’t advertise being 
> resources.
> 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", 
>>   
>> 

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

2019-01-30 Thread Nhut Thai Le via osgi-dev
Tim,

Thank you for quickly identify my problems :D, please see my comments inline

On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  wrote:

> Hi,
>
> Firstly:
>
> Why does DiagramRestApp do this?
>
>   @Override
>   public Set getSingletons() {
>   return Collections.singleton(this);
>   }
>
>
> That is just all kinds of wrong!
>
i'm using aries-jaxrs-whiteboard for our REST api and i was was looking at
> the test to see how to build the Application class, i think this is what i
> was following:
> https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java.
> I got some errors at that time without the getSingletons() so i left it
> there. Now i just removed it and it seem fine.
>

> Secondly, you’re using String properties everywhere rather than the
> annotations. This is asking for trouble with typos and inconsistencies.
> You are right, i should change to annotations
>
> Next:
>
> The following:
>
> @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
>
> @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 {...}
>
>
> These types declare that they are extensions - why? They don’t advertise
> any extension interfaces. They should advertise themselves as resources
> (which is what they are). I would not expect these to be picked up properly
> by the whiteboard as they are not extensions and they don’t advertise being
> resources.
>
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
>>> 
>>>  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
>>> 

Re: [osgi-dev] Limks to R7 ionline spec

2019-01-30 Thread Tim Ward via osgi-dev
When I type "osgi specifications” into Google the first links I get are:

To the main specifications page you’re already at (this requires you to follow 
the download link for the version you want)
To the HTML version of the R7 core specification
To the HTML version of the R7 compendium specification
To the wikipedia page listing OSGi specification implementations

After that the signal to noise ratio drops pretty rapidly, but that top 4 feels 
like a pretty good hit rate to me.

If I type:

"OSGi  specifications” into Google then the top link is the HTML 
version of that specification.

Again, this feels like a pretty good hit rate to me, but if you have more ideas 
of things that could be done then please let us know. The intent is that these 
documents are easy to find!

Best Regards,

Tim

> On 30 Jan 2019, at 10:36, Paul F Fraser via osgi-dev  
> wrote:
> 
> Hi David,
> 
> That is fine if you know that.
> But searching with google it is almost impossible (or I find it almost 
> impossible)  to find the online vsersion or even know it exists unless you 
> stumble upon a link that takes you into the online version.
> 
> Paul
> 
> On 30/01/2019 9:00 pm, David Bosschaert wrote:
>> Hi Paul,
>> 
>> If I follow the Download links from there I end up at the actual page that 
>> contains the specs: https://www.osgi.org/release-7-1/ 
>> 
>> That page contains both the PDFs as well as the online ones...
>> 
>> Best regards,
>> 
>> David 
>> 
>> On Wed, 30 Jan 2019 at 00:00, Paul F Fraser via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> Hi,
>> 
>> Who or how do I tell someone that the page 
>> https://www.osgi.org/developer/specifications/ 
>>  needs 
>> links to the online spec.
>> 
>> The bugs and issues area  seems difficult to use without further study.
>> 
>> A low friction way to report these, relatively minor, but annoying aspects 
>> of the search for OSGi 
>> knowledge would be useful.
>> 
>> I suppose someone will suggest that I fix it, but this misses the point.
>> 
>> 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

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

Re: [osgi-dev] Loading xxxApp contents has encountererd NPE

2019-01-30 Thread Paul F Fraser via osgi-dev

Thanks Tim,
Good to know you are not experiencing this. I presume you are using eclipse?
I am using m2e exclusively, no command line, could be the problem. Will try with cli and see what 
happens.

Paul


On 30/01/2019 8:28 pm, Tim Ward wrote:

Hi Paul,

It’s not normal to see NPEs during your build, but I also don’t see them when 
using OSGi enRoute. Assuming that you can identify the Maven plugin causing the 
problem it might be worth talking to the maintainers of the plugin. At the very 
least it’s hard to diagnose without more details, such as the stack trace and 
the log entries leading up to it.

Best Regards,

Tim


On 30 Jan 2019, at 06:04, Paul F Fraser via osgi-dev  
wrote:

Hi,

Now heavily into new enRoute, I am getting quite regularly (multiple) NPEs 
during build. Does not seem to affect runtime.

Is this a normal situation or should I look for a problem in my code? Any clues?

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

Re: [osgi-dev] Limks to R7 ionline spec

2019-01-30 Thread Paul F Fraser via osgi-dev

Hi David,

That is fine if you know that.
But searching with google it is almost impossible (or I find it almost impossible)  to find the 
online vsersion or even know it exists unless you stumble upon a link that takes you into the online 
version.


Paul

On 30/01/2019 9:00 pm, David Bosschaert wrote:

Hi Paul,

If I follow the Download links from there I end up at the actual page that contains the specs: 
https://www.osgi.org/release-7-1/

That page contains both the PDFs as well as the online ones...

Best regards,

David

On Wed, 30 Jan 2019 at 00:00, Paul F Fraser via osgi-dev > wrote:


Hi,

Who or how do I tell someone that the page 
https://www.osgi.org/developer/specifications/ needs
links to the online spec.

The bugs and issues area  seems difficult to use without further study.

A low friction way to report these, relatively minor, but annoying aspects 
of the search for OSGi
knowledge would be useful.

I suppose someone will suggest that I fix it, but this misses the point.

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

Re: [osgi-dev] Limks to R7 ionline spec

2019-01-30 Thread David Bosschaert via osgi-dev
Hi Paul,

If I follow the Download links from there I end up at the actual page that
contains the specs: https://www.osgi.org/release-7-1/
That page contains both the PDFs as well as the online ones...

Best regards,

David

On Wed, 30 Jan 2019 at 00:00, Paul F Fraser via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi,
>
> Who or how do I tell someone that the page
> https://www.osgi.org/developer/specifications/ needs
> links to the online spec.
>
> The bugs and issues area  seems difficult to use without further study.
>
> A low friction way to report these, relatively minor, but annoying aspects
> of the search for OSGi
> knowledge would be useful.
>
> I suppose someone will suggest that I fix it, but this misses the point.
>
> 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

Re: [osgi-dev] Prototype scope components and Fluent builder

2019-01-30 Thread Tim Ward via osgi-dev
I’m not quite sure what this question means, but the most obvious 
interpretation is “how should I deal with registering a service that is a 
fluent builder?”. 

The JAX-RS Whiteboard does this with the ClientBuilder service 
. 
And the way in which it works is highly related to the rules of the builder. In 
the case of the ClientBuilder the builder returns this not a copy, therefore it 
is not possible for multiple components to share a single builder service. 
Therefore the builder must be registered and used as a prototype scope service.

If (and only if) your builder creates copies of itself each time a method on it 
is called then it is safe to use it as a singleton or bundle scoped service. 
This situation is comparatively rare.

I hope this helps.

Tim

> On 29 Jan 2019, at 16:39, Alain Picard via osgi-dev  
> wrote:
> 
> I am curious if there is a prescribed or suggested approach to use fluent 
> builder in conjunction with Fluent builders?
> 
> Cheers,
> 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

Re: [osgi-dev] Loading xxxApp contents has encountererd NPE

2019-01-30 Thread Tim Ward via osgi-dev
Hi Paul,

It’s not normal to see NPEs during your build, but I also don’t see them when 
using OSGi enRoute. Assuming that you can identify the Maven plugin causing the 
problem it might be worth talking to the maintainers of the plugin. At the very 
least it’s hard to diagnose without more details, such as the stack trace and 
the log entries leading up to it.

Best Regards,

Tim

> On 30 Jan 2019, at 06:04, Paul F Fraser via osgi-dev  
> wrote:
> 
> Hi,
> 
> Now heavily into new enRoute, I am getting quite regularly (multiple) NPEs 
> during build. Does not seem to affect runtime.
> 
> Is this a normal situation or should I look for a problem in my code? Any 
> clues?
> 
> 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