Re: [osgi-dev] Component being activated twice?

[Benson Margulies]

On Wed, Nov 23, 2016 at 11:35 AM, Christian Schneider
 wrote:
> Good question. I think one issue with not installing the scr feature is that
> you do not have the scr karaf commands.
> Apart from that not installing the scr feature would make it easier for
> bndtools users.

Well, if you have Karaf shell-compat, you have the scr gogo  commands,
which are a more useful superset in some of our opinions.



> Maybe you can create a pull request on the documentation and discuss with
> the maintainers if the change is good.
>
> Christian
>
>
> On 23.11.2016 17:27, Tim Ward wrote:
>
> OK, so if I feature:uninstall scr from Karaf I can let Resolve do its thing
> and everything works.
>
> Is that an error in
>
> http://enroute.osgi.org/appnotes/bndtools-and-karaf.html
>
> then?
>
> On 23/11/2016 16:23, Christian Schneider wrote:
>
> -runfw just sets the OSGi framework. Karaf basically also does this inside
> when you can choose between felix and equinox but karaf is a lot more than
> that.
> So correctly setting up bndtools for karaf as a runtime will involve a lot
> more than -rnfw.
>
> I think there currently is not complete solution for this but I am also be
> very interested in the combination of karaf and bndtools.
>
> Christian
>
> On 23.11.2016 17:18, Tim Ward wrote:
>
> I was sort-of guessing that that's what -runfw was about, but didn't find
> enough documentation to be able to understand it. Via monkey-see monkey-do
> cut-and-paste I've ended up with
>
> -runfw: org.apache.felix.framework;version='[5.6.1,5.6.1]'
>
> which clearly does NOT tell it "you are running on Karaf, with such-and-such
> list of other bundles installed".
>
> Further, I was sort-of guessing that -runblacklist might be relevant here,
> but was puzzled to find it expressed (in the GUI) in terms of bundles?
> packages? rather than capabilities.
>
> But it's not what I want, because putting the unwanted bundle in as a
> blacklisted item gets me
>
> ==
> Unable to resolve <> version=null:
>missing requirement com.telensa.apps.planet.p2c.provider
>
> ->  Unable to resolve com.telensa.apps.planet.p2c.provider
> version=1.0.0.201611231522:
>missing requirement org.osgi.service.component; version=[1.3.0,2.0.0)]
> ==
>
> when I try to resolve.
>
> Another point which might relate to duplicate scrs: in
> http://enroute.osgi.org/appnotes/bndtools-and-karaf.html it says to do
>
> karaf@root(bundle)> feature:install scr
>
> Did that contribute to my problem? Should I alternatively uninstall that
> feature?
>
> On 23/11/2016 16:06, Timothy Ward wrote:
>
> Isn’t this exactly what enRoute was trying to do with the distros?
>
> Regards,
>
> Tim
>
> On 23 Nov 2016, at 16:05, Raymond Auge  wrote:
>
> @Peter this is exactly a scenario I'd love to be able to eliminate by
> exposing the target runtime as a repo which we can specify as the the BASE
> for the resolver.
>
> - Ray
>
> On Wed, Nov 23, 2016 at 11:04 AM, Tim Ward  wrote:
>>
>> So, if I manually delete
>>
>> org.apache.felix.scr
>>
>> from -runbundles then both symptoms go away.
>>
>> All I've got to do now is try to find out how to stop the Resolve button
>> putting it back in every time?
>>
>>
>> On 23/11/2016 15:58, Peter Kriens wrote:
>>
>> That sounds a bit like scr is started twice.
>>
>> Sounds? Are their other possible explanations?
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 23 Nov 2016, at 16:49, Christian Schneider 
>> wrote:
>>
>> On 23.11.2016 16:47, Tim Ward wrote:
>>
>> OK, doesn't look like configuration.
>>
>> - Comment out @RequireConfigureExtender
>> - Resolve
>> - Confirm that osgi.enroute.configurer.simple.provider no longer appears
>> in -runbundles
>> - Confirm that osgi.enroute.configurer.simple.provider no longer appears
>> in Karaf's "list" command
>> - Restart Karaf and run it again
>>
>> and the same happens.
>>
>> By the way, I also get the following from time to time in the log, which
>> I've ignored so far, but it does suggest that my component isn't the only
>> thing being started twice?
>>
>> 2016-11-23 15:43:43,266 | INFO  | pool-61-thread-3 | ScrServiceMBeanImpl
>> | 55 - org.apache.karaf.scr.management - 4.0.7 | Activating the Apache Karaf
>> SCR Service MBean
>> 2016-11-23 15:43:43,268 | ERROR | pool-61-thread-3 | ScrServiceMBeanImpl
>> | 55 - org.apache.karaf.scr.management - 4.0.7 | Exception registering the
>> SCR Management MBean: org.apache.karaf:type=scr,name=root
>> javax.management.InstanceAlreadyExistsException:
>> org.apache.karaf:type=scr,name=root
>>at
>> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_60]
>>
>> That sounds a bit like scr is started twice.
>>
>> Christian
>>
>> --
>
>
>
>
> --
> Tim Ward
>
>
>
> ___
> OSGi Developer Mail List
> 

Re: [osgi-dev] OSGi factory pids and configuration admin

[Benson Margulies]

p.s. Thank you, those emails rescued me from the confused state I
landed in reading the fileinstall code.

On Mon, Nov 21, 2016 at 2:09 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> I am really only concerned with fileinstall as a model/example of what
> I am trying to do. Let me try again and nearly eliminate all evidence
> of it from my question.
>
> Step 1: Code in CXF does:
>
> Properties servProps = new Properties();
> servProps.put(Constants.SERVICE_PID, FACTORY_PID);
> reg = context.registerService(ManagedServiceFactory.class.getName(),
>this, servProps);
>
> That FACTORY_PID is org.apache.cxf.http.jetty.
>
> Step 2:
>
> I call createFactoryConfiguration on "org.apache.cxf.http.jetty" with
> some properties.
>
> Step 3:
>
> I decide that I have changed my mind, and I want to adjust one of the values.
>
> So I think I need to do what Mr. Ward had explained and use a property
> to identify my particular configuration.
>
> I think that the 'magic property' in the fileinstall case is probably
> the property they use for their file name, and that's why I missed it,
> but I don't need to deal with that.
>
>
>
>
>
> On Mon, Nov 21, 2016 at 1:49 PM, BJ Hargrave <hargr...@us.ibm.com> wrote:
>> I think you need to ask this in a felix list since you are asking about how
>> felix fileinstall works.
>>
>> --
>>
>> 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: Benson Margulies <bimargul...@gmail.com>
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
>> Cc:
>> Subject: [osgi-dev] OSGi factory pids and configuration admin
>> Date: Mon, Nov 21, 2016 1:34 PM
>>
>> Given a factory pid of a.b.c, and a pid of q, I am a little
>> disoriented about how to manage some properties.
>>
>> Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.
>> It calls createFactoryConfiguration for 'a.b.c', and ignores the q.
>>
>> The 'updated' method on the service is called on a pid like
>> 'a.b.c.UNIQUE-STRING'.
>>
>> Do I need to add something to the properties so that the pid remains
>> 'a.b.c-q'?
>>
>> As it is, I'm failing to use a second call to configuration admin to
>> update one of the properties.
>> ___
>> 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

[osgi-dev] OSGi factory pids and configuration admin

[Benson Margulies]

Given a factory pid of a.b.c, and a pid of q, I am a little
disoriented about how to manage some properties.

Felix fileinstall parses a.b.c-q as 'pid = a.b.c', factoryPid = 'q'.
It calls createFactoryConfiguration for 'a.b.c', and ignores the q.

The 'updated' method on the service is called on a pid like
'a.b.c.UNIQUE-STRING'.

Do I need to add something to the properties so that the pid remains 'a.b.c-q'?

As it is, I'm failing to use a second call to configuration admin to
update one of the properties.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Is there an enroute http service?

[Benson Margulies]

I will.

On Fri, Nov 18, 2016 at 8:48 AM, Peter Kriens <peter.kri...@aqute.biz> wrote:
> You filed a bug at KF?
>
> Kind regards,
>
> Peter Kriens
>
>> On 18 nov. 2016, at 14:43, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> Unfortunately, the felix web console provokes NPE's in the KF http
>> service. I'll stick to the Felix lite alternative.
>>
>> On Thu, Nov 17, 2016 at 3:12 PM, Christer Larsson <c...@makewave.com> wrote:
>>> Hi
>>>
>>> The repo is there, but after moving the whole web site to github.io we 
>>> discovered that directory listing / browsing is not supported on github.io 
>>> pages ;-)
>>>
>>> There is a complete listing at:
>>> http://www.knopflerfish.org/releases/6.0.0/maven2/org/knopflerfish/KF-6.0.0_dependencyManagement.xml
>>>
>>> This is the direct link;
>>> http://www.knopflerfish.org/releases/6.0.0/maven2/org/knopflerfish/bundle/http/5.2.0/http-5.2.0.jar
>>>
>>> You will also need the Servlet API:
>>> http://www.knopflerfish.org/releases/6.0.0/maven2/org/knopflerfish/bundle/jsdk-API/2.5.0.kf3-2/jsdk-API-2.5.0.kf3-2.jar
>>>
>>> Please note that Servlet API 3+ is not supported. At least not yet.
>>>
>>> Regards,
>>> Christer
>>>
>>> --
>>> Christer Larsson
>>> Makewave, http://www.makewave.com
>>> VP EMEA OSGi Alliance, http://www.osgi.org
>>> Knopflerfish OSGi, http://www.knopflerfish.org
>>>
>>>> On 2016-11-17, at 20:15, Benson Margulies <bimargul...@gmail.com> wrote:
>>>>
>>>> /Per, I can't figure out how to find this in any public maven repo.
>>>> The repo described http://www.knopflerfish.org/maven.html can't be
>>>> browsed, and jcenter does not show it when searched contra the text on
>>>> the page.
>>>>
>>>>
>>>> On Thu, Nov 17, 2016 at 1:01 PM,  <p...@makewave.com> wrote:
>>>>> Knopflerfish has one too:
>>>>> http://www.knopflerfish.org/releases/6.0.0/docs/bundledoc/index.html?docpage=http/index.html
>>>>>
>>>>> /Per
>>>>>
>>>>>
>>>>> On 2016-11-17 18:13, Benson Margulies wrote:
>>>>>>
>>>>>> On Thu, Nov 17, 2016 at 11:54 AM, Peter Kriens <peter.kri...@aqute.biz>
>>>>>> wrote:
>>>>>>>
>>>>>>> I think there is (or was?) also another Http server for embedded 
>>>>>>> designs.
>>>>>>>
>>>>>>> I was right! https://github.com/apache/felix/tree/trunk/httplite
>>>>>>
>>>>>>
>>>>>> Oh! well, that's interesting. Thanks!
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Peter Kriens
>>>>>>>
>>>>>>> On 17 nov. 2016, at 17:10, Benson Margulies <bimargul...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Thu, Nov 17, 2016 at 11:05 AM, Peter Kriens <peter.kri...@aqute.biz>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I think there is a simple Http server at Felix written by someone from
>>>>>>> Bug
>>>>>>> labs?
>>>>>>>
>>>>>>>
>>>>>>> That's Felix HTTP. It isn't simple. It uses Jetty, and exports Jetty
>>>>>>> packages in a problematic way, and has some other issues I've hit. I'm
>>>>>>> in a bit of a hurry to try to finish something, and if there had been
>>>>>>> a true self-contained http service available from enroute, that might
>>>>>>> have done the trick.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>>  Peter Kriens
>>>>>>>
>>>>>>> On 17 nov. 2016, at 16:37, Benson Margulies <bimargul...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> We've had some problems with pax-web and felix HTTP, so I was looking
>>>>>>> around, and read:
>>>>>>>
>>>>>>> http://enroute.osgi.org/services/org.osgi.service.http.html
&

Re: [osgi-dev] Is there an enroute http service?

[Benson Margulies]

Unfortunately, the felix web console provokes NPE's in the KF http
service. I'll stick to the Felix lite alternative.

On Thu, Nov 17, 2016 at 3:12 PM, Christer Larsson <c...@makewave.com> wrote:
> Hi
>
> The repo is there, but after moving the whole web site to github.io we 
> discovered that directory listing / browsing is not supported on github.io 
> pages ;-)
>
> There is a complete listing at:
> http://www.knopflerfish.org/releases/6.0.0/maven2/org/knopflerfish/KF-6.0.0_dependencyManagement.xml
>
> This is the direct link;
> http://www.knopflerfish.org/releases/6.0.0/maven2/org/knopflerfish/bundle/http/5.2.0/http-5.2.0.jar
>
> You will also need the Servlet API:
> http://www.knopflerfish.org/releases/6.0.0/maven2/org/knopflerfish/bundle/jsdk-API/2.5.0.kf3-2/jsdk-API-2.5.0.kf3-2.jar
>
> Please note that Servlet API 3+ is not supported. At least not yet.
>
> Regards,
> Christer
>
> --
> Christer Larsson
> Makewave, http://www.makewave.com
> VP EMEA OSGi Alliance, http://www.osgi.org
> Knopflerfish OSGi, http://www.knopflerfish.org
>
>> On 2016-11-17, at 20:15, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> /Per, I can't figure out how to find this in any public maven repo.
>> The repo described http://www.knopflerfish.org/maven.html can't be
>> browsed, and jcenter does not show it when searched contra the text on
>> the page.
>>
>>
>> On Thu, Nov 17, 2016 at 1:01 PM,  <p...@makewave.com> wrote:
>>> Knopflerfish has one too:
>>> http://www.knopflerfish.org/releases/6.0.0/docs/bundledoc/index.html?docpage=http/index.html
>>>
>>> /Per
>>>
>>>
>>> On 2016-11-17 18:13, Benson Margulies wrote:
>>>>
>>>> On Thu, Nov 17, 2016 at 11:54 AM, Peter Kriens <peter.kri...@aqute.biz>
>>>> wrote:
>>>>>
>>>>> I think there is (or was?) also another Http server for embedded designs.
>>>>>
>>>>> I was right! https://github.com/apache/felix/tree/trunk/httplite
>>>>
>>>>
>>>> Oh! well, that's interesting. Thanks!
>>>>
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Peter Kriens
>>>>>
>>>>> On 17 nov. 2016, at 17:10, Benson Margulies <bimargul...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Thu, Nov 17, 2016 at 11:05 AM, Peter Kriens <peter.kri...@aqute.biz>
>>>>> wrote:
>>>>>
>>>>> I think there is a simple Http server at Felix written by someone from
>>>>> Bug
>>>>> labs?
>>>>>
>>>>>
>>>>> That's Felix HTTP. It isn't simple. It uses Jetty, and exports Jetty
>>>>> packages in a problematic way, and has some other issues I've hit. I'm
>>>>> in a bit of a hurry to try to finish something, and if there had been
>>>>> a true self-contained http service available from enroute, that might
>>>>> have done the trick.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>   Peter Kriens
>>>>>
>>>>> On 17 nov. 2016, at 16:37, Benson Margulies <bimargul...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> We've had some problems with pax-web and felix HTTP, so I was looking
>>>>> around, and read:
>>>>>
>>>>> http://enroute.osgi.org/services/org.osgi.service.http.html
>>>>>
>>>>> This led me to wonder if someone has actually built yet another HTTP
>>>>> service (perhaps a very simple one based on the http server in the
>>>>> JDK), or whether this is just explaining the concept. Maven Central
>>>>> does not seem to have a relevant bundle.
>>>>> ___
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> 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
>> ___
>> 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 an enroute http service?

[Benson Margulies]

/Per, I can't figure out how to find this in any public maven repo.
The repo described http://www.knopflerfish.org/maven.html can't be
browsed, and jcenter does not show it when searched contra the text on
the page.


On Thu, Nov 17, 2016 at 1:01 PM,  <p...@makewave.com> wrote:
> Knopflerfish has one too:
> http://www.knopflerfish.org/releases/6.0.0/docs/bundledoc/index.html?docpage=http/index.html
>
> /Per
>
>
> On 2016-11-17 18:13, Benson Margulies wrote:
>>
>> On Thu, Nov 17, 2016 at 11:54 AM, Peter Kriens <peter.kri...@aqute.biz>
>> wrote:
>>>
>>> I think there is (or was?) also another Http server for embedded designs.
>>>
>>> I was right! https://github.com/apache/felix/tree/trunk/httplite
>>
>>
>> Oh! well, that's interesting. Thanks!
>>
>>
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> On 17 nov. 2016, at 17:10, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>>
>>> On Thu, Nov 17, 2016 at 11:05 AM, Peter Kriens <peter.kri...@aqute.biz>
>>> wrote:
>>>
>>> I think there is a simple Http server at Felix written by someone from
>>> Bug
>>> labs?
>>>
>>>
>>> That's Felix HTTP. It isn't simple. It uses Jetty, and exports Jetty
>>> packages in a problematic way, and has some other issues I've hit. I'm
>>> in a bit of a hurry to try to finish something, and if there had been
>>> a true self-contained http service available from enroute, that might
>>> have done the trick.
>>>
>>>
>>>
>>>
>>> Kind regards,
>>>
>>>Peter Kriens
>>>
>>> On 17 nov. 2016, at 16:37, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>>
>>> We've had some problems with pax-web and felix HTTP, so I was looking
>>> around, and read:
>>>
>>> http://enroute.osgi.org/services/org.osgi.service.http.html
>>>
>>> This led me to wonder if someone has actually built yet another HTTP
>>> service (perhaps a very simple one based on the http server in the
>>> JDK), or whether this is just explaining the concept. Maven Central
>>> does not seem to have a relevant bundle.
>>> ___
>>> 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
>>>
>>>
>>>
>>> ___
>>> 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
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Is there an enroute http service?

[Benson Margulies]

On Thu, Nov 17, 2016 at 11:54 AM, Peter Kriens <peter.kri...@aqute.biz> wrote:
> I think there is (or was?) also another Http server for embedded designs.
>
> I was right! https://github.com/apache/felix/tree/trunk/httplite

Oh! well, that's interesting. Thanks!


>
> Kind regards,
>
> Peter Kriens
>
> On 17 nov. 2016, at 17:10, Benson Margulies <bimargul...@gmail.com> wrote:
>
> On Thu, Nov 17, 2016 at 11:05 AM, Peter Kriens <peter.kri...@aqute.biz>
> wrote:
>
> I think there is a simple Http server at Felix written by someone from Bug
> labs?
>
>
> That's Felix HTTP. It isn't simple. It uses Jetty, and exports Jetty
> packages in a problematic way, and has some other issues I've hit. I'm
> in a bit of a hurry to try to finish something, and if there had been
> a true self-contained http service available from enroute, that might
> have done the trick.
>
>
>
>
> Kind regards,
>
>Peter Kriens
>
> On 17 nov. 2016, at 16:37, Benson Margulies <bimargul...@gmail.com> wrote:
>
> We've had some problems with pax-web and felix HTTP, so I was looking
> around, and read:
>
> http://enroute.osgi.org/services/org.osgi.service.http.html
>
> This led me to wonder if someone has actually built yet another HTTP
> service (perhaps a very simple one based on the http server in the
> JDK), or whether this is just explaining the concept. Maven Central
> does not seem to have a relevant bundle.
> ___
> 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
>
>
>
> ___
> 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 an enroute http service?

[Benson Margulies]

On Thu, Nov 17, 2016 at 11:05 AM, Peter Kriens <peter.kri...@aqute.biz> wrote:
> I think there is a simple Http server at Felix written by someone from Bug 
> labs?

That's Felix HTTP. It isn't simple. It uses Jetty, and exports Jetty
packages in a problematic way, and has some other issues I've hit. I'm
in a bit of a hurry to try to finish something, and if there had been
a true self-contained http service available from enroute, that might
have done the trick.



>
> Kind regards,
>
> Peter Kriens
>
>> On 17 nov. 2016, at 16:37, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> We've had some problems with pax-web and felix HTTP, so I was looking
>> around, and read:
>>
>> http://enroute.osgi.org/services/org.osgi.service.http.html
>>
>> This led me to wonder if someone has actually built yet another HTTP
>> service (perhaps a very simple one based on the http server in the
>> JDK), or whether this is just explaining the concept. Maven Central
>> does not seem to have a relevant bundle.
>> ___
>> 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

[osgi-dev] Is there an enroute http service?

[Benson Margulies]

We've had some problems with pax-web and felix HTTP, so I was looking
around, and read:

http://enroute.osgi.org/services/org.osgi.service.http.html

This led me to wonder if someone has actually built yet another HTTP
service (perhaps a very simple one based on the http server in the
JDK), or whether this is just explaining the concept. Maven Central
does not seem to have a relevant bundle.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Why is 'start' an error for fragments?

[Benson Margulies]

On Thu, Nov 10, 2016 at 11:16 AM, BJ Hargrave <hargr...@us.ibm.com> wrote:
> Not really. Fragments are not bundle in that they do not have a class loader
> or a separate activation life. They can be attached to zero or more host
> bundles (non-fragment bundles). So to start them is not possible. To make it
> a no-op will break an invariant: After callings start, the bundle must be
> STARTING/ACTIVE or an exception is thrown to indicate failure to start.
> Since a fragment can not be started, that means an exception must be thrown.
>
> Generally, unless you are writing a management agent, you probably should
> not be starting/stopping bundles. If you are writing a management agent,
> then the distinction between fragments and bundles is important to to
> manage.

I'm maintaining a device that launches an application, and maps from
Maven dependencies to a list of bundles to load and start, or not.
However, in any case, I'm not here to have an argument. There are good
reasons why it is as it is? OK, fine, I was just curious.

>
> --
>
> 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: Benson Margulies <bimargul...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: [osgi-dev] Why is 'start' an error for fragments?
> Date: Thu, Nov 10, 2016 10:59 AM
>
> Has there ever been consideration of making 'start' be a harmless
> no-op for fragment bundles? I keep having to write code to check the
> headers and avoid the call to start on fragments.
> ___
> 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

[osgi-dev] Why is 'start' an error for fragments?

[Benson Margulies]

Has there ever been consideration of making 'start' be a harmless
no-op for fragment bundles? I keep having to write code to check the
headers and avoid the call to start on fragments.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Getting _all_ of the framework properties

[Benson Margulies]

On Fri, Nov 4, 2016 at 8:41 AM, Thomas Watson <tjwat...@us.ibm.com> wrote:
> In an OSGi R6 Framework the  osgi.native namespace [1] should be populated
> with the framework launching properties:
>
> BundleRevision system =
>
> bundleContext.getBundle(Constants.SYSTEM_BUNDLE_LOCATION).adapt(BundleRevision.class);
>
> Map<String, Object> launchingProps =
>
> system.getDeclaredCapabilities(NativeNamespace.NATIVE_NAMESPACE).get(0).getAttributes();
>
>
> This only contains the values from the launching map used to launch the
> framework [2] plus the osgi.native.* props set for the osgi.native
> namespace.  This may not include all the props that are automatically set by
> the framework though and it will not include the values of the system
> properties which back the values of BundleContext.getProperty.

That does what I need. Thanks.

>
> Tom
>
> [1]
> https://osgi.org/javadoc/r6/core/org/osgi/framework/namespace/NativeNamespace.html
> [2]
> https://osgi.org/javadoc/r6/core/org/osgi/framework/launch/FrameworkFactory.html#newFramework(java.util.Map)
>
>
>
>
> From:Benson Margulies <bimargul...@gmail.com>
> To:OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Date:11/04/2016 07:03 AM
> Subject:[osgi-dev] Getting _all_ of the framework properties
> Sent by:osgi-dev-boun...@mail.osgi.org
> 
>
>
>
> Is there a service that has access to the enumeration of all the
> framework property keys? BundleContext.getProperty can only get the
> ones I know about, of course.
> ___
> 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

[osgi-dev] Getting _all_ of the framework properties

[Benson Margulies]

Is there a service that has access to the enumeration of all the
framework property keys? BundleContext.getProperty can only get the
ones I know about, of course.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] How to track down a problem that appears to come through an unwanted system bundle package

[Benson Margulies]

Note: There's an obvious binary search solution to the problem here,
but I wonder if anyone has a shortcut.

I have a working test of some code that launches a fairly complex
collection of services in Felix 5.6.1.

Then, I tried to port across a more sophisticated test. I changed
nothing about what goes into the container. However, I added quite a
bit to the container's classpath.

Result: One part of 'jetty' gets a class not found exception on
another. Both pieces are in active bundles, and, again, all this works
just fine in the simple version.

So, I reason, some jar file on the large list of dependencies I added
to the test's classpath contains some package that is on the long list
of Export-Package packages that end up on the system bundle by
default.

Absent some shortcut, I'll binary search adding dependencies from good
to bad until I find the culprit. I'm not sure why I think that there
could be royal road to this, but perhaps someone's been here.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Using events

[Benson Margulies]

Ray,

Thanks for the help. I want to clarify what sort of beast I'm dealing
with here. There is no "user interface" in the exact sense that you
are thinking of.

What we have here is an SDK for complex NLP processing. In order to
avoid classpath problems of all sorts, we've decided to embed an OSGi
container 'behind' the API, because our customer will not accept a
requirement to use OSGi for their framework.

There's a good deal of configuration that can be specified for this
thing. You are right: it could be more robust. As things are, there
are things that can go wrong. The configuration is scattered in a
number of YAML files, read by a number of DS Components, in their
@Activate methods.

I've have not come up with an approach that avoids the possibility of
falling over these problems in @Activate methods. I could make my
orchestration code ask some questions about the state of some of the
'leaves' before it tries to grab the 'root', if the tree metaphor
makes sense to you. Maybe the design principle is that DS activate
methods must always succeed, and every component is capable of
existing in an 'I'm broken, you can ask me how' state.

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

Re: [osgi-dev] Using events

[Benson Margulies]

On Wed, Oct 19, 2016 at 8:12 AM, Peter Kriens <peter.kri...@aqute.biz> wrote:
> Not sure. This is the purpose of the log? If you’re interested in a more 
> active notification then just listen to the log events (LogReaderService) and 
> send to console out or whatever. Showing all errors is very useful for 
> debugging.

The log is not terrible, don't get me wrong. The shape I'm thinking of us this:

- Customer application calls startup API.
- Startup API starts up container
- 'Something goes wrong'.
- a FrameworkEvent of type ERROR shows up
- Customer sees focussed error like 'license file missing'
- log is there for more subtle/hard to anticipate situations

If I am not allowed to generate FrameworkEvents, I could plugin in
EventAdmin; but I was concerned that (a) people here would write 'oh,
that's old and disliked', and (b) that it will be a bit clumsy to
arrange for the results to show up 'outside'. But, on consideration, I
see how to do that not too badly.



>
> Kind regards,
>
> Peter Kriens
>
>> On 19 okt. 2016, at 14:11, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> I've found myself in situations where a (user) configuration error
>> leads to a throw in a DS @Activate method, and the eventual result is
>> that a component doesn't start and a service isn't found. While the
>> activate message can certainly log, it would be better, in my view, if
>> I could come up with a strategy for a more direct notification.
>>
>> Would readers here recommend EventAdmin for this job, or is there some
>> way to generate events at the framework level? One complexity is that
>> this is an 'embedded' application; the eventual audience of the
>> situation is code that starts up the framework, not code inside the
>> framework.
>> ___
>> 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

[osgi-dev] Using events

[Benson Margulies]

I've found myself in situations where a (user) configuration error
leads to a throw in a DS @Activate method, and the eventual result is
that a component doesn't start and a service isn't found. While the
activate message can certainly log, it would be better, in my view, if
I could come up with a strategy for a more direct notification.

Would readers here recommend EventAdmin for this job, or is there some
way to generate events at the framework level? One complexity is that
this is an 'embedded' application; the eventual audience of the
situation is code that starts up the framework, not code inside the
framework.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

[Benson Margulies]

On Tue, Oct 18, 2016 at 3:18 PM, Paul F Fraser <pa...@a2zliving.com> wrote:
> Hi Benson,
>
> Instead of null
>
> try using configurationAdmin.getConfiguration(pid, "?");

Thanks. This seems to have improved things. Now I can't explain why
the working test worked before, but you can't have everything.

>
> Paul
>
>
> On 18/10/2016 11:46 PM, Benson Margulies wrote:
>>
>> On Tue, Oct 18, 2016 at 8:40 AM, Timothy Ward <tim.w...@paremus.com>
>> wrote:
>>>
>>> How are you creating the configuration?
>>>
>>> Configuration Admin uses the concept of a bundle location to restrict the
>>> visibility of a pid to a particular bundle. This almost always trips people
>>> up when they create the configuration themselves (i.e. in code) as the
>>> “default” methods bind the configuration to the bundle creating it (rarely
>>> what you actually want).
>>
>> I carefully use a 'null' location:
>>
>>   configurationAdmin.getConfiguration(pid, null);
>>
>> which I thought was the right recipe.
>>
>> Here's some debug from felix CM:
>>
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]getConfiguration(pid=com.basistech.ws.bus,
>> location=null)
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
>> installed; grant CONFIGURE permission on configuration bound to * to
>> bundle
>> /Users/benson/x/rosapi-on-premise/embedded/test/../pre-package/target/bundles/base/rosapi-headless-config-reader-1.4.101-SNAPSHOT.jar
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]createConfiguration(com.basistech.ws.bus,
>> null, null)
>> 08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]update(properties={licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml})
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Updating config
>> com.basistech.ws.bus with
>>
>> {licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml}
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]No
>> SynchronousConfigurationListeners to send CM_UPDATED event to.
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Fire
>> ConfigurationEvent: pid=com.basistech.ws.bus
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Update:
>> pid=com.basistech.ws.bus
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]UpdateConfiguration(com.basistech.ws.bus)
>> scheduled
>>
>>
>>
>>> Also, if your component is not immediate *and* it provides a service then
>>> it will not activate until somebody “gets” the service.
>>
>> Yes, but I have 10 other components stuck waiting for it, so that
>> problem should be solved.
>>
>> While I thank you for advice on diagnosing the problem, I also want to
>> remind you that my original question is how the state is reflected in
>> the DTOs. Solving the actual problem is probably just a matter of log
>> comparison with the working environment.
>>
>>
>>> Regards,
>>>
>>> Tim
>>>
>>>
>>>> On 18 Oct 2016, at 12:47, Benson Margulies <bimargul...@gmail.com>
>>>> wrote:
>>>>
>>>> Here's my puzzle.
>>>>
>>>> I have a set o

Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

[Benson Margulies]

On Tue, Oct 18, 2016 at 8:40 AM, Timothy Ward <tim.w...@paremus.com> wrote:
> How are you creating the configuration?
>
> Configuration Admin uses the concept of a bundle location to restrict the 
> visibility of a pid to a particular bundle. This almost always trips people 
> up when they create the configuration themselves (i.e. in code) as the 
> “default” methods bind the configuration to the bundle creating it (rarely 
> what you actually want).

I carefully use a 'null' location:

 configurationAdmin.getConfiguration(pid, null);

which I thought was the right recipe.

Here's some debug from felix CM:

08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]getConfiguration(pid=com.basistech.ws.bus,
location=null)
08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to * to
bundle 
/Users/benson/x/rosapi-on-premise/embedded/test/../pre-package/target/bundles/base/rosapi-headless-config-reader-1.4.101-SNAPSHOT.jar
08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]createConfiguration(com.basistech.ws.bus,
null, null)
08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]update(properties={licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml})
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Updating config
com.basistech.ws.bus with
{licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml}
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No
SynchronousConfigurationListeners to send CM_UPDATED event to.
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Fire
ConfigurationEvent: pid=com.basistech.ws.bus
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Update:
pid=com.basistech.ws.bus
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]UpdateConfiguration(com.basistech.ws.bus)
scheduled



>
> Also, if your component is not immediate *and* it provides a service then it 
> will not activate until somebody “gets” the service.

Yes, but I have 10 other components stuck waiting for it, so that
problem should be solved.

While I thank you for advice on diagnosing the problem, I also want to
remind you that my original question is how the state is reflected in
the DTOs. Solving the actual problem is probably just a matter of log
comparison with the working environment.


>
> Regards,
>
> Tim
>
>
>> On 18 Oct 2016, at 12:47, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> Here's my puzzle.
>>
>> I have a set of services that all have unsatisfied references to the
>> same thing - a vanilla @Reference to the interface WorkerBusService.
>>
>> In each case, there is a configuration DTO with an unsatisfied
>> reference with name BusConfigured and target null.
>>
>> WorkerBusService is implemented by an @Component named BusService.
>>
>> it has a required configuration pid and is _not_ immediate. The
>> configuration should be there, I see a log message corresponding to my
>> code that updates it into place.
>>
>> When things time out, BusService has no configuration dtos at all,
>> just the description DTO. So, how do I tell why it hasn't started?
>> Note that this is an environment where I can't use the shell, so I've
>> basically written code that dumps useful output from the introspection
>> into a String.
>>
>> Note that all this works in a slightly different environment, and I'm
>> trying to hone these diagnostic tools rather than brute-force a
>> comparison to explain the discrepancy.
>> ___
>> OSGi Developer Mail List
>>

[osgi-dev] SATISFIED versus ACTIVE

[Benson Margulies]

I've got a component that I know has been activated: I've seen log
messages from its activate message. Yet the DTO says state is
SATISFIED, not ACTIVE.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Interpreting the ServiceComponentRuntime DTOs

[Benson Margulies]

Here's my puzzle.

I have a set of services that all have unsatisfied references to the
same thing - a vanilla @Reference to the interface WorkerBusService.

In each case, there is a configuration DTO with an unsatisfied
reference with name BusConfigured and target null.

WorkerBusService is implemented by an @Component named BusService.

it has a required configuration pid and is _not_ immediate. The
configuration should be there, I see a log message corresponding to my
code that updates it into place.

When things time out, BusService has no configuration dtos at all,
just the description DTO. So, how do I tell why it hasn't started?
Note that this is an environment where I can't use the shell, so I've
basically written code that dumps useful output from the introspection
into a String.

Note that all this works in a slightly different environment, and I'm
trying to hone these diagnostic tools rather than brute-force a
comparison to explain the discrepancy.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] SCR: Why do unsatisfied references have target services?

[Benson Margulies]

In org.osgi.service.component.runtime.dto.UnsatisfiedReferenceDTO
there are targetServices. What are they, given that the service is
unsatisfied?
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

On Wed, Oct 12, 2016 at 3:36 PM,  <chris.g...@kiffer.be> wrote:
> I hesitate to prolong this thread, but FWIW: Google can index PDFs just
> fine, what their seachbot doesn't do is to click through "I agree to ..."
> checkboxes.
>
> Whether the "front page" of a web site should always display the same
> information is another question. Most don't.

The point was, that at the time there was no navigation at all to
reach the javadoc or pdfs. Believe me or not.


>
>> These sides are -completely- disconnected and run by very different
>> webmasters.
>>
>> Kind regards,
>>
>>   Peter Kriens
>>
>>> On 11 okt. 2016, at 16:28, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>>
>>> It's no longer dead AFAICT, so I doubt that I can be very precise here.
>>>
>>> When the enRoute stuff first came up, several more or less front pages
>>> of osgi.org stopped displaying what they used to display, and
>>> displayed information about enRoute instead. I deleted my bookmarks,
>>> swore a bit, and moved on. As of today, the osgi.org front page is
>>> (back to?) displaying a front page, and searching in Google for
>>> 'ConfigurationListener' gets a hit for the 4.2 javadoc and no hit for
>>> the spec PDF, which is better than nothing.
>>>
>>>
>>> On Sat, Oct 8, 2016 at 9:48 AM, Peter Kriens <peter.kri...@aqute.biz>
>>> wrote:
>>>> What URL went dead?
>>>>
>>>>
>>>> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies
>>>> <bimargul...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett <njbartl...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On 7 Oct 2016, at 22:33, Benson Margulies <bimargul...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 7 Oct 2016, at 20:56, Benson Margulies <bimargul...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <maili...@hupie.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 07/10/16 21:04, Benson Margulies wrote:
>>>>>>
>>>>>>
>>>>>> I am trying to express the following idea using DS:
>>>>>>
>>>>>> "If service X is provisioned in this container, do not activate me
>>>>>> until it is activated and injected into me. If service X is not
>>>>>> provisioned in this container, go ahead and activate me without it."
>>>>>>
>>>>>>
>>>>>>
>>>>>> how about making the dependency: static + greedy + optional.
>>>>>>
>>>>>>
>>>>>> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>>>>>>
>>>>>>
>>>>>> Greedy means that if a service becomes available after your component
>>>>>> is
>>>>>> activated, then it will *always* be supplied to your component, even
>>>>>> if
>>>>>> that
>>>>>> forces a restart of the component due to the reference having static
>>>>>> policy.
>>>>>>
>>>>>> (It’s worth contrasting this with its opposite, reluctant: if you
>>>>>> have
>>>>>> an
>>>>>> optional, static, reluctant reference then your component will NOT be
>>>>>> restarted in order to give it a service that arrives after it is
>>>>>> activated.
>>>>>> That is, the component will continue to be bound to nothing even when
>>>>>> a
>>>>>> valid candidate service is available. While this makes perfect sense
>>>>>> if
>>>>>> you
>>>>>> take the time to think it through, OSGi newbies tend to find it
>>>>>> counterintuitive).
>>>>>>
>>>>>> By the way, with a greedy reference, you will also get re-bound when
>>>>>> a
>>>>>> service comes along that has a higher ranking than the one you are
>>>>>> currently
>&g

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

It's no longer dead AFAICT, so I doubt that I can be very precise here.

When the enRoute stuff first came up, several more or less front pages
of osgi.org stopped displaying what they used to display, and
displayed information about enRoute instead. I deleted my bookmarks,
swore a bit, and moved on. As of today, the osgi.org front page is
(back to?) displaying a front page, and searching in Google for
'ConfigurationListener' gets a hit for the 4.2 javadoc and no hit for
the spec PDF, which is better than nothing.


On Sat, Oct 8, 2016 at 9:48 AM, Peter Kriens <peter.kri...@aqute.biz> wrote:
> What URL went dead?
>
>
> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>>
>> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett <njbartl...@gmail.com>
>> wrote:
>> >
>> > On 7 Oct 2016, at 22:33, Benson Margulies <bimargul...@gmail.com> wrote:
>> >
>> > On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com>
>> > wrote:
>> >
>> >
>> > On 7 Oct 2016, at 20:56, Benson Margulies <bimargul...@gmail.com> wrote:
>> >
>> > On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <maili...@hupie.com>
>> > wrote:
>> >
>> >
>> >
>> > On 07/10/16 21:04, Benson Margulies wrote:
>> >
>> >
>> > I am trying to express the following idea using DS:
>> >
>> >  "If service X is provisioned in this container, do not activate me
>> > until it is activated and injected into me. If service X is not
>> > provisioned in this container, go ahead and activate me without it."
>> >
>> >
>> >
>> > how about making the dependency: static + greedy + optional.
>> >
>> >
>> > So, in practical terms, how greedy is 'greedy'? What's the behavior?
>> >
>> >
>> > Greedy means that if a service becomes available after your component is
>> > activated, then it will *always* be supplied to your component, even if
>> > that
>> > forces a restart of the component due to the reference having static
>> > policy.
>> >
>> > (It’s worth contrasting this with its opposite, reluctant: if you have
>> > an
>> > optional, static, reluctant reference then your component will NOT be
>> > restarted in order to give it a service that arrives after it is
>> > activated.
>> > That is, the component will continue to be bound to nothing even when a
>> > valid candidate service is available. While this makes perfect sense if
>> > you
>> > take the time to think it through, OSGi newbies tend to find it
>> > counterintuitive).
>> >
>> > By the way, with a greedy reference, you will also get re-bound when a
>> > service comes along that has a higher ranking than the one you are
>> > currently
>> > bound to. Again, this happens even if it requires restarting the
>> > component
>> > due to a static reference policy.
>> >
>> > All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
>> > Option”.
>> >
>> >
>> > I will do a better job of reading the specs when they are plain HTML
>> > files, searched by google, and not fenced with a mile legal verbiage.
>> >
>> >
>> > Please don’t misunderstand… when I give a reference to the spec it’s to
>> > back
>> > up what I’m saying so that you know it’s true, and to give you the
>> > opportunity to dig deeper. It is certainly NOT an accusation that you
>> > are
>> > being lazy for not already having found this information yourself.
>>
>> OK, sorry about the snark. I have a certain amount of pent-up
>> frustration, especially after a bunch of URLs went dead when the
>> enRoute info went up. Thanks as always for the help.
>>
>>
>> >
>> > I would also like the specs to be more searchable. The PDFs look
>> > beautiful
>> > but that’s not so important unless they are in book form, and who wants
>> > to
>> > carry around a 1246 pages of Compendium?
>> >
>> > Neil
>> >
>> >
>> >
>> >
>> >
>> > Regards,
>> > Neil
>> >
>> >
>> >
>> >
>> >
>> > that way your component will get started always, and restarted once X
>> > becomes available.
>> >
>> >
>> > I fully appreciate that this concept is not compatible with the
>> > generally dynamic approach 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
> On 7 Oct 2016, at 22:33, Benson Margulies <bimargul...@gmail.com> wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies <bimargul...@gmail.com> wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <maili...@hupie.com> wrote:
>
>
>
> On 07/10/16 21:04, Benson Margulies wrote:
>
>
> I am trying to express the following idea using DS:
>
>  "If service X is provisioned in this container, do not activate me
> until it is activated and injected into me. If service X is not
> provisioned in this container, go ahead and activate me without it."
>
>
>
> how about making the dependency: static + greedy + optional.
>
>
> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>
>
> Greedy means that if a service becomes available after your component is
> activated, then it will *always* be supplied to your component, even if that
> forces a restart of the component due to the reference having static policy.
>
> (It’s worth contrasting this with its opposite, reluctant: if you have an
> optional, static, reluctant reference then your component will NOT be
> restarted in order to give it a service that arrives after it is activated.
> That is, the component will continue to be bound to nothing even when a
> valid candidate service is available. While this makes perfect sense if you
> take the time to think it through, OSGi newbies tend to find it
> counterintuitive).
>
> By the way, with a greedy reference, you will also get re-bound when a
> service comes along that has a higher ranking than the one you are currently
> bound to. Again, this happens even if it requires restarting the component
> due to a static reference policy.
>
> All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
> Option”.
>
>
> I will do a better job of reading the specs when they are plain HTML
> files, searched by google, and not fenced with a mile legal verbiage.
>
>
> Please don’t misunderstand… when I give a reference to the spec it’s to back
> up what I’m saying so that you know it’s true, and to give you the
> opportunity to dig deeper. It is certainly NOT an accusation that you are
> being lazy for not already having found this information yourself.

OK, sorry about the snark. I have a certain amount of pent-up
frustration, especially after a bunch of URLs went dead when the
enRoute info went up. Thanks as always for the help.


>
> I would also like the specs to be more searchable. The PDFs look beautiful
> but that’s not so important unless they are in book form, and who wants to
> carry around a 1246 pages of Compendium?
>
> Neil
>
>
>
>
>
> Regards,
> Neil
>
>
>
>
>
> that way your component will get started always, and restarted once X
> becomes available.
>
>
> I fully appreciate that this concept is not compatible with the
> generally dynamic approach of OSGi in general, and declarative
> services in particular. However, I can think of a variation like:
>
> "I am willing to wait N seconds for service X. If it isn't there by
> then, activate me without it."
>
> I am taking a risk here -- it's always possible that some phenomenon
> would result in a delay of longer than N. But in my case, the startup
> properties of the containing application are such that this would be a
> low risk.
>
> Another possible approach would be to focus on provide/require
> capability. I don't know how I would get DS to pay attention, but it
> seems as if there's not enough information:
>
> Provide-Capability: osgi.service;objectClass:List="com.basiste
> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
> eComponentService"
>
> Note that any properties are not represented here. So if the
> dependency is specific to some filter on properties, you can't use
> this data.
>
> At the extreme, I could take very close control of start order, and
> then go ahead and use optional references. That's a lot of start order
> management.
>
> Finally? I could use configuration admin, by setting the reference
> cardinality as part of provisioning. To do this cleanly, I think I'd
> want some sort of management layer that generated these 'minimum
> cardinality properties'; editing it in something like Karaf's cfg
> files would be quite messy.
>
> Is there something I'm missing?
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> --
>

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
> On 7 Oct 2016, at 20:56, Benson Margulies <bimargul...@gmail.com> wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <maili...@hupie.com> wrote:
>
>
>
> On 07/10/16 21:04, Benson Margulies wrote:
>
>
> I am trying to express the following idea using DS:
>
>   "If service X is provisioned in this container, do not activate me
> until it is activated and injected into me. If service X is not
> provisioned in this container, go ahead and activate me without it."
>
>
>
> how about making the dependency: static + greedy + optional.
>
>
> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>
>
> Greedy means that if a service becomes available after your component is
> activated, then it will *always* be supplied to your component, even if that
> forces a restart of the component due to the reference having static policy.
>
> (It’s worth contrasting this with its opposite, reluctant: if you have an
> optional, static, reluctant reference then your component will NOT be
> restarted in order to give it a service that arrives after it is activated.
> That is, the component will continue to be bound to nothing even when a
> valid candidate service is available. While this makes perfect sense if you
> take the time to think it through, OSGi newbies tend to find it
> counterintuitive).
>
> By the way, with a greedy reference, you will also get re-bound when a
> service comes along that has a higher ranking than the one you are currently
> bound to. Again, this happens even if it requires restarting the component
> due to a static reference policy.
>
> All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
> Option”.

I will do a better job of reading the specs when they are plain HTML
files, searched by google, and not fenced with a mile legal verbiage.


>
> Regards,
> Neil
>
>
>
>
>
> that way your component will get started always, and restarted once X
> becomes available.
>
>
> I fully appreciate that this concept is not compatible with the
> generally dynamic approach of OSGi in general, and declarative
> services in particular. However, I can think of a variation like:
>
>  "I am willing to wait N seconds for service X. If it isn't there by
> then, activate me without it."
>
> I am taking a risk here -- it's always possible that some phenomenon
> would result in a delay of longer than N. But in my case, the startup
> properties of the containing application are such that this would be a
> low risk.
>
> Another possible approach would be to focus on provide/require
> capability. I don't know how I would get DS to pay attention, but it
> seems as if there's not enough information:
>
> Provide-Capability: osgi.service;objectClass:List="com.basiste
> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
> eComponentService"
>
> Note that any properties are not represented here. So if the
> dependency is specific to some filter on properties, you can't use
> this data.
>
> At the extreme, I could take very close control of start order, and
> then go ahead and use optional references. That's a lot of start order
> management.
>
> Finally? I could use configuration admin, by setting the reference
> cardinality as part of provisioning. To do this cleanly, I think I'd
> want some sort of management layer that generated these 'minimum
> cardinality properties'; editing it in something like Karaf's cfg
> files would be quite messy.
>
> Is there something I'm missing?
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> --
> Ferry Huberts
> ___
> 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
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev