Re: [osgi-dev] Correct processor types for ARM?

[Chris Gray via osgi-dev]

Hi Peter,

I would argue that it is "os.arch" which is a bit of a mess, because it
attempts to represent too much in a single name. Compare this with the set
of "triples" here :
http://llvm.org/doxygen/classllvm_1_1Triple.html

I would argue that these definitions would be a more useful way to specify
the target for native code, as they correspond to the way that code is
compiled for the various targets.

Kind Regards

Chris


> That is my experience on the ARM processor, there are so many variations,
> 32/64, le/be, floating point/no floating point, etc. that it is a bit of a
> mess.
>
> In general, on ARM I see people define the properties themselves to
> whatever the VM they use reports.
>
> Kind regards,
>
>   Peter Kriens
>
>
>> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev
>>  wrote:
>>
>> This has been already done by someone here:
>> https://stackoverflow.com/a/57893125
>> It seems os.arch is not really "stable" at all:
>> https://bugs.openjdk.java.net/browse/JDK-8167584
>> ___
>> 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] Correct processor types for ARM?

[Chris Gray via osgi-dev]

Hi Peter,

I would argue that it is "os.arch" which is a bit of a mess, because it
attempts to represent too much in a single name. Compare this with the set
of "triples" here :
http://llvm.org/doxygen/classllvm_1_1Triple.html

I would argue that these definitions would be a more useful way to specify
the target for native code, as they correspond to the way that code is
compiled for the various targets.

Kind Regards

Chris


> That is my experience on the ARM processor, there are so many variations,
> 32/64, le/be, floating point/no floating point, etc. that it is a bit of a
> mess.
>
> In general, on ARM I see people define the properties themselves to
> whatever the VM they use reports.
>
> Kind regards,
>
>   Peter Kriens
>
>
>> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev
>>  wrote:
>>
>> This has been already done by someone here:
>> https://stackoverflow.com/a/57893125
>> It seems os.arch is not really "stable" at all:
>> https://bugs.openjdk.java.net/browse/JDK-8167584
>> ___
>> 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] R: Api compile-only and remote services

[Chris Gray via osgi-dev]

In my experience it is quite often handy to have a separate API bundle -
yours is one use case, another is where the system may run on different
platforms which require different implementations for some services (cloud
vs development machine, embedded vs dev, self-contained demo vs real
distributed system, ...). In fact in a way this is the "normal"
configuration, provider-exports is a convenience.

If the packages can be exported by both api bundle and provider then you
have to watch out for "uses" constraint violations if versions diverge,
Keep It Simple is the key here.

Have fun

Chris

> I understand that with api compile only is not possible to run a remote
> instance without the related provider bundle.
>
> With a provider with conditional package I have to resolve both api and
> provider bundle because api packages are only copied inside provider but
> not exported.
> So I don’t think that is better than having api and provider separated.
>
> Now I’ve tried to modify my bundles in this way:
> - api without compile only that export packages
> - provider like before that export api packages
>
> With this configuration I can:
> - run an osgi instance resolving only provider bundle like before
> - run another instance without the provider resolving only api bundle
>
> Daniele
>
>
> Da: David Daniel
> Inviato: sabato 3 febbraio 2018 21:24
> A: Dominik Przybysz; OSGi Developer Mail List
> Cc: Daniele Pirola
> Oggetto: Re: [osgi-dev] Api compile-only and remote services
>
> I think different projects handle it differently.  The way I do it is if
> only one provider loaded will implement the interface then I include the
> interface in the provider with a conditional package and leave the api
> compile only 
> http://enroute.osgi.org/tutorial_wrap/212-conditional-package.html  If
> multiple providers are going to implement the interface then I will change
> the api bundle to a regular bundle to inclusion.
> David
>
> On Sat, Feb 3, 2018 at 2:35 PM, Dominik Przybysz via osgi-dev
>  wrote:
> Hi,
> if you know that you may run your bundles in distributed environment and
> want to use Remote Services, your API bundles must be normal bundles.
>
> 2018-02-03 19:12 GMT+01:00 Daniele Pirola via osgi-dev
> :
> Hi,
> I have an Osgi workspace with many bundles with different "types": api,
> provider and application. I follow enroute tutorials and my api bundles
> are "compile only" and providers export api packages. 
> Now I would like to use osgi remote services but how can I use api
> packages in different osgi instances without importing also the provider
> that export these packages? I have to build another api project that only
> export packages? Or api "compile only" is not the right thing for remote?
>
> Kind regards
> Daniele
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
Mail priva di virus. www.avg.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

Re: [osgi-dev] looking for OSGi plug-in

[chris . gray]

You could try asking your colleagues, Huawei claim to have a few hundred
people working on OSGi?

> Hi
>
> Now I've got an OSGi based RG, which declared support OSGi 3rd party
> plug-in, I am looking for some plug-In to install on the RG.
>
> Do you know where could I get it?  Such as OSGi plug-in which
> functionality is speed test, or other functionality could demo on an RG.
>
> Thank you!
> ___
> 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] Problem with configuration admin

[chris . gray]

It's very useful. But the bit about the "two-parameter getConfiguration
method using null (no location) as the second parameter" should maybe be
mentioned from the start, because it's not at all obvious and I remember
getting bitten by this myself a few years back.

> Hi,
>
> I wrote a blog post about configuring services a while ago.
>
> http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/
>
> Maybe it helps to understand it better.
>
> Greez,
> Dirk
>
> Am 04.06.2017 14:02 schrieb "Mark Raynsford" :
>
>> On 2017-06-04T13:04:12 +0200
>> Felix Meschberger  wrote:
>>
>> > Hi Mark
>> >
>> > I assume your configurator is creating the configuraiton with:
>> >
>> > >final Configuration config =
>> > >  this.configurations.getConfiguration(
>> > >"com.io7m.callisto.stringtables.main.provider“)
>> >
>> > If this is the case, this new configuration is bound to the
>> configurator’s bundle, which IIUIC is the same bundle also containing
>> the
>> Example component.
>>
>> I see.
>>
>> > Thus the Example component gets the configuration being in the same
>> bundle, but the provider does not as it is in another bundle.
>> >
>> > You might want to try to use the two-parameter getConfiguration method
>> using null (no location) as the second parameter to make sure the
>> configuration is not bound at the time of creation — but later when it
>> is
>> first provided to the consumer
>> >
>>
>> Yes, this worked! Thanks.
>>
>> I have to admit, I'm not exactly sure what's happening here. The R6
>> compendium spec mentions that location binding is a security feature
>> (104.4.1), but it then uses terms like "management bundle" without
>> actually explaining what that is.
>>
>> M
>>
>> ___
>> 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] Different conceptual version numbers for different forms of backwards compatibility?

[chris . gray]

> On Thu, May 4, 2017 at 5:19 PM, BJ Hargrave  wrote:
>
>> Again, see https://docs.oracle.com/javase/specs/jls/se7/html/jls-
>> 13.html#jls-13.4.15.
>>
>> If an API is released and then you change the API such that the return
>> type is different, e.g. List to Collection, that is a binary
>> incompatible
>> change. The user of the API may expect it to be a List and invoke List
>> methods on it.
>>
>
> Changing the return type from a more specific type (e.g. List ) to a more
> general type (e.g. Collection) is an intrinsically breaking change, for
> the
> reasons you note.
>
> Changing in the other direction from a more general type to a more
> specific
> one is not intrinsically breaking, since we know the value returned by the
> new method must be assignment compatible with the old code:
>
> If the method returns a reference type, only an *areturn* instruction may
> be used, and the type of the returned value must be assignment compatible
> with the return descriptor of the method (JLS §5.2, §4.3.3
> 
> ).
>
> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.9.2
>
> [...]

Yes, it should be possible to fit the round peg into the elliptical hole
by means of "bytecode manipulation" (or rather constant-pool manipulation,
as you point out). However I doubt that it is worth the trouble (and there
will surely be some 'interesting' corner cases to deal with). As BJ
pointed out, OSGi is all about binary compatibility not source
compatibility, and I don't think it is helpful to blur this distinction.

> [ Alternatively, I believe it might technically be possible to have two
> methods in a class file that differ only in return type.
>  The JVMS states that "No two methods in one class file may have the same
> name and descriptor", and the prolog code doesn't seem to parse the
> descriptor in places that one would expect it to (e.g. checking for
> non-override of final methods).
>
>  https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6
>
>
> I am pretty sure that this would not end well :)  ]

That would be an example of the exotic category "legal class file which
could not be generated by a correct Java compiler from a valid Java
program". Maybe not so exotic these days, with so many other languages
being compiled to the JVM target.


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

Re: [osgi-dev] osgi broker bundle

[chris . gray]

As I said I haven't tried Moquette yet because I didn't yet have the need
to run an MQTT broker in an OSGi context. However the developer
specifically mentions the *possibility* of "running inside an embedded
OSGi broker like Concierge" so it would be worth contacting him about it.

https://projects.eclipse.org/proposals/moquette-mqtt

If you want to run a broker on an embedded device then probably your
device is some kind of "gateway" between a local network of
sensors/actuators and some kind of "cloud", am I close? In that case I
must say "Welcome to the Fog". :-)

In this use case you probably want your own broker to act in "bridging"
mode, and then you will find that mosquitto is not very dynamic - to
change the bridging configuration you need to stop mosquitto, update the
mosquitto.conf file and restart it, a mere "HUP" is not enough.  So any
OSGi service you create to control the mosquitto lifecycle is going to be
pretty ugly.

Whether Moquette is any better in this case remains to be seen, if the
developer's idea of OSGi is "slap on an Activator and a manifest" then
you're not much further ... how much this all matters depends on your use
case and how much dynamic behaviour you need ...


> oki :) i'll try thay out and will let you know how it was.
> As i said i'll need the broker as a bundle in my concierge container.
> Will update you in this next week on my findings.
> Have a great week end.
> Cheers! 😊
>
> On 17 Feb 2017 22:18, "Achim Nierbeck"  wrote:
>
>> must be a typo :)
>>
>> mosquitto, but that's a "standalone" mqtt broker. In general it should
>> be
>> enough, depending on your use-cases :)
>>
>>
>> https://projects.eclipse.org/projects/technology.mosquitto
>>
>> 2017-02-17 22:16 GMT+01:00 Mestiri Meher :
>>
>>> thanks guys for your answers.
>>> Achim are you talking about moquito or moquette ?
>>>
>>> Chris, does osgfying the moquette is sthg straight forward ? do you
>>> have
>>> a moquette or mosquitto already ogfyied as bundle ?
>>>
>>>
>>> On 17 Feb 2017 21:56, "Achim Nierbeck"  wrote:
>>>
>>> Hi,
>>>
>>> I second that, and I can tell mosquito works out nicely for me.
>>> If you look for a tool to investigate what data is sent to your mqtt
>>> broker, I suggest mqttfx.
>>> It's a nice tool to investigate your broker.
>>>
>>> regards, Achim
>>>
>>> 2017-02-17 20:42 GMT+01:00 :
>>>
 If you really only need MQTT then I think you should be looking at a
 dedicated MQTT broker rather than an all-singing, all-dancing message
 boroker like ActiveMQ. Moquette looks promising (caveat - I haven't
 tried
 it. yet)

 > Hi guys,
 >
 > I'm looking on how deploying an MQTT broker into an osgi
 environment.
 >
 > I'm running my osgi container in an embedded environment.
 >
 > I tried installing apache Karaf as it already has the ActiveMQ
 broker
 > integration easy, but i was not able to install it as it needs some
 junit
 > libraries that does not comply with the jre embedded.
 >
 > The other solution I'm thinking of is installing the ActiveMQ broker
 > against Felix.
 >
 > I found in an mvn repo an osgi bundle for the activeMQ but it needs
 its
 > dependencies.
 >
 > So I tried adding them as bundles but I faced an issue right now
 because
 > when I start that bundle it asks for a dependency that I can't find
 it.
 >
 > ->  Unable to resolve org.apache.activemq.activemq-osgi
 version=5.14.3:
 >missing requirement org.osgi.service.blueprint;
 version=[1.0.0,2.0.0)]
 >
 > Do you have an idea on how I have to proceed ?
 >
 > Thanks in advance :)
 > Meher
 > ___
 > 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

>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf  Committer & PMC
>>> OPS4J Pax Web  Committer
>>> & Project Lead
>>> blog 
>>> Co-Author of Apache Karaf Cookbook 
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf  Committer & PMC
>> OPS4J Pax Web 

Re: [osgi-dev] osgi broker bundle

[chris . gray]

If you really only need MQTT then I think you should be looking at a
dedicated MQTT broker rather than an all-singing, all-dancing message
boroker like ActiveMQ. Moquette looks promising (caveat - I haven't tried
it. yet)

> Hi guys,
>
> I'm looking on how deploying an MQTT broker into an osgi environment.
>
> I'm running my osgi container in an embedded environment.
>
> I tried installing apache Karaf as it already has the ActiveMQ broker
> integration easy, but i was not able to install it as it needs some junit
> libraries that does not comply with the jre embedded.
>
> The other solution I'm thinking of is installing the ActiveMQ broker
> against Felix.
>
> I found in an mvn repo an osgi bundle for the activeMQ but it needs its
> dependencies.
>
> So I tried adding them as bundles but I faced an issue right now because
> when I start that bundle it asks for a dependency that I can't find it.
>
> ->  Unable to resolve org.apache.activemq.activemq-osgi version=5.14.3:
>missing requirement org.osgi.service.blueprint; version=[1.0.0,2.0.0)]
>
> Do you have an idea on how I have to proceed ?
>
> Thanks in advance :)
> Meher
> ___
> 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] Hi

[chris . gray]

> As soon as a bundle accesses resources of another bundle these classes are
> instantiated. A bundle that is uninstalled can only be completely purged
> once the last class of that bundle is garbage collected.

Which can only happen when there are no longer any references to any
instance of any class in the bundle, and no references to the bundle class
loader itself. (Just for the sake of completeness).

> Refreshing the bundles that used the uninstalled bundle normally fix this
> but you also need to make sure the other bundles are cleaning up
> correctly.
> So for example if a bundle starts a thread at some point and this thread
> is
> not stopped on shutdown of the bundle then all classes used in the thread
> will not be cleaned up. So if the thread uses classes of the now
> uninstalled bundle they will remain loaded. This also prevents the
> classloader of the uninstalled bundle to be garbage collected.

This is one common source of problems; another is where bundle A retains a
reference to an instance of a class defined in B, for example as the
result of calling a method in B. So long as this reference is not
overwritten, bundle B cannot be garbage-collected.

Chris

> Christian
>
> 2016-11-11 5:35 GMT+01:00 :
>
>> Hi All,
>>
>>
>>
>> I am on Enroute/Eclipse/Bndtools. I INSTALL a certain bundle and then go
>> on to UNINSTALL. But still, the bundle seem to exist (may be in the
>> cache)
>> as I am able to execute functions in this uninstalled bundle.  How do I
>> eliminate this bundle’s presence completely?
>>
>>
>>
>> Thanks,
>>
>> Manoj
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s)
>> and
>> may contain proprietary, confidential or privileged information. If you
>> are
>> not the intended recipient, you should not disseminate, distribute or
>> copy
>> this e-mail. Please notify the sender immediately and destroy all copies
>> of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no
>> liability
>> for any damage caused by any virus transmitted by this email.
>> www.wipro.com
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> 
>
> Open Source Architect
> http://www.talend.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

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

[chris . gray]

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.

> These sides are -completely- disconnected and run by very different
> webmasters.
>
> Kind regards,
>
>   Peter Kriens
>
>> On 11 okt. 2016, at 16:28, Benson Margulies 
>> 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 
>> wrote:
>>> What URL went dead?
>>>
>>>
>>> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies
>>> 
>>> wrote:

 On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
 wrote:
>
> On 7 Oct 2016, at 22:33, Benson Margulies 
> wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
> wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies 
> wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
> 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 

Re: [osgi-dev] Rest Management service

[chris . gray]

Daghan scripsit:

> also I prefer to use an artifact instead of building from source due to
> Licencing issues.

We live in strange times.


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

Re: [osgi-dev] Clarify usage of ServiceTracker

[chris . gray]

Scripsit Raymond:

> -1% - blueprint (we have a test that fails the build if someone tries to

Personally I would make this -100% :-)

I don't regard DS as "magic", because what it does is rather
straightforward conceptually and is clearly described in the
specification. I only wish I could say the same for all the other
annotation-based frameworks in the Java "ecosystem" ... 7 years ago I
would have said to concentrate on ServiceTracker and ignore old tutorials
which use the low-level interface, and nowadays I would say concentrate on
DS and only start messing with ServiceTracker when you really have to.

> On Fri, Apr 15, 2016 at 1:34 PM, Alexander Klimetschek
> 
> wrote:
>> FWIW: As a long time user of DS I can only say it's awesome, and I
personally would never use OSGi without it. Never seen any problems
with
>> it
>> because of "too much magic" - in fact, it's straightforward.
>> Cheers,
>> Alex
>> > On 15.04.2016, at 08:41, Neil Bartlett  wrote:
Michael,
>> > I share your aversion to opaque magic, but I'm not entirely in
>> agreement. You seem to be arguing that programmers should have full
knowledge of all levels of the stack they are building on. If so, can
you
>> explain in detail how, say, the Java garbage collector works?
>> > In fact I suspect you probably can... but my point is that you don't
>> need this knowledge to be a good Java programmer. You only need to know
the
>> contract offered by the JVM. Likewise you can be productive with DS
without
>> understanding the nitty gritty details of a DS implementation.
>> > Neil
>> > On 15 Apr 2016 3:19 pm, "Michael Lipp"  wrote:
>> > Thanks to everyone. Especially to Timothy for pointing out the
>> problems
>> with the simple approach. I didn't find these problems laid out in any of
>> the examples or tutorials that I came across.
>> > I know that a newbie's problems are always a bit "been there, done
>> that"
>> to the experts. But simply using something like DS without further
understanding the problems that it solves is a bit like using magic and
I
>> don't think that this is what programming should be like.
>> >  - Michael
>> > Am 13.04.2016 um 22:47 schrieb Michael Lipp:
>> >> Hi,
>> >> I'm trying to get a clear picture of the ServiceTracker. I've looked
>> at
>> some examples (e.g. http://www.aqute.biz/Snippets/Tracker), but they
all
>> seem rather complicated. I'm especially interested in knowing when I
can
>> assume a service object to exist.
>> >> It is clear to me from the specification that a service object is
>> available (different from null) when the default implementation of
addingService returns. So to avoid constantly calling
>> myTracker.getService() (and check for null) whenever I want to invoke a
method of the service object, I can derive my own ServiceTracker by
overriding addingService (using the LogService as an example):
>> >> @Override
>> >> public LogService addingService(ServiceReference
>> reference) {
>> >>  myLogService = super.addingService(reference);
>> >>  // Start the thread(s) that refer to (use) myLogService
return myLogService;
>> >> }
>> >> ... and use myLogService until the service becomes unavailable
>> (invalid).
>> >> It is less clear to me how to know when the service becomes
>> unavailable. The specification says:
>> >> removedService(ServiceReference,T) - Called whenever a tracked
>> service is removed from the
>> >> ServiceTracker object.
>> >> IMHO "is removed" is a bit unspecific (before/after?). However, I
>> found
>> in the Apache Felix implementation (which isn't a specification, of
course)
>> that removedService is invoked while handling the UNREGISTERING event:
>> >> UNREGISTERING - A service object is in the process of being
>> unregistered. This event is synchro-
>> >> nously delivered before the service object has completed
>> unregistering. That is, during the deliv-
>> >> ery of this event, the service object is still valid.
>> >> So I should be on the safe side if I also override removedService:
>> >> @Override
>> >> public void removedService(ServiceReference
>> reference,
>> >>LogService service) {
>> >> // Interrupt and join the thread(s) that refer to (use)
>> myLogService
>> >> myLogService = null;
>> >> super.removedService(reference, service);
>> >> }
>> >> Doing it this way, using myLogService in the thread(s) started in
>> addingService and stopped in in removeService should be safe, right?
>> >>  - Michael
>> >> ___
>> >> 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 

Re: [osgi-dev] Run a bundle as a certain jaas user

[chris . gray]

JAAS (like Shiro and other frameworks) ultimately relies on JavaSE's
java.security.AccessController - as does java.lang.SecurityManager.  So
these frameworks effectively replace the SecurityManager - and as they do
not link access to a code source they don't need the stack-inspection
magic that SecurityManager needs.

> The AccessControlContext is simply used as an independent vehicle to
> transport the logged in user and the groups. It allows for example CXF to
> set the authentication information in a CXF interceptor and the blueprint
> authz module to read the authentication. As JAAS is available in standard
> java the login can be transported without introducing a dependency between
> CXF and blueprint.
>
> The security is then for example enforced by a blueprint interceptor
> (blueprint-authz) or by java code. This security measure is not meant to
> protect against unauthorized code. It is only on application level like
> Guillaume explained.
>
> Christian
>
>
> 2016-03-01 9:47 GMT+01:00 Peter Kriens :
>
>> So no security manager and you can still use the AccessControlContext?
>> That surprises me and makes me wonder what it means? Without a security
>> manager, I do not understand how the checks are done, nor how they can
>> be
>> enforced?
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> > On 1 mrt. 2016, at 00:33, Christian Schneider
>> 
>> wrote:
>> >
>> > I will have to look into Conditional Permission admin.
>> > I only use JAAS to do the authentication and make the
>> AccesControlContext available on the thread via:
>> > AccessControlContext acc = AccessController.getContext()
>> > The nice thing is that this allows other parts of the code to do
>> authorization decisions without being coupled to any special security
>> library.
>> > I do not use the SecurityManager.
>> > The JAAS approach is already used in many places. For example the
>> karaf
>> web console populates the AccessControlContext  on the web console and
>> the
>> console. Karaf also checks the authorization of commands executed on the
>> shell this way. CXF populates the AccessControlContext from the service
>> authentication information. Aries blueprint can do annoation based
>> authorization using @RolesAllowed.
>> > So a nice way to run a bundle as a certain user would play very nicely
>> together with these mechanisms. Of course you can already do a JAAS
>> login
>> with code but it is a lot of boiler plate code.
>> > Christian
>> >
>> >
>> > 2016-02-29 8:42 GMT+01:00 Peter Kriens :
>> > There is no standardized solution for this. In general, Bundle
>> Activators are called on the thread the start method is called but this
>> is
>> not guaranteed and for DS you’er out of luck.
>> >
>> > That said, I am a bit puzzled by the model. JAAS is based on the same
>> (terrible) security model the VM gave us. Why not use Conditional
>> Permission admin to just manage the required permission for that bundle,
>> that you can do standardized and quite easy?
>> >
>> > Kind regards,
>> >
>> > Peter Kriens
>> >
>> > > On 28 feb. 2016, at 12:09, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>> > >
>> > > When working with JAAS based authentication it is necessary to run
>> the
>> code as a certain subject.
>> > >
>> > > For code that is called from the outside as well as from the karaf
>> shell there are existing solutions to do the login.
>> > > I wonder if there is an OSGi mechanism to do the same for code that
>> is
>> started inside a bundle. (Activator, blueprint or DS).
>> > > What I would like to have is some way to say: The startup code for
>> this bundle should run as a certain user.
>> > >
>> > > Is this already possible or would I have to create such a mechanism
>> myself?
>> > >
>> > > Christian
>> > >
>> > > --
>> > > Christian Schneider
>> > > http://www.liquid-reality.de
>> > >
>> > > Open Source Architect
>> > > http://www.talend.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
>> >
>> >
>> >
>> > --
>> > --
>> > Christian Schneider
>> > http://www.liquid-reality.de
>> >
>> > Open Source Architect
>> > http://www.talend.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
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> 
>
> 

Re: [osgi-dev] Understanding OSGi Initial Provisioning and Deployment Admin

[chris . gray]

If I want the log service to start first then I make every service depend
on the log service, mandatorily.  And then if the log service restarts
then so does everything else, but so what?  Just make sure the log service
doesn't restart halfway through boot ...

> On 14/12/15 18:29, Peter Kriens wrote:
>> NO startlevels is best … :-)
>>
>> If you really need start levels (and after thinking again) then you can
>> your set start levels by your management agent. One more reason why only
>> one bundle is started.
>>
>> Though start levels can be helpful to make it look like the systems
>> boots faster, it is too often used to mask bad bundles that are not
>> properly handling their dependencies. Those bundles will give you pain
>> in the future so it is better to fix them from the start. And then they
>> do not need start levels.
>>
>
>
> As a valid use-case I see the very early starting of a log bundle...
> (as an example)
>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>>
>>> On 14 dec. 2015, at 17:02, Seth Lana >> > wrote:
>>>
>>> Hi Peter,
>>>
>>> many thanks for your inputs, it really helped us to defined the way
>>> our team should to go.
>>>
>>> We had some difficulties defining the requirements of this pilot
>>> project due to, as you said, the large number of possibilities and
>>> combinations that we could have. But we are getting there...
>>>
>>> One last doubt, we have found no reference about bundle start level on
>>> both Initial Provisioning and Deployment Admin specs.
>>>
>>> In case of IP, we thought about two possibilities. One is to use IP
>>> archive's manifest file to hold the information and let the IP
>>> implementation bundle to use it after it install the bundle. for
>>> example:
>>>
>>> InitialProvisioning-Entries:
>>> org.apache.felix.scr;type=bundle;*startLevel=2*
>>>
>>> Another one is to add a text entry on the IP zip. as that will be
>>> stored in the provisioning dictionary then the management agent can
>>> obtain that information using the provisioning service and use it to
>>> set the startLevel.
>>>
>>> We are inclined for the option one. which would be the best approach
>>> for you?
>>>
>>> best regards,
>>>
>>> Seth
>>>
>>> On 10-12-2015 11:48, Peter Kriens wrote:
> On 9 dec. 2015, at 00:46, Seth Lana  wrote:
> Hello,
> I’m researching about the best ways to provide automatic remote
> provisioning for small devices and also for the servers that will
> provide content for such devices. Reading the OSGi compendium, some
> specs caught my attention: Initial Provisioning, Deployment Admin,
> Subsystems and Repository Services.
>
> If I got it right, we can have a device with only the OSGi
> container(with a minimal deps) and the IP Agent bundle jars assembled
> at factory.
 Yes. The core idea is that you deliver identical devices to all your
 customers except for the identity (serial number or so).

> At first use, the IP agent will contact the remote provisioning
> service (using Http or another protocol) and will download one or
> more IP zip files containing one or more bundles and configuration
> files defined by the remote provisioning operator for that device.
> All bundles inside the IP zips will be installed by the IP agent. So,
> this process follows until all necessary bundles are installed,
> ending with the Management Agent bundle being started. Am I right?
 Yup.

> What I found strange was the fact that only one bundle can be started
> at each time (each zip can have only one start entry pointing to only
> one bundle). Why this restriction?
 This allows this single bundle to verify the environment, do some
 checks, and setup security &  start levels for example.

> Should the Management Agent uninstall the IP agent after it is fully
> operational? or the IP must run every time the device starts up ?
 There is no obligation here. Personally, I would make sure that in
 certain situations the device can go back to initial mode so that the
 operator can regain control of the device after a catastrophic event.
 But again, there are not rules defined here.

> But the biggest doubt is about that Management Agent itself. It seems
> that one needs to be developed, right?.
 Yes. Something needs to provide YOUR policy, this is the management
 agent. You could buy one (this was ProSyst’s answer), there is open
 source (this was Marcel’s answer, or there is building it yourself. I
 prefer the latter because it allows you to provide your policy to the
 management operations. It is not a big deal because the management
 operations are part of the well defined OSGi API and are almost
 trivial to use.

> Should the Management Agent to use a Deployment Admin service
> provided by another bundle or should it 

Re: [osgi-dev] common osgi confussions

[chris . gray]

I recently had the luxury of being able to impose my preferences on the
whole team, because I was the whole team. ;-)  Here's what I did:

1) Bundle naming convention different to package name conventions - I used
two- or three-word names in CamelCase e.g. ShimmerPolishApi for the
polishing API of the Shimmer product.

2) Bundles generally containing more than one package.  If you sometimes
need to look up the bundle which contains a given package there are ways
enough to do so.

3) Strict segregation between Api and Impl bundles.  The Impl bundle
re-exports the corresponding Api packages.  Only Api bundles may be build
dependencies.  Only Impl bundles are deployed at runtime.

4) Use a resolver.  You do need to keep an eye open to stop e.g. the
bloody Felix web console from bringing in two versions of the SCR, but
still it's better than chasing resolution errors.

5) Use bndtools.  Shun PDE.

Of course on a one-man project almost any system of organisation will
work, but these recommendations are all based on larger projects I've
worked on.

HTH

Chris

> Regarding 1). I tend to have more than one package in a bundle (albeit,
> fairly coupled packages, as one should expect in this case). Bundle
> equates to coarse-grain component while package equates to more finer
> grain software construct(s).
>
> Regarding 2). As per having more than one package in a bundle, it is
> expected that versions of packages would vary independently of the bundle
> version.
>
> While on the subject - I separate API packages/bundles from Implementation
> packages/bundles, where "API" mayr or may not necessarily equate to a Java
> Interface construct.
>
> As always, avoid circular dependencies between packages (and, thus,
> bundles). There are other means to accomplish inter-communication without
> resorting to circles.
>
> HTH
>
> 
> From: osgi-dev-boun...@mail.osgi.org [osgi-dev-boun...@mail.osgi.org] on
> behalf of Endo, Alejandro [alejandro.e...@grassvalley.com]
> Sent: Monday, November 02, 2015 12:05 PM
> To: OSGi Developer Mail List
> Subject: [osgi-dev] common osgi confussions
>
> Hello everyone,
>
> My team has been using OSGi for over 2 years now but I still have to
> clarify something quite often, so I am hoping I can improve this to reduce
> development issues so that non-osgi developers (especially new hires) can
> deal with versioning and dependency resolution without needing to know all
> the internal details of OSGi
>
> There are basically two problems that arrive quite often
>
> 1)  Package name != bundle name: the naming convention we are using
> makes it hard to differentiate between a symbolicName and a java package.
> The recommended way that I found when we started using OSGi was to make
> the symbolic name match the java packages inside, but now I think this is
> confusing. Plus, there are some bad cases where the symbolic name doesn’t
> match the package name, in that case the person will spend a long time
> wondering where is that bundle called foo.hello when in reality foo.hello
> is the *package* and it is part of a bundle called my.bar.hello. I’ve been
> following the jigsaw expert group that Peter is part of and I have hear
> some suggestions of using a different delimiter for bundle names to avoid
> this. What do you guys think about this? We use PDE so I personally rely
> on the icon that PDE shows when complaining about missing dependencies.
> Otherwise, in the actual java log you just need to know the fact that OSGi
> uses packages for dependencies but that packages are packaged in bundles
> so when you see a bundle complaining, the bundle itself is a symbolic
> name, but it’s missing dependency is a java package. This is a lot of
> internal OSGi details for most developers whose tasks are to implement new
> features or fix bugs without having to think of the architecture of our
> system. I’m thinking of changing the symbolic name delimiter to make it
> more obvious that the concepts are orthogonal. So even if they don’t know
> all the internal details, they will know that a missing dependency a.b.c
> cannot be resolved just with a bundle a_b_c or a-b-c. Are there any
> drawbacks you guys have encountered? Is there a better technique?
>
> 2)  Package version != bundle version: This is even more surprising if
> you don’t know how dependency resolution works in OSGi. Imagine a bundle
> foo_1.0.0 exports package a.b.c_1.0.0 and a.b.d_1.0.0. Then there’s a
> bugfix on a.b.c so it becomes 1.0.1 and the bundle version also 1.0.1
> (a.b.d stays 1.0.0). Then another bugfix this time on a.b.d so it becomes
> 1.0.1 and the bundle 1.0.2 (a.b.c stays at 1.0.1). Then someone runs
> another bundle “bar” which depends on a.b.d 1.0.1 but installs foo
> version 1.0.1 (which has a.b.d at 1.0.0). They are usually (and
> understandably) really surprised that osgi is complaining about missing
> a.b.d 1.0.1 but see that foo contains the package a.b.d and that the
> version of 

Re: [osgi-dev] Is it possible to define services programatically using the blueprint container

[chris . gray]

They even eat XML (GD)

> Did you checkout Declarative Services?
>
> Kind regards,
>
>   Peter Kriens
>
>> On 21 okt. 2015, at 22:47, Leschke, Scott  wrote:
>>
>> I will do that.  Thanks.  I was interested in the Blueprint/XML route
>> mostly because I’m reasonably familiar with Blueprint and I think it
>> would be interesting if you could get some of the other aspects of
>> Blueprint, like service proxies, in a bit more dynamic fashion.
>>
>> Scott
>>
>> From: osgi-dev-boun...@mail.osgi.org
>> [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Arjun Panday
>> Sent: Wednesday, October 21, 2015 3:33 PM
>> To: OSGi Developer Mail List 
>> Subject: Re: [osgi-dev] Is it possible to define services
>> programatically using the blueprint container
>>
>> Hi Scott,
>>
>> Have a look at Felix's DependencyManager
>> (http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
>> ).
>> You don't feed it XML (yuck) but it has a very nice declarative API with
>> which you can build pretty much any programatic scenario you can think
>> of.
>>
>> /arjun
>>
>> On Wed, Oct 21, 2015 at 6:08 PM, Leschke, Scott > > wrote:
>> Looking at the container API it appears that it’s possible to get hold
>> of the container service and query it but it doesn’t look like it’s
>> possible to actually feed it XML and have it create and register
>> services at runtime.  Am I correct in this assessment?
>>
>> Scott
>>
>> ___
>> 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] Valid coordinator scenario?

[chris . gray]

To me this is less bad than having the coordination hang around for who-
knows- how- long in a ThreadLocal (or similar), but tastes may vary.

 I've created an OSGi issue to clarify whether below snippet is supposed
 to always work and after discussing this with BJ, that code is bound to
 fail as there is no strong reference to the coordination. The spec and
 the CT hint that the thread local (or equivalent construct) which holds
 the coordination in the implementation must be a weak reference.
 Therefore with the example below, no one is holding a strong reference
 to the coordination which then allows it to be garbage collected.

 Regards
 Carsten

 Am 31.07.15 um 04:48 schrieb Carsten Ziegeler:
 Hi,

 Christian brought up an interesting scenario for using the coordinator.
 The question is, if the following is a valid scenario:

coordinator.begin(test, 0);
System.gc();
coordinator.pop().end();

 (Of course no one will do a gc() call in his code, its just for
 demonstrational purposes)

 The coordination is bound to the thread, but no reference is held.

 Should the coordination be garbage collected? Looking at the CT it
 seems, the answer is yes.

 Regards
 Carsten



 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org
 ___
 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] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine

[chris . gray]

This is normal behaviour for a Java application which is spiralling out of
control. ;)  As in infinite recursion, or stuck in a tight loop trying to
create a component and always failing.

You should take this up on the felix mailing list, and preferably post the
stack trace instead of I get an error stating that the heap stack is out
of memory..

 There is one weird thing I've noticed ... my project is running super
 well with equinox 3.10.
 When I trying to run it with Felix 4.4.1 which comes with Bndtools the
 RAM usage climbs up
 to 2GB and then I get an error stating that the heap stack is out of
 memory.

 This is not normal behaviour from an OSGi container.


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

Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine

[chris . gray]

But do you know why?

 It's working now!

 On 21.06.2015 20:09, chris.g...@kiffer.be wrote:
 If you are launching the giant jar in both cases then that does indeed
 reduce the differences to a minimum.  Therefore I think you need to look
 at things outside of the jar: the Java version, the database (is it
 accessible on the ARM7 target, with the same credentials?), anything
 which
 is being read from the host filesystem (i.e. not from inside a bundle)
 and
 which could therefore be different or absent on the target ... have you
 tried running the giant jar on a virgin PC, one that has never been
 used
 to develop or run your software?

 If bundles are staying as ACTIVE that indicates that they are not
 getting
 RESOLVED.  Chances are that something pretty basic is going wrong in one
 bundle and this is having a domino effect on all the rest - and this
 could
 be happening before logging is initialised, so you don't see the root
 cause.  See if you can get Equinox to send some detailed logging to
 stdout.

 So the way Bndtools packages the whole project is by compressing all
 the
 required jars inside
 of one giant jar. When you run that jar with the following :

 java -jar MyBigProject.jar

 Bndtools start the initialization of the OSGi framework and then loads
 all the other jars
 within.

 I was not expecting to have any problem because java runs the same on
 all platform
 in theory.

 Again I'm confused why It's not working

 On 20.06.2015 21:43, chris.g...@kiffer.be wrote:
 So we have the same bundles running on the same framework ... what are
 the
 other variables?  Maybe another JDBC driver or a different JVM for
 example? Neither should make a big difference, but you never know.  Or
 the
 framework is being launched with different parameters - on DEV it is
 presumably launched by bndtools, how is it launched on ARM7?

 Like Neil I'm a bit surprised by the lack of detail in the error
 message,
 are you sure there is not more information available somewhere?

 It could be interesting to know which bundles stay in INSTALLED, maybe
 this will give a clue.

 Sorry for the targetted email towards Peter... this question was
 copied
 and pasted from a skype session and I forgot to remove his name to
 render
 the question more generic. :)

 Yes Neil you are correct I'm running equinox 3.7. Which comes
 with
 Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi
 R5)
 because of the incompatibility of Aries Transaction Manager which
 breaks
 the PlatformTransactionManager I depend on from Spring when I use it.

 Chris I verified the (lb command from gogo shell) from my dev IDE and
 the
 ARM7 server I setup and they are showing the sames bundle versions.

 I don't think that there is a real conflict since I'm only using
 Spring
 Transaction Manager 4.1.1.

 The other bundles which are using the SPM 4.1.1 don't show this error
 only
 few get ACTIVE and the rest stays as INSTALLED. I double checked with
 WebConsole and it's only on the ARM7 server it breaks.

 Sent from my iPod

 On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote:

 It’s a bit odd to see the “Package uses conflict” message but
 without the diagnostics of the conflicting chains. Are you running
 on
 an
 older OSGi Framework implementation? How are you launching your
 framework?

 Regards
 Neil


 On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote:

 Fortunately Peter is not the only one on this mailing list ;-)

 I'm no Blueprint wizard, but it does look very as much as if bambu
 is
 in a
 bit of a tizz about spring.framework.transaction.annotation.
 Probably
 the
 framework you are deploying into has different versions of some
 modules
 to
 what you have on your dev machine; your code was probably compiled
 against
 version 4.1, so you need to have version 4.x installed on the
 server
 and
 not 3.x or 5.x for example.

 Wherever possible you should try to have the same version of all
 the
 dependencies on the dev machine as are on the target, to avoid
 these
 surprises.  In particular, having a more recent version on dev
 than
 is
 running on the target is inviting disappointment.

 greetings Peter
 do you have an idea why i get this error on ARM7
 when I try to put my osgi project on production on the ARM7

 I run the project within my eclipse environment I get no error
 with
 Bndtools
 by the way I use the EXPORT function from bndtools to generate the
 jar
 that I'm using on the headless ARM7 ubuntu server

 Best regards

 Ergü






 ___
 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] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine

[chris . gray]

If you are launching the giant jar in both cases then that does indeed
reduce the differences to a minimum.  Therefore I think you need to look
at things outside of the jar: the Java version, the database (is it
accessible on the ARM7 target, with the same credentials?), anything which
is being read from the host filesystem (i.e. not from inside a bundle) and
which could therefore be different or absent on the target ... have you
tried running the giant jar on a virgin PC, one that has never been used
to develop or run your software?

If bundles are staying as ACTIVE that indicates that they are not getting
RESOLVED.  Chances are that something pretty basic is going wrong in one
bundle and this is having a domino effect on all the rest - and this could
be happening before logging is initialised, so you don't see the root
cause.  See if you can get Equinox to send some detailed logging to
stdout.

 So the way Bndtools packages the whole project is by compressing all the
 required jars inside
 of one giant jar. When you run that jar with the following :

 java -jar MyBigProject.jar

 Bndtools start the initialization of the OSGi framework and then loads
 all the other jars
 within.

 I was not expecting to have any problem because java runs the same on
 all platform
 in theory.

 Again I'm confused why It's not working

 On 20.06.2015 21:43, chris.g...@kiffer.be wrote:
 So we have the same bundles running on the same framework ... what are
 the
 other variables?  Maybe another JDBC driver or a different JVM for
 example? Neither should make a big difference, but you never know.  Or
 the
 framework is being launched with different parameters - on DEV it is
 presumably launched by bndtools, how is it launched on ARM7?

 Like Neil I'm a bit surprised by the lack of detail in the error
 message,
 are you sure there is not more information available somewhere?

 It could be interesting to know which bundles stay in INSTALLED, maybe
 this will give a clue.

 Sorry for the targetted email towards Peter... this question was copied
 and pasted from a skype session and I forgot to remove his name to
 render
 the question more generic. :)

 Yes Neil you are correct I'm running equinox 3.7. Which comes with
 Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5)
 because of the incompatibility of Aries Transaction Manager which
 breaks
 the PlatformTransactionManager I depend on from Spring when I use it.

 Chris I verified the (lb command from gogo shell) from my dev IDE and
 the
 ARM7 server I setup and they are showing the sames bundle versions.

 I don't think that there is a real conflict since I'm only using Spring
 Transaction Manager 4.1.1.

 The other bundles which are using the SPM 4.1.1 don't show this error
 only
 few get ACTIVE and the rest stays as INSTALLED. I double checked with
 WebConsole and it's only on the ARM7 server it breaks.

 Sent from my iPod

 On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote:

 It’s a bit odd to see the “Package uses conflict” message but
 without the diagnostics of the conflicting chains. Are you running on
 an
 older OSGi Framework implementation? How are you launching your
 framework?

 Regards
 Neil


 On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote:

 Fortunately Peter is not the only one on this mailing list ;-)

 I'm no Blueprint wizard, but it does look very as much as if bambu is
 in a
 bit of a tizz about spring.framework.transaction.annotation.
 Probably
 the
 framework you are deploying into has different versions of some
 modules
 to
 what you have on your dev machine; your code was probably compiled
 against
 version 4.1, so you need to have version 4.x installed on the server
 and
 not 3.x or 5.x for example.

 Wherever possible you should try to have the same version of all the
 dependencies on the dev machine as are on the target, to avoid these
 surprises.  In particular, having a more recent version on dev than
 is
 running on the target is inviting disappointment.

 greetings Peter
 do you have an idea why i get this error on ARM7
 when I try to put my osgi project on production on the ARM7

 I run the project within my eclipse environment I get no error with
 Bndtools
 by the way I use the EXPORT function from bndtools to generate the
 jar
 that I'm using on the headless ARM7 ubuntu server

 Best regards

 Ergü






 ___
 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] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine

[chris . gray]

So we have the same bundles running on the same framework ... what are the
other variables?  Maybe another JDBC driver or a different JVM for
example? Neither should make a big difference, but you never know.  Or the
framework is being launched with different parameters - on DEV it is
presumably launched by bndtools, how is it launched on ARM7?

Like Neil I'm a bit surprised by the lack of detail in the error message,
are you sure there is not more information available somewhere?

It could be interesting to know which bundles stay in INSTALLED, maybe
this will give a clue.

 Sorry for the targetted email towards Peter... this question was copied
 and pasted from a skype session and I forgot to remove his name to render
 the question more generic. :)

 Yes Neil you are correct I'm running equinox 3.7. Which comes with
 Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5)
 because of the incompatibility of Aries Transaction Manager which breaks
 the PlatformTransactionManager I depend on from Spring when I use it.

 Chris I verified the (lb command from gogo shell) from my dev IDE and the
 ARM7 server I setup and they are showing the sames bundle versions.

 I don't think that there is a real conflict since I'm only using Spring
 Transaction Manager 4.1.1.

 The other bundles which are using the SPM 4.1.1 don't show this error only
 few get ACTIVE and the rest stays as INSTALLED. I double checked with
 WebConsole and it's only on the ARM7 server it breaks.

 Sent from my iPod

 On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote:

 It’s a bit odd to see the “Package uses conflict” message but
 without the diagnostics of the conflicting chains. Are you running on an
 older OSGi Framework implementation? How are you launching your
 framework?

 Regards
 Neil


 On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote:

 Fortunately Peter is not the only one on this mailing list ;-)

 I'm no Blueprint wizard, but it does look very as much as if bambu is
 in a
 bit of a tizz about spring.framework.transaction.annotation.  Probably
 the
 framework you are deploying into has different versions of some modules
 to
 what you have on your dev machine; your code was probably compiled
 against
 version 4.1, so you need to have version 4.x installed on the server
 and
 not 3.x or 5.x for example.

 Wherever possible you should try to have the same version of all the
 dependencies on the dev machine as are on the target, to avoid these
 surprises.  In particular, having a more recent version on dev than
 is
 running on the target is inviting disappointment.

 greetings Peter
 do you have an idea why i get this error on ARM7
 when I try to put my osgi project on production on the ARM7

 I run the project within my eclipse environment I get no error with
 Bndtools
 by the way I use the EXPORT function from bndtools to generate the jar
 that I'm using on the headless ARM7 ubuntu server

 Best regards

 Ergü






 ___
 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] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine

[chris . gray]

Fortunately Peter is not the only one on this mailing list ;-)

I'm no Blueprint wizard, but it does look very as much as if bambu is in a
bit of a tizz about spring.framework.transaction.annotation.  Probably the
framework you are deploying into has different versions of some modules to
what you have on your dev machine; your code was probably compiled against
version 4.1, so you need to have version 4.x installed on the server and
not 3.x or 5.x for example.

Wherever possible you should try to have the same version of all the
dependencies on the dev machine as are on the target, to avoid these
surprises.  In particular, having a more recent version on dev than is
running on the target is inviting disappointment.

 greetings Peter
 do you have an idea why i get this error on ARM7
 when I try to put my osgi project on production on the ARM7

 I run the project within my eclipse environment I get no error with
 Bndtools
 by the way I use the EXPORT function from bndtools to generate the jar
 that I'm using on the headless ARM7 ubuntu server

 Best regards

 Ergü






 ___
 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] whiteboard pattern extenders

[chris . gray]

 It fails because equinox's FiltereServiceListener (as ServiceTracker
 registers a ServiceListener) does the following:

 if (allservices || ServiceRegistry.isAssignableTo(context, reference)) {

 }

 The call to ServiceRegistry.isAssignableTo(context, reference) fails when
 context (A) does not import package of reference (foo)

 Is this a bug?

ServiceRegistry.isAssignableTo(context, reference) seems to be doing its job.

 This method performs the following checks:

1. Get the package name from the specified class name.
2. For the bundle that registered the service referenced by this
ServiceReference (registrant bundle); find the source for the package.
If no source is found then return true if the registrant bundle is
equal to the specified bundle; otherwise return false.

Ding!  No source is found for the package for A, and A != B.

So the question is whether ServiceRegistry.isAssignableTo(context,
reference) is a necessary condition for ServiceTracker.  As I understand
Peter's post, it is too narrow a constraint because it excludes the
(unusual) case where no source for the package is found in 'context'.


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

Re: [osgi-dev] whiteboard pattern extenders

[chris . gray]

I haven't ever built


 I agree with BJ.

 If the wicket extender were a wicket whiteboard, rather than an extender,
 then I think we would expect it to track wicket services and then
 register Servlet services using its own context as a result of finding
 them. This is the same thing that lots of adapter bundles do.

 In the case of the wicket extender the only difference is how the wicket
 object is obtained. Other than that it should behave in the same way as
 the whiteboard version.

 Incidentally, it feels to me as if the wicket example would work better
 with a whiteboard than an extender, as it would allow downstream service
 dependencies for the wicket objects. I understand that it is only an
 example though :)

 Tim

 Sent from my iPhone

 On 18 Jun 2015, at 00:21, BJ Hargrave hargr...@us.ibm.com wrote:

 I think it should be B, the wicket extender,  since it is B that
 actually is wired to the servlet package and it is B which actually
 implements the Servlet. C does not implement the Servlet and does not
 import the servlet package. It just contributes implementation detail to
 the Servlet created by B.

 --

 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 5:54 PM



 On Wed, Jun 17, 2015 at 5:48 PM, BJ Hargrave hargr...@us.ibm.com
 wrote:
 In this case B, the Wicket extender, must import the servlet package
 since it is making Servlet objects and registering them as Servlet
 services. It must use the same servlet package as A, the whiteboard
 impl, in order for A to understand the Servlet services.

 Ok, that's fine. Who's bundleContext should be used to register the
 service?


 --

 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 5:20 PM

 Haha, I think everyone is very close! But I will try very hard to be
 really really clear to the use case:

 Take Apache Wicket:

 https://wicket.apache.org/learn/examples/helloworld.html

 This frame work allows a developer to implement web applications without
 ever needing to touch the Servlet API. It's more like building native
 GUI building, except that it produces HTML.

 Most of the time you have to bundle all the framework jars (which
 contain the servlets).

 However, let's imagine that now the bundle with the wicket application
 only imports the wicket APIs (no framework jars, or servlet API).

 Now let's consider a Wicket extender. This bundle is the wicket
 framework. It knows about how a wicket application should be
 bootstrapped. And it provides the concrete Servlet which exposes the
 application.

 Now the Wicket extender just wants to use the Http Whiteboard to
 register the wicket servlets.

 So, you have:

 A) the http whiteboard
 B) the Wicket Extender
 C) the Wicket application

 I can repeat this example many more times for many other web frameworks.

 - Ray

 On Wed, Jun 17, 2015 at 4:52 PM, Neil Bartlett njbartl...@gmail.com
 wrote:
 Felix,


 On 17 Jun 2015, at 21:35, Felix Meschberger fmesc...@adobe.com wrote:

 Hi


 Am 17.06.2015 um 21:56 schrieb Neil Bartlett njbartl...@gmail.com:

 I think that B (the extender) must register the Servlet service using
 its own BundleContext, since it is the bundle that actually creates
 the Servlet objects.

 I don’t think that works in general. And I actually think it is
 wrong.

 No, I stand by it because your summary below doesn’t match up with
 what Ray actually said. At least insofar as I have understood him
 correctly.



 To repeat Ray’s example:

 (A) consumes a service, say javax.servlet.Servlet
 (B) extends packages declaring something and registering services on
 behalf of them
 (C) declare something and provide the Servlets, hence implementations
 of the javax.servlet.Servlet interface.

 Ray stated that the extended bundle C does NOT provide Servlets or know
 anything about Servlet API. It just creates these “webby
 somethings”.



 Now, C having the implementations implementing an interface *must* by
 definition be wired to the service interface, otherwise the
 implementations cannot be loaded by C’s class loader. And B must not
 use its own (B’s) class loader but must use C’s class loader to
 load the implementations from C and use C’s bundle context to
 register the service. B is only a messenger and B’s bundle context
 (and 

Re: [osgi-dev] whiteboard pattern extenders

[chris . gray]

I haven't ever built a wicket extender, but I did once make a contraption
which automagically generated a REST interface based on information in the
target bundle.  In this case B registers servlets which will be picked up
by C, so far so good, but these servlets result in calls to classes which
are defined in A - to which B is not normally wired.  So B has to do some
fancy stuff to load those packages (using A's class loader), but this does
not imply that the servlets themselves should be registered on behalf of
A: the servlets do not expose any of A's packages in the interfaces they
register with C.

 I agree with BJ.

 If the wicket extender were a wicket whiteboard, rather than an extender,
 then I think we would expect it to track wicket services and then
 register Servlet services using its own context as a result of finding
 them. This is the same thing that lots of adapter bundles do.

 In the case of the wicket extender the only difference is how the wicket
 object is obtained. Other than that it should behave in the same way as
 the whiteboard version.

 Incidentally, it feels to me as if the wicket example would work better
 with a whiteboard than an extender, as it would allow downstream service
 dependencies for the wicket objects. I understand that it is only an
 example though :)

 Tim

 Sent from my iPhone

 On 18 Jun 2015, at 00:21, BJ Hargrave hargr...@us.ibm.com wrote:

 I think it should be B, the wicket extender,  since it is B that
 actually is wired to the servlet package and it is B which actually
 implements the Servlet. C does not implement the Servlet and does not
 import the servlet package. It just contributes implementation detail to
 the Servlet created by B.

 --

 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 5:54 PM



 On Wed, Jun 17, 2015 at 5:48 PM, BJ Hargrave hargr...@us.ibm.com
 wrote:
 In this case B, the Wicket extender, must import the servlet package
 since it is making Servlet objects and registering them as Servlet
 services. It must use the same servlet package as A, the whiteboard
 impl, in order for A to understand the Servlet services.

 Ok, that's fine. Who's bundleContext should be used to register the
 service?


 --

 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 5:20 PM

 Haha, I think everyone is very close! But I will try very hard to be
 really really clear to the use case:

 Take Apache Wicket:

 https://wicket.apache.org/learn/examples/helloworld.html

 This frame work allows a developer to implement web applications without
 ever needing to touch the Servlet API. It's more like building native
 GUI building, except that it produces HTML.

 Most of the time you have to bundle all the framework jars (which
 contain the servlets).

 However, let's imagine that now the bundle with the wicket application
 only imports the wicket APIs (no framework jars, or servlet API).

 Now let's consider a Wicket extender. This bundle is the wicket
 framework. It knows about how a wicket application should be
 bootstrapped. And it provides the concrete Servlet which exposes the
 application.

 Now the Wicket extender just wants to use the Http Whiteboard to
 register the wicket servlets.

 So, you have:

 A) the http whiteboard
 B) the Wicket Extender
 C) the Wicket application

 I can repeat this example many more times for many other web frameworks.

 - Ray

 On Wed, Jun 17, 2015 at 4:52 PM, Neil Bartlett njbartl...@gmail.com
 wrote:
 Felix,


 On 17 Jun 2015, at 21:35, Felix Meschberger fmesc...@adobe.com wrote:

 Hi


 Am 17.06.2015 um 21:56 schrieb Neil Bartlett njbartl...@gmail.com:

 I think that B (the extender) must register the Servlet service using
 its own BundleContext, since it is the bundle that actually creates
 the Servlet objects.

 I don’t think that works in general. And I actually think it is
 wrong.

 No, I stand by it because your summary below doesn’t match up with
 what Ray actually said. At least insofar as I have understood him
 correctly.



 To repeat Ray’s example:

 (A) consumes a service, say javax.servlet.Servlet
 (B) extends packages declaring something and registering services on
 behalf of them
 (C) declare something and provide the Servlets, hence implementations
 of the 

Re: [osgi-dev] whiteboard pattern extenders

[chris . gray]

Now I'm the one that's lost, perhaps because part of clause B) below has
been eaten by gremlins.

Suppose that my extender recognises some magic header in your bundle and
uses it to generate a Servlet which acts as a plug-in for the Felix web
console.  Would that be an example?

 On Wed, Jun 17, 2015 at 2:44 PM, BJ Hargrave hargr...@us.ibm.com wrote:

 So this is like DS (an extender) registering Servlet services on behalf
 of
 a bundle using DS. Then of course the extender bundle does not care
 about
 the servlet package but also the extender bundle is not using
 ServiceTrackers to track the Servlet services. That is done by the Http
 Whiteboard impl bundle which does care about the servlet package and its
 version.


 I'm sorry but you've lost me, and DS isn't an example of the scenario
 because the DS bundle is itself tracker in this scenario.

 In the scenario I'm describing there are 3 bundles in play:

 A) the whiteboard bundle (has the trackers)
 B) an extender which registers services that the whiteboard
 C) a bundle which is being extended by B) but doesn't know anything about
 A) or the API it's being extended with

 Sincerely,
 - 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 2:23 PM

 But an extender who registers services to a whiteboard impl on behalf of
 extendee will result in those services not being visible to the
 whiteboard
 if the extendee does not import the packages used by the services?

 On Wed, Jun 17, 2015 at 2:16 PM, BJ Hargrave hargr...@us.ibm.com
 wrote:

 Well whiteboard and extenders are different.

 Whiteboard should not use true since it cares about the specific API
 package version.

 Extenders should use BundleTrackers rather than ServiceTrackers since
 they
 are not using whiteboard services.

 --

 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: 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: [osgi-dev] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 2:12 PM

 When implementing a whiteboard pattern should we always open trackers
 using the trackAllServices = true ? via:

 ServiceTracker.open(true);

 It would seem that this is the only way that we can support extenders
 where the extendee has no knowledge of the APIs in question, correct?

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




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




 --
 *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] whiteboard pattern extenders

[chris . gray]

 I think that B (the extender) must register the Servlet service using its
 own BundleContext, since it is the bundle that actually creates the
 Servlet objects.

+1

For DS the situation is different: the SCR knows nothing about the
services it is registering on behalf of other bundles, it just
regurgitates what it finds in the XML.  In the webby proxy thingy model it
is precisely the extender which knows about servlets and who knows maybe
MVC and REST frameworks and more besides, while the extendee is just a
passive victim.  That's why in the former case it make sense for the
extender to masquerade as the extendee and in the latter it doesn't.


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

Re: [osgi-dev] whiteboard pattern extenders

[chris . gray]

Since B is the one creating the service objects, B must be wired up to C
in order to use the same runtime package.  The fact that these objects are
being created because of some magic cookies in A doesn't really change
very much - B could as well register a servlice every time it receives a
tweet with the hashtag #crackerjack.  Or am I missing something?


 On Wed, Jun 17, 2015 at 3:38 PM, BJ Hargrave hargr...@us.ibm.com wrote:

 Well you were the one describing the scenario, I was trying to repeat
 what
 I thought you were saying :-)

 So C is a bundle which does not have any implementation of Servlet and
 does not import the servlet package and B will register a Servlet
 service,
 using C's bundle context, with some object implementing Servlet and B
 does
 not import the servlet package.

 How does B get an object implementing Servlet to register as the service
 since it has no wiring to any package containing Servlet?


 I never said that B doesn't know about Servlet... In fact I said exactly
 that B knows about making Servlets.


 It seems odd that neither B or C is wired to the servlet package, yet
 they
 conspire to register a Servlet service.


 B should certainly be wired to the servlet package... and the same one as
 the whiteboard.

 Let me try to clarify with a concrete example.

 There are many webby technologies in existence which remove the need for
 a developer to have any knowledge of Servlet API. These technologies use
 things like annotations or even simply pure packaging conventions for
 describing their application.

 However, in the end, you need a servlet. Typically some framework looks at
 the packaging convention and then reacts to that by creating a Servlet
 which turns the convention into something concrete.

 In this scenario the original bundle doesn't know anything about
 Servlet... BUT there is certainly a concrete servlet implementation
 somewhere that knows about the convention.

 However, this concrete thing (the extender) wants to use the whiteboard
 instead of handling all the HTTP stuff itself.

 the whiteboard knows nothing about this extender.





 --

 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 3:32 PM

 Actually Chris is correct in describing the scenario and BJ you are not
 correct.

 C) is some bundle which has a header ImCool: oh so cool!
 B) is an extender which makes servlets from the header ImCool IT knows
 how to make a Servlet service.
 A) is the whiteboard


 This doesn't work because C) does not import Servlet.

 - Ray

 On Wed, Jun 17, 2015 at 3:24 PM, BJ Hargrave hargr...@us.ibm.com
 wrote:

 OK.

 So A, the whiteboard impl, has ServiceTrackers and must care about the
 specific package.

 B is the extends which registers the services. It has no ServiceTrackers
 and does not care about the package since it does not use the package
 itself.

 C also must care about the same package as A (so they are type
 compatible).

 So there is not bundle which both is the extender and registers the
 services and also has ServiceTrackers which must care about the specific
 package. Therefore trackAllServices=true is not needed.

 --

 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: 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] whiteboard pattern  extenders
 Date: Wed, Jun 17, 2015 2:55 PM



 On Wed, Jun 17, 2015 at 2:44 PM, BJ Hargrave hargr...@us.ibm.com
 wrote:

 So this is like DS (an extender) registering Servlet services on behalf
 of
 a bundle using DS. Then of course the extender bundle does not care
 about
 the servlet package but also the extender bundle is not using
 ServiceTrackers to track the Servlet services. That is done by the Http
 Whiteboard impl bundle which does care about the servlet package and its
 version.


 I'm sorry but you've lost me, and DS isn't an example of the scenario
 because the DS bundle is itself tracker in this scenario.

 In the scenario I'm describing there are 3 bundles in play:

 A) the whiteboard bundle (has the trackers)
 B) an extender which registers services that the whiteboard
 C) a bundle which is being extended by B) but doesn't know anything
 about
 A) or the API it's being extended with

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



 

Re: [osgi-dev] Change service properties using OSGI API

[chris . gray]

The question does arise, why exactly do you want to do this?.  I felt
such a need once in the past, but ended by deciding that actually it
wasn't such a good idea.  If you want to use this to for indicate that for
example a component has switched from active to standby mode then you may
find you are pushing on a piece of string.

 Hi,

 I would like to change and add properties to an OSGI service. The only way
 I
 know requires access to the ServiceRegistration object of the service
 instance.
 However, this ServiceRegistration object cannot be retrieved from the OSGI
 registry, but is returned only when we register the service and therefore
 hardly available to a 3rd party that hasn¹t created the service.

 Is there any other way to change service properties or obtain the
 ServiceRegistration object?
 Thanks in advance
 Frank



 ___
 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] osgi-dev Digest, Vol 103, Issue 2

[chris . gray]

Frank

Do try to be precise, it can be quite handy when developing software. ;-)

If you only want your service to start up if-and-when some service is
available, make a (mandatory) @Reference to that service.  If you want
something else, then be more precise as to what it is that you want ...

 I am sorry for not being sufficiently precise, I didn¹t mean annotation, I
 meant Component property

   @Component(properties={property1=value})


 Based on the value of property1, I will check if the service component
 should be in the state ACTIVE or STATE_UNSATISFIED

 The actual use case is to check if a message queue was in a messaging
 middleware was previously setup. If not, the service (EventHandler) should
 not startup.


 On 5/5/15, 6:00 PM, osgi-dev-requ...@mail.osgi.org
 osgi-dev-requ...@mail.osgi.org wrote:

Send osgi-dev mailing list submissions to
  osgi-dev@mail.osgi.org

To subscribe or unsubscribe via the World Wide Web, visit
  https://mail.osgi.org/mailman/listinfo/osgi-dev
or, via email, send a message with subject or body 'help' to
  osgi-dev-requ...@mail.osgi.org

You can reach the person managing the list at
  osgi-dev-ow...@mail.osgi.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of osgi-dev digest...


Today's Topics:

   1. Stop/disable OSGI component/service based on annotation
  (Frank Langel)
   2. Re: Stop/disable OSGI component/service based onannotation
  (Neil Bartlett)


--

Message: 1
Date: Tue, 05 May 2015 11:03:39 +0200
From: Frank Langel fr...@frankjlangel.com
To: osgi-dev@mail.osgi.org
Subject: [osgi-dev] Stop/disable OSGI component/service based on
  annotation
Message-ID: d16e540b.242c7%fr...@frankjlangel.com
Content-Type: text/plain; charset=iso-8859-1

Hi,

Here is the scenario I like to achieve
1. I create a OSGI component/service X that has an annotation A1
2. It has no dependencies or start/active methods
3. Based on the value of A1, I like this service to be available or
 marked
as STATE_UNSATISFIED when starting up
How can I do this?
*  ServiceTracker is not the answer I think. It doesn?t provide the
ability
to access the component context that would allow me to disable the
 service
again, plus I think its not a good idea as there might be dependencies to
be
managed
* I don?t want to add the logic in the activate method bc I want to apply
it
to all components with the annotation
* Introspection in Activator : I could not use the component model
directly,
but search my bundle for all classes with this annotation, and start the
service myself
* I cannot use service listener, as ServiceEvent does not expose an
possibly
to interfere when registering the service
* Are service hocks the answer ?
Thanks a lot in advance
Frank





-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.osgi.org/pipermail/osgi-dev/attachments/20150505/27605ced/att
achment-0001.html

--

Message: 2
Date: Tue, 5 May 2015 10:08:31 +0100
From: Neil Bartlett njbartl...@gmail.com
To: OSGi Developer Mail List osgi-dev@mail.osgi.org
Subject: Re: [osgi-dev] Stop/disable OSGI component/service based on
  annotation
Message-ID: f014f5c5-b64e-48e5-876a-a98b9fa29...@gmail.com
Content-Type: text/plain; charset=windows-1252

Hi Frank,

Can you please clarify the meaning of point 3.

?Based on the value of A1?? but this is an annotation on a class so is
there any possibility for it to change during runtime? It seems that
whatever the value of A1 is at compile time will determine forever
whether that component is active or inactive. That can?t be what you mean
though, so could you please elaborate a little further what you had in
mind?

Regards,
Neil

 On 5 May 2015, at 10:03, Frank Langel fr...@frankjlangel.com wrote:

 Hi,

 Here is the scenario I like to achieve
 I create a OSGI component/service X that has an annotation A1
 It has no dependencies or start/active methods
 Based on the value of A1, I like this service to be available or marked
as STATE_UNSATISFIED when starting up
 How can I do this?
  ServiceTracker is not the answer I think. It doesn?t provide the
ability to access the component context that would allow me to disable
the service again, plus I think its not a good idea as there might be
dependencies to be managed
 I don?t want to add the logic in the activate method bc I want to apply
it to all components with the annotation
 Introspection in Activator : I could not use the component model
directly, but search my bundle for all classes with this annotation, and
start the service myself
 I cannot use service listener, as ServiceEvent does not expose an
possibly to interfere when registering the service
 Are service hocks the answer ?
 Thanks a lot in advance
 Frank



 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org
 

Re: [osgi-dev] service tracker precedence

[chris . gray]

Then you have been lying to us when you said that provider A cannot be
changed; you have the source code. ;-)

Trying to make a delegating proxy like this is really quite hard, believe
me (and others in this thread).  Are you saying that B should use a
persistent and distributed event handling system if one is available,
otherwise it just delegates to A?  And that the consumers couldn't care
less which happens?  I have my doubts about that last bit, and if they
*do* care then they should be able to express this in a filter.

 Yep, thought so.  Idea was to have two EventAdmin implementations
 * Provider A is the fellix event admin impl
 * Provider B is a custom implementation providing additional
 functionality/capabilities
 Provider B is registering a service of type EventHandler if that event
 handler service has some specific properties, else A is used. In my case,
 B
 provides persistent and distributed  messaging implementation.

 Does that make sense?
 Thanks
 Frank


 From:  Marcel Offermans marcel.offerm...@luminis.nl
 Date:  Wednesday, April 15, 2015 at 12:59 PM
 To:  Frank Langel fr...@frankjlangel.com, OSGi Developer Mail List
 osgi-dev@mail.osgi.org
 Subject:  Re: [osgi-dev] service tracker precedence


 Greetings, Marcel



 ___
 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] Packaging OSGi for (desktop) Windows

[chris . gray]

Hi Tim,

As in
http://stackoverflow.com/questions/17742961/how-to-write-a-an-osgi-command-line-application?
I should have known - if there is a possible use for it, bnd can do it!

Indeed this reduces my problem to that of creating an installer for a Java
application, for which there are plenty of solutions available. Bedankt
hoor!

Regards

Chris

 Hi Chris,

 With bndtools you can also export your complete OSGi application to a
 single .jar file. From thereon you can create an installer like any
 regular Java application.

 Regards,

 Tim

 On 04/13/2015 10:11 PM, chris.g...@kiffer.be wrote:
 Hi all,

 I'm developing a Windows taskbar app which revolves around a Java
 library,
 so I am using OSGi to build it. This part is going just fine, but once
 the
 app is working I have to find a way to distribute it so that it can be
 installed by highly qualified medical personnel, i.e. complete
 nincompoops
 so far as IT is concerned (of course they view us in the same way).  In
 principle this seems pretty do-able (the framework is the main app, and
 it
 needs some bundles to be around just like other apps need fonts and
 images
 etc.), I just wondered if anyone out there has already been through this
 and can point to some tools which are helpful, or blind alleys not to
 get
 stuck in?

 Regards, Chris


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


 --
 Tim Verbelen
 Department of Information Technology
 Broadband Communication Networks (IBCN)
 Ghent University - iMinds
 Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
 T: +32 9 33 14940 ; T Secr: +32 9 33 14900
 F: +32 9 33 14899
 E: tim.verbe...@intec.ugent.be
 W : www.ibcn.intec.UGent.be

 ___
 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] Packaging OSGi for (desktop) Windows

[chris . gray]

Hi all,

I'm developing a Windows taskbar app which revolves around a Java library,
so I am using OSGi to build it. This part is going just fine, but once the
app is working I have to find a way to distribute it so that it can be
installed by highly qualified medical personnel, i.e. complete nincompoops
so far as IT is concerned (of course they view us in the same way).  In
principle this seems pretty do-able (the framework is the main app, and it
needs some bundles to be around just like other apps need fonts and images
etc.), I just wondered if anyone out there has already been through this
and can point to some tools which are helpful, or blind alleys not to get
stuck in?

Regards, Chris


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

Re: [osgi-dev] Packaging OSGi for (desktop) Windows

[chris . gray]

Indeed, looks like the client is an OSGi app. Certainly worth a look,
thanks for the tip!

 Hi,

 I am only a user of jitsi but what I see it is pretty easy to install and
 use it: https://jitsi.org/
 It is a skype-like chat, video conference and screen sharing app that is
 based on Apache Felix. You might want to analyze the source of that
 project.

 Regards,
 Balazs


 On Mon, Apr 13, 2015 at 10:11 PM, chris.g...@kiffer.be wrote:

 Hi all,

 I'm developing a Windows taskbar app which revolves around a Java
 library,
 so I am using OSGi to build it. This part is going just fine, but once
 the
 app is working I have to find a way to distribute it so that it can be
 installed by highly qualified medical personnel, i.e. complete
 nincompoops
 so far as IT is concerned (of course they view us in the same way).  In
 principle this seems pretty do-able (the framework is the main app, and
 it
 needs some bundles to be around just like other apps need fonts and
 images
 etc.), I just wondered if anyone out there has already been through this
 and can point to some tools which are helpful, or blind alleys not to
 get
 stuck in?

 Regards, Chris


 ___
 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] persistence, lazy loading and service dynamic

[chris . gray]

Hi Andreas,

 So I think with some unlucky timing there allways remains a small risk of
 failure when calling a service due to service dynamic.

Yes.

 My question is, if it is possible to avoid this small risk?

No. Or to put it another way: when you invoke a service you are always (in
principle) invoking unknown code which may not behave the way you
expect, so you should program defensively. Be prepared for the service to
fail, and take the time to think what you should do if it does - propagate
the failure? or try to carry on?

To me this is a part of modularity, independent of dynamics - within your
service you should not need to perform many checks, but you should check
the parameters with which you are invoked and if you call another service
you should treat it as fallible.

Chris


 -Ursprüngliche Nachricht-
 Von:David Bosschaert david.bosscha...@gmail.com
 Gesendet:Mi 18.03.2015 21:45
 Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic
 An:OSGi Developer Mail List osgi-dev@mail.osgi.org;
 Hi Andreas,

 If I understand your email correctly the following is your concern:

 So it may occur, that a call by the DomainsService on a property of an
 entity happens when the DAO-Service is not available anymore.
 ...
 What options do I have to safely load the entities?

 AFAICS you really have two options:
 1. If the service is gone, the call will fail. Maybe you can
 gracefully deal with the failure.
 2. If the dependent service is gone then make sure the depending code
 does not run. This is really the approach taken by DS. If you declare
 a mandatory dependency on your DAO service for the DomainService code
 then if the DAO service disappears the DomainService will also not
 exist. In DS mandatory dependencies are the default model.

 Option 2. above is clearly the most elegant scenario. Does this cover
 your concern or is there something that I missed?

 Best regards,

 David


 On 14 March 2015 at 16:41, Andreas Klotz andreas.kl...@n-design.de
 wrote:
 Hi all,



 I have an use case where I want the dynamic of a service to be bound to
 another higher level service. Maybe I need Subsystems...?



 I think it is a good design of an OSGi-service if it just provides data
 in
 contrast to provide objects on which an operation can be performed that
 is
 using resources of the underlying bundle. Although the second variant
 would
 be possible, I think that handling service/bundle dynamic becomes very
 complex or even unmanageable.



 However there is a use case where I can't deliver just data by a
 service. I
 think of lazy loading when dealing with persistence.

 I usually define interfaces for the data access layer. So I get a
 Bundle-Setting like this:



 - Entity-Bundle (contains Entities)

 - DataAccessAPI-Bundle (contains DAO-Interfaces)

 - DataAccessImpl-Bundle (provides Services implementing DAO-Interfaces)

 - DomainService_A-Bundle (contains domain Logic for e.g. a GUI, uses
 DAO-Services; would be separated in API and impl of course)

 - DomainService_B-Bundle (contains more domain Logic, uses same
 DAO-Services
 as DomainsService_A)



 DomainServices A and B are clients of DAO-Services. A DAO-Service may
 provide an entity with some lazy loading properties. The transactions of
 the
 data accesses are defined by the DomainServices. So it may occur, that
 a
 call by the DomainsService on a property of an entity happens when the
 DAO-Service is not available anymore. That would lead to an
 unsuccessful
 attempt to load the property lazily (assuming that connections to the
 database are managed by the DAO-Bundle and not by a separate e.g.
 EntityManager-Service). So the DAO-Service delivered an object that
 tries to
 perform an operation on its delivering service.



 What options do I have to safely load the entities?

 - Do not use lazy Loading? I know cases where this would load the whole
 DB
 in to the RAM...

 - Make assumptions about certain properties a client might need and
 load
 them explicitly in the DAO-Layer? This will not work if I have
 different
 clients for one DAO-Service.

 - Is there a possibility to package DomainServices A and B as different
 Subsystems with the DAO-Service as a shared capability? Would this have
 the
 effect that the bundle providing the DAO-Service will only be stoppable,
 if
 both DomainServices are stopped?



 To be more general: In our OSGi-projects we use micro-services intensely
 to
 loosely couple not only domain logic (vertical) but also the
 architectural
 layers (horizontal). And I often feel that I only want dynamic for the
 vertical bundles/services.



 I am very interested in your opinion and how you deal with lazy loading
 or
 equivalent cases.



 Thanks and best regards,

                 Andreas


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

Re: [osgi-dev] Declarative Services - Idea

[chris . gray]

Hi Florian,

It's the SCR which picks up those XML files when the bundle containing
them is installed, and therefore knows what service interfaces it should
be listening for and which components need to be injected with those
services when they appear (and to de-inject them when they disappear).
The use cases where you cannot use DS are typically those where either1)
you don't have an SCR or 2) there is an SCR some other entity is
responsible for creating components and the SCR has no insight into this. 
(Worse still there can be two versions of the component, one managed by
SCR and one by the other framework - aaargh).

The bundleContext object is used to talk to the OSGi framework, and the
OSGi framework doesn't know anything about DS so it cannot do anything
with your injectMembers() call. This separation of concerns (extender
pattern) is part of the beauty of DS, and I think any proposal to make
the framework DS-aware would be greeted with much shaking of wise heads.

There may be scope for the various component/injection mechanisms which
are currently supported by OSGi to work better with one another, or even
with the anti-modular, anti-dynamic, reflection-infested frameworks(*)
widely used in the industry, but that is something else.

All the best

Chris

(*) Of course I love them really. Right?

 Hey,

 i got an idea for a nice DS enhancement. I am using DS a lot. And
 sometimes
 google.Guice too. And indeed there are some usecases where these features
 can be combined.

 Using DS i sometimes a miss a method, that injects (wires) all references
 according the component definition xml for classes instantiated by new.

 Like this:
 *class Service {*

 * @Reference(...)*
 * protected void bindTransactionManager(TransactionManager tm) {*
 *  .*
 *  }*
 *}*

 A different piece of code:
 *Service s = new Service();*
 *bundleContext.injectMembers(s);*

 The call #injectMembers(s) will use the component definition (there is
 generated xml file based on the annotations of Service.java) to wire up
 all
 references for the given instance.

 Usecase:
 There are usecases where you can not use DS. And for these ones a
 possibility to inject required services based on the component definition
 would be great.

 Are there any plans for such a specification change?

 Thanks
 Florian

 --
 Florian Pirchner
 Lunifera GmbH
 Marchfelder Straße 2
 2301 Groß Enzersdorf
 Austria
 ___
 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] getting a service filtered on my bundleId

[chris . gray]

The first time I used built a WAB I spent some time going quietly insane
because I was using DS (of course) and I ended up with two instances of my
service object, one created by DS and one by the WS container. That was an
easy one - kill the WAB - but in general I think there will always be
problems if two component frameworks are trying to control the same bundle
(and potentially to instantiate the same components). Between
DS/Blueprint/iPOJO it could maybe be made to work by agreeing on some
common APIs, but if the other framework is WS, CDI or whatever then forget
it.


 From: Raymond Auge raymond.a...@liferay.com
 BJ bundles are not limited to using only a single spec! OSGi is
 modular after all, no?

 It's entirely possible for a bundle to use several extenders at
 once. This is a completely legitimate use case.

 This is exactly the case I'm dealing with.

 I don't think what I'm asking is outlandish.

 It is a case discussed in the OSGi EGs and that we never agreed to solve.
 Basically, we don't support multiple active extenders like DS, Blueprint
 and Web Application Specification each trying to control a bundle. There
 is no way to coordinate that as you see. We certainly expect different
 bundles to use different technologies, but did not do anything to support
 a single bundle to be extended by multiple active extenders. What you are
 attempting to do is outside the scope of the existing OSGi specifications.
 I highly recommend you split the bundle up so that only a single active
 extender is controlling each bundle.

 --

 BJ Hargrave
 Senior Technical Staff Member, IBM
 OSGi Fellow and CTO of the OSGi Alliance
 hargr...@us.ibm.com

 office: +1 386 848 1781
 mobile: +1 386 848 3788
 ___
 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] setting contextClassLoader inside library bundles

[chris . gray]

IMO TCCL is BAD, end of story. Just do what you have to do, when you have to.

 In OSGi, just use the bundle's existing class loader. But there is no
 general purpose solution to setting the TCCL in OSGi since there is no one
 class loader that would have visibility to the types some arbitrary code
 wants to load.
 --

 BJ Hargrave
 Senior Technical Staff Member, IBM
 OSGi Fellow and CTO of the OSGi Alliance
 hargr...@us.ibm.com

 office: +1 386 848 1781
 mobile: +1 386 848 3788




 From:   Mike Wilson mike...@hotmail.com
 To: 'OSGi Developer Mail List' osgi-dev@mail.osgi.org
 Date:   2015/02/23 13:37
 Subject:Re: [osgi-dev] setting contextClassLoader inside library
 bundles
 Sent by:osgi-dev-boun...@mail.osgi.org



 Hm, I'm pondering whether the TCCL assignment in CXF is aimed for CXF
 itself. Maybe it depends on this mechanism to get access to the classes in
 generated APIs? When calling methods on generated API, inside the CXF core
 bundle I see TCCL set to the generated API bundle.

 It seems this could be a general pattern for libraries that let the client
 generate code, and I wonder if there is a better solution than TCCL in
 OSGi
 for this case?

 Best regards
 Mike

 BJ Hargrave wrote:
 There are times when it is necessary when dealing with legacy
 code that
 demands the TCCL provide visibility to some types. Normally you do a
 try/finally to set and restore the TCCL around the call to
 the legacy code
 which needs the TCCL set to some value. But I imagine there
 are times when
 you will encounter conflicting interests in the value of TCCL
 that cannot
 be easily solved.
 --

 BJ Hargrave
 Senior Technical Staff Member, IBM
 OSGi Fellow and CTO of the OSGi Alliance
 hargr...@us.ibm.com

 office: +1 386 848 1781
 mobile: +1 386 848 3788




 From:   Mike Wilson mike...@hotmail.com
 To: osgi-dev@mail.osgi.org osgi-dev@mail.osgi.org
 Date:   2015/02/23 11:03
 Subject:[osgi-dev] setting contextClassLoader inside library
 bundles
 Sent by:osgi-dev-boun...@mail.osgi.org



 We just ran into some problems when running CXF inside Karaf.
 The cause is
 that CXF assigns the contextClassLoader to the bundle
 ClassLoader during
 each message event.
 Based on various discussion on the net (f ex [1]) I had expected that
 libraries like CXF would not touch the contextClassLoader
 when run inside
 OSGi. Or are there valid use cases for this?

 Thanks
 Mike

 [1]
 http://njbartlett.name/2012/10/23/dreaded-thread-context-class
 loader.html

 ___
 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] Routing service calls?

[chris . gray]

On 14 Jan 2015, at 08:23, Christian Schneider ch...@die-schneider.net
wrote:

 How about using a special property for the routing proxy? Publish it
with the same interface as the backend services but give it a service
property like proxy=true.
 Then in the front end you can filter for a service with
 filter=“(proxy=true).

This is the simple, straightforward, idiomatic way to do things. The only
drawback is that all the clients need to specify that filter otherwise
they are likely to get a backend injected instead of the proxy.

Timothy Ward tim.w...@paremus.com write;

 Also, if your service client is a DS component then these filters can be
dynamically added/changed/removed using Configuration Admin.

Thinking out loud: could one use a ListenerHook to detect service
listeners binding to the service interface without filtering on the
'proxy' property and send them an improved filter via CA? Or would this
be opening up another can of worms?

Chris



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

Re: [osgi-dev] Faking DS for classpath libraries

[chris . gray]

Thanks BJ, I was aware of org.osgi.framework.system.packages.extra but I
had overlooked org.osgi.framework.bundle.parent=app. It's no problem to
set these as I am indeed in charge of launching the framework.

Do I also need to take some steps to ensure that the consumers get wired
up to my bundle rather than to the system bundle - or maybe that doesn't
matter, so long as my bundle is registering the services?

Thanks, Chris

 First, you will need to get the system bundle to export the necessary
 packages. This could be done with the system.classpath.extra launch
 property or a framework extension fragment with an Export-Package header.
 The latter doesn't require you to be in control of launching the framework
 but you probably need to be to get your jar on the CLASSPATH. You will
 probably need to make sure that bundle's parent class loader is the
 application class loader rather than the default of the boot class loader.

 http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#FRAMEWORK_BUNDLE_PARENT_APP
 But this is also a launch property :-)

 Then your bundle can just import the necessary packages which you arranged
 above to be exported and the component description XML you supply will do
 the job. As for bnd, just -includeresource your XML and add a
 Service-Component header which references the XML.
 --

 BJ Hargrave
 Senior Technical Staff Member, IBM
 OSGi Fellow and CTO of the OSGi Alliance
 hargr...@us.ibm.com

 office: +1 386 848 1781
 mobile: +1 386 848 3788




 From:   chris.g...@kiffer.be
 To: 'OSGi Developer Mail List' osgi-dev@mail.osgi.org
 Date:   2014/10/01 15:50
 Subject:[osgi-dev] Faking DS for classpath libraries
 Sent by:osgi-dev-boun...@mail.osgi.org



 Hello gang,

 What I am trying to do is a bit underhand, but maybe no more so than some
 of the other ideas I've seen discussed here recently ...

 I have a library which is suitable for use as a provider of OSGi services
 (because it was conceived that way), but for reasons I really really do
 not intend to go into here it is going to have to be loaded on the dear
 old linear CLASSPATH (in all-caps, to bring out the retro-flavour of this
 concept). Despite this I would like the services to pop up in the service
 registry just as they would if the library was loaded as a bundle, so that
 other bundles which use DS are able to handle service references in the
 same way.

 I can see two ways to do this: 1) write some code which creates instances
 of all the service classes and registers them with the framework (in
 effect a fake SCR), or 2) create a bundle which contains no code but does
 contain some Service-Component XML to fool the SCR into doing the work.
 Of these the second approach promises to be the more maintainable once I
 get it to work, but there are a few bridges to be crossed along the way
 ...

 The main issues I have are 1) determining the right combination of
 framework properties etc. to get the packages in question to be exported
 by the fake bundle, and 2) getting bnd[tools] to generate the right
 Manifest and Service-Component files so that I can automate the build
 process.

 Any ideas?

 Regards, Chris


 ___
 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] Start a bundle from BundleTrackerCustomizer.addingBundle()

[chris . gray]

You could probably solve the callback problem by launching a separate
thread to call the start method (although it's an interesting challenge to
make sure that this, too, does not execute too soon). However

 I want to use start/stop, because I want the bundles out of memory when
 stopped. I don’t want objects to linger in memory when not used.

Stopping a bundle does not cause it to be removed from memory. References
to service objects based on the bundle will no longer be valid, but the
service objects themselves will only be eligible for garbage collection
when the last consumer has the grace to discard any references it has to
that object.

Good luck,

Chris


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

Re: [osgi-dev] [SNMP4J] SNMP4J and OSGI

[chris . gray]

Hi Daniel,

I can only say that I used snmp4j in an OSGi project a year or two ago and
I don't remember having any particular difficulties. I did make my own
bundle containing snmp4j and all its dependencies, either the servicemix
bundle didn't exist back then or I didn't find it.

Have you successfully built and run other OSGi projects using external
libraries? Trying to figure out whether this is a problem with snmp4j or a
problem with using bndtools. Does it compile? When you try to run it, what
exactly does it tell you? etc..

Regards, Chris

 Hi Tim,
 I'm trying yo implement a simple SNMP Trap based in this example:
 http://www.techdive.in/snmp/snmp4j-trap-receiver
 I'm using BNDtools, i have added the bundle to the building path, however
 most of the functions does not exist.
 example:
System.out.println(Trap Type =  + pdu.getType());
 System.out.println(Variable Bindings =  + pdu.getVariableBindings());
  int pduType = pdu.getType();  if ((pduType != PDU.TRAP) 
 (pduType != PDU.V1TRAP)  (pduType != PDU.REPORT)   (pduType !=
 PDU.RESPONSE))  {pdu.setErrorIndex(0);
 pdu.setErrorStatus(0);pdu.setType(PDU.RESPONSE);
 StatusInformation statusInformation = new StatusInformation();
 StateReference ref = cmdRespEvent.getStateReference();

 I try to use PDU, but it does not have.. and i have imported import
 org.snmp4j.*;
 I have try to search for a example of SNMP4J trap or other in OSGI but
 without success..

 From: tim.w...@paremus.com
 Date: Mon, 15 Sep 2014 10:25:22 +0100
 To: osgi-dev@mail.osgi.org
 CC: snm...@agentpp.org
 Subject: Re: [osgi-dev] [SNMP4J] SNMP4J and OSGI

 Hi Daniel,
 Some more detailed information would be helpful. What do you mean when you
 say that “the normal commands aren’t there”? How are you attempting to use
 the library? What exceptions are you seeing (if any)? Are you sure that
 your code is running?
 Once we have a better understanding of what you’re doing we might be able
 to provide some advice and/or an understanding of what the problem is.
 Best Regards,
 Tim
 On 15 Sep 2014, at 10:14, daniel Trump x5ra...@hotmail.com wrote:Thanks
 for the reply.The bundle already exists, however I have not been able to
 work with
 it.http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.snmp4j




 Date: Sun, 14 Sep 2014 06:18:29 -0400
 From: mta...@redhat.com
 To: x5ra...@hotmail.com
 CC: snm...@agentpp.org
 Subject: Re: [SNMP4J] SNMP4J and OSGI

 So you can do it in with snmp4j jar but not under OSGI?
 So AFAIK your problem is not with snmp4j but with OSGI.

 It is simply a problem of converting whatever jar you are using to a
 bundle
 - adding certain headers to the jar. This can usually be done
 automatically.
 See number 6 here or ask in their forum:
 http://www.osgi.org/Community/HomePage

 Mooli.

 - Original Message -
  Hello I'm very new in this,
  I'm developing and SNMP application with trap and request(sending OID
 and
  receiving result data).
  I have research in google for example but without success...
  I'm able to create a SNMP Trap normal Java programming.. however I
 can't do
  it in OSGI..
  I'm using the latest bundle a the normal commands are not there...
  Does any one is working with iT or can anyone send me more information
 about
  SNMP with OSGI?thanks
 
 
  ___
  SNMP4J mailing list
  snm...@agentpp.org
  https://oosnmp.net/mailman/listinfo/snmp4j
 
 ___
 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] bundle.getDataFile(string)

[chris . gray]

Marcel wrote:

 If you ask me, it definitely is. I know a lot of people kill the bundle
 cache on every startup and re-install all bundles each time, but I would
 advocate that that is bad practice in OSGi.

Hear hear.  In fact if there are anti-patterns out there then this is one
of them - and not just because of getDataFile.


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

Re: [osgi-dev] Solving Split Packages for the MongoDB Java Driver

[chris . gray]

Anger is of course but one possible reaction; there is also laughter or
indeed tears.

If this is the same org.mongodb.mongo-java-driver as I am using in a
project then 1. I think I'll go for tears and 2. there are about 300
classes in com.mongodb itself (not counting the subpackages, which each
contain much fewer classes - which is itself a significant statistic).
That's quite a lot of classes to have in one package, although I'm sure
there are many worse cases Out There.

If the driver maintainers have identified some classes as being low-level
and some as being high-level then they should be able to split them into
two packages (say, com.mongodb.binding.java and com.mongodb.common), in
such a way that com.mongodb.binding.java depends on com.mongodb.common -
and your problem is solved. If they can't do that then they have a problem
which you cannot solve for them by concocting fancy headers in a manifest.
And they should solve that problem now, while they have only 300 classes
and a handful of Java-related language bindings to deal with.

The modularity which OSGi provides is based on packages. Expecting OSGi to
deliver modularity when there is no package structure is, uh, optimistic.

Good luck,

Chris


 Hi Justin.

 First, what a horrible, horrible situation. I can only sympathise with
 you, while boiling with anger at the developers who did this!

 There are ways of dealing with this, using a combination of Require-Bundle
 along with mandatory attributes on package exports… but I would strongly
 caution against trying to go down this route. It will inevitably cause
 much more complexity for the downstream users.

 Why not just combine all parts of the API into one bundle? Why do they
 want to ship as separate bundles? Surely it can’t just be to save disk
 space!

 Regards,
 Neil



 On 1 August 2014 at 21:39:39, Justin Edelson (jus...@justinedelson.com)
 wrote:

 Hi,
 I'm trying to work out a split package scenario which seems very
 tricky, but I wanted to tap into this list's collective wisdom as
 split packages are not my thing.

 The library in question is the MongoDB Java Driver
 (https://github.com/mongodb/mongo-java-driver) and specifically the
 package com.mongodb. Leaving aside the question of how it got to this
 state, at present there are basically two different APIs in this
 package. There is a low-level API (e.g. classes like WriteConcern,
 ReadPreference, and MongoException) and then a high-level API (e.g.
 MongoClient, DB, and DBConnection). The driver maintainers want to
 ship these APIs in separate bundles. There are *other* high-level APIs
 such as for other JVM languages like Scala and Clojure. The
 implementations of those APIs should only depend up the low-level API.
 In all cases, the classes and interfaces within the low-level API are
 exposed dependencies of the high-level APIs, e.g. DBConnection has
 methods which throw MongoException (in other words, if these were two
 separate packages, the export of the high-level API would have a uses
 clause pointing to the low-level API).

 So, the question (at least for me) becomes how to export the packages
 in such a way that allows for the following cases, while of course
 retaining backwards compatibility:

 1. Deploying the Java high-level API and the low-level API.
 2. Deploying the Scala high-level API and the low-level API.
 3. Deploying both the Java and Scala high-level APIs and the low-level
 APIs.

 Any suggestions would be welcome.

 Regards,
 Justin
 ___
 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 to model hierarchically complex configuration for components

[chris . gray]

 hmm.. too bad.

You could always base64-encode it and replace +/= by .-_ GDR

 On Wed, Oct 2, 2013 at 2:28 PM, Peter Kriens peter.kri...@aqute.biz
wrote:
 I think the config admin spec recommends (SHOULD) that a property key
is
 a
 symbolic name, this leaves out square brackets ...
 Kind regards,
 Peter Kriens
 On 2 okt. 2013, at 15:35, Raymond Auge raymond.a...@liferay.com
wrote:
 On Wed, Oct 2, 2013 at 4:48 AM, Peter Kriens
 peter.kri...@aqute.bizwrote:
 Well, you can store the actual configuration somewhere else and use
the
 current mechanism to provide a pointer. Or just store it in XML/JSON
in
 a
 string/byte[] in the configuration?
 Alternatively you can map the configuration of virtually an XML to
properties using nested property names and integers for elements
ab3/bb1/b/a - a.1.b=1
 Ok, that's actually close to how I have it modelled so far.
 I'm also looking for a way to perhaps auto convert. So perhaps, as you
imply, something close to xml - xpath - property.
 /a[1]/b[1]=3
 /a[1]/b[2]=1
 a.b[1]=3
 a.b[2]=1
 We consciously prevented the complexity of XML Schemas to allow things
like Metatype (see Webconsole's editor) since we expected the
 configuration
 data to be relatively simple.
 Right, in this case the properties here are static (i.e. it's not
really
 configuration), so no UI.
 However, there are no limits to the byte[] length or String length so
this allows you to encode more complex data. Although this will not
give
 you the automatic UI.
 Good to know.
 Thank you,
 - Ray
 Kind regards,
 Peter Kriens
 On 1 okt. 2013, at 16:59, Raymond Auge raymond.a...@liferay.com wrote:
 Hello everyone,
 I'm wondering the best approach for modelling hierarchically complex
configuration data in DS
 For example, Portlets (JSR-168/286) have rather complex configuration
http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd.
 If I wanted to model a Portlet as a DS component, I have a hard time
mapping the complexity.
 Any ideas how to model this?
 I could ref an XML resource or some other weirdness, but is there perhaps
 a more elegant approach?
 --
 *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
 --
 *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
 --
 *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

Re: [osgi-dev] Fabric Service Model - Request for feedback

[chris . gray]

Amen!

 Christian,

 I consider that to be one of the worst features of Blueprint, so I
 would be very opposed to adding it to DS!

 Regards
 Neil

 On Fri, Sep 13, 2013 at 11:17 AM, Christian Schneider
 ch...@die-schneider.net wrote:
 I think you can take a look at what aries blueprint does for these
 cases.
 They create a proxy for each injected service and switch the service if
 the
 original one goes away. If no service is available then I think it
 waits for some time for a new one to come and throws an exception if a
 time
 out happens.

 Perhaps a similar behaviour can also be added for DS. Not sure if it
 matches
 the DS ideas though.

 Christian


 On 13.09.2013 12:10, Thomas Diesler wrote:

 Thank you all for your replies. We ended up with three measures

 #1 assert that the component is still valid on entry of every public
 method
 (AtomicBoolean set by activate/deactivate)
 #2 Use a ValidatingReference to hold unary references to dependent
 services
 (prevents NPE when a dependent service goes away)
 #3 Throw an InvalidComponentException runtime exception on #1 and #2

 The idea is that access to a deactivated reference never throws NPE
 Access to the public API is prevented from deactivated service instances

 cheers
 --thomas

 On Sep 11, 2013, at 11:11 AM, Richard S. Hall he...@ungoverned.org
 wrote:

 Resending my reply from yesterday since my original message didn't seem
 to
 go through...

 

 Yes, you can do some of these sorts of things with iPOJO.

 First, iPOJO has the notion of a service-level service dependency as
 well as
 an implementation-level service dependency (which is the level of DS
 dependencies). Second, iPOJO caches services references within a service
 method invocation so that a thread calling a method on a service will
 see
 the same injected services until the thread exits the invoked service
 method.

 It doesn't deal with configuration locking (at least not of which I am
 aware).

 - richard

 On 9/10/13 06:41 , Thomas Diesler wrote:

 Hi Folks,

 in Fabric we have a service model whereby services have
 interdependencies,
 are configurable and dynamic by nature - all of which is managed in OSGi
 with the help of Declarative Services. To illustrate I use a simple
 example

 ServiceT {

 @Reference
 ServiceA serviceA;

 @Reference
 ServiceB serviceB;

 public doStuff() {
// that uses serviceA  serviceB
 }
 }


 The injection is handled by the DS framework - there are various
 callbacks
 involved.

 Lets assume the system is fully configured and a client makes a call on
 ServiceT

 ServiceT serviceT = getServiceT();
 serviceT.doStuff();


 Due to the dynamic nature of OSGi services and their respective
 configuration ServiceT must deal with the following possible/likely
 situations

 #1 An instance of a referenced service is not available at the point of
 access (i.e. serviceA is null)
 #2 In the context of a single call the service instance may change (i.e.
 call may span multiple instances of serviceA)
 #3 In the context of a single call the configuration of a service
 instance
 may change (i.e. serviceA is not immutable, sequential operations on A
 may
 access different configurations)

 In OSGi there is no notion of global lock for service/configurations nor
 a
 notion of lock of a given set of services/configurations - I cannot do

 lock(T, A, B);
 try {
ServiceT serviceT = getServiceT();
serviceT.doStuff();
 } finally {
unlock(T, A, B);
 }

 This code is also flawed because it assumes that the caller of doStuff()
 is
 aware of the transitive set of services involved in the call and that
 this
 set will not change.

 As a conclusion we can say that the behaviour of doStuff() is only
 defined
 when we assume stability in service availability and their respective
 configuration, which happens to be true most of the time - nevertheless,
 there are no guarantees for defined behaviour.

 How about this …

 The functionality of A and B and its respective configuration is
 decoupled
 from OSGi and its dynamicity


 A {
   final Map config;
  public doStuffInA() {
  }
 }

 B {
   final Map config;
  public doStuffInB() {
  }
 }


 ServiceA and ServiceB are providers of immutable instances of A and B
 respectively. There is a notion of CallContext that provides an
 idempotent
 set of instances involved in the call.

 CallContext {
  public T get(ClassT type);
 }

 This guarantees that throughout the duration of a call we always access
 the
 same instance, which itself is immutable. CallContext also takes care of
 instance availability and may have appropriate timeouts if a given
 instance
 type cannot be provided. It would still be the responsibility of A/B to
 decide wether an operation is permissible on stale configuration.

 Changes to the system would be non-trival and before I do any
 prototyping
 I'd like to hear what you think.

 cheers
 --thomas



 ___
 OSGi 

Re: [osgi-dev] Fabric Service Model - Request for feedback

[chris . gray]

Wise words (as usual) from Neil.  I'd like to single out these sentences
for printing out and hanging on the wall:

as the caller of a service it is simply not your concern to try to
enforce something about the implementation of the service you are calling.
You should however be prepared for the service invocation to go wrong in
unpredictable ways.

In OSGi invoking a service looks just like any other method call (which is
great), but at the same time it represents crossing a boundary. Maybe you
think you know now how the service will behave, but next week someone may
have the bright idea of moving the implementation to a USB dongle or The
Cloud, or they switch to using a new open-source library - and your
assumptions are rendered invalid.  So every time you invoke another
service you should be asking yourself questions like do I need a try -
catch -finally here?  Am I holding any locks that could cause problems?.

It's interesting to know that iPOJO won't do this, but then iPOJO too is
just one implementation. Just as you shouldn't rely on the known
behaviour of your services, you certainly shouldn't rely on the known
behaviour of a particular framework.

Chris



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

Re: [osgi-dev] Fabric Service Model - Request for feedback

[chris . gray]

 I'm wondering how other folks deal with the issues of service
 dynamicity and configuration change in the duration of a single call to a
 complex graph of interconnected services.

Services injected by DS are, as you say, non-final fields so they can
change their value. This situation is not unique to DS - in principle
*any* non-final field of your class could be modified at any time by any
other thread which can access it, so you have to either handle this or
prove that it can't happen.  For example you make a copy in a (final)
local variable: then you are safe from NPEs but you may be using an
instance which is somehow obsolete - so you have to be aware of that.
Etc..

Turning to DS, the solution can depend upon whether the absence of a
dependency is a normal or an abnormal state of affairs. If it is
normal then you declare the dependency as optional unary and indeed you
have be aware that it can go away or be replaced at the most inconvenient
moment.  As you say there are a lot of callbacks: in this case you
almost certainly want to write your own set/unset methods so that you can
deal with synchronisation issues etc..  If OTOH you really don't want to
deal with the dynamics then you declare the dependency as mandatory
unary and then if it goes away, so do you.  If it comes back a new
instance of your component is created so there is no problem of stale
references etc..

It is important that components properly handle being stopped: any
subsequent service calls should be handled in a way which helps the caller
realise that the service object is no longer usable.

I don't think this is a problem which can be solved by adding one more
layer of abstraction; rather it is a case of applying best practices and
using DS idiomatically.  Does this make sense?

Regards

Chris Gray


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

Re: [osgi-dev] best pattern for instance factories

[chris . gray]

Ray,

 What we have is a typical event handler scenario:

 processEvent(Event event) {
 Handler[] handlers = getHandlers(key);

 for (Handler handler : handlers) {
 handler.process(event);
 }
 }

 I'd like to be able to use osgi to affect the handlers result set during
runtime.

This is a classic use case for the whiteboard pattern; the handler
registers itself as a provider of the Handler service and the event source
uses the framework to track changes in the Handler population.  This is
very easy using Declarative Services, but it can also be done with a good
ol' ServiceTracker.  That does mean that your handlers have to register
with the framework, but this can be as easy as serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable()) on the way in and serviceRegistration.unregister() on the
way out.

HTH

Chris







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

Re: [osgi-dev] best pattern for instance factories

[chris . gray]

Raymond Auge wrote:

  What we have is a typical event handler scenario:
 
  processEvent(Event event) {
  Handler[] handlers = getHandlers(key);
 
  for (Handler handler : handlers) {
  handler.process(event);
  }
  }
 
  I'd like to be able to use osgi to affect the handlers result set
 during
 runtime.

I wrote:

 This is a classic use case for the whiteboard pattern; the handler
registers itself as a provider of the Handler service and the event source
 uses the framework to track changes in the Handler population.  This is
very easy using Declarative Services, but it can also be done with a good
 ol' ServiceTracker.  That does mean that your handlers have to register
with the framework, but this can be as easy as serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable()) on the way in and serviceRegistration.unregister() on the
 way out.
 [Ray]
 This is great. I'm glad that I was at least on the right track.

 However, I do have some concerns with this:

 - currently a handler is instantiated then released (to GC aether)

 This insures, among other things, that no state is mistakenly preserved
[...]

This is indeed stretching the envelope of the whiteboard pattern, which
is more often used when each handler will be invoked many times during its
lifetime, as opposed to just once.

 - thread safety (we're not exactly sure that some plugin developer won't
break the system with non-thread safe code) [...]

In my example you would need to control the lifecycle of the handlers in
order to perform the registration and deregistration, so simply abandoning
them to the tender mercies of GC is probably not an option.

 - low to no contention for simply getting the list of handlers? Namely,
was
 the bellow example indended to support a high degree of
 concurrency/contention?

 CollectionServiceReferenceHandler references =
 _bundleContext.getServiceReferences(Handler.class, filter.toString());

 for (ServiceReferenceHandler reference : references) {
Handler handler = _bundleContext.getService(reference);

handler.init(context);
handler.doSomething();

_bundleContext.ungetService(reference);
 }


 I'm kind of concerned with the fact that there is an implied
registration
 here which in this particular scenario sounds either too costly or
simply
 not nessecary.

This code avoids the problem of creating a list of direct references to
the handlers by creating a list of ServiceReferences instead.  SRs are
reference-counted, so the get/ungetService calls in this example are
basically just incrementing/decrementing a counter.

If the turnover of the handlers is as high as you say then some degree of
contention is inevitable.  A COW list should minimise the impact on the
list traversal.

 Basicly I guess I'm asking how much abuse this pattern can take, say it
if
 were to trigger potentially thousands of times per request (not all for
the
 same event handler)?

I'm still a bit unsure about how your system works.  How are all of these
single-use event handlers conjured into existence?

BTW it should be said that Peter Kriens is patron saint of whiteboards, so
you should pay extra attention to what he says on the subject.

- Chris

 Perhaps I'm over thinking it problem (or just entirely incorrectly,
which
 is quite possible)?

 - Ray


 HTH
 Chris
 ___
 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
http://twitter.com/#!/rotty3000 | Senior Software Architect |
*Liferay,
 Inc.* http://www.liferay.com  https://twitter.com/#!/liferay

 ---

 24-25 October 2012 |* Liferay **Spain Symposium* |
 liferay.com/spain2012http://www.liferay.com/spain2012

 16 November 2012 |* Liferay **Italy Symposium* |
 liferay.com/italy2012http://www.liferay.com/italy2012
 ___
 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] What is OSGi bundle profiling going on?

[chris . gray]

Even using a custom SM or java.lang.instrumentation it's pretty difficult
to answer question such as who is allocating so much memory?.  Christer
Larsson (MakeWave) and I demonstrated a resource management API at the
OSGi Community Event in Darmstadt last year, but this also relied on
modifying the JVM - I think it is pretty well impossible to develop a
performant solution otherwise.

You also have to ask yourself just what you mean when you say a service
bundle eats too much memory.  As has already been pointed out in this
thread, services can call other services and objects can be passed from
one service to another, so it is hard to say that a thread or an object
belongs to a particular bundle.  Take the case of a component in bundle
A which receives messages on some interface and passes them on to all
services which have registered an interest.  One such service component,
in bundle B, accepts and processes these messages but owing to a
programming error it retains a reference to all the messages so they
cannot be garbage-collected.  So we have a memory leak, and if we ask the
question which bundle allocated all this memory the answer is bundle
A.  Yet bundle A is innocent of any crime, and moreover stopping bundle A
will not solve the problem (since B is holding references to the objects).

If the JVM would support Isolates (JSR121), it might be possible to device
an efficient inter-isolate communications protocol to invoke Remote
Services on another Isolate ...

Chris Gray

 My team is developing a service platform on OSGi platform.
 One big concern of my boss is bundle resource monitoring/profiling on
 service bundles.
 That is, if a service bundle eats too much memory or CPU, can OSGi
 runtime
 detect this event and take some action?



 I think the only way to do it in stock jvm  OSGi is to take advantage of
 java security API which gives you the possibility collect bundle metrics
 as
 they call through the security API. This gives you access to all
 classloading, thread management, resource access, etc.

 You will have to write a custom SecurityManager which tracks bundle
 metrics, and also supports OSGi enhanced java security (perhaps extending
 an existing implementation like
 org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager).

 It will not be trivial, but it is as close as you can get in stock java
 APIs (that or instrumenting the JVM, java.lang.instrument).

 Furthermore, expect a considerable performance degradation, even without
 customization, when using java security because it's quite intense.

 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 http://twitter.com/#!/rotty3000 | Senior Software Architect | *Liferay,
 Inc.* http://www.liferay.com  https://twitter.com/#!/liferay

 ---

 8-9 October 2012 |* Liferay **North America Symposium* |
 liferay.com/northamerica2012 http://www.liferay.com/northamerica2012

 16-17 October 2012 |* Liferay **Europe Symposium* |
 liferay.com/europe2012http://www.liferay.com/europe2012

 24-25 October 2012 |* Liferay **Spain Symposium* |
 liferay.com/spain2012http://www.liferay.com/spain2012
 ___
 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 dynamically generated classes

[chris . gray]

Hi Davd,

 The bundle that registers the service could create this custom class
loader with its bundle class loader as its parent, and with appropriate
imports for that bundle the custom class loader would be able to resolve
external references in your bag of class bytes. This would include the
import of the package that holds your service interface. The life cycle
of
 the class loader and the service registration would be tied to the life
cycle of this implementation bundle.

This looks like being the winning answer.  My proposed hack with
installing a fragment bundle has the undesired side-effect of triggering a
refresh of the parent bundle (which is especially good fun if the parent
is the one doing the install).  As you point out the parent class loader
does need to be able to resolve the service interface(s); maybe we can
restrict these interfaces to some closed list of packages, otherwise this
may be a legitimate usage of DynamicImport-Package: com.acme.*.

 In this way your creation of a custom class loader is simply an
implementation detail of your bundle. If you're going to be
materializing
 a bag of bytes into a class, you're going to need a class loader
*somewhere*, so you're not *adding* any additional smell. ;-)

Yes, I'm now convinced of that.  Users of the proxy object should not need
to access the object's implementation class, so it shouldn't be a problem
that it wasn't loaded by any bundle class loader.  If anyone claims that
they need such access (e.g. to re-instantiate a previously serialized
object), we take them outside and shoot them. ;-)

Thanks,

Chris





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

Re: [osgi-dev] Loading dynamically generated classes

[chris . gray]

Justin,

 Why does this design require that these classes be exported? As long as the
 bundle registering them as services has access to the dynamic classes,
no
 other bundle needs to.

That is correct, and the recipient of a proxy service objects have no
legitimate interest in its implementation; it should be happy that it
implements the interface they want and has whatever properties were
specified in the filter (if any).

But before we can create any proxy instance, the class needs to exist
which means that some ClassLoader somewhere has to call defineClass().  Or
am I missing something?

 Alternatively, you could register a special Classloader as a service
which
 could be used to load them.

Hm, that doesn't smell too good (creating custom ClassLoaders in an OSGi
system), but it might work.  Need to examine that more closely.

Thx

Chris

 Justin

 On Sun, Mar 18, 2012 at 5:07 PM, chris.g...@k-embedded-java.com wrote:

 Hello all,
 I am working on a design which involves generating new classes at runtime,
 so that afterwards I can create one or more instances which will be
registered as services.  Generating the class files (or byte arrays)
goes
 fine, introducing them into the environment is less obvious; I need to
somehow persuade some bundle classloader to read in my hand-crafted
bytes
 and pass them to defineClass().  The best I have been able to come up with
 so far is to wrap up the generated class in a bundle fragment and ask the
 framework to install this - which seems a little baroque, so I am just
wondering if there is some API I've missed which would do this more
naturally?
 If I wanted to modify the original class I could of course use weaving
hooks, but I would really prefer to create a new class.
 Thanks,
 Chris
 ___
 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] CPU Measurement on a Bundle

[chris . gray]

[vide infra]

 Sorry by the simplistic idea, but catching the execution of methods
 with
 AOP cannot help to measure their execution time?

 If method a of bundle A calls method b of bundle B, which in turn calls
 InetAddress.getByName(), then the execution time measured for a will
 include the execution time proper to b and the time taken to do the DNS
 lookup.  Separating these out could be tricky.

 Generally speaking a bundle corresponds to a set of packages (either
 exported or private), so your best approach is probably to ask your
 favourite profiler to report results on a package basis.  This breaks
 down
 of course if a given package name is (privately) present in multiple
 bundles, or when the same jar file is embedded into multiple bundles.

 True.

 The only special case is if all your bundles communicate with each other
 via services. In that case, if you intercept all service calls, you can
 use those interceptors to measure the time taken inside each bundle.
 Adding those interceptors can be done at runtime.

Hi Marcel,

Heaven forbid that my bundles should communicate with each other by any
other means :-).  Yes, if you clock all calls to and returns from all
methods which implement service interfaces then you can calculate the time
spent in each service (including calls to code on the system class path,
embedded library jars, etc) - on a single-threaded system.  You also need
to instrument various methods such as wait(), sleep(), read() from sockets
or ports etc. in order to eliminate them. In the multi-threaded case you
have to collect the timelines on a per-thread basis, and when two or more
threads are active at the same time you need to allocate the CPU time
between them.

On the whole I think these techniques can be used to gather useful
information in a lab context, where you can run one bundle and mock all
its dependencies; but to study the complete system you are going to need
to use a profiler and/or instrument the VM.

Regards

Chris


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

Re: [osgi-dev] CPU Measurement on a Bundle

[chris . gray]

 Sorry by the simplistic idea, but catching the execution of methods with
 AOP cannot help to measure their execution time?

If method a of bundle A calls method b of bundle B, which in turn calls
InetAddress.getByName(), then the execution time measured for a will
include the execution time proper to b and the time taken to do the DNS
lookup.  Separating these out could be tricky.

Generally speaking a bundle corresponds to a set of packages (either
exported or private), so your best approach is probably to ask your
favourite profiler to report results on a package basis.  This breaks down
of course if a given package name is (privately) present in multiple
bundles, or when the same jar file is embedded into multiple bundles.

HTH

Chris


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

Re: [osgi-dev] Monitorable PID length: bump

[chris . gray]

Does nobody have any thoughts on this?

 Hi there,

 In 119.2 compendium, Version 4.2 I read that the length of the
 monitorable-pid must fit in 32 bytes when UTF-8 encoded.  (Given that
 all the characters allowed in the symbolic-name syntax encode as one byte,
 this would appear to mean that the length is limited to 32 characters).

 However in 119.7.2 it is stated that The length of the PID must not
 exceed 20 characters.  Am I missing something, or is there an
 inconsistency here?

 Best regards

 Chris Gray


 ___
 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] Question about Memory Usage per Bundle

[chris . gray]

BJ is right, the quantity you are trying to measure is not well-defined. 
We were able to modify the Mika VM to associate each allocation with the
most local non-system class loader on the stack at the time of allocation,
which gives an answer to the question how much memory has this bundle
allocated which has not yet been reclaimed by GC, for one possible
definition of memory is allocated by a bundle.  But if a bundle were
generating objects which should be short-lived, but some other bundle is
obsessively cacheing them then our system would blame the first bundle
when in fact it is the second which is the real culprit.

Carrying out measurements when the bundle is loaded/started is probably
not very realistic either, I wouldn't expect many Java modules to allocate
all the memory they need at startup time.  For that you should be looking
at something like Fortran (prior to Fortran 90).

-- 
Chris Gray

 How do you define how much memory a bundle uses? It is generally not
 possible to do this unless you have a very specific definition of memory
 use. Bundles can extend classes imported from other bundles. Bundles can
 call other bundles which allocate memory for the caller. To which bundle
 does this memory belong? A bundle is a unit of encapsulation and
 classloader isolation but it is not a unit of memory isolation. From a
 memory perspective, bundles are very intertwined and it is extremely hard
 to try and disentangle them.

 --

 BJ Hargrave
 Senior Technical Staff Member, IBM
 OSGi Fellow and CTO of the OSGi Alliance
 hargr...@us.ibm.com

 office: +1 386 848 1781
 mobile: +1 386 848 3788





 From:   masti whoknows masti...@yahoo.com
 To: osgi-dev@mail.osgi.org osgi-dev@mail.osgi.org,
 Date:   2011/11/17 12:51
 Subject:[osgi-dev] Question about Memory Usage per Bundle
 Sent by:osgi-dev-boun...@mail.osgi.org



 Hi,

  I am using OSGi to create a plug  play framework. My goal is to
 measure how much memory each bundle is using. Is there a way to do this
 dynamically when the bundle is loaded/started? Please note I don't want to
 use any external tools. I want to do it while the system is running.

Any help is highly appreciated.

 Thanks
 Masti___
 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] Monitorable PID length

[chris . gray]

Hi there,

In 119.2 compendium, Version 4.2 I read that the length of the
monitorable-pid must fit in 32 bytes when UTF-8 encoded.  (Given that
all the characters allowed in the symbolic-name syntax encode as one byte,
this would appear to mean that the length is limited to 32 characters).

However in 119.7.2 it is stated that The length of the PID must not
exceed 20 characters.  Am I missing something, or is there an
inconsistency here?

Best regards

Chris Gray


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

Re: [osgi-dev] Restart OSGi framework programatically

[chris . gray]

 Hi,

 I need to restart an OSGi application programmatically in Java. How can
 I do this?
 AFAICT the official way is to call Bundle.update() on the system
 bundle.


 Thanks for all proposals. I only need to restart the OSGi Framework, not
 the entire JVM. You mentioned a system bundle, do you mean
 org.eclipse.osgi ? If yes, what's the best way to get the appropriate
 reference, iterate over all bundles?

The system bundle has id 0, so (for example) you can call getBundle(0) on
the BundleContext.

Chris

 Eugen


 Am 09.06.2011 um 10:26 schrieb Felix Meschberger:

 Hi,

 Am Mittwoch, den 08.06.2011, 18:00 +0200 schrieb Guillaume Nodet:
 Right, we have the same kind of launcher in Karaf that even enable us
 to update the osgi framework itself.

 Ok, lets continue with ads: The Sling launcher can also do this
 supporting the Bundle.update(InputStream) method on the system
 bundle ;-)

 Regards
 Felix


 On Wed, Jun 8, 2011 at 17:43, Felix Meschberger fmesc...@gmail.com
 wrote:
 Hi,

 Am Mittwoch, den 08.06.2011, 11:34 -0400 schrieb Richard S. Hall:
 On 6/8/11 11:20, Felix Meschberger wrote:
 Hi,

 Am Mittwoch, den 08.06.2011, 17:12 +0200 schrieb Eugen Reiswich:
 Hi folks,

 I need to restart an OSGi application programmatically in Java. How
 can I do this?
 AFAICT the official way is to call Bundle.update() on the system
 bundle.

 True.

 BUT: This requires support from the framework launcher.

 Not entirely true.

 Yes, I just realized that I remained in the 4.1 times when Peter
 posted
 his reply.


 If you want to simply restart the framework, then calling update() on
 the system bundle would be sufficient. However, if you want to
 restart
 the JVM (e.g., to change what's on the boot class path) then you need
 help from the launcher.

 In fact, what we do in the Sling launcher is that we create root
 class
 loader to load the framework with and on framework restart we throw
 away
 the old one and create a new one.

 I think this further helps PermGen GC --- but I would be happy to
 learn
 that I am wrong ;-)

 Regards
 Felix


 ___
 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] Monitoring the SCR

[chris . gray]

Hi Felix,

 I once started on a new API which I intended to propose to the OSGi as
 the standard DS admin API [1]... But somehow this always was pushed back
 by some other work; I should pick this up again, probably ;-)

Probably. :-) I can see it being a real boon for both testing and
diagnostic purposes.  Imagine for example that a device is failing to
become fully operational because of a corrupt file somewhere causing an
activator to fail - how to diagnose if you can't visualise the state of
the SCR?

 [1] http://svn.apache.org/viewvc/felix/sandbox/fmeschbe/dsadmin/

Yes, that (or something very like it) is just what is needed - go for it!

Chris
-- 

 On Tue, Jun 7, 2011 at 10:44 PM,  chris.g...@k-embedded-java.com
 wrote:
  Working with DS, I often feel the need to dig in and find out how the
  various components are getting along.  Some frameworks have shell
 commands
  which allow one to examine the status of components (e.g. Felix, mBS)
  while others haven't or at least not yet (Knopflerfish).  What I would
  most like though would be to design a probe which can inspect its
  environment and produce reports.  Is there a (framework-independent)
 way
  to do this?  Bundles and services are quite easy to enumerate and to
 track
  (race conditions aside), but components?  Am I missing something?
 
  Best regards
 
  Chris
 
 
  ___
  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] ZK Web Application Framework with OSGi

[chris . gray]

Hi BJ,

 I don't know anything about ZK, but it would seem to be loading classes by
 name which is problematic in a modular system. See
 http://www.osgi.org/blog/2011/05/what-you-should-know-about-class.html

How true.

Not so long ago I discovered another such pseudo-random hack lurking in
(at least one JavaSE implementation of) RMI: at a certain point it gambles
on the closest non-bootstrap class loader on the call stack, halleluja.
https://labs.oracle.com/techrep/2006/smli_tr-2006-149.pdf

It's everywhere.

Chris


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

[osgi-dev] Monitoring the SCR

[chris . gray]

Working with DS, I often feel the need to dig in and find out how the
various components are getting along.  Some frameworks have shell commands
which allow one to examine the status of components (e.g. Felix, mBS)
while others haven't or at least not yet (Knopflerfish).  What I would
most like though would be to design a probe which can inspect its
environment and produce reports.  Is there a (framework-independent) way
to do this?  Bundles and services are quite easy to enumerate and to track
(race conditions aside), but components?  Am I missing something?

Best regards

Chris


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

RE: [osgi-dev] exception aggregation for error reporting?

[chris . gray]

Creating a ThreadGroup is one thing, getting rid of it is quite another -
you have to call ThreadGroup.destroy() from outside the ThreadGroup after
all the member threads have terminated. Otherwise you have a classloader
leak:
https://developer.opencloud.com/devportal/display/ENGBLOG/2009/03/11/Avoid+ThreadGroup+in+Resource+Adaptors

I would recommend against using ThreadGroup in an OSGi environment.  As
the blogpost points out, starting with SE5 you have
Thread.setUncaughtExceptionHandler() available.



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

Re: Service cleanup best practices (Was: [osgi-dev] What happens to class instances when bundle containing the class unloads)

[chris . gray]

Peter
 A very cheap way to do what I want is to let the VM just throw some
 runtime exception on any object that is from a stale class loader.

You make it all sound so easy. :-)
If you mean throw some runtime exception on any *access to* object that
is from a stale class loader then you are asking for some kind of read
barrier which is going to penalise all accesses, or else you have to screw
with the *references to* those objects in such a way as to cause an
runtime exception.  For example you could simply set them to null, or to
some out-of-range value which would be caught by a hardware trap.  (The
latter is expensive when it happens, but actual violations should be
rather rare.)

 I think the java semantics is a red-herring, OSGi is a framework running
 on Java, we can add our own semantics when you run as a bundle. The choice
 is between two evils: or you have people using stale objects, which they
 were notified about or the bad guys get an exception ... And any code can
 get an exception at any time, that is part of the Java semantics.

Any code can get an exception at any time is true at the source code
level, but at the execution level it doesn't hold any more (which is a
Good Thing).  For example the execution engine may legitimately conclude
that if a reference was valid at instruction p then it will remain valid
at instruction p+1, etc. until q where another code path joins this one,
so
it doesn't need to perform any more checks.  Then you come along and
invalidate that reference, the execution engine uses it to calculate a
path to something else and hey-ho, la-la-land.  I'm thinking particularly
of local variables here, not just fields.

 It is all about putting the burden on the culprit and in this case the
 culprit is the user of the stale object.

The culprit gets the exception but the overhead is also borne by others.
And these now-invalid references may already have been passed to other
components which might be completely unaware that they were loaded by a
stale bundle class loader, yet they get punished too.

Best regards

Chris

 On 20 feb 2011, at 09:34, chris.g...@k-embedded-java.com wrote:


 NJB Given that there is no way to take an object away from someone who
 has a
 reference to the object, the service contract should state the behavior
 of
 the object outside of its defined life time.

 I remember a conversation with Peter a few years ago where Peter was
 wondering whether it would be possible to tell a Java runtime to
 forcibly
 clean up a class loader, which would imply nulling out all references to
 instances of classes which it had loaded.  I think that at the time I
 said
 it was simply impossible; nowadays I would say it is technically
 possible
 but violates Java semantics in a way which is probably unacceptable (and
 the runtime overhead could be significant).

 A service could send a very strong signal to its users by only returning
 WeakReference's to the objects it creates instead of direct references
 to
 the object itself.  Of course the service user can sabotage this by
 cacheing a strong reference to the object.

 ___
 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: Service cleanup best practices (Was: [osgi-dev] What happens to class instances when bundle containing the class unloads)

[chris . gray]

NJB Given that there is no way to take an object away from someone who has a
 reference to the object, the service contract should state the behavior of
 the object outside of its defined life time.

I remember a conversation with Peter a few years ago where Peter was
wondering whether it would be possible to tell a Java runtime to forcibly
clean up a class loader, which would imply nulling out all references to
instances of classes which it had loaded.  I think that at the time I said
it was simply impossible; nowadays I would say it is technically possible
but violates Java semantics in a way which is probably unacceptable (and
the runtime overhead could be significant).

A service could send a very strong signal to its users by only returning
WeakReference's to the objects it creates instead of direct references to
the object itself.  Of course the service user can sabotage this by
cacheing a strong reference to the object.

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

Re: [osgi-dev] OSGi dynamics

[chris . gray]

[Peter Kriens] Of course you're right that there is an issue with when
you consider
 the application to have started, whether successfully or
 unsuccessfully. DS does not consider a component with unsatisfied
references to be any kind of error, because the services that would
make it a satisfied component may be coming along very soon... so, when
should an error be thrown?

[Eugen Reiswich] That's exactly the question I was not able to answer!

Basically only the system designer can know whether the non-availability
of a particular component is a normal or an error case.  A component
might be used in devices with and without a touch screen, or there could
be a requirement to continue to provide limited service if the network
connection goes down ... the case if any component fails, the whole
system fails is the exception rather than the rule.

[Peter Kriens] That said, I did have a similar problem last year with
framework
 startup. I decided I wanted a READY service that would be registered by
the framework when the framework was ready with the starting of all the
bundles. This got efficiently shut down in the CPEG though but during
the discussion we came to an interesting idea for DS.

[Eugene]
 Ok, I can life with this solution even though it feels like a workaround.
 As I understand I will need to deploy the ReadyService twice: server-side
 and client-side in a distributed environment with server-side OSGi, right?

If the server can only handle client requests when all its components are
active then I suppose you need some kind of mechanism to prevent the
client from making requests before the server is ready; or else you
respond to the requests with service unavailable, please try later. 
This would depend very much on the nature of the client application and
the protocols being used.

[Peter] The idea was to add a new filter to a DS component that
controlled the enabled status of the component. As long as that filter was
not satisfied, the component was disabled. Obviously, you could set this
filter in the XML (or bnd annotations [plug!]) or in Configuration Admin.
I think this would address many of your needs.

After gaining some practical experience with DS I find that (1) it's
pretty neat, (2) sometimes I wish for just a little more control or
interactivity. Your enabling filter sounds like a good idea, some
standardised introspection mechanism could also help.  Then again there
are probably existing features that I haven't yet understood how to use
effectively ...

Best regards

Chris




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