Re: [osgi-dev] Time to move

[Peter Kriens via osgi-dev]

Wow, the end of an era ...

Thanks for all the work BJ. 

Kind regards,

Peter Kriens

> On 9 Dec 2020, at 21:41, BJ Hargrave via osgi-dev  
> wrote:
> 
> As part of the mission transfer to the Eclipse Foundation, the osgi.org and 
> mail.osgi.org servers will be soon shutting down.
>  
> So I have asked Eclipse [1] to provision a new osgi-users mail list to 
> replace this osgi-dev mail list. Once provisioned, the new list [2] should be 
> osgi-us...@eclipse.org.
>  
> Please look for this new list shortly and subscribe.
>  
> This is likely the last message from this list as the server is being 
> decommissioned.
>  
> See you on the other side...
>  
> [1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=569608 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=569608>
> [2]: https://accounts.eclipse.org/mailing-list/osgi-users 
> <https://accounts.eclipse.org/mailing-list/osgi-users>
> --
> 
> 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
> 
> ___
> 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] Can I rely on service properties to glue together many combinations of services?

[Peter Kriens via osgi-dev]

I you want to do this without code it is easy to setup using a similar model 
then that I gave you, maybe even the same. However, it will be horror to use 
for coders since it is inevitable that these traits will interact, and often in 
unintended ways. They will likely also have to work together and then the type 
safety helps a lot.

However, there was a saying in the 80's that said that if someone wanted a 
language where you could just say what you wanted, then give him a lollipop. 
The problem you're trying to solve is ancient and would be worth a lot of money 
if you could pull it off. So far these systems generally tend to turn into 
bloated monsters that are hard to use for users as well as developers.

Unless you user trait integration is just selecting them on an object, you 
could take a look at Javascript. It is quite a nice integration language and 
there are zillion of tutorials. The trait model works very well for Javascript 
since you can easily add fields and functions and everything is visible to 
everybody. However, that means giving up type safety. 

Good luck, 

Peter Kriens

> On 18 Sep 2020, at 07:49, Zyle Moore  wrote:
> 
> Thanks so much for looking at this. I'll be playing around with the code you 
> provided and seeing where that gets me. An additional complexity I didn't 
> mention in the initial question was that I also want users, not developers, 
> of this game to have nearly as much flexibility with the "traits" as the 
> developers themselves. Meaning that developers would provide the traits, and 
> the users could configure them into whatever combination they want, without 
> the need to write code to wire it together, and figured I could leverage the 
> developer way more easily for the users, but it seems I still have a lot of 
> thinking to do. Thanks again.
> 
> On Thu, Sep 17, 2020 at 3:31 AM Peter Kriens  <mailto:peter.kri...@aqute.biz>> wrote:
> You're moving in a direction that can be a siren song. You basically want to 
> add what I'd call 'traits' to actor dynamically. Now, this is not so 
> difficult to do. In Smalltalk and Javascript this is quite easy to do because 
> you can dynamically extend the fields of an instance. In Java, everything 
> must statically compile. The advantage is of course that then everything is 
> statically compiled and the compiler can help you tremendously to write 
> error-free code.
> 
> If you implement the trait model in a type safe way, it tends to become a lot 
> harder to write code for it. That is why it is very easy to implement such a 
> model in languages like Smalltalk, Javascript, and I recall Python. You just 
> add extra fields and methods. Since nothing is type checked in the compiler, 
> you do not have to provide any metadata that makes the compiler happy. 
> However, if you want to do this
> type safe in Java then the APIs become a lot more ugly. And if you're willing 
> to give up type safety, the API is a lot harder to use than plain Java 
> becausYou e you need to use some kind of property model.
> 
> That said, there is a trick I am very fond of. Actually it is two tricks. 
> First, instead of focusing how to implement something it often helps to view 
> it from the perspective how to use something. As we're all implementers, we 
> tend to want to provide it all to our customers, as easy as possible. 
> However, we often forget that the client just has more knowledge we as 
> providers have. A given client of these
> traits knows exactly which traits are needed. For type safety, that client 
> muse depend on the actual trait types. Something that is impossible for the 
> provider, the whole idea of the trait provider is to be oblivious of the 
> actual traits. Unlike the client ...
> 
> The second trick is the magic of interface proxies. It is already 6 years ago 
> I came up with the idea to use the annotation interfaces as a front for the 
> OSGi configuration data. I still love it every day I program a component. 
> I've used this trick in lots of places. It allows you to write code almost as 
> simple as in Python, Javascript, or Smalltalk but you get much more type 
> safety.
> 
> So if we look from the perspective of the provider we do actually have normal 
> Java type dependencies. A client that uses Entity and Position knows exactly 
> that it uses these types and it will have import packages to prove it. Since 
> it has type dependencies, OSGi tends to be invisible. If your code runs with 
> these dependencies all things work ok. This is very important in a dynamic 
> system.
> 
> So lets say we have a Trait Manager service. How would a client that has 
> Entity & Position wants to work?
> 
> interface Position { int x(); int y(); }
> interface Entity { String id(); }

Re: [osgi-dev] Can I rely on service properties to glue together many combinations of services?

[Peter Kriens via osgi-dev]

ic boolean handles(Class c) { return c == 
Entity.class; } 
}

This is of course a sketch. A major problem with these kind of solutions is the 
dynamicity of OSGi. The solution here is I think quite ok if you make sure the 
trait's type is exported by the same bundle that provides the Trait service for 
that type and there are no other exporters. The type dependency will then 
ensure that you can never create a view  where the corresponding Trait is 
missing. This can of course also be achieved with explicit capabilities.

However, the problem gets more problematic when you start to share your objects 
with parties that want to augment the trait host further. I.e. I get a Position 
object in my code but now I want to add a Foo trait if it is not already there:

Foo f = tm.ensure( Foo.class, cv );

This imho inevitable extension will create multiple proxies on the same 
underlying trait host. With one proxy, the trait host will get garbage 
collected if the client goes away. However, when you have multiple proxies the 
trait host will not be garbage collected until _all_ proxies become 
unreachable. This means that in some cases the trait host is holding on to 
classes that should be garbage collected. This is solvable but to much for this 
mail.

Anyway, some caution is in place. When I was first hired by Ericsson in 1992 I 
developed a fantastic framework to handle data in a network management system 
with some of the qualities you're looking. I really think it worked rather well 
but developers hated it because it was always something extra over normal code. 
I do think the proxy trick is quite powerful and works very nice but almost 
nothing beats plain old java code. So be aware. The rules that this model will 
oblige your developers to follow will not always be appreciated. And of course 
as the GC showed, there are lots of corner cases to be aware of.

I've enclosed the files I used to verify that I did not make compiler errors 
... which I probably did anyway. You can try them out. This is of course an 
extremely minimal implementation.

Hope this helps. Kind regards,

    Peter Kriens





TraitManager.java
Description: Binary data


TraitManagerTest.java
Description: Binary data


> On 17 Sep 2020, at 03:37, Zyle Moore via osgi-dev  
> wrote:
> 
> In my game, all content, mechanics, and systems will be modular, and
> based on OSGi bundles. One of these bundles is for an Entity. Entities
> are uniquely identifiable things in the game world. Examples would
> include trees, rocks, and characters. The game though does not
> necessarily have to have any of those. If the game doesn't need trees,
> it shouldn't have trees. If it doesn't need rocks, it shouldn't have
> rocks. The Entity is the unique identity other things are associated
> with. One of the things an Entity can be associated with is a Position.
> A Position is an (x, y) coordinate in the world. Positions are in a
> separate bundle than Entities. Positions are not inherently tied to
> Entities, and Entities do not inherently have Positions, even though
> they will likely be used together, depending on the game.
> 
> At this point, there are two bundles; Entity, and Position. To get more
> functionality out of these two, a third bundle is needed;
> EntityPosition, which provides a glue class (EntityPosition) which
> associates a Position with an Entity.
> 
> ```
> ++++ +--+
> |||| |  |
> | Entity || EntityPosition | | Position |
> |||| |  |
> ++++ +--+
> |||| |  |
> | id: String +--->+ entity: Entity | | x: Int   |
> ||| position: Position +<+ y: Int   |
> ++|| |  |
>   ++ +--+
> ```
> 
> In this simple example, two bundles became three, in order to associate
> them. If I only needed to turn two into three, that wouldn't be so bad.
> But if I wanted to associate a name with an Entity, that adds another
> bundle. If I wanted to associate a sprite with an Entity, that adds two
> other bundles, one for the sprite, one for the EntitySprite association.
> This results in an explosion of small, but simple, bundles; each one
> only binding two things from other bundles together.
> 
> - Entity
> - Position
>  - EntityPosition
> - Name
>  - EntityName
> - Sprite
>  - EntitySprite
> - Sound
>  - EntitySound
> 
> This has always seemed off to me somehow. Even though the code is small,
> easy, and sharing a common pattern, the sheer scale seems overwhelming.
> Each one has to be built, tested, deploye

Re: [osgi-dev] How granular should Capabilities be?

[Peter Kriens via osgi-dev]

stom namespaces 
quickly turn a system into a complex nightmare.

That is why I've saved one of the very interesting qualities as last. 
Capabilities carry properties and the properties of the wired capabilities are 
easy to traverse in runtime with OSGi API. This makes them extremely attractive 
to carry data contributed from different resources. I am quite addicted to this 
but I realize it is dangerous because you can easily go too far and create a 
mess. Recently, I used this to provide a bloom filter on class names on 
exported packages so we can search them from repo data, and another use case 
was to provide plugin metadata in bnd so you can now insert plugins from a 
menu. Actually using a feature I added years ago that makes sure that any bnd 
bundles in Bndtools are accessible to the plugins class loaders, which was also 
based on a special capability.


So it depends on the Modularity Maturity Model (MMM) you are ... If you're very 
comfortable with OSGi and your build runs very smooth then this technique can 
be very useful since it allows you to find many problems very early. However, 
it does require a maturity of the build that is not common in our industry. And 
if there is one thing the MMM teaches is that you cannot skip the different 
phases. 

Generally, the best advice I have is to enjoy the many automatic fruits given 
to you by bnd, based on the OSGi cap/req model. However, don't start eagerly 
_looking for problems_ that fit this solution. When you have a new pain, 
sometimes this is an awesome technique. Or not. 

Hope this helps.

Kind regards,

Peter Kriens


> On 23 Aug 2020, at 07:01, Zyle Moore via osgi-dev  
> wrote:
> 
> I'm trying to familiarize myself with the Capability-Requirement model.
> 
> Each Capability has a Namespace, Name, and Version. The example given in the 
> documentation is
> 
> @Capability(
> namespace=ExtenderNamespace.EXTENDER_NAMESPACE,// "osgi.extender"
> name="osgi.component",
> version="1.3.0")
> 
> This can be read as "I provide version 1.3.0 of the osgi.component capability 
> of the osgi.extender namespace". There are some other common namespaces OSGi 
> provides; osgi.implementation is for implementations of a specification or 
> contract, and osgi.service is used to indicate that a service can be 
> registered.
> 
> osgi.implementation;
> osgi.implementation="osgi.cm <http://osgi.cm/>";
> version:Version="1.6"
> 
> osgi.service;
> objectClass:List="org.osgi.service.cm.ConfigurationAdmin"
> 
> At this point, the namespace seems like a generic idea, or concept. I'm 
> looking for an _implementation_ of a spec. I'm looking for a _service_ that's 
> registered. These kind of overlap to me though, because an implementation of 
> osgi.cm <http://osgi.cm/> seemingly includes an implementation of the 
> ConfigurationAdmin service. Because these are in two different namespaces, it 
> seems like there could be misconfigurations. For instance if a bundle 
> provided the ConfigurationAdmin osgi.service Capability, it may not 
> necessarily provide the osgi.cm <http://osgi.cm/> osgi.implementation 
> Capability. The reverse may have the same issue, unless the osgi.cm 
> <http://osgi.cm/> osgi.implementation Capability specifically implied the 
> ConfigurationAdmin osgi.service Capability.
> 
> Another example mentioned in Core 3.3.5 is for a screen with a known
> resolution.
> 
> com.acme.screen;
> width:Long=640;
> height:Long=480;
> card=GeForce
> 
> At this point, a "screen with a resolution" is at the same conceptual level 
> as a "specification implementation" or "registered service". A screen with a 
> resolution is a Capability, a specification implementation is a Capability, a 
> registered service is a Capability. They are all things that a Bundle can 
> provide, or require, which I believe is the conceptual level they all live 
> at; provided by a Bundle, or required by a Bundle. Maybe more along the lines 
> of provided by a Resource or required by a Resource, but Bundle should be 
> good enough for now.
> 
> So what other concepts or ideas could be provided by a Bundle, or required by 
> a Bundle? Would a constant String value be something that a Bundle could 
> provide or require? It seems like it, but it also doesn't seem like something 
> that we would want to put in a Capability. It seems too small a concept, or 
> too specific a concept to warrant a Capability. What about a localized 
> String? It's a bit of a larger concept, as it includes a locale, a key, as 
> well as the localized string. Something about it though still doesn't seem to 
> fit well as a Capability. Perhaps it's becaus

Re: [osgi-dev] Can separate OSGi Deployment Packages use the same types of Resources?

[Peter Kriens via osgi-dev]

You might want to read https://www.aqute.biz/2020/03/17/req-caps.html 
<https://www.aqute.biz/2020/03/17/req-caps.html>

It is a bit of work to get your build on the level so that you can use that 
model, it does require a high level on the Modularity Maturity Model[1]. 
However, you won't believe the benefits once you get there. On the highest 
level, it takes most of the pain out of development and allows you to focus on 
developing new functionality, the fun part. It is sadly our industry's best 
kept secret :-(

Kind regards,

    Peter Kriens

[1]: https://www.aqute.biz/appnotes/modularity-maturity-model.html 
<https://www.aqute.biz/appnotes/modularity-maturity-model.html>



> On 21 Aug 2020, at 00:32, Zyle Moore  wrote:
> 
> Hi Peter, thanks for the clarification.
> 
> The spec did make it clear that what is contained in the DP is treated as a 
> unit, and that unit is very tightly contained. My thinking was that I could 
> have a tightly contained unit for the framework, and a tightly contained unit 
> for the resources, but this doesn't seem to be the right tool for the job.
> 
> You mentioned a resolver; what were you talking about when you referenced 
> this?
> 
> I'll ask another question, under a different subject, that gets to why I 
> wanted to use DPs in the first place, instead of trying to un-XY-problem it.
> 
> On Thu, Aug 20, 2020 at 1:53 AM Peter Kriens  <mailto:peter.kri...@aqute.biz>> wrote:
> Yes, Deployment Packages may not overlap. As I recall we were never shy about 
> this in the spec since it was controversial? 
> 
> The problems you need to solve when you have the same bundle in different 
> DP's with different versions were deemed too much for the hardware we were 
> considering in 2003. The problem with DPs is that it is too easy to create 
> incompatible packages, the model has a lot of error state. If you have plenty 
> of disk space you and you can have plenty of memory and CPU you can isolate 
> many of those problems. However, in a VM on an embedded device there is no 
> such luxury. 
> 
> I also think Deployment Packages are superseded by what you can do with the 
> resolver. A resolver takes a set of initial requirements and calculates a 
> solution that takes all these problems like versions of the same bundle into 
> account. You then get a resolution for your platform. 
> 
> For my customers, I've helped developing several management systems. The one 
> that works best uses the initial requirements as the configuration. When a 
> remote gateway needs to be updated, we calculate the actual bundles. The 
> gateway then calculates the differences and installs/removes/updates the 
> bundles accordingly. 
> 
> This model is a lot less error prone.
> 
> Kind regards,
> 
> Peter Kriens
> 
> 
> 
> 
> > On 20 Aug 2020, at 03:30, Zyle Moore via osgi-dev  > <mailto:osgi-dev@mail.osgi.org>> wrote:
> > 
> > Posted this at StackOverflow, but thought it might be better to ask here.
> > ---
> > The Deployment Admin Specification defines a way of creating Deployment 
> > Packages, which can contain Bundles and Resources.
> > 
> > I wanted to use the Deployment Admin to install two types of Deployment 
> > Packages. The first Deployment Package would contain the "framework" of the 
> > program; including all infrastructure level services and bundles, like the 
> > Configuration Admin, Declarative Services, etc. The second Deployment 
> > Package would contain the "data" of the program; almost exclusively 
> > Resources to be processed by the Resource Processors in the framework 
> > package.
> > 
> > In this situation, the Resource Processors would be in Customizer bundles 
> > in the framework package.
> > 
> > When trying to do it this way, though, the second package is recognized as 
> > a foreign deployment package, and therefore can't be installed. The 
> > Specification, (114.5, Customizer) mentions
> > 
> > > As a Customizer bundle is started, it should register one or more 
> > > Resource Processor services. These
> > Resource Processor services must only be used by resources originating from 
> > the same Deployment
> > Package. Customizer bundles must never process a resource from another 
> > Deployment Package,
> > which must be ensured by the Deployment Admin service.
> > 
> > To check if this was true, I looked to the Auto Configuration Specification 
> > (115), which specifies an Autoconf Resource Processor, which is an 
> > extension of the Deployment Package Specification. It specifies a Resource 
> > Processor implementation, and processes Resources from t

Re: [osgi-dev] Can separate OSGi Deployment Packages use the same types of Resources?

[Peter Kriens via osgi-dev]

Yes, Deployment Packages may not overlap. As I recall we were never shy about 
this in the spec since it was controversial? 

The problems you need to solve when you have the same bundle in different DP's 
with different versions were deemed too much for the hardware we were 
considering in 2003. The problem with DPs is that it is too easy to create 
incompatible packages, the model has a lot of error state. If you have plenty 
of disk space you and you can have plenty of memory and CPU you can isolate 
many of those problems. However, in a VM on an embedded device there is no such 
luxury. 

I also think Deployment Packages are superseded by what you can do with the 
resolver. A resolver takes a set of initial requirements and calculates a 
solution that takes all these problems like versions of the same bundle into 
account. You then get a resolution for your platform. 

For my customers, I've helped developing several management systems. The one 
that works best uses the initial requirements as the configuration. When a 
remote gateway needs to be updated, we calculate the actual bundles. The 
gateway then calculates the differences and installs/removes/updates the 
bundles accordingly. 

This model is a lot less error prone.

Kind regards,

Peter Kriens




> On 20 Aug 2020, at 03:30, Zyle Moore via osgi-dev  
> wrote:
> 
> Posted this at StackOverflow, but thought it might be better to ask here.
> ---
> The Deployment Admin Specification defines a way of creating Deployment 
> Packages, which can contain Bundles and Resources.
> 
> I wanted to use the Deployment Admin to install two types of Deployment 
> Packages. The first Deployment Package would contain the "framework" of the 
> program; including all infrastructure level services and bundles, like the 
> Configuration Admin, Declarative Services, etc. The second Deployment Package 
> would contain the "data" of the program; almost exclusively Resources to be 
> processed by the Resource Processors in the framework package.
> 
> In this situation, the Resource Processors would be in Customizer bundles in 
> the framework package.
> 
> When trying to do it this way, though, the second package is recognized as a 
> foreign deployment package, and therefore can't be installed. The 
> Specification, (114.5, Customizer) mentions
> 
> > As a Customizer bundle is started, it should register one or more Resource 
> > Processor services. These
> Resource Processor services must only be used by resources originating from 
> the same Deployment
> Package. Customizer bundles must never process a resource from another 
> Deployment Package,
> which must be ensured by the Deployment Admin service.
> 
> To check if this was true, I looked to the Auto Configuration Specification 
> (115), which specifies an Autoconf Resource Processor, which is an extension 
> of the Deployment Package Specification. It specifies a Resource Processor 
> implementation, and processes Resources from the Deployment Package.
> 
> Based on this, if I wanted to use the Auto Configuration Specification, then 
> I would seemingly need to include the Auto Configuration Bundle, and the 
> Autoconf Resources within the same Deployment Package. This seems to result 
> in another problem though. The Auto Configuration Bundle wouldn't be able to 
> be used by another package, since a Resource Processor can only be used by 
> Resources in the same package; additionally that Bundle couldn't be used by a 
> separate, unrelated deployment package, because the Autoconf Bundle is 
> already registered by the first package.
> 
> It seems like if two Deployment Packages wanted to use Autoconf Resources, we 
> would be blocked because the Resource Processor is either installed as a 
> Bundle, and therefore unusable by the Deployment Admin because it is not in a 
> Deployment Package, or as part of a single Deployment Package, and no other 
> Deployment Package can ever use that version of that Bundle.
> 
> Is my understanding correct then, that two Deployment Packages not only have 
> to be separate, but also completely unrelated, to the point of not reusing 
> even a single Bundle? If this is the case, then does that mean that it is 
> impossible to have two Deployment Packages with Autoconf Resources; or at 
> least, two packages with the same type of Resource?
> ___
> 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 Compendium vs Enterprise specification

[Peter Kriens via osgi-dev]

OSGi consists of the the Core specification, that defines the framework, and 
the compendium specification, which is the aggregate of _all_ current OSGi 
_service_ specifications. Each service specification has a unique chapter 
number.

The Enterprise, Residential, and IoT specifications are a subset of the 
Compendium and use the same chapter numbers. The purpose of these aggregates is 
to select the specifications that are useful for a specific audience. However, 
the same chapter number and version in different aggregate specifications is 
exactly the same service specification. 

Each specification has a PDF that contains the textual specification, a test 
suite, a designated reference implementation and a JAR containing all the Java 
APIs in that specification. 

The aggregate JARs, compendium, enterprise, etc, are not a severe problem to 
compile against but turned out to be problematic in the runtime assembly. 
Because they combine a set of service specification versions it becomes very 
hard to use an older, or newer version of a specific service. You're basically 
locked into that set of versions. This can severely restrict your choice in the 
set of bundles in your runtime. There you'd like to pick and choose and not be 
artificially constrained.

Therefore, a few years ago, the OSGi started to publish a JAR per service 
specification as well. This will allow you to compile against any version of a 
service and it will allow the runtime assembly a lot of freedom in mixing and 
matching version.

Hope this helps, kind regards,

Peter Kriens


> On 6 May 2020, at 09:35, CHINCHOLE, SHANTESHWAR ASHOKRAO via osgi-dev 
>  wrote:
> 
> Hi,
>  
> What exactly is the difference between compendium and enterprise 
> specification of OSGi. What was the intent of introducing these 2 different 
> specifications?
>  
> I came across a note on the forum saying – “The compendium jar was never 
> meant to be used at runtime but people abused it anyway”. Does it mean that, 
> we can drop usage of compendium jar going forward?
>  
> Thanks & Regards,
> Shanteshwar C
>  
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <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?

[Peter Kriens via osgi-dev]

I agree but I am not sure any member has enough interest to drive that through 
a spec. It would still require the VMs to report it properly.

Kind regards,

Peter Kriens

> On 13 Apr 2020, at 19:57, chris.g...@kiffer.be wrote:
> 
> 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?

[Peter Kriens via osgi-dev]

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

Re: [osgi-dev] Intermittent failure to getService

[Peter Kriens via osgi-dev]

It all depends ... In general state can be managed in many different ways. 
Prototype scope is too much in your face, too much boilerplate, that is why I 
avoid it. It works nicely behind the scenes though like DS and CDI. I do not 
think I've ever used them so far. (Which is a self perpetuating truth, I know.)

PK



> On 11 Mar 2020, at 13:26, Alain Picard  wrote:
> 
> Peter and Tim,
> 
> Thanks for the pointers. The error was caused by some invalid use of a 
> disposed object. This was using factory components and I switched all of it 
> to use prototype components instead which IMHO are easier to manage.
> 
> And Peter to your question about using prototype scope, those objects contain 
> state and it is my understanding that prototype scope is required in those 
> cases.
> 
> Thanks
> Alain
> 
> 
> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens  <mailto:peter.kri...@aqute.biz>> wrote:
> Some remarks:
> 
> * Yes, it is thread safe. In OSGi we mark all thread safe types with the 
> @ThreadSafe annotation.
> * The error message is not in the log you listed. Since the log contains a 
> deactivation message, I hope you're handling the case corrected that you're 
> being called after deactivation? Seems too simple, but anyway ... :-)
> 
> * And for something completely different, is there any reason you use the 
> prototype scope? You real code might need it but for this code it just looks 
> like making it accidentally complex?
> * And last but not least, you seem to be using slf4j? Did you wire up the 
> OSGi log to it? I've seen cases where the information was in the OSGi log but 
> those messages were discarded.
> 
> Kind regards,
> 
>   Peter Kriens
> 
> 
>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev > <mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> Question: The method getDiagnosticForEObject can be called by different 
>> threads. Can this be the source of the issue? I see that 
>> ComponentServiceObject is tagged as ThreadSafe, but?
>> 
>> Alain
>> 
>> 
>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard > <mailto:pic...@castortech.com>> wrote:
>> Tim,
>> 
>> I don't think so. BaValidationManagerExt is used in only 1 place and it is 
>> instantiated in activate and released in deactivate:
>> @Component(
>> factory = ValidationManager.CONFIG_FACTORY, 
>> service = ValidationManager.class
>> )
>> public final class CoreValidationManager extends 
>> CDODefaultTransactionHandler1 implements ValidationManager, 
>> CDOTransactionHandler2 {
>> ...
>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>> private ComponentServiceObjects extenderFactory;
>> private ValidationManagerExt extender;
>> 
>> @Activate
>> private void activate() {
>> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>> 
>> extender = extenderFactory.getService();
>> }
>> 
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
>> extenderFactory.ungetService(extender);
>> }
>> 
>> Cheers,
>> Alain
>> 
>> Alain Picard
>> Chief Strategy Officer
>> Castor Technologies Inc
>> o:514-360-7208
>> m:813-787-3424
>> 
>> pic...@castortech.com <mailto:pic...@castortech.com>
>> www.castortech.com <http://www.castortech.com/>
>> 
>> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward > <mailto:tim.w...@paremus.com>> wrote:
>> Hi Alain,
>> 
>> Is it possible that someone has a reference to a BaValidationManagerExt 
>> service instance that they aren’t releasing after ungetting it (or that 
>> they’re holding onto after it has been unregistered)? It might be an SCR 
>> bug, but it’s more likely to be some code holding onto a component instance 
>> that it shouldn’t.
>> 
>> Best Regards,
>> 
>> Tim
>> 
>>> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev >> <mailto:osgi-dev@mail.osgi.org>> wrote:
>>> 
>>> Hi
>>> 
>>> I am having a very intermittent issue with getService on a prototype 
>>> component. This is called hundreds of times and I put a breakpoint a few 
>>> weeks ago and have now gotten the error.
>>> 
>>> I have this class:
>>> @Component(scope=ServiceScope.PROTOTYPE,
>>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>>> )
>>> public final class BaValidationManagerExt implements ValidationManagerExt {
>>> private final Logger log = LoggerFactory.getLogger(g

[osgi-dev] Android, OSGi Connect, & bnd

[Peter Kriens via osgi-dev]

I had to do a Proof of Concept of using OSGi applications on an Android 
embedded platform. This turned out to need OSGi Connect, an upcoming OSGi Spec. 
If you're interested:

https://www.aqute.biz/2020/03/02/osgi-on-android.html 
<https://www.aqute.biz/2020/03/02/osgi-on-android.html>

Kind regards,

    Peter Kriens

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

Re: [osgi-dev] Intermittent failure to getService

[Peter Kriens via osgi-dev]

Some remarks:

* Yes, it is thread safe. In OSGi we mark all thread safe types with the 
@ThreadSafe annotation.
* The error message is not in the log you listed. Since the log contains a 
deactivation message, I hope you're handling the case corrected that you're 
being called after deactivation? Seems too simple, but anyway ... :-)

* And for something completely different, is there any reason you use the 
prototype scope? You real code might need it but for this code it just looks 
like making it accidentally complex?
* And last but not least, you seem to be using slf4j? Did you wire up the OSGi 
log to it? I've seen cases where the information was in the OSGi log but those 
messages were discarded.

Kind regards,

Peter Kriens


> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev  
> wrote:
> 
> Question: The method getDiagnosticForEObject can be called by different 
> threads. Can this be the source of the issue? I see that 
> ComponentServiceObject is tagged as ThreadSafe, but?
> 
> Alain
> 
> 
> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard  <mailto:pic...@castortech.com>> wrote:
> Tim,
> 
> I don't think so. BaValidationManagerExt is used in only 1 place and it is 
> instantiated in activate and released in deactivate:
> @Component(
> factory = ValidationManager.CONFIG_FACTORY, 
> service = ValidationManager.class
> )
> public final class CoreValidationManager extends 
> CDODefaultTransactionHandler1 implements ValidationManager, 
> CDOTransactionHandler2 {
> ...
> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
> private ComponentServiceObjects extenderFactory;
> private ValidationManagerExt extender;
> 
> @Activate
> private void activate() {
> log.trace("Activating {}", getClass()); //$NON-NLS-1$
> 
> extender = extenderFactory.getService();
> }
> 
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
> extenderFactory.ungetService(extender);
> }
> 
> Cheers,
> Alain
> 
> Alain Picard
> Chief Strategy Officer
> Castor Technologies Inc
> o:514-360-7208
> m:813-787-3424
> 
> pic...@castortech.com <mailto:pic...@castortech.com>
> www.castortech.com <http://www.castortech.com/>
> 
> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  <mailto:tim.w...@paremus.com>> wrote:
> Hi Alain,
> 
> Is it possible that someone has a reference to a BaValidationManagerExt 
> service instance that they aren’t releasing after ungetting it (or that 
> they’re holding onto after it has been unregistered)? It might be an SCR bug, 
> but it’s more likely to be some code holding onto a component instance that 
> it shouldn’t.
> 
> Best Regards,
> 
> Tim
> 
>> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev > <mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> Hi
>> 
>> I am having a very intermittent issue with getService on a prototype 
>> component. This is called hundreds of times and I put a breakpoint a few 
>> weeks ago and have now gotten the error.
>> 
>> I have this class:
>> @Component(scope=ServiceScope.PROTOTYPE,
>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>> )
>> public final class BaValidationManagerExt implements ValidationManagerExt {
>> private final Logger log = LoggerFactory.getLogger(getClass());
>> 
>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>> private ComponentServiceObjects validatorFactory;
>> 
>> @Activate
>> private void activate() {
>> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this)); 
>> //$NON-NLS-1$
>> }
>> 
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this)); 
>> //$NON-NLS-1$
>> }
>> 
>> @Override
>> public Diagnostic getDiagnosticForEObject(EObject eObj) {
>> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
>> Validator validator = validatorFactory.getService();
>> 
>> if (validator != null) {
>> try {
>> return validator.runValidation(false, Collections.singletonMap(eObj, new 
>> HashSet<>()),
>> new NullProgressMonitor()).getB();
>> }
>> finally {
>> validatorFactory.ungetService(validator);
>> }
>> }
>> else {
>> log.error("Validator Service not found for {}", eObj, new Throwable()); 
>> //$NON-NLS-1$
>> return Diagnostic.CANCEL_INSTANCE;
>> }
>> }
>> }
>> 
>> and the validator:
>> @Component(
>> scope = ServiceScope.PROTOTY

[osgi-dev] Bndtools starter

[Peter Kriens via osgi-dev]

I've written a little booklet and created a number of videos to make it easier 
to get started with bndtools. 

https://bndtools.org/workspace.html

If you have any feedback, let me know. I heard from a lot of people that they 
had a hard time starting with the Bndtools which is a real shame. When properly 
setup, it is hard to beat with the Gradle build for Github Actions and the 
almost script language like fluidity of Bndtools.

Again, let me know if I can make improvements. And if you're interested in 
providing an audio tape with a native speaker with a better voice for the 
videos, don't hesitate to contact me. Would be appreciated.

Kind regards,

Peter Kriens

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

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

[Peter Kriens via osgi-dev]

It is surprisingly simple. :-)

Let's assume Oracle adds a new method to `java.nio.file.Path`. Would you care? 
Unless you work for Azul, you'd like couldn't give a rats ass. Once you use 
that new method you care, but before that moment it is irrelevant to you. That 
makes you a _consumer_ of the `java.nio.file` package. Azul and Oracle are, 
however, _providers_ of this package. Oracle and Azul do care when this method 
gets added because you would be very upset if the method is not there. However, 
if Oracle added a method to `java.io.Serializable` you would likely be pretty 
upset because you are a _consumer_ of the `java.io ` package.

When you make a change to an API package you might break users of that package. 
To distinguish between the Azuls and Oracles of this world and mere mortals 
OSGi/bnd allows you to mark a type to be **only** affecting _providers_. I.e. 
the Path interface would be a _provider type_. (The @ConsumerType is default 
and just breaks everybody when you make a binary incompatible change.)

The archetypical example is Event Admin. If we add a method to the EventAmin 
interface we only break the 5 or 6 implementations of Event Admin. And we 
should break those implementation because they need to implement this new 
method. However, the 50 million bundles that depend on Event Admin are not 
affected since this change is fully backward compatible for them. However, if 
we add a method to Event Handler then we break all those 50 million bundles 
that implement Event Handler. That is why  the `EventHandler` interface is a 
@ConsumerType.

So the sole purpose of the @ProviderType annotation is to make a breaking 
change but indicate that only, the usually smaller number of, bundles that 
_provide_ the API should be broken instead of the majority of bundles that only 
_consume_ this API.

The key thing to realize is that provider/consumer is about the API **package** 
and not an interface. If you make a binary incompatible change, the key 
question is does it affect everybody (consumer and providers) or can I limit it 
to a smaller number of bundles (providers)?

PK

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

Re: [osgi-dev] Best way to move an OSGi application to Docker plus K8 ?

[Peter Kriens via osgi-dev]

Christian,

Yes, for JPM, which feels very long ago, I had a base image and then added only 
an executable JAR as a new layer.

However, since I've seen the stats for porn sites on the Internet the size of 
images got me a lot less worried :-) I've spent a lot of my working life trying 
to make things work in small spaces and trying to make them efficient. However, 
in the last decade I've been bypassed by several people that just could not 
care less about these issues and thereby gained speed. So I am trying to also 
become less obsessed with efficiency because it does remove a lot of 
complexity. Today, quite often keeping it simple and stupid is actually good 
enough.

Kind regards,

Peter Kriens



> On 7 Aug 2019, at 09:49, Christian Schneider  wrote:
> 
> Hi Peter,
> 
> I also thought a bit about how to possibly make the deployments smaller.
> 
> I see three possible solutions:
> 1. Put the main version of a system in a docker layer and upgrades in a layer 
> on top.
> 
> An example where this might make sense is Adobe Experience Manager. You put 
> the bundles of AEM 6.5 in one docker layer. Each file name must uniquely map 
> to a bundle symbolic name + version (or maven coordinates).
> Then for any updates you overwrite or add the changed bundles in a layer on 
> top and overwrite the runbundles list.
> 
> Even if you write out the full list of bundles again for any update docker 
> will be able to create an effective diff that makes your new docker image 
> pretty small.
> 
> 2. Put your dependencies in one docker layer and your own bundles in another
> 
> Typically you have more changes to your own code than changes to 
> dependencies. Also typically your own code is much smaller than your 
> dependencies. 
> 
> So this approach can also make your docker images (needed for an upgrade) a 
> lot smaller.
> 
> 3. Pull bundles from maven repository (maybe with local caching)
> 
> In this case you only deploy the list of runbundles with maven coordinates 
> and a starter in the docker image. The starter then downloads the bundles 
> from a maven repo. To make this fast you would need a local cache of bundles 
> that survives restart of a pod. (Not sure how to best achieve this for k8s 
> but I am sure it can be done).
> 
> What do you think? What concept do you have in mind?
> 
> Christian
> 
> Am Di., 6. Aug. 2019 um 16:58 Uhr schrieb Peter Kriens via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>>:
> I don't see any reason why upgrading your existing workflow with a static 
> Docker container and then updating the bundles would not work.
> 
> However ...
> 
> Just look at the number of moving parts that you then need in runtime. 
> Creating a Docker image in the build is trivial and deploying it to 
> Kubernetes is, well less than trivial. You need to have a lot of things going 
> right on different systems and much more configuration to make the dynamic 
> update work. All these moving parts can fail.
> 
> The only issue is size & time. If you need to deploy a full docker image to 
> hundreds of thousands of machines the update can be done more efficiently 
> using OSGi bundles. And actually that is a solution I'm working on at the 
> moment. However, if time/size is not a concern I find a full docker image 
> disturbingly hard to beat. About 5 years ago I ran the 'Java Package Manager' 
> web site on Kubernetes and it worked scarily easy and reliable.
> 
> When I am hired to help one of the first things I look for is reduce as many 
> of the moving parts as possible. Yes, you can get anything to work but 
> reducing the possible errors cases really increases reliability imho.
> 
> Kind regards,
> 
> Peter Kriens
> 
> 
> > On 6 Aug 2019, at 16:28, Cristiano via osgi-dev  > <mailto:osgi-dev@mail.osgi.org>> wrote:
> > 
> > Hello all,
> > 
> > I have a challenged POC to do in order to dockerize an existent OSGi
> > based application and then deploy it to a Kubernetes based cloud.
> > 
> > I'm not totally aware of k8 features yet, so I have some doubts that I
> > would like discuss here.
> > 
> > The main doubt is related to our existent upgrading process which
> > currently we upload a R5 repository to a webserver and then a node
> > management agent bundle access it and upgrades the necessary app bundles.
> > 
> > Many examples I saw in the web creates a docker image in their building
> > process and delivery an image at each dev cycle. I don't like much of
> > this idea, so initially I thought to mimic our existent process in a
> > docker container just setting up a Volume in order to upload the newer
> > repositories.
> > 
> >

Re: [osgi-dev] Best way to move an OSGi application to Docker plus K8 ?

[Peter Kriens via osgi-dev]

I don't see any reason why upgrading your existing workflow with a static 
Docker container and then updating the bundles would not work.

However ...

Just look at the number of moving parts that you then need in runtime. Creating 
a Docker image in the build is trivial and deploying it to Kubernetes is, well 
less than trivial. You need to have a lot of things going right on different 
systems and much more configuration to make the dynamic update work. All these 
moving parts can fail.

The only issue is size & time. If you need to deploy a full docker image to 
hundreds of thousands of machines the update can be done more efficiently using 
OSGi bundles. And actually that is a solution I'm working on at the moment. 
However, if time/size is not a concern I find a full docker image disturbingly 
hard to beat. About 5 years ago I ran the 'Java Package Manager' web site on 
Kubernetes and it worked scarily easy and reliable.

When I am hired to help one of the first things I look for is reduce as many of 
the moving parts as possible. Yes, you can get anything to work but reducing 
the possible errors cases really increases reliability imho.

Kind regards,

Peter Kriens


> On 6 Aug 2019, at 16:28, Cristiano via osgi-dev  
> wrote:
> 
> Hello all,
> 
> I have a challenged POC to do in order to dockerize an existent OSGi
> based application and then deploy it to a Kubernetes based cloud.
> 
> I'm not totally aware of k8 features yet, so I have some doubts that I
> would like discuss here.
> 
> The main doubt is related to our existent upgrading process which
> currently we upload a R5 repository to a webserver and then a node
> management agent bundle access it and upgrades the necessary app bundles.
> 
> Many examples I saw in the web creates a docker image in their building
> process and delivery an image at each dev cycle. I don't like much of
> this idea, so initially I thought to mimic our existent process in a
> docker container just setting up a Volume in order to upload the newer
> repositories.
> 
> So I have created two docker images for testing this locally. One image
> contains the OSGI container and framework bundle (that do not change
> much) and other image that extends the other for only the apps bundles.
> it have worked well running locally.
> 
> Would this also work in K8 ?  What would happen if I need to scale and
> then create multiple PODS for this application?
> 
> thanks for any help.
> 
> best regards,
> 
> Cristiano
> 
> 
> ___
> 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] Conditional Target

[Peter Kriens via osgi-dev]

I was vaguely aware of this RFC but that is an extension to the DS Components 
isn't it? That will have more capabilities I assume since you're not restricted 
to the features of the current spec. 

This is basically a continuance of the aggregate service but with a bit smaller 
scope. The Aggregate Service had some basic limitations because not all 
components shared the same view at the same time.

It is a tricky area.

I read the RFC in detail. Kind regards,

Peter Kriens



> On 26 Jun 2019, at 14:29, BJ Hargrave  wrote:
> 
> This seems just like 
> https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf
>  
> <https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf>
>  
> Are you making an alternate design? Or did you not know of this RFC?
> --
> 
> 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: Peter Kriens via osgi-dev 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: via bndtools-users , 
> osgi-dev@mail.osgi.org
> Cc:
> Subject: [EXTERNAL] [osgi-dev] Conditional Target
> Date: Wed, Jun 26, 2019 08:26
>  
> I've developed a service that you can use to block the activation of a DS 
> component until a set of other services are ready. This is related to the 
> whiteboard pattern when the sender wants to be sure a certain set of 
> whiteboard services are present. Normally you can only assert the properties 
> of 1 service but this allows you to use a filter to select the aggregated 
> properties of a group of services. An example is when you need a set of at 
> least 3 remote services where there are at least 2 unique regions. 
>  
> For example, you want to block until the average of the `foo` properties on 
> the registered Foo services is higher than 2:
>  
> @Reference( target="([avg]foo>=2)" )
> ConditionalTarget foos;
>  
> The Conditional Target object provides a direct reference to the services and 
> service references being tracked as well as the aggregated properties. 
>  
> It is described in 
>  
> https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.osgi.conditionaltarget
>  
> <https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.osgi.conditionaltarget>
>  
> And you can find the binary artifact in:
>  
> https://oss.sonatype.org/content/repositories/snapshots/biz/aQute/biz.aQute.osgi.conditionaltarget/
>  
> <https://oss.sonatype.org/content/repositories/snapshots/biz/aQute/biz.aQute.osgi.conditionaltarget/>
>  
> Feedback appreciated on the idea and execution. If people like this, I can 
> submit it to Apache Felix if they're interested.
>  
> Kind regards,
>  
> Peter Kriens
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <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] Conditional Target

[Peter Kriens via osgi-dev]

I've developed a service that you can use to block the activation of a DS 
component until a set of other services are ready. This is related to the 
whiteboard pattern when the sender wants to be sure a certain set of whiteboard 
services are present. Normally you can only assert the properties of 1 service 
but this allows you to use a filter to select the aggregated properties of a 
group of services. An example is when you need a set of at least 3 remote 
services where there are at least 2 unique regions. 

For example, you want to block until the average of the `foo` properties on the 
registered Foo services is higher than 2:

@Reference( target="([avg]foo>=2)" )
ConditionalTarget  foos;

The Conditional Target object provides a direct reference to the services and 
service references being tracked as well as the aggregated properties. 

It is described in 


https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.osgi.conditionaltarget
 


And you can find the binary artifact in:


https://oss.sonatype.org/content/repositories/snapshots/biz/aQute/biz.aQute.osgi.conditionaltarget/
 


Feedback appreciated on the idea and execution. If people like this, I can 
submit it to Apache Felix if they're interested.

Kind regards,

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

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Peter Kriens via osgi-dev]

> Considering this, lowering a lower bound of an Import-Package statement when 
> resolving should be acknowledged as a bug. 
> 
I beg to differ ...

As said, you can set the consumer/provider policy to your desired strategy.


Kind regards,

    Peter Kriens

> On 18 Jun 2019, at 10:33, Michael Lipp  wrote:
> 
> 
>> 
>> I expect there are two things at play. First, OSGi specifies things as you 
>> indicate. An import of [1.2.3.qualifier,2) must not select anything lower 
>> than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the 
>> qualifier and micro part in calculating the import ranges from the exports 
>> on the class path.
> Thanks for the clarification, I think this explains things.
> 
>> [...]
>> 
>> Conclusion, the spec is perfect but the implementations apply heuristics and 
>> may have bugs.
> The specification says (or defines, if you like): "micro - A change that does 
> not affect the API, for example, a typo in a comment or a bug fix in an 
> implementation." It explicitly invites the developer to indicate a bug fix by 
> incrementing the micro part. There's no hint or requirement that he should 
> increment the minor part to reflect a bug fix. I do not find your statement 
> "The definition of the micro version is that it should not make a difference 
> in runtime" to be supported by the spec or the Semantic Versioning 
> Whitepaper. Actually, this interpretation would restrict the usage of the 
> micro part to documentation changes because every bug fix changes the runtime 
> behavior. This is, after all, what it is intended to do.
> 
> Considering this, lowering a lower bound of an Import-Package statement when 
> resolving should be acknowledged as a bug. 
> 
>  - Michael
> 
> 
> 
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>>> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev >> <mailto:osgi-dev@mail.osgi.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I have in my repository a bundle A-2.0.1 that exports packages with
>>> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
>>> version 2.0.3. Version A-2.0.3 fixes a bug.
>>> 
>>> I have a bundle B that imports the packages from A with import
>>> statements "... version=[2.0.3,3)" because the bug fix is crucial for
>>> the proper working of B.
>>> 
>>> Clicking on "Resolve" in bndtools, I get a resolution with bundle
>>> A-2.0.1. I understand that this complies with the specification ("It is
>>> recommended to ignore the micro part of the version because systems tend
>>> to become very rigid if they require the latest bug fix to be deployed
>>> all the time.").
>>> 
>>> What I don't understand is the rationale. I don't see any drawbacks in
>>> deploying the latest bug fix. Of course, there's always the risk of
>>> introducing a new bug with a new version, even if it is supposed to only
>>> fix a bug in the previous version. But if you're afraid of this, you may
>>> also not allow imports with version ranges such as "[1.0,2)" (for
>>> consumers).
>>> 
>>> In my case, I now have to distribute bundle B with a release note to
>>> configure the resolution in such a way that only A 2.0.3 and up is used.
>>> Something that you would expect to happen automatically looking at the
>>> import statement. And if I want to make sure that the release note is
>>> not overlooked, the only way seems to be to check the version of "A" at
>>> run-time in the activation of "B". This is downright ugly.
>>> 
>>>  - Michael
>>> 
>>> 
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <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] Micro version ignored when resolving, rationale?

[Peter Kriens via osgi-dev]

As Tim indicates we need more information. 

I expect there are two things at play. First, OSGi specifies things as you 
indicate. An import of [1.2.3.qualifier,2) must not select anything lower than 
1.2.3.qualifier. Second, bnd does have heuristics that do drop the qualifier 
and micro part in calculating the import ranges from the exports on the class 
path.

When bnd builds a bundle it calculates the import range based on the package it 
was compiled against. Bnd finds the version looking at packageinfo, 
package-info.class, and the manifest. 

It then checks if that package is 'provided' or 'consumed' by the bundle, and 
from this information it calculates the range. The base version does indeed 
drop the qualifier and the micro version. I hope dropping the qualifier sounds 
logical to you? If you do not drop the qualifier you always need a fresh bundle 
with whatever you do. This is hell.

Since the micro version in a semantic version cannot make a difference it is 
logically safe to drop that one as well. The definition of the micro version is 
that it should not make a difference in runtime. Having a bug fix in a micro 
version is just plain wrong. Why have a spec when a tool cannot rely on its 
semantics?

At the time when we're starting with this this heuristic made things a lot 
easier to work with. Although the micro version is less volatile than the 
qualifier, our experience was that you ended up in a similar hell that the most 
minute change required everything to change. Especially since we did not have a 
resolver at that time. We've got almost 18 years of experience with this model 
and I think it has worked quite well so far. However, with the resolver going 
mainstream in the last few years maybe we need to revisit it. 

If you do not agree with the heuristic you can set the policy for the provider 
and consumer import range yourself. See 
https://bnd.bndtools.org/instructions/provider_policy.html 
<https://bnd.bndtools.org/instructions/provider_policy.html> Personally I would 
not do this because your then trying to fix the original error (a bug fix in a 
micro version) in the wrong place. Although this can be a quick fix, in my 
experience these hacks tend to exponentially increase the complexity of the 
build over time since you can no longer rely on the established rules, forcing 
you to make specials everywhere over time.

In your case you or someone in your team did not apply the rules for semantic 
versioning. That happens, especially when you have to rely on external 
software. In that case you can manually apply the import range in the 
manifest/bnd.bnd file. This exact import range must be obeyed by the resolver. 

That said, if 2.0.1 and 2.0.3 are available then it would be nice if the 
resolver would prefer the highest possible version as a heuristic. In bnd we 
compile against the lowest version to keep the base as low as possible but in 
runtime we prefer the highest allowed version. I assumed that the bnd resolver 
had this behavior since we order the resources. Maybe there were other 
constraints that made 2.0.3 less attractive than 2.0.1. To know that we need to 
know more about the exact setup.

Conclusion, the spec is perfect but the implementations apply heuristics and 
may have bugs.

Kind regards,

    Peter Kriens

> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev  
> wrote:
> 
> Hi,
> 
> I have in my repository a bundle A-2.0.1 that exports packages with
> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
> version 2.0.3. Version A-2.0.3 fixes a bug.
> 
> I have a bundle B that imports the packages from A with import
> statements "... version=[2.0.3,3)" because the bug fix is crucial for
> the proper working of B.
> 
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the specification ("It is
> recommended to ignore the micro part of the version because systems tend
> to become very rigid if they require the latest bug fix to be deployed
> all the time.").
> 
> What I don't understand is the rationale. I don't see any drawbacks in
> deploying the latest bug fix. Of course, there's always the risk of
> introducing a new bug with a new version, even if it is supposed to only
> fix a bug in the previous version. But if you're afraid of this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
> 
> In my case, I now have to distribute bundle B with a release note to
> configure the resolution in such a way that only A 2.0.3 and up is used.
> Something that you would expect to happen automatically looking at the
> import statement. And if I want to make sure that the release note is
> not overlooked, the only way seems to be to check the version of "A" at
> run-time in the activation of 

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

[Peter Kriens via osgi-dev]

> On 14 May 2019, at 10:23, Christian Schneider via osgi-dev 
>  wrote:
> I agree that switching from local services to remote services is usually not 
> just a configuration change (even with RSA). Remote services have to be 
> designed with a completely different level of granularity and more 
> consideration to version compatibility. 
True. But since RSA I find that my service designs are much more DTO driven 
then before. Just make sure you do not exchange objects and you're usually fine.

That said, even if you don't, creating a facade is usually a lot easier than 
changing highly coupled domain code.

Kind regards,

    Peter Kriens

> 
> Can you go into a bit more detail about how to create smarter services using 
> OSGi service dynamics? I think we might be able to extract some interesting 
> patterns there.
> 
> Christian
> 
> Am So., 12. Mai 2019 um 11:07 Uhr schrieb Toni Menzel via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>>:
> It's not necessarily about one or the other. 
> What you mention is the k8s control plane that can take over your 
> traffic/scaling needs.
> However, the beauty of dynamic services on OSGi can be that you reflect the 
> "as-is" service topology (controlled and managed by k8s).
> OSGi services can understand and adapt to the availability (or 
> non-availability) dynamically. It gives you fine-grained control which leads 
> to smarter services.
> They are not black and white anymore (on or off) but can help re-reoute, 
> cache or otherwise mitigate short term changes in the service topology.
> 
> Note that this is complementary to remote services mentioned above. RSA help 
> you partition your (micro-)services easier. Though i think the story is not 
> as easy because.. you know.. the network is not reliable, etc. 
> 
> There is a lot more to this, and its a great discussion you are having here. 
> And its up to your needs if you want smarter services or can live with cheap 
> & dump instances (that ultimately leads you towards FaaS) - which can be 
> totally fine.
> 
> Toni
> 
> Toni Menzel / rebaze consultancy
> Alleestrasse 25 / 30167 Hannover / Germany
> M +49 171 6520284
> www.rebaze.com <https://www.rebaze.com/>
> 
> Software Engineering Therapy
> rebaze GmbH, Zollstrasse 6, 39114 Hannover, Germany 
> Managing Director: Toni Menzel
> Phone: +49  171 6520284 / E-Mail: h...@rebaze.com 
> <mailto:h...@rebaze.com>
> Registration Court: District Court of Stendal
> Registration Number: HRB 17993 
> Sales Tax (VAT) Registration Number: DE282233792
> 
> 
> 
> 
> 
> On Sat, May 11, 2019 at 10:05 PM Jürgen Albert via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> Depends on how you build your services. If you go the classic way, with a 
> normal HTTP API with e.g. docker compose or swarm, you would get load 
> balancing out of the box. They do a DNS round robin, the moment you scale a 
> service there. I believe Kubernetes does the same. The remote service Admin 
> does not really specify something like this. Here you can do the load 
> balancing on the application side. if you have e.g. 3 instances of the 
> billing container, you would find 3 service instances on your consumer side. 
> 
> Am 11/05/2019 um 10:36 schrieb Andrei Dulvac:
>> Hi Jürgen.
>> 
>> Ok, I missed the context of your previous mail - how modularity helps even 
>> if you have multiple containers. 
>> 
>> I get it... It's fast to develop and easy to switch boundaries. One other 
>> thing that I have on my mind: in your example, how easy would it be to scale 
>> the billing container? I assume it would be easy to route calls at least 
>> through a load balancer (I am not at all familiar with e. g. JaxRS) 
>> 
>> I might start to consider again the whole idea of microservices and using 
>> OSGi to modularize code inside them. 
>> 
>> 
>> On Fri, May 10, 2019, 22:26 Jürgen Albert > <mailto:j.alb...@data-in-motion.biz>> wrote:
>> Hi Andrej,
>> 
>> I think you got us wrong. Nobody suggested to use OSGi or Http MIcroservices 
>> as you have called them. The Concepts behind both are modularity. The 
>> following Definition would fit both:
>> 
>> The smallest unit is a module that defines Service APIs as Interaction 
>> points. 
>> 
>> Thus OSGi is the best tool to create Http Microservices. I would prefer 
>> Distributed Microservices because you don't necessarily need HTTP for the 
>> Communication between your containers/processes. You can split your Bundles 
>> over as many Containers as you like and I will guarantee that is it easier 
>> to achieve and maintain then with anything else.

Re: [osgi-dev] Launchpad

[Peter Kriens via osgi-dev]

There is something else in the pipeline as well that might help: 
biz.aQute.bnd.runtime.snapshot. It is not being built yet but you can build it 
yourself in the bnd workspace. If you place that bundle in your runtime it will 
make a snapshot in the current directory just before the framework stops. You 
can then drag from the file system and then drop this file on 
https://bnd.bndtools.org/snapshot.html

It is still under development but it provides a wealth of information. There 
are also gogo commands to make intermediate snapshots. I find this an 
invaluable tool for debugging OSGi issues. 

Glad you like it! Looking forward to your PR's! :-)

Kind regards,

Peter Kriens



> On 15 Mar 2019, at 08:43, Bram Pouwelse  wrote:
> 
> Hi Peter, 
> 
> I actually started to play with this cool new toy yesterday and I like it.  
> It gives a lot more control over the framework(s) launched than the test 
> support that has always been there. Not that long ago I was looking for 
> something like this but had to hand craft some code to get more than one 
> framework in a test but with Launchpad I can just use a bndrun again to 
> bootstrap multiple framework instances. So it was a perfect fit for my tests 
> and I can get rid of some framework boostrap boilerplate :).   
> 
> I did run into the "Version Sensitivity" issue when trying to obtain 
> ConfigurationAdmin but that's well explained on the page you just shared, if 
> only I'd read that page yesterday that would've saved me some time  
> 
> So this is definitely a useful tool, thanks Peter!
> 
> Kind regards, 
> Bram
> 
> 
> Op vr 15 mrt. 2019 om 08:28 schreef Peter Kriens via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>>:
> I've recently been working on a bndtools testing framework based on some Pax 
> Exam envy. The result is _Launchpad_. It is a builder for a framework setup 
> using all the information from a bnd workspace and its projects. For each 
> test method you can then execute your tests without having to generate a test 
> bundle. Due to some deep class loading magic, the class space of the test 
> code (for example JUnit) is properly exported via the framework. Although 
> there are some pitfalls, sharing the classes this way works quite well.
> 
> Launchpad also contains an injector that you can use to inject services and 
> some key OSGi objects like BundleContext in your test object. A large number 
> of utility methods on Launchpad provide conveniences for testing. For 
> example, you can also hide services with one call.
> 
> Launchpad is agnostic of a testing framework. It has been tested with JUnit 
> but TestNG or other frameworks should be no problem.
> 
> This is all documented: 
> https://bnd.bndtools.org/chapters/315-launchpad-testing.html 
> <https://bnd.bndtools.org/chapters/315-launchpad-testing.html>
> 
> This is an ambitious test environment. There is now experience at one of my 
> customers but it clearly needs to go to a learning period. Almost all of what 
> is documented is in 4.2.0 which is just released, if you want the absolute 
> latest get the 4.3.0 snapshot. 
> 
> Launchpad is developed for the bnd Workspace model. I think it can be adapted 
> to the Maven model with the bndrun files since this mimics a Workspace 
> beneath the covers. However, that might require some work and surely some 
> documentation. Volunteers welcome.
> 
> Let me know if this is useful and file issues on 
> https://github.com/bndtools/bnd/issues 
> <https://github.com/bndtools/bnd/issues> when there are issues or really good 
> ideas.
> 
> Kind regards,
> 
> Peter Kriens
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <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] Launchpad

[Peter Kriens via osgi-dev]

I've recently been working on a bndtools testing framework based on some Pax 
Exam envy. The result is _Launchpad_. It is a builder for a framework setup 
using all the information from a bnd workspace and its projects. For each test 
method you can then execute your tests without having to generate a test 
bundle. Due to some deep class loading magic, the class space of the test code 
(for example JUnit) is properly exported via the framework. Although there are 
some pitfalls, sharing the classes this way works quite well.

Launchpad also contains an injector that you can use to inject services and 
some key OSGi objects like BundleContext in your test object. A large number of 
utility methods on Launchpad provide conveniences for testing. For example, you 
can also hide services with one call.

Launchpad is agnostic of a testing framework. It has been tested with JUnit but 
TestNG or other frameworks should be no problem.

This is all documented: 
https://bnd.bndtools.org/chapters/315-launchpad-testing.html

This is an ambitious test environment. There is now experience at one of my 
customers but it clearly needs to go to a learning period. Almost all of what 
is documented is in 4.2.0 which is just released, if you want the absolute 
latest get the 4.3.0 snapshot. 

Launchpad is developed for the bnd Workspace model. I think it can be adapted 
to the Maven model with the bndrun files since this mimics a Workspace beneath 
the covers. However, that might require some work and surely some 
documentation. Volunteers welcome.

Let me know if this is useful and file issues on 
https://github.com/bndtools/bnd/issues when there are issues or really good 
ideas.

Kind regards,

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

[osgi-dev] Wrapping: Do not use the same bsn

[Peter Kriens via osgi-dev]

I just wasted an hour trying to figure out why my test was complaining about 
missing the `org.osgi.service.component` package. The Apache Felix SCR bundle I 
was using was clearly exporting and importing it. Since I was testing launchpad 
I blamed myself so I dug deep into things but could not figure it out.

Until I realized I had SCR in my repository twice. 



Reasonable people would assume that 2.0.10.v20170501-2007 is the same bundle as 
2.0.10 so I only looked at the first one, the original Apache Felix. Until I 
finally became desperate enough and looked at the Eclipse version, which indeed 
turned out to be a variation.

Apache Felix original:

Export-Package
  org.apache.felix.scr.component {version=1.1.0, imported-as=[1.1,1.2)}
  org.apache.felix.scr.info  {version=1.0.0, imported-as=[1.0,1.1)}
  org.osgi.service.component {version=1.3, imported-as=[1.3,1.4)}
  org.osgi.service.component.runtime {version=1.3, imported-as=[1.3,1.4)}
  org.osgi.service.component.runtime.dto {version=1.3, imported-as=[1.3,1.4)}
  org.osgi.util.function {version=1.0, imported-as=[1.0,2)}
  org.osgi.util.promise  {version=1.0, imported-as=[1.0,2)}

The Eclipse variation:

Export-Package
  org.apache.felix.scr.component {version=1.1.0, imported-as=[1.1,1.2)}
  org.apache.felix.scr.info  {version=1.0.0, imported-as=[1.0,1.1)}

This is just wrong. If you wrap a bundle and change its signature you **must** 
give it a new name because you fundamentally modify the public API. You do not 
own that other person's namespace! Just changing the micro/patch part of the 
version is just wrong. These kind of self inflicted wounds cause imho the most 
pain in software development.

That all said, it does make another case for the resolver. If I'd used that one 
I'd seen it immediately.

Kind regards,

Peter Kriens


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

Re: [osgi-dev] Removing queued events in Push Steams

[Peter Kriens via osgi-dev]

I probably would use a (static?) priority set with a weak reference to the 
event object. (Or some key that uniquely identifies that object). The processor 
can then consult this set to see if the event has higher priority. A weak 
reference is needed to make sure that no events remain in this priority set 
without locking.  

PK

> On 27 Feb 2019, at 12:49, Alain Picard via osgi-dev  
> wrote:
> 
> Anyone has any insight here?
> Alain
> 
> On Tue, Feb 5, 2019 at 1:28 PM Alain Picard  > wrote:
> Hi,
> 
> We have cases where we need to process events with different priorities, and 
> such priority can change after the initial event having been queued, but not 
> yet processed.
> 
> For example, when there is an event that some content has changed, we 
> subscribe to this event and based on some conditions this might trigger the 
> need to update some diagrams in our case. This is considered a "background 
> priority" event, since we simply want to get it updated when we have some 
> cycles so as not being stuck doing it whenever someone requests such diagram 
> to view/edit it.
> 
> We also have events when someone for example requests to open such a diagram, 
> where we need to determine if it is up to date, and if it needs to be 
> updated, to get this pushed and processed as quickly as possible, as the user 
> is waiting.
> 
> So far we have setup 2 different push streams to support this. 
> 
> The issue here is that while this is high-priority event comes in, we need to 
> make sure that we can cancel any similar queued events from the low priority 
> stream, and possibly let it proceed if it is already being processed.
> 
> What is the best approach here ? Are we on the right track to start with?
> 
> Thanks
> Alain
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Service component resolution time

[Peter Kriens via osgi-dev]

If your code sends its time in the resolver it generally means that the 
resolver has too much choice. This can happen that the same package is exported 
under different versions for example.

Certain configurations can turn pathological since the resolver is an NP 
complete problem. In my experience taking a good look at the package 
imports/exports and the service requirements tends to show that the resolver 
has too many choices to make.

Kind regards,

Peter Kriens





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



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

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

[Peter Kriens via osgi-dev]

The bnd code contains an AggregateRepository class that aggregates a number of 
repositories defined by the OSGi Repository standard. It is actually used in 
the bnd resolver API.

Kind regards,

Peter Kriens



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



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Logger at startup

[Peter Kriens via osgi-dev]

>> If you buffer you always have temporal inconsistency, no matter what.
> That I do not understand?
> I don't see what is hard to understand. The log record arrives at the 
> appender long after it was reported. Which you may not care too much about. 
> But sometimes it's a pain in the backside.  
But there is no guarantee when it arrives in the appender anyway? And as long 
as it is properly serialized what would the problem be?


>> The solution I like is DON'T buffer. 
> Then you have ordering problems.
> There's no ordering issue when logging is setup with the framework.
Nope, because you took care of it. It is still there lurking to bite you though 
:-)

>  The only way NOT to buffer is make sure the log service starts with an 
> appender immediately. That's what the "immediate" logging approach provides. 
> It puts the log service setup and configuration immediately at the framework 
> level so that no buffering is used or required.
> That is a good solution but it makes logging extremely 'special'. Agree this 
> is a very foundational service but losing the possibility to have appenders 
> in bundles is a pretty big thing.
> Logging IS special. We all know that and there's no use pretending, 
> otherwise, we WOULD have solved this long ago.
Yes, and I am special too ... :-) And so is every developer's bundle I've seen 
in my life ...

>> Logging is an infrastructure detail unlike any other. It really must be 
>> bootstrapped with the runtime as early as possible. It's not ideal to handle 
>> it at the module layer, so I propose not to (thought it still integrates 
>> nicely with any bundle based logging APIs as demonstrated in the Felix 
>> logback integration tests).
> The problem with this approach is that it is also true for configuration 
> admin, and DS, and event admin, etc. etc. They are all infrastructure and 
> they all have ordering issues. Going down your route is imho a slippery 
> slope. Before you know you're back to a completely static model. And maybe 
> that is not bad, I just prefer a solution where I can debug all day on the 
> same framework that is never restarted. I also dislike hybrids since they 
> tend to become quite complex to handle on other levels.
> There's nothing in the immediate model that prevents from debugging all day 
> without restarts, that's just hyperbole. Logback supports configuration file 
> updates (if you like), so you can tweak and flex those loggers/appenders any 
> way you like at runtime (if you like).
Yes, of course you can, don't expect anything else. But each of those actions 
requires _completely_ different handling than the unified OSGi solution to 
those problems ...

Don't get me wrong, I understand that you have to live in the existing mess of 
Java and life is tough there. I probably would do the same in your shoes. 
However, I think it would be a pity that out of pragmatism we forget that an 
insane amount of problems are caused by our strenuous desire for backward 
compatibility.

Kind regards,

Peter Kriens


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

Re: [osgi-dev] Logger at startup

[Peter Kriens via osgi-dev]

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

> If you buffer to little you _may_ lose records
> If you buffer you always have temporal inconsistency, no matter what.
That I do not understand?


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

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

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

Kind regards,

Peter Kriens
 

> 
> Sincerely,
> - Ray
>  
> 
> This issue, the problem of startup dependencies and configuration… Maybe 
> there is something missing in the spec in terms of some kind of "boot 
> service” that would handle these “common” problems. If the problems are so 
> common, then maybe it is a sign of a gap in the specs… Just a thought.
> 
> 
> Anyway, thanks!
> =David
> 
> 
> 
>> On Aug 27, 2018, at 22:19, Raymond Auge > <mailto:raymond.a...@liferay.com>> wrote:
>> 
>> There's setup details in the integration tests [1]
>> 
>> HTH
>> - Ray
>> 
>> [1] https://github.com/apache/felix/tree/trunk/logback/itests 
>> <https://github.com/apache/felix/tree/trunk/logback/itests>
>> 
>> On Mon, Aug 27, 2018 at 9:15 AM, Raymond Auge > <mailto:raymond.a...@liferay.com>> wrote:
>> My personal favourite is the Apache Felix Logback [1] integration which 
>> supports immediate logging when follow the correct steps. I feel it's the 
>> best logging solution available.
>> 
>> There are a couple of prerequisites as outlined in the documentation. But 
>> it's very simple to achieve your goal (NO BUFFERING OR MISSED LOG RECORDS)!
>> 
>> [1] 
>> http://felix.apache.org/documentation/subprojects/apache-felix-logback.html 
>> <http://felix.apache.org/documentation/subprojects/apache-felix-logback.html>
>> 
>> - Ray
>> 
>> On Mon, Aug 27, 2018 at 7:50 AM, BJ Hargrave via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> Equinox has the LogService implementation built into the framework, so it 
>> starts logging very early.
>>  
>> In the alternate, for framework related information, you can write your own 
>> launcher and it can add listeners for the framework event types.
>> --
>> 
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 17

Re: [osgi-dev] Logger at startup

[Peter Kriens via osgi-dev]

The v2Archive contains a logger that might fit your needs. It exports slf4j.api 
and has a custom implementation that records everything in a static queue (oh 
horror!) until the bundle is actually started. I.e. other bundles use the 
static slf4j API where the first will create the implementation. Since this is 
on class loading level you should get output from every slf4j logging bundle. 
(You won't get output from the Framework itself.)


https://github.com/osgi/v2archive.osgi.enroute/blob/master/osgi.enroute.logger.simple.provide
 
<https://github.com/osgi/v2archive.osgi.enroute/blob/master/osgi.enroute.logger.simple.provide>r


There are Gogo commands but I recall they had some issue.

Kind regards,

    Peter Kriens



> On 26 Aug 2018, at 21:05, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi!
> 
> I’m sure that this question has been asked before, but I did not successfully 
> find an answer anywhere. It applies to both R6 and R7 logging.
> 
> I would like to set up diagnostics so I can figure out what is happening 
> during system startup. however, by the time the logger starts, I have already 
> missed most of the messages that I needed to receive and there is no record 
> of the things I want to see. Another oddity is that even after the logger has 
> started, some messages are not getting logged. I can only assume that there 
> is some concurrency/dynamics issue at play.
> 
> In any case, other than using start levels, is there a way of ensuring that 
> the LogService (or Logger) is available when I need it?
> 
> 
> Thanks!
> =David
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Docker configuration via environment variables

[Peter Kriens via osgi-dev]

I think you get the point …

A simple macro processor is ~10k and would go a long way to address the far 
majority of the common requirements. And there is more than 6 years experience 
with the model already :-)

Kind regards,

Peter Kriens

> On 21 Aug 2018, at 12:09, Christian Schneider  wrote:
> 
> I agree this easily can cause ordering issues.
> In the best case these can cause components to be started with wrong 
> configuration first and with the correct one later. This can at least cause 
> some error messages but might also cause more serious issues.
> 
> For a cloud deployment were config is mainly static I hope we can provide a 
> solution that avoids restarts in most cases. Env variable substitution could 
> be a core feature of the configurator as it is very common.
> 
> Christian
> 
> 
> Am Di., 21. Aug. 2018 um 10:22 Uhr schrieb Peter Kriens via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>>:
>> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev > <mailto:osgi-dev@mail.osgi.org>> wrote:
>> Just another vote in favour of the ConfigurationPlugin model - you can use 
>> this to post-process configurations wherever they come from (meaning it 
>> isn’t tied to the Configurer or Configurator).
>> A configuration plugin that does this sort of work is easy to write, and if 
>> using DS could be done in a lot less than 100 LoC. It can also look at 
>> things other than environment variables if you want, and if/else logic is 
>> much easier to write/maintain in Java code than it is in macros in a JSON 
>> file!
> 
> It is only easier after you sold the ordering problem of the 
> 
> * Configurator, 
> * Configuration bundle, and 
> * Configuration plugin bundle … 
> 
> It also adds quite a bit of complexity by:
> 
> * Separating the rules from the actual configuration, and 
> * Adding extra bundles.
> 
> This additional complexity is only worth it if you can reuse the rules in 
> many different places. Hmm. Maybe a configuration plugin with a macro 
> processor? :-)
> 
>   Peter Kriens
> 
>> 
>> Best Regards,
>> 
>> Tim
>> 
>>> On 20 Aug 2018, at 17:08, Mark Hoffmann via osgi-dev 
>>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Carsten Ziegeler pointed us to the Configuration Plugin Services, that are 
>>> part of the ConfigurationAdmin specification. Together with the 
>>> Configurator specification, it could be possible to do that substitution in 
>>> such an plugin.
>>> Regards,
>>> 
>>> Mark
>>> 
>>> Am 20.08.2018 um 17:56 schrieb Christian Schneider via osgi-dev:
>>>> I think this would be a good extension to the configurator to also allow 
>>>> env variable replacement.
>>>> Actually I hoped it would already do this...
>>>> WDYT?
>>>> 
>>>> Christian
>>>> 
>>>> Am Mo., 20. Aug. 2018 um 17:05 Uhr schrieb Peter Kriens via osgi-dev 
>>>> mailto:osgi-dev@mail.osgi.org>>:
>>>> Are you using v2Archive enRoute or the new one?
>>>> 
>>>> The v2Archive OSGi enRoute has the simple Configurer (the predecessor of 
>>>> the OSGi R7 Configurator but with, according to some, a better name :-). 
>>>> It runs things through the macro processor you could therefore use 
>>>> environment variables to make the difference. 
>>>> 
>>>> E.g. ${env;XUZ} in the json files. Since it also supports ${if} you can 
>>>> eat your heart out! You can set environment variables in docker with -e in 
>>>> the command line when you start the container. You can also use @{ instead 
>>>> of ${ to not run afoul of the bnd processing that can happen at build 
>>>> time. I.e. the Configurer replaces all @{…} with ${…}.
>>>> 
>>>> If you are using the new R7 Configurator then you are on your own ...
>>>> 
>>>> Kind regards,
>>>> 
>>>> Peter Kriens
>>>> 
>>>> 
>>>> 
>>>> 
>>>> > On 18 Aug 2018, at 18:51, Randy Leonard via osgi-dev 
>>>> > mailto:osgi-dev@mail.osgi.org>> wrote:
>>>> > 
>>>> > To all:
>>>> > 
>>>> > We are at the point where we are deploying our OSGI enRoute applications 
>>>> > via Docker.
>>>> > 
>>>> > - A key sticking point is the syntax for embedding environment variables 
>>>> > within our configuration.json files.  
>>>&

Re: [osgi-dev] Docker configuration via environment variables

[Peter Kriens via osgi-dev]

> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev  
> wrote:
> Just another vote in favour of the ConfigurationPlugin model - you can use 
> this to post-process configurations wherever they come from (meaning it isn’t 
> tied to the Configurer or Configurator).
> A configuration plugin that does this sort of work is easy to write, and if 
> using DS could be done in a lot less than 100 LoC. It can also look at things 
> other than environment variables if you want, and if/else logic is much 
> easier to write/maintain in Java code than it is in macros in a JSON file!

It is only easier after you sold the ordering problem of the 

* Configurator, 
* Configuration bundle, and 
* Configuration plugin bundle … 

It also adds quite a bit of complexity by:

* Separating the rules from the actual configuration, and 
* Adding extra bundles.

This additional complexity is only worth it if you can reuse the rules in many 
different places. Hmm. Maybe a configuration plugin with a macro processor? :-)

Peter Kriens

> 
> Best Regards,
> 
> Tim
> 
>> On 20 Aug 2018, at 17:08, Mark Hoffmann via osgi-dev > <mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> Hi all,
>> 
>> Carsten Ziegeler pointed us to the Configuration Plugin Services, that are 
>> part of the ConfigurationAdmin specification. Together with the Configurator 
>> specification, it could be possible to do that substitution in such an 
>> plugin.
>> Regards,
>> 
>> Mark
>> 
>> Am 20.08.2018 um 17:56 schrieb Christian Schneider via osgi-dev:
>>> I think this would be a good extension to the configurator to also allow 
>>> env variable replacement.
>>> Actually I hoped it would already do this...
>>> WDYT?
>>> 
>>> Christian
>>> 
>>> Am Mo., 20. Aug. 2018 um 17:05 Uhr schrieb Peter Kriens via osgi-dev 
>>> mailto:osgi-dev@mail.osgi.org>>:
>>> Are you using v2Archive enRoute or the new one?
>>> 
>>> The v2Archive OSGi enRoute has the simple Configurer (the predecessor of 
>>> the OSGi R7 Configurator but with, according to some, a better name :-). It 
>>> runs things through the macro processor you could therefore use environment 
>>> variables to make the difference. 
>>> 
>>> E.g. ${env;XUZ} in the json files. Since it also supports ${if} you can eat 
>>> your heart out! You can set environment variables in docker with -e in the 
>>> command line when you start the container. You can also use @{ instead of 
>>> ${ to not run afoul of the bnd processing that can happen at build time. 
>>> I.e. the Configurer replaces all @{…} with ${…}.
>>> 
>>> If you are using the new R7 Configurator then you are on your own ...
>>> 
>>> Kind regards,
>>> 
>>> Peter Kriens
>>> 
>>> 
>>> 
>>> 
>>> > On 18 Aug 2018, at 18:51, Randy Leonard via osgi-dev 
>>> > mailto:osgi-dev@mail.osgi.org>> wrote:
>>> > 
>>> > To all:
>>> > 
>>> > We are at the point where we are deploying our OSGI enRoute applications 
>>> > via Docker.
>>> > 
>>> > - A key sticking point is the syntax for embedding environment variables 
>>> > within our configuration.json files.  
>>> > - For example, a developer would set a hostName to ‘localhost’ for 
>>> > development, but this same environment variable would be different for 
>>> > QA, UAT, and Production environments
>>> > - I presume this is the best way of allowing the same container to be 
>>> > deployed in different environments without modification?
>>> > - Suggestions and/or examples are appreciated.
>>> > 
>>> > 
>>> > 
>>> > Thanks,
>>> > Randy Leonard
>>> > 
>>> > ___
>>> > OSGi Developer Mail List
>>> > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> > https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>> 
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>> 
>>> -- 
>>> -- 
>>> Christian Schneider
>>> http://www.liq

Re: [osgi-dev] Docker configuration via environment variables

[Peter Kriens via osgi-dev]

Are you using v2Archive enRoute or the new one?

The v2Archive OSGi enRoute has the simple Configurer (the predecessor of the 
OSGi R7 Configurator but with, according to some, a better name :-). It runs 
things through the macro processor you could therefore use environment 
variables to make the difference. 

E.g. ${env;XUZ} in the json files. Since it also supports ${if} you can eat 
your heart out! You can set environment variables in docker with -e in the 
command line when you start the container. You can also use @{ instead of ${ to 
not run afoul of the bnd processing that can happen at build time. I.e. the 
Configurer replaces all @{…} with ${…}.

If you are using the new R7 Configurator then you are on your own ...

Kind regards,

Peter Kriens




> On 18 Aug 2018, at 18:51, Randy Leonard via osgi-dev  
> wrote:
> 
> To all:
> 
> We are at the point where we are deploying our OSGI enRoute applications via 
> Docker.
> 
> - A key sticking point is the syntax for embedding environment variables 
> within our configuration.json files.  
> - For example, a developer would set a hostName to ‘localhost’ for 
> development, but this same environment variable would be different for QA, 
> UAT, and Production environments
> - I presume this is the best way of allowing the same container to be 
> deployed in different environments without modification?
> - Suggestions and/or examples are appreciated.
> 
> 
> 
> Thanks,
> Randy Leonard
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Question about consistency and visibility

[Peter Kriens via osgi-dev]

Your understanding is correct with respect to the _service_. DS guarantees that 
activate is called before the service is registered and thus available to 
others.  The service is unregistered before you deactivate is called. Nulling 
fields is generally unnecessary unless you want to ensure an NPE if an object 
uses your service after unregistering.

Kind regards,

Peter Kriens

> On 14 Aug 2018, at 05:20, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi!
> 
> In a concurrent system, if a class is immutable, the problem is simplified 
> and the class can be used without fear by multiple threads because (i) it’s 
> state does not change, and (2) it’s state is guaranteed to be visible;
> 
> Example:
> 
> /**
>  * The class is immutable because the fields are both immutable types
>  * and are "private + final”. The fields are guaranteed to be visible
>  * to all threads after construction. In other words, there is a
>  * “happens-before” constraint on the fields.
>  */
> public class SimpleImmutableClass {
> private final String value1;
> private final int value2;
> 
> public SimpleImmutableClass( String aString, int anInt ) {
> value1 = aString;
> value2 = anInt;
> }
> 
> public String getValue1() {
> return value1;
> }
> 
> public int getvalue2() {
> return value2;
> }
> }
> 
> My understanding is that DS will provide the same happens-before constraint 
> to the fields in the following service, so presuming that there is no method 
> exposed to change the field values, the service is effectively immutable and 
> can be used without fear in a concurrent context. So in the following, value1 
> and value2 are guaranteed to be visible to all threads thanks to the 
> happens-before constraint placed on the fields during activation:
> 
> /**
>  * The LogService is basically just added to show that the component is used
>  * in a static way, as only a static component can be effectively immutable.
>  */
> @Component
> public class EffectivelyImmutableService {
> private String value1;
> private int value2;
> 
> @Reference private LogService logger;
> 
> @Activate
> void activate( Map properties ) {
> value1 = (String)properties.get( "value1" );
> value2 = (int)properties.get( "value2" );
> }
> 
> /**
>  * H, but if an instance is never reused, then wouldn't it be 
> completely
>  * unnecessary to deactivate()??
>  */
> void deactivate() {
> value1 = null;
> value2 = -1;
> }
> 
> public String getValue1() {
> logger.log( LogService.LOG_INFO, String.format( "Value of String is 
> %s", value1 ) );
> return value1;
> }
> 
> public int getvalue2() {
> logger.log( LogService.LOG_INFO, String.format( "Value of int is %s", 
> value2 ) );
> return value2;
> }
> }
> 
> 
> Is somebody able to confirm my understanding?
> 
> Thanks!!
> =David
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Felix resolver takes forever to resolve dependencies

[Peter Kriens via osgi-dev]

This is a Felix issue :-( 

* Did you find the -runbundles with the Bndtools resolver? How long did that 
take?
* Did you upgrade to the latest Felix?
* Did you try an older version?
* Did you try Equinox?

You might want to post it on the Apache Felix list. They probably have some 
secret system properties you can set to get more diagnostic info.

Sorry I can't help you more … 

Kind regards,

Peter Kriens




> On 2 Aug 2018, at 16:41, Nhut Thai Le via osgi-dev  
> wrote:
> 
> Hello,
> 
> We are trying to integrate Keycloak admin-client and zk into our web app 
> running on felix using bndtool.
> 
> If we use our web app with Keycloak admin-client alone, it's fine.
> 
> If we use our web app with zk alone, it's also fine.
> 
> When adding both Keycloak admin-client and zk, we are not able to start the 
> container from bndrun. Looks like the framework resolver get stuck in 
> resolving dependencies. Here is the stack of the main thread:
> Thread [main] (Suspended) 
>   waiting for: AtomicInteger  (id=29) 
>   Object.wait(long) line: not available [native method]   
>   AtomicInteger(Object).wait() line: 502  
>   ResolverImpl$EnhancedExecutor.await() line: 2523
>   ResolverImpl.calculatePackageSpaces(ResolveSession, Candidates, 
> Collection) line: 1217
>   ResolverImpl.checkConsistency(ResolveSession, Candidates, 
> Map) line: 572  
>   ResolverImpl.findValidCandidates(ResolveSession, 
> Map) line: 532   
>   ResolverImpl.doResolve(ResolveSession) line: 395
>   ResolverImpl.resolve(ResolveContext, Executor) line: 377
>   ResolverImpl.resolve(ResolveContext) line: 331  
>   StatefulResolver.resolve(Set, Set) 
> line: 478
>   Felix.resolveBundles(Collection) line: 4108 
>   FrameworkWiringImpl.resolveBundles(Collection) line: 133
>   PackageAdminImpl.resolveBundles(Bundle[]) line: 267 
>   Launcher.startBundles(List) line: 489   
>   Launcher.activate() line: 423   
>   Launcher.run(String[]) line: 301
>   Launcher.main(String[]) line: 147   
> 
> A small note here is that Keycloak admin-client uses resteasy which is not an 
> osgi bundle so I wrap both admin-client, resteasy and its dependencies in an 
> osgi bundle and enabling service loader mediator header so that the service 
> files provided in the resteasy dependencies can be loaded.
> 
> For debugging I downloaded the source of org.apache.felix.framework but it 
> has no resolver/RersolverImpl class
> 
> I'm not sure what to do to debug this.
> 
> Thai
> 
> 
> ___
> 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] Life-cycle race condition

[Peter Kriens via osgi-dev]

Yup, it got a bit windy ;-) I put it on my website as a blog since I've no good 
other place at the moment.

http://aqute.biz/2018/08/02/the-service-window.html 
<http://aqute.biz/2018/08/02/the-service-window.html>

Let me know if things are unclear. Kind regards,

    Peter Kriens


> On 2 Aug 2018, at 11:58, David Leangen via osgi-dev  
> wrote:
> 
> 
> Wow! That is a lot to digest.
> 
> I’ll need to get back to you in a few days/weeks/months/years. :-D
> 
> Thanks so much!!
> 
> 
> Cheers,
> =David
> 
> 
> 
> 
>> On Aug 2, 2018, at 18:38, Peter Kriens > <mailto:peter.kri...@aqute.biz>> wrote:
>> 
>> 
>> ## Keep Passing the Open Windows
>> 
>> You did read the classic [v2Archive OSGi enRoute App note][5] about this 
>> topic? It has been archived by the OSGi to [v2Archive OSGi enRoute web 
>> site][3]. It handles a lot of similar cases. There is an accompanying 
>> workspace [v2Archive OSGi enRoute osgi.enroute.examples.concurrency 
>> <https://github.com/osgi/osgi.enroute.examples.concurrency>][7]
>> 
>> Anyway, I am not sure if you want to solve this pragmatic or pure?
>> 
>> ## Pragmatic 
>> 
>> Pragmatic means there is a tiny chance you hit the window where you check if 
>> the MyService is unregistered and then use it. If you're really unlucky you 
>> just hit the unregistration after you checked it but before you can use it. 
>> It works when the unregistration of MyService is rare and the work is long. 
>> Yes, it can fail but so can anything so you should be prepared for it. 
>> 
>> Pragmatic works best as follows:
>> 
>>@Component
>>public class MyClass extends Thread {   
>>   @Reference MyService myService;
>>
>>   @Activate void activate()  { start(); }
>>   @Deactivate void deactivate()  { interrupt(); }
>>
>>   public void run() {
>>  while (!isInterrupted()) {
>> try {
>> MyResult result = doHardWork();
>> if (!isInterrupted())
>> myService.setResult(result);
>> } catch (Exception e) { /* TODO */ }
>>  }
>>   }
>>}
>> 
>> Clearly there is a race condition. 
>> 
>> 
>> 
>> 
>> ## Pure 
>> 
>> I once had a use case where we had whiteboard listeners that received 
>> events. The frequency and some not so good event listeners that took too 
>> much time in their callback. This created a quite long window where it could 
>> fail so it often did. For that use case I created a special highly optimized 
>> class that could delay the removal of the listener while it was being 
>> dispatched. To make it have absolutely minimal overhead was tricky, I even 
>> made an Alloy model of it that found some design errors. Anyway, sometimes 
>> you have pick one of the bad sides, this was one where delaying the 
>> deactivate was worth it.
>> 
>> So how would you make this 'purer' by delaying the deactivation until you 
>> stopped using it? Since the service is still supposed to be valid during 
>> deactivate we could make the setResult() and the deactivate() methods 
>> exclude each other. That is, we need to make sure that no interrupt can 
>> happen when we check for the isInterrupted() and call myService.setResult(). 
>> We could use heavy locks but synchronized works fine for me when you realize 
>> some of its caveats:
>> 
>> * Short blocks
>> * Ensure you cannot create deadlocks
>> 
>> So there must be an explicit contract that the MyService is not going to 
>> stay away for a long time nor call lots of other unknown code that could 
>> cause deadlocks. After all, we're blocking the deactivate() method which is 
>> very bad practice in general. So you will trade off one purity for another.
>> 
>>@Component
>>public class MyClass extends Thread {   
>>   @Reference MyService myService;
>>
>>   @Activate void activate()  { start(); }
>>   @Deactivate synchronized void deactivate() { interrupt(); }
>>
>>   public void run() {
>>  while (!isInterrupted()) {
>> try {
>> MyResult result = doHardWork();
>>  synchronized(this) {
>> if (!isInterrupted()) {
>> myService.setResult(result);
>>  }
>>  }
>> } catch (Exception e) { /* TODO */ }
>>  

Re: [osgi-dev] Life-cycle race condition

[Peter Kriens via osgi-dev]

rdWork );
myService.setResult( result );
  }
   }

This is an example where you see a very weird effect that I first noticed in 
the eighties during my first big OO design. At first you think the problem is 
now moved from MyClass to MyService? I think when you try to implement this 
that you find that the problem mostly _disappeared_. During one of the first 
large systems I designed I kept feeling we were kicking the hard problems down 
the road and we still run into a brick wall. However, one day we realized we 
were done. For some reason the hard problems were solved in the structure of 
the application and not in specific code. Weird. However, realizing this I 
often have to cry a bit when I realize how some designs are doing the opposite 
and make simple things complex :-(

## Multiple Results

If you have multiple results to deliver you might want to take a look at the 
[OSGi PushStream][1]. When I made the initial design for ASyncStreams (feels 
eons ago :-( ) that inspired the OSGi Push Stream specification  this was one 
of the use cases I had in mind. The Push Stream are intended to handle all the 
nasty cases and shield you from them. As a bonus, it actually works for 
multiple receivers as well. Push Streams provide a simple low cost backlink to 
handle the case where the MyService gets closed. Haven't looked at where Push 
Stream's ended up but as far as I know they should still be useful when your 
hard work delivers multiple results. Ah well, I wanted to take a look at it 
anyway since it has been released now. Let's see how that would look like:

@Component
public class ProviderImpl extends Thread {

@Reference PushStreamProvider   psp;
@Reference MyServicemyService;

volatile SimplePushEventSourcedispatcher;

@Activate void activate() throws Exception {
dispatcher = 
psp.createSimpleEventSource(MyResult.class);
myService.setResult(dispatcher);
start();
}

@Deactivate void deactivate() {
interrupt();
}

@Override
public void run() {
try {
MyResult r = doHardWork();
while (!isInterrupted()) {
dispatcher.publish(r);
r = doHardWork();
}
} finally {
dispatcher.close();
}
}
}

## Use of Executors

As a side note. I've been in systems where everybody was mucking around with 
ExecutorServices and it became a mess. In [v2Archive OSGi enRoute][3] I always 
provided an [Executor service][4] that is shared and does proper cleanup when 
the service getter goes away. (The [v2Archive OSGi enRoute Scheduler][6] was 
also very nice for this since it provides Cancelable Promises.) Executor 
Services created statically are horror in OSGi since they are completely 
oblivious of the OSGi dynamics. And in your case they are totally unnecessary. 
The only utility they provide to you is that they interrupt the threads. This 
is trivial to do when you create your own thread. (And messages about the 
expensiveness of threads are highly exaggerated.) Even if you use an Executor 
you can pass the thread.

Deferred deferred = new Deferred<>();   
Promise promiseFactory.submit( () -> {
deferred.resolve( Thread.currentThread() );

while ( result == null && !Thread 
<http://thread.is/>.currentThread().isInterrupted() {
… do some hard work
}
return result;
});

// deactivate
deferred.getPromise().getValue().interrupt();

In general, if you go this route, suggest you clearly separate the strategies 
from the code. I.e. make a separate class to capture the strategy of handling 
these things. Worst designs are where these are mixed.

## Disclaimer

I guess this became a tad long, I guess I will turn it into a blog.
 
Anyway, usually disclaimer: none of the code has been tested so use it at your 
own peril!

Good luck, kind regards,

Peter Kriens

[1]: https://osgi.org/specification/osgi.cmpn/7.0.0/util.pushstream.html 
<https://osgi.org/specification/osgi.cmpn/7.0.0/util.pushstream.html>
[2]: 
http://www.plantuml.com/plantuml/png/RP2n2i8m48RtF4NST6WVe4Cj24M7Ka71EII71jjKxYwLlhsXMXghO-w3Z-zFGQoGVTk8QZW1zbQ3J79PNcGc4QwM6524LxXLmwvHH07epX6Zr_mcCo1WsKwU9LIQRQyOn7GAplCDGPa0nmoHfgdud69ekhr2y-pm_ezQEZW6HFzWCDlHyRl5ksXDN6LWsPNaiteIhpUBjk_D2EGRZeVD1PayrdMv4WKu4_xv1G00
 
<http://www.plantuml.com/plantuml/png/RP2n2i8m48RtF4NST6W

Re: [osgi-dev] Dealing with bouncing

[Peter Kriens via osgi-dev]

Ok … on the top of my head …


public interface Bar {
void m1();
void m2();
}

@Component 
public class BarImpl implements Bar {
Deferred   delegate = new Deferred<>();

@Reference
void setExec( Executor e ) {
delegate.resolve( new BarImpl2(e) );
}


public void m1() {
delegate.getPromise().m1();
}   

public void m2() {
delegate.getPromise().m2();
}   
}

This works for you?

Kind regards,

    Peter Kriens



> On 22 Jul 2018, at 22:51, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi Peter,
> 
> Thanks for the tip.
> 
> I’m not quite getting it. Would you be able to direct me to an example?
> 
> Thanks!
> =David
> 
> 
> 
>> On Jul 22, 2018, at 21:49, Peter Kriens  wrote:
>> 
>> In some cases (when the extra complexity was warranted) I let the component 
>> class act as a proxy to a delegate. I then get the delegate from a  Promise. 
>> So you just forward every method in your service interface to the delegate. 
>> There is a function in Eclipse that will create the delegation methods.
>> 
>> In general you want to afford this complexity and for example use a simple 
>> init() method that blocks until init is done. However, the delegate has some 
>> nice qualities if you switch more often than just at init.
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>>> On 22 Jul 2018, at 10:35, David Leangen via osgi-dev 
>>>  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> This may be more of a basic Java question, but I’ll ask it anyway because 
>>> it relates to “bouncing” and the handling of dynamic behavior.
>>> 
>>> In my @Activate method, I configure my component. Since the configuration 
>>> may be long-running (data is retrieved remotely), I use a Promise. But, the 
>>> component is available before it is actually “ready”. So far, this has not 
>>> been a problem.
>>> 
>>> It looks something like this:
>>> 
>>> @Reference private Store dataStore;
>>> 
>>> @Activate
>>> void activate() {
>>> configure(dataStore);
>>> }
>>> 
>>> void configure(Store withDataStore) {
>>> // Configuration is set up via a Promise, using a data store to retrieve 
>>> the data
>>> }
>>> 
>>> However, because there is some bouncing occurring, I think what is 
>>> happening is that configure() starts running in a different thread, but in 
>>> the meantime the reference to the dataStore is changed. The error log shows 
>>> that the data store is in an impossible state. After following a hunch, I 
>>> could confirm that the configureData process is running on a data store 
>>> service that was deactivated during bouncing.
>>> 
>>> What would be a good (and simple) strategy to handle this type of 
>>> long-running configuration, where the configuration is in a different 
>>> thread and depends on services that may come and go?
>>> 
>>> 
>>> Note: in the end, the component gets configured and the application runs, 
>>> but I would still like to be able to handle this situation properly.
>>> 
>>> 
>>> Thanks!
>>> =David
>>> 
>>> 
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Dealing with bouncing

[Peter Kriens via osgi-dev]

In some cases (when the extra complexity was warranted) I let the component 
class act as a proxy to a delegate. I then get the delegate from a  Promise. So 
you just forward every method in your service interface to the delegate. There 
is a function in Eclipse that will create the delegation methods.

In general you want to afford this complexity and for example use a simple 
init() method that blocks until init is done. However, the delegate has some 
nice qualities if you switch more often than just at init.

Kind regards,

Peter Kriens

> On 22 Jul 2018, at 10:35, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi,
> 
> This may be more of a basic Java question, but I’ll ask it anyway because it 
> relates to “bouncing” and the handling of dynamic behavior.
> 
> In my @Activate method, I configure my component. Since the configuration may 
> be long-running (data is retrieved remotely), I use a Promise. But, the 
> component is available before it is actually “ready”. So far, this has not 
> been a problem.
> 
> It looks something like this:
> 
> @Reference private Store dataStore;
> 
> @Activate
> void activate() {
>  configure(dataStore);
> }
> 
> void configure(Store withDataStore) {
>  // Configuration is set up via a Promise, using a data store to retrieve the 
> data
> }
> 
> However, because there is some bouncing occurring, I think what is happening 
> is that configure() starts running in a different thread, but in the meantime 
> the reference to the dataStore is changed. The error log shows that the data 
> store is in an impossible state. After following a hunch, I could confirm 
> that the configureData process is running on a data store service that was 
> deactivated during bouncing.
> 
> What would be a good (and simple) strategy to handle this type of 
> long-running configuration, where the configuration is in a different thread 
> and depends on services that may come and go?
> 
> 
> Note: in the end, the component gets configured and the application runs, but 
> I would still like to be able to handle this situation properly.
> 
> 
> Thanks!
> =David
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Service binding order

[Peter Kriens via osgi-dev]

A really elegant solution to these problems is to use a Promise …

1) Create a Deferrred
2) Execute your item code through the promise of the deferred
3) When the Executor reference is set, you resolve the deferred


@Component
public class Foo {
Deferred  deferred = new Deferred<>();

@Reference
void setExecutor( Executor e) { deferred.resolve(e); }

@Reference( multiple/dynmaic) 
void addItem( Item item) {
deferred.getPromise().thenAccept ( executor -> … )
}
}

This will automatically process your items after the executor is set. It think 
it also easily extends to multiple dependencies but would have to puzzle a bit. 
If you’re unfamiliar with Promises, I’ve written an app note, ehh blog, 
recently about 1.1 Promises  http://aqute.biz/2018/06/28/Promises.html 
<http://aqute.biz/2018/06/28/Promises.html>. They really shine in these 
ordering issues.

Kind regards,

    Peter Kriens



> On 18 Jul 2018, at 00:16, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi!
> 
> I have a component that acts a bit like a whiteboard provider. It looks 
> something like this:
> 
> public class MyWhiteboard
> {
>  boolean isActive;
> 
>  @Reference MyExecutor executor; // Required service to execute on an Item
> 
>  @Reference(multiple/dynamic)
>  void bindItem( Item item )
>  {
>if (isActivated)
>  // add the Item
>else
>  // Store the item to be added once this component is activated
>  }
> 
>  void unbindItem( Item item )
>  {
>// Remove the item
>  }
> 
>  @Activate
>  void activate()
>  {
>// execute non-processed Items
>isActivate = true;
>  }
> }
> 
> The MyExecutor must be present before an Item can be processed, but there is 
> no guarantee as to the binding order. All I can think of doing is ensuring 
> that the Component is Activated before processing.
> 
> My question is: is there a more elegant / simpler / less error prone way of 
> accomplishing this?
> 
> 
> Thanks!
> =David
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Functions as configuration

[Peter Kriens via osgi-dev]

> On 16 Jul 2018, at 22:47, David Leangen via osgi-dev  
> wrote:
> Thanks Peter.
> Could you please expand on what you mean by this?
>> Notice that you can easily share (non managed service) configurations 
>> between components.
You can get the configuration from different PIDs in your component. The 
`configurationPid` method in the @Component annotation takes multiple 
arguments. I recall that the first is a factory pid, the others are normal 
managed service pids. (Only 1 pid can control the life cycle.)

This allows you to create shared configuration between different components.

You probably need to read up on the spec about the details …

Kind regards,

Peter Kriens

> Also, thanks a lot for this:
>> BTW, I updated the v2archive.osgi.enroute to build again. So the snapshots 
>> are also available now again. I tried to release this version but I did not 
>> have authority. Will try to get that.



> 
> 
> Cheers,
> =David
> 
> 
>> On Jul 16, 2018, at 16:07, Peter Kriens > <mailto:peter.kri...@aqute.biz>> wrote:
>> 
>> Just be careful with these things. I call it the C++ effect. You get really 
>> thrilled about all the things you could do and how easy life is when you got 
>> that function. Then after a few years when you have it you see that the 
>> complexity went to your lambdas. I did that a lot in C++ from there the name 
>> :-)
>> 
>> In my experience you want your configuration to be simple and any processing 
>> should be done by the component. Notice that you can easily share (non 
>> managed service) configurations between components.
>> 
>> BTW, I updated the v2archive.osgi.enroute to build again. So the snapshots 
>> are also available now again. I tried to release this version but I did not 
>> have authority. Will try to get that.
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>>> On 16 Jul 2018, at 03:09, David Leangen via osgi-dev 
>>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>> 
>>> 
>>> Thanks, Peter. That could actually be useful in some cases.
>>> 
>>> I guess what I’m really looking for right now though is a way to inject a 
>>> lambda function.
>>> 
>>> I suppose what I could do it have a 2-step configuration: the first step 
>>> would have constant configuration values being read as per usual via the 
>>> Configurator, and my lambdas provided from a Java class (or perhaps parsed 
>>> from a configuration file if I can find a way to do that). Then for the 
>>> second step the two could be combined, put into a Dictionary, and the 
>>> actual service would be instantiated based on the combined constant+lambda 
>>> configuration.
>>> 
>>> I would ideally like to keep the constants and the lambdas together in a 
>>> configuration file, but maybe that is just not possible right now.
>>> 
>>> In any case, this sounds very frameworky to me, so I was hoping that 
>>> something like this already exists…
>>> 
>>> 
>>> Cheers,
>>> =David
>>> 
>>> 
>>> 
>>>> On Jul 15, 2018, at 1:01, Peter Kriens >>> <mailto:peter.kri...@aqute.biz>> wrote:
>>>> 
>>>> The v2Archive OSGi enRoute has a Configurer that uses a subset of the bnd 
>>>> Macro language. This supports ${system;..} and ${system_allow_fail}. These 
>>>> take shell command lines.
>>>> 
>>>> P
>>>> 
>>>> 
>>>> 
>>>>> On 14 Jul 2018, at 09:07, David Leangen via osgi-dev 
>>>>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>>>> 
>>>>> 
>>>>> Thanks, BJ.
>>>>> 
>>>>> Yeah, right now I am using a Dictionary exactly how you mentioned, but I 
>>>>> am wondering if there is a way to maintain it the same way I do as for my 
>>>>> configurations.
>>>>> 
>>>>> Has there ever been a discussion about possibly including this type of 
>>>>> thing in the spec? For instance, a spec could include a script (saved in 
>>>>> a configuration file), and the script could be parsed and included in a 
>>>>> Configuration.
>>>>> 
>>>>> Has nobody ever encountered this use case? If you have, how did you solve 
>>>>> it?
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> =David
>>>>> 
>>>>> 
>>>>>> On Jul 14, 2018, a

Re: [osgi-dev] Functions as configuration

[Peter Kriens via osgi-dev]

Just be careful with these things. I call it the C++ effect. You get really 
thrilled about all the things you could do and how easy life is when you got 
that function. Then after a few years when you have it you see that the 
complexity went to your lambdas. I did that a lot in C++ from there the name :-)

In my experience you want your configuration to be simple and any processing 
should be done by the component. Notice that you can easily share (non managed 
service) configurations between components.

BTW, I updated the v2archive.osgi.enroute to build again. So the snapshots are 
also available now again. I tried to release this version but I did not have 
authority. Will try to get that.

Kind regards,

Peter Kriens

> On 16 Jul 2018, at 03:09, David Leangen via osgi-dev  
> wrote:
> 
> 
> Thanks, Peter. That could actually be useful in some cases.
> 
> I guess what I’m really looking for right now though is a way to inject a 
> lambda function.
> 
> I suppose what I could do it have a 2-step configuration: the first step 
> would have constant configuration values being read as per usual via the 
> Configurator, and my lambdas provided from a Java class (or perhaps parsed 
> from a configuration file if I can find a way to do that). Then for the 
> second step the two could be combined, put into a Dictionary, and the actual 
> service would be instantiated based on the combined constant+lambda 
> configuration.
> 
> I would ideally like to keep the constants and the lambdas together in a 
> configuration file, but maybe that is just not possible right now.
> 
> In any case, this sounds very frameworky to me, so I was hoping that 
> something like this already exists…
> 
> 
> Cheers,
> =David
> 
> 
> 
>> On Jul 15, 2018, at 1:01, Peter Kriens > <mailto:peter.kri...@aqute.biz>> wrote:
>> 
>> The v2Archive OSGi enRoute has a Configurer that uses a subset of the bnd 
>> Macro language. This supports ${system;..} and ${system_allow_fail}. These 
>> take shell command lines.
>> 
>> P
>> 
>> 
>> 
>>> On 14 Jul 2018, at 09:07, David Leangen via osgi-dev 
>>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>> 
>>> 
>>> Thanks, BJ.
>>> 
>>> Yeah, right now I am using a Dictionary exactly how you mentioned, but I am 
>>> wondering if there is a way to maintain it the same way I do as for my 
>>> configurations.
>>> 
>>> Has there ever been a discussion about possibly including this type of 
>>> thing in the spec? For instance, a spec could include a script (saved in a 
>>> configuration file), and the script could be parsed and included in a 
>>> Configuration.
>>> 
>>> Has nobody ever encountered this use case? If you have, how did you solve 
>>> it?
>>> 
>>> 
>>> Cheers,
>>> =David
>>> 
>>> 
>>>> On Jul 14, 2018, at 5:04, BJ Hargrave >>> <mailto:hargr...@us.ibm.com>> wrote:
>>>> 
>>>> Component properties are basically service properties which are basically 
>>>> meant to be things that can go in a Configuration: 
>>>> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3217016
>>>>  
>>>> <https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3217016>.
>>>>  Complex objects including objects implementing functional interfaces are 
>>>> not in scope for a Configuration.
>>>>  
>>>> That said, I imagine you could pass any value object in the Dictionary 
>>>> supplied to ComponentFactory.newInstance since they are not stored in 
>>>> Configuration Admin and SCR would not police the value object types :-)
>>>> --
>>>> 
>>>> BJ Hargrave
>>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>>>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>>>> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>
>>>>  
>>>>  
>>>> - Original message -
>>>> From: David Leangen via osgi-dev >>> <mailto:osgi-dev@mail.osgi.org>>
>>>> Sent by: osgi-dev-boun...@mail.osgi.org 
>>>> <mailto:osgi-dev-boun...@mail.osgi.org>
>>>> To: David Leangen via osgi-dev >>> <mailto:osgi-dev@mail.osgi.org>>
>>>> Cc:
>>>> Subject: [osgi-dev] Functions as configuration
>>>> Date: Fri, Jul 13, 2018 3:32 PM
>>>>  
>>>> Hi!
>>>> 
>>>> Is there any way to i

Re: [osgi-dev] Functions as configuration

[Peter Kriens via osgi-dev]

The v2Archive OSGi enRoute has a Configurer that uses a subset of the bnd Macro 
language. This supports ${system;..} and ${system_allow_fail}. These take shell 
command lines.

P



> On 14 Jul 2018, at 09:07, David Leangen via osgi-dev  
> wrote:
> 
> 
> Thanks, BJ.
> 
> Yeah, right now I am using a Dictionary exactly how you mentioned, but I am 
> wondering if there is a way to maintain it the same way I do as for my 
> configurations.
> 
> Has there ever been a discussion about possibly including this type of thing 
> in the spec? For instance, a spec could include a script (saved in a 
> configuration file), and the script could be parsed and included in a 
> Configuration.
> 
> Has nobody ever encountered this use case? If you have, how did you solve it?
> 
> 
> Cheers,
> =David
> 
> 
>> On Jul 14, 2018, at 5:04, BJ Hargrave > > wrote:
>> 
>> Component properties are basically service properties which are basically 
>> meant to be things that can go in a Configuration: 
>> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3217016
>>  
>> .
>>  Complex objects including objects implementing functional interfaces are 
>> not in scope for a Configuration.
>>  
>> That said, I imagine you could pass any value object in the Dictionary 
>> supplied to ComponentFactory.newInstance since they are not stored in 
>> Configuration Admin and SCR would not police the value object types :-)
>> --
>> 
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com 
>>  
>>  
>> - Original message -
>> From: David Leangen via osgi-dev > >
>> Sent by: osgi-dev-boun...@mail.osgi.org 
>> 
>> To: David Leangen via osgi-dev > >
>> Cc:
>> Subject: [osgi-dev] Functions as configuration
>> Date: Fri, Jul 13, 2018 3:32 PM
>>  
>> Hi!
>> 
>> Is there any way to include functions as part of a component configuration?
>> 
>> 
>> Cheers,
>> =David
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org 
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> 
>>  
>>  
>> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Double config

[Peter Kriens via osgi-dev]

Well, OSGi has a tendency to punish short cuts. In the long run this is very 
valuable, I’ve seen too many software disasters to sleep well at night. 
However, for a developer behind his screen and a looming deadline the long term 
goals are unfortunately not so urgent :-(

Kind regards,

Peter Kriens



> On 12 Jul 2018, at 13:38, David Leangen via osgi-dev  
> wrote:
> 
> 
> As always, thank you VERY much to all of you for your great suggestions. I 
> will look into this from tomorrow. I didn’t know the concept of “bouncing”. 
> That is interesting. Now that I am aware, I will give more thought to it.
> 
> One thing I have seen stated before on this list is that OSGi is indeed 
> complex, but it is not accidental complexity. It is simply making complexity 
> explicit, and providing the tools to work with complexity. I completely agree 
> with this statement.
> 
> I am still learning all the time, and am always amazed that there is still so 
> much deeper to go. Thanks for helping me along this journey.
> 
> 
> Cheers,
> =David
> 
> 
> 
>> On Jul 12, 2018, at 17:42, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> If it is a bouncing problem, than you could also try to configure the 
>> behavior using the property
>>  
>> ds.delayed.keepInstances=true
>> 
>> From the Apache Felix documentation:
>>  
>> Whether or not to keep instances of delayed components once they are not 
>> referred to any more. The Declarative Services specifications suggests that 
>> instances of delayed components are disposed off if there is not used any 
>> longer. Setting this flag causes the components to not be disposed off and 
>> thus prevent them from being constantly recreated if often used. Examples of 
>> such components may be EventHandler services. The default is to dispose off 
>> unused components. See FELIX-3039 
>> <https://issues.apache.org/jira/browse/FELIX-3039> for details.
>>  
>> http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html
>>  
>> <http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html>
>>  
>> Equinox DS had this set by default, while the default in Felix SCR is false. 
>> With the usage of Felix SCR in Eclipse we needed to explicitly set this 
>> parameter to true so the previous behavior persists.
>>  
>> Mit freundlichen Grüßen / Best regards 
>> 
>> Dirk Fauth
>> 
>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
>> www.bosch.com <http://www.bosch.com/> 
>> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com 
>> <mailto:dirk.fa...@de.bosch.com> 
>> 
>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
>> Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, Dr. 
>> Stefan Hartung, Dr. Markus Heyn,
>> Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller 
>> 
>> 
>> Von: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org> 
>> [mailto:osgi-dev-boun...@mail.osgi.org 
>> <mailto:osgi-dev-boun...@mail.osgi.org>] Im Auftrag von Tim Ward via osgi-dev
>> Gesendet: Donnerstag, 12. Juli 2018 10:22
>> An: Peter Kriens mailto:peter.kri...@aqute.biz>>; 
>> OSGi Developer Mail List > <mailto:osgi-dev@mail.osgi.org>>
>> Betreff: Re: [osgi-dev] Double config
>>  
>> Hi David,
>> 
>> 
>> This is a gift! :-) It means your code is not handling the dynamics 
>> correctly and now you know it! 
>>  
>> I’m not sure that there’s quite enough evidence to come to this conclusion. 
>> It could simply be that everything is working fine with a static policy, and 
>> working the way that DS is supposed to. In general a DS component being 
>> bounced like this is nothing to worry about, it’s just a change rippling 
>> through the system, and it’s typically resolved in very short order. If you 
>> do want to reason about why, however, then there are several places to look.
>>  
>> For some reason, the Component gets activated, deactivated, then activated 
>> again, which is not desirable.
>> ...
>> 1. How can I figure out why this is happening. I have tried many approaches, 
>> but can’t seem to get a clue as to why this is happening. Since it generally 
>> doesn’t seem to happen for other configured components, I am

Re: [osgi-dev] Double config

[Peter Kriens via osgi-dev]

This is a gift! :-) It means your code is not handling the dynamics correctly 
and now you know it! 

The cause is that that the DS starts the components before the Configurator has 
done its work. The easiest solution seems to be to use start levels. If your 
code CAN handle the dynamics, then this is one of the few legitimate places 
where startlevels are useful. I usually oppose it because people do not handle 
the dynamics correctly and want a short cut. This is fine until it is not. And 
the ‘not’ happens guaranteed one day. So first fix the dynamics, and then think 
of solutions that improve the experience.

For this purpose, enRoute Classic had a 
‘osgi.enroute.configurer.api.ConfigurationDone’ service. If you made an 
@Reference to ConfigurationDone then you were guaranteed to not start before 
the Configurer had done its magic. Since you did not want to depend on such a 
specific service for reasons of cohesion, I developed AggregateState. One of 
the aggregated states was then the presence of the ConfigurationDone service. 
Although this is also not perfectly cohesive it at least aggregates all the 
uncohesive things in one place and it is configurable.

Although this works the customer still is not completely happy since also the 
Aggregate State feels uncohesive. So we’ve been discussing a new angle. I want 
to try to make the Configuration Records _transient_. In Felix Config Admin you 
can provide a persistence service (and it was recently made useful). I was 
thinking of setting a special property in the configuration (something like 
‘:persistence:transient’). The persistence layer would then _not_ persist it. 
I.e. after a restart there would be no configuration until the Configurer sets 
it. This will (I expect) seriously diminish the bouncing caused for these kind 
of components.

And if you’re asking why I am still on the enRoute classic Configurer. Well, it 
has ‘precious’ fields and they solved a nasty problem. We needed to use a well 
defined value but if the user set one of those values, we wanted to keep the 
user’s value. Quite a common scenario. With `precious` fields you rely on 
default values (so no value for a precious field in the configurer’s input) but 
copy the previous value to the newer configuration, if present. Works quite 
well.

I think `transient` and `precious` could be nice extensions to the new 
Configurator for R8.

Hope this helps. Kind regards,

Peter Kriens

> On 12 Jul 2018, at 00:48, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi!
> 
> A question about component configuration.
> 
> I have a component that has a required configuration policy. Using a (pre R7) 
> Configurator to configure the component. For some reason, the Component gets 
> activated, deactivated, then activated again, which is not desirable.
> 
> Questions:
> 
> 1. How can I figure out why this is happening. I have tried many approaches, 
> but can’t seem to get a clue as to why this is happening. Since it generally 
> doesn’t seem to happen for other configured components, I am assuming that it 
> is not a Configurator problem.
> 
> 2. Is there a way to prohibit this from happening?
> 
> 
> In the meantime, I will make the dependent services more dynamic so they are 
> not thrown off by this change, but their behavior is actually correct: the 
> expectation is that the configured service should only get instantiated once, 
> so a static @Reference is correct.
> 
> 
> Thanks!
> =David
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] OSGi Specification Question

[Peter Kriens via osgi-dev]

LOL. One of the first ‘memory tricks’ I had was that it looked like a butler 
serving a tray. I.e. the publisher was ‘offering’ the service to the world.

Strange that it is still hard to remember :-)

Kind regards,

Peter Kriens

> On 29 Jun 2018, at 12:53, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev 
>  wrote:
> 
> Another way to look at the picture and remind about the triangle direction 
> would be to see it as a megaphone. The provider shouts out to the “world” 
> that there is a new service available. J
>  
> Mit freundlichen Grüßen / Best regards 
> 
> Dirk Fauth
> 
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
> www.bosch.com <http://www.bosch.com/> 
> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com 
> <mailto:dirk.fa...@de.bosch.com> 
> 
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
> Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller 
> 
> 
> Von: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org> 
> [mailto:osgi-dev-boun...@mail.osgi.org 
> <mailto:osgi-dev-boun...@mail.osgi.org>] Im Auftrag von Peter Kriens via 
> osgi-dev
> Gesendet: Donnerstag, 28. Juni 2018 17:45
> An: Dirk Fauth mailto:dirk.fa...@gmail.com>>
> Cc: OSGi Developer Mail List  <mailto:osgi-dev@mail.osgi.org>>
> Betreff: Re: [osgi-dev] OSGi Specification Question
>  
> I think this is the same confusion that exists for the UML interface symbol. 
>  
> Lots of problems that have a client-publisher relation have a hard time with 
> a good symbol since the relation is symmetric but not really.
>  
> Imho once you take a bit of time to see that the arrow points in the 
> dependency direction you tend to never forget it.
>  
> I’d love to change it for another symbol but never found a better one. UML 
> interfaces are not services (and probably even more confusing) and I’ve never 
> so far seen a symbol for micro-services, where I guess they have the same 
> need for a symbol. Most symbols tend to draw something on the publisher.
>  
> 
> However, in OSGi that does not make sense since we have independent 
> publisher. In OSGi, the service is its own entity. Nobody else but OSGi seem 
> to make that distinction. We reified the service and the service object(s) 
> because they are independent of the provider and the consumer. Our dependency 
> versioning is based on the version of the API, NOT the provider nor the 
> consymer. (At the time I tried to get the Semver people to understand that 
> they should add support for the compatibility rule differences between 
> providers and consumers and failed.)
>  
> The service broker model in OSGi is very innovative but unfortunately badly 
> understood since it is so outlandish. Ah well, story of my life.
>  
> Kind regards,
>  
> Peter Kriens
>  
>  
>  
>  
>  
>  
> 
> 
> On 28 Jun 2018, at 16:56, Dirk Fauth  <mailto:dirk.fa...@gmail.com>> wrote:
>  
> Thanks a lot for the answers. Then I updated my slides last year correctly 
> after the feedback from Tim. I just didn't remember. :) 
>  
> The confusion seems to be quite big. I need to update my getting started with 
> DS tutorial. And the incorrect picture is also posted on the Concierge 
> website https://www.eclipse.org/concierge/ 
> <https://www.eclipse.org/concierge/>
>  
>  
>  
> Peter Kriens via osgi-dev  <mailto:osgi-dev@mail.osgi.org>> schrieb am Do., 28. Juni 2018, 16:23:
> Not sure it is a good idea to repeat this picture for future confusion on a 
> mailing list?
>  
> Peter Kriens
>  
> 
> 
> On 28 Jun 2018, at 16:10, Tim Ward via osgi-dev  <mailto:osgi-dev@mail.osgi.org>> wrote:
>  
> I think it is this picture that causes the confusion:
>  
> 
>  
>  
> In this picture the “register” action is between A and S. This appears to 
> suggest that the service S is registered by bundle A. If that is the case 
> then the pointy-end of the triangle needs to point at A. Similarly the “get” 
> and “listen” actions are coming from bundle B, which would appear to make it 
> the consumer of S. The consumer should have the fat end of the triangle.
>  
> Note that almost all OSGi diagrams put the consumer on the left and the 
> provider on the right.
>  
> Best Regards,
>  
> Tim
> 
> 
> On 28 Jun 2018, at 15:04, Neil Bartlett via osgi-dev  <mailto:osgi-dev@mail.osgi.org>> wro

Re: [osgi-dev] OSGi Specification Question

[Peter Kriens via osgi-dev]

I think this is the same confusion that exists for the UML interface symbol. 

Lots of problems that have a client-publisher relation have a hard time with a 
good symbol since the relation is symmetric but not really.

Imho once you take a bit of time to see that the arrow points in the dependency 
direction you tend to never forget it.

I’d love to change it for another symbol but never found a better one. UML 
interfaces are not services (and probably even more confusing) and I’ve never 
so far seen a symbol for micro-services, where I guess they have the same need 
for a symbol. Most symbols tend to draw something on the publisher.


However, in OSGi that does not make sense since we have independent publisher. 
In OSGi, the service is its own entity. Nobody else but OSGi seem to make that 
distinction. We reified the service and the service object(s) because they are 
independent of the provider and the consumer. Our dependency versioning is 
based on the version of the API, NOT the provider nor the consymer. (At the 
time I tried to get the Semver people to understand that they should add 
support for the compatibility rule differences between providers and consumers 
and failed.)

The service broker model in OSGi is very innovative but unfortunately badly 
understood since it is so outlandish. Ah well, story of my life.

Kind regards,

Peter Kriens







> On 28 Jun 2018, at 16:56, Dirk Fauth  wrote:
> 
> Thanks a lot for the answers. Then I updated my slides last year correctly 
> after the feedback from Tim. I just didn't remember. :) 
> 
> The confusion seems to be quite big. I need to update my getting started with 
> DS tutorial. And the incorrect picture is also posted on the Concierge 
> website https://www.eclipse.org/concierge/ 
> <https://www.eclipse.org/concierge/>
> 
> 
> 
> Peter Kriens via osgi-dev  <mailto:osgi-dev@mail.osgi.org>> schrieb am Do., 28. Juni 2018, 16:23:
> Not sure it is a good idea to repeat this picture for future confusion on a 
> mailing list?
> 
>   Peter Kriens
> 
> 
>> On 28 Jun 2018, at 16:10, Tim Ward via osgi-dev > <mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> I think it is this picture that causes the confusion:
>> 
>>  <https://jaxenter.de/wp-content/uploads/2016/05/enRoute1.png> 
>> <https://jaxenter.de/wp-content/uploads/2016/05/enRoute1.png>
>> 
>> 
>> In this picture the “register” action is between A and S. This appears to 
>> suggest that the service S is registered by bundle A. If that is the case 
>> then the pointy-end of the triangle needs to point at A. Similarly the “get” 
>> and “listen” actions are coming from bundle B, which would appear to make it 
>> the consumer of S. The consumer should have the fat end of the triangle.
>> 
>> Note that almost all OSGi diagrams put the consumer on the left and the 
>> provider on the right.
>> 
>> Best Regards,
>> 
>> Tim
>> 
>>> On 28 Jun 2018, at 15:04, Neil Bartlett via osgi-dev 
>>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>> 
>>> The spec is correct, and either Tim misspoke or you misheard him.
>>> 
>>> The service should look like a big arrow pointing from the consumer to the 
>>> provider.
>>> 
>>> Neil
>>> 
>>> 
>>> 
>>> On Thu, Jun 28, 2018 at 2:57 PM, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev 
>>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>> Hi,
>>> 
>>>  
>>> 
>>> maybe a stupid question, but I am preparing my slides for the Java Forum 
>>> Stuttgart about Remote Services, and remembered that Tim told me that my 
>>> diagrams are incorrect, as the triangle is directing into the wrong 
>>> direction.
>>> 
>>>  
>>> 
>>> The big end should be on the producer side, while the cone end points to 
>>> the consumer bundle.
>>> 
>>> https://enrouteclassic.github.io/doc/215-sos.html 
>>> <https://enrouteclassic.github.io/doc/215-sos.html>
>>> https://jaxenter.de/osgi-enroute-1-0-hintergruende-architektur-best-practices-39709
>>>  
>>> <https://jaxenter.de/osgi-enroute-1-0-hintergruende-architektur-best-practices-39709>
>>>  
>>> 
>>> The architecture picture in the Remote Services chapter show the triangles 
>>> differently.
>>> 
>>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html 
>>> <https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html>
>>>  
>>> 
>>> Where is my misunderstanding? Is the picture incorrect, or does

Re: [osgi-dev] OSGi Specification Question

[Peter Kriens via osgi-dev]

Not sure it is a good idea to repeat this picture for future confusion on a 
mailing list?

Peter Kriens


> On 28 Jun 2018, at 16:10, Tim Ward via osgi-dev  
> wrote:
> 
> I think it is this picture that causes the confusion:
> 
>  <https://jaxenter.de/wp-content/uploads/2016/05/enRoute1.png> 
> <https://jaxenter.de/wp-content/uploads/2016/05/enRoute1.png>
> 
> 
> In this picture the “register” action is between A and S. This appears to 
> suggest that the service S is registered by bundle A. If that is the case 
> then the pointy-end of the triangle needs to point at A. Similarly the “get” 
> and “listen” actions are coming from bundle B, which would appear to make it 
> the consumer of S. The consumer should have the fat end of the triangle.
> 
> Note that almost all OSGi diagrams put the consumer on the left and the 
> provider on the right.
> 
> Best Regards,
> 
> Tim
> 
>> On 28 Jun 2018, at 15:04, Neil Bartlett via osgi-dev > <mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> The spec is correct, and either Tim misspoke or you misheard him.
>> 
>> The service should look like a big arrow pointing from the consumer to the 
>> provider.
>> 
>> Neil
>> 
>> 
>> 
>> On Thu, Jun 28, 2018 at 2:57 PM, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> Hi,
>> 
>>  
>> 
>> maybe a stupid question, but I am preparing my slides for the Java Forum 
>> Stuttgart about Remote Services, and remembered that Tim told me that my 
>> diagrams are incorrect, as the triangle is directing into the wrong 
>> direction.
>> 
>>  
>> 
>> The big end should be on the producer side, while the cone end points to the 
>> consumer bundle.
>> 
>> https://enrouteclassic.github.io/doc/215-sos.html 
>> <https://enrouteclassic.github.io/doc/215-sos.html>
>> https://jaxenter.de/osgi-enroute-1-0-hintergruende-architektur-best-practices-39709
>>  
>> <https://jaxenter.de/osgi-enroute-1-0-hintergruende-architektur-best-practices-39709>
>>  
>> 
>> The architecture picture in the Remote Services chapter show the triangles 
>> differently.
>> 
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html 
>> <https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html>
>>  
>> 
>> Where is my misunderstanding? Is the picture incorrect, or does the picture 
>> show something different?
>> 
>>  
>> 
>> Mit freundlichen Grüßen / Best regards 
>> 
>> Dirk Fauth
>> 
>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
>> www.bosch.com <http://www.bosch.com/> 
>> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com 
>> <mailto:dirk.fa...@de.bosch.com> 
>> 
>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
>> Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, 
>> Dr. Markus Heyn, Dr. Dirk Hoheisel,
>> Christoph Kübel, Uwe Raschke, Peter Tyroller 
>> 
>> 
>> 
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto: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] enRoute classic

[Peter Kriens via osgi-dev]

I got requests from several people what happened with the OSGi enRoute articles 
and tutorials. OSGi seems to have broken all the links. I do think it contained 
some valuable material, especially for bndtools users, so I reconstructed the 
web site as it was:

https://enrouteclassic.github.io/ <https://enrouteclassic.github.io/>

I would prefer to move the articles and tutorials to the bndtools side when I 
find time.

Kind regards,

    Peter Kriens



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

Re: [osgi-dev] Bndtools 3.3 enRoute distro update Jetty

[Peter Kriens via osgi-dev]

That is a pretty harsh thing to do, gratuitously renaming this file?

Peter Kriens

> On 15 May 2018, at 10:43, Tim Ward via osgi-dev <osgi-dev@mail.osgi.org> 
> wrote:
> 
> The correct link is 
> https://github.com/osgi/osgi.enroute/blob/deprecated/osgi.enroute.pom.distro/distro-pom.xml
>  
> <https://github.com/osgi/osgi.enroute/blob/deprecated/osgi.enroute.pom.distro/distro-pom.xml>
> 
> Sent from my iPhone
> 
> On 15 May 2018, at 09:14, Paul F Fraser via osgi-dev <osgi-dev@mail.osgi.org 
> <mailto:osgi-dev@mail.osgi.org>> wrote:
> 
>> This does not work for me and the link to the distro pom is dead.
>> Is it still possible to alter the distro now that we have the new enRoute?
>> If so how would I do this as I am tied to bndtools 3.3 for now?
>> The latest jetty bundle is now at 4.0.0
>> 
>> Paul Fraser
>> 
>> On 1/12/2017 8:18 PM, Peter Kriens wrote:
>>> You can add the newer Jetty in your pom.xml in cnf/central.xml in your 
>>> workspace. Need to touch build.bnd so Eclipse rebuilds. The latest distro 
>>> pom on Github is actually 3.2 and should drag in the proper Jetty 
>>> transitively? 
>>> (https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.pom.distro/distro-pom.xml
>>>  
>>> <https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.pom.distro/distro-pom.xml>)
>>> 
>>> Kind regards,
>>> 
>>> Peter Kriens
>>> 
>>>> On 1 Dec 2017, at 07:32, Paul F Fraser via osgi-dev 
>>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> The jetty bundles in the current distro (the one I have)  are version 3.1 
>>>> which imports jetty 9.2.10.
>>>> 
>>>> The latest felix bundle is 3.4.6 which imports jetty 9.3.9.
>>>> 
>>>> What needs to be done to upgrade the distro or how can I force the 
>>>> resolver to ignore the old version and work from a version in the local 
>>>> repo?
>>>> 
>>>> Paul Fraser
>>> 
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <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] Competing module systems

[Peter Kriens via osgi-dev]

Very nice example of something I see too often: choosing a bad solution that 
just appears to be  ’simpler’ to use. I think the Java world suffers from this 
terribly.

We also had a big discussions about circularity in the OSGi for the DTO’s. 
Initially they were circular but in the we agreed to not make them have inner 
references. It is slightly more work for the receiver but it makes life so much 
simpler overall …

Kind regards,

Peter Kriens


> On 14 Apr 2018, at 05:35, Peter via osgi-dev <osgi-dev@mail.osgi.org> wrote:
> 
> On 13/04/2018 6:32 PM, Neil Bartlett via osgi-dev wrote:
>> 
>> 
>> On Thu, Apr 12, 2018 at 10:12 PM, Mark Raynsford via osgi-dev 
>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> 
>> <mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>> wrote:
>> 
>>On 2018-04-12T20:32:13 +0200
>>Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>
>><mailto:peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>>> wrote:
>> 
>>> Caught between a rock and a hard place with only one way forward …
>> 
>>I should make the point that I don't hate the JPMS. I do think that
>>it's just barely the minimum viable product, though.
>> 
>>The JVM really did need a module system, both for the maintenance of
>>the JDK itself and the future features that the system enables.
>> 
>>> Oracle’s strategy is a mystery to me.
>> 
>>I think their strategy is fairly explicable, but I think they did make
>>some mistakes with some of the specifics (filename-based
>>automodules!).
>>There's a pattern that Oracle tend to follow: They solicit
>>opinions from
>>everyone vigorously, and then they implement the smallest possible
>>subset such that the fewest possible people are pissed off by it. If
>>there's a possibility of doing something wrong, nothing is done
>>instead.
>> 
>> 
>> While I've seen that principle operate at other times (remember how 
>> controversial erasure was in Java 5?), I'm not sure it's worked that way in 
>> the JPMS case. In fact JPMS does far more than it needed to.
>> 
>> The key feature of JPMS that could not be achieved before, even with 
>> ClassLoaders, was strictly enforced isolation via the accessibility 
>> mechanism, as opposed to the visibility mechanism that is employed by OSGi. 
>> That strict isolation was needed primarily to allow Oracle to close off JVM 
>> internals from application code and thereby prevent a whole class of 
>> security vulnerabilities. Remember that Oracle was being absolutely 
>> slaughtered in the press around 2011-12 over the insecurity of Java, and 
>> most corporates uninstalled it from user desktops.
> 
> Java deserialization vulnerabilties.
> 
> Ironically, Java serialization was an exception, rather than a minimalist 
> approach, it was given advanced, if not excessive functionality, including 
> the ability to serialize circular object graphs.
> 
> Circular relationships generally tend to be difficult to manage.
> 
> Due to the support for circular object graphs, it wasn't possible to to use a 
> serialization constructor, so all invariant checks had to be made after 
> construction, when it was too late.   Making matters worse, an attacker can 
> create any serializable object they want, and because of the way deserialized 
> objects are created, child class domains aren't on the call stack during 
> super class deserialization.   An attacker can take advantage of the circular 
> object graph support, and caching to obtain a reference to any object in a 
> deserialized graph.
> 
> In essence, they needed to have an alternative locked down implementation of 
> serialization.
> 
> There's nothing wrong with the java serialization protocol.   I wrote a 
> hardened implementation of java serialization, refactored from Apache 
> Harmony's implementation, implementing classes use a serialization 
> constructor, that ensures an object cannot be created unless it's invariants 
> were satisfied, this includes the ability to check inter class invariants as 
> well.   It doesn't support circular object graphs and has limits on how much 
> data could be cached, limits on array size etc.
> 
> I submitted the api to the OpenJDK development mail list, there was interest 
> there, but they decided they needed to support circular object graphs.
> 
> In the end Oracle decided to use white listing.
> 
> Cheers,
> 
> Peter.
> 
>> 
>> But they could have achieved this with a thin API, comparable to 
>> Pro

Re: [osgi-dev] Go Package versioning support proposal

[Peter Kriens via osgi-dev]

I am extremely interested in go and an OSGi like thing for it … 

Oracle’s stewardship is becoming painful.

Kind regards,

Peter Kriens




> On 13 Apr 2018, at 13:22, Balázs Zsoldos via osgi-dev 
> <osgi-dev@mail.osgi.org> wrote:
> 
> Hi,
> 
> Sorry if too offtopic.
> 
> I have just found the Proposal for Package Versioning in Go 
> <https://blog.golang.org/versioning-proposal>. I only had a quick look so 
> far, but I have the feeling that this is a first step to support a module 
> system natively in Go that is very similar to OSGi (even more similar to OSGi 
> than JPMS).
> 
> Seeing what is happening with Java JPMS, this is the first time I have got 
> interested in another language in the last 14 years. It would make sense to 
> share experience between OSGi experts and GoLang implementors.
> 
> Regards,
> -- 
> Balázs Zsoldos
> 
> ___
> 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] Competing module systems

[Peter Kriens via osgi-dev]

Caught between a rock and a hard place with only one way forward …

Oracle’s strategy is a mystery to me.

Kind regards,

Peter Kriens

> On 12 Apr 2018, at 20:06, Mark Raynsford via osgi-dev 
> <osgi-dev@mail.osgi.org> wrote:
> 
> Thought this might be of mild interest to people on this list:
> 
> https://blog.io7m.com/2018/04/12/competing-module-systems.xhtml
> 
> -- 
> Mark Raynsford | http://www.io7m.com
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Api compile-only and remote services

[Peter Kriens via osgi-dev]

Remote OSGi is a good example, but then then API can be viewed the provider.

Kind regards,

Peter Kriens

> On 9 Feb 2018, at 01:12, Scott Lewis via osgi-dev <osgi-dev@mail.osgi.org> 
> wrote:
> 
> I think cases where the service consumer doesn't need or want the provider 
> code (e.g. small or embedded environments) is one such example.   In such 
> cases a separate API can keep things smaller and less complicated on the 
> consumer.
> 
> Scott
> 
> On 2/8/2018 12:54 PM, Peter Kriens via osgi-dev wrote:
>> I think there are only a few good cases where you really need an API bundle. 
>> Virtually cases I’ve seen in the wild were incorrect because they fudged the 
>> versions to make the API more backward compatible than it really was so more 
>> providers could leverage it. In very few cases can you have different 
>> providers for the same API version.
>> 
>> Exporting the API from the provider is usually the safest way imho and it 
>> works very well without extra metadata with resolving.
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>> 
>>> On 8 Feb 2018, at 21:01, Chris Gray via osgi-dev <osgi-dev@mail.osgi.org> 
>>> wrote:
>>> 
>>> 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
>>>> <osgi-dev@mail.osgi.org> 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
>>>> <osgi-dev@mail.osgi.org>:
>>>> 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 hav

Re: [osgi-dev] Api compile-only and remote services

[Peter Kriens via osgi-dev]

I think there are only a few good cases where you really need an API bundle. 
Virtually cases I’ve seen in the wild were incorrect because they fudged the 
versions to make the API more backward compatible than it really was so more 
providers could leverage it. In very few cases can you have different providers 
for the same API version.

Exporting the API from the provider is usually the safest way imho and it works 
very well without extra metadata with resolving. 

Kind regards,

Peter Kriens


> On 8 Feb 2018, at 21:01, Chris Gray via osgi-dev <osgi-dev@mail.osgi.org> 
> wrote:
> 
> 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
>> <osgi-dev@mail.osgi.org> 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
>> <osgi-dev@mail.osgi.org>:
>> 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

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

Re: [osgi-dev] DS Reference injection order

[Peter Kriens via osgi-dev]

In this case you do not have such guarantee about injection. And it won’t be 
necessary since you could just make them mandatory references. 

You need to distinguish two things:

1) The existence of or the state of the system
2) Injection

If you have an optional dependence then all bets are off because there can 
always be a delay between the events. Only mandatory references give you any 
guarantee here. For example, to handle cyclic dependencies DS can delay 
injection of optional dependencies although the service is present. 

What you could do is to lookup the services through the component context, they 
should be there.

So what you can observe through the AggregateState service is not by definition 
observable through optional services. A bit like relativity theory.

Kind regards,

Peter Kriens




> On 2 Feb 2018, at 10:35, Thomas Driessen via osgi-dev 
> <osgi-dev@mail.osgi.org> wrote:
> 
> Hi,
> 
> thanks for all those answers and sorry for my late response.
> 
> Maybe I have been a little bit too imprecise.
> The reason I asked, was that I found this article by Peter Kriens about an 
> AggregateState: http://aqute.biz/2017/04/24/aggregate-state.html 
> <http://aqute.biz/2017/04/24/aggregate-state.html>
> 
> I wrote such a service and only was wondering afterwards if this really works 
> all the times or if I just hit a lucky punch and it worked the few times I 
> tested it. Or if I got Peter's intentions completely wrong and did something 
> AggregateState was not meant for.
> 
> So what I do is writing a component as described in the article like this:
> 
> @Component
> public class MyComp{
> 
> @Reference(target="(&(x.prop=x)(y.prop=y))")
> private AggregateState state;
> 
> @Reference(target="(x.prop=x)")
> private volatile X x;
> 
> @Reference(target="(y.prop=y)")
> private volatile Y y;
> 
> @Activate
> private void activate(){
> doSomethingWithXandY();
> }
> 
> }
> 
> So even if my AggregateState is satisfied, which means that there are 
> fitting, activated services for X and Y, can I rest assured that X and Y are 
> injected BEFORE activate() is called? Because my understanding was that X and 
> Y might still be null and MyComp is nevertheless eligible for activation. 
> 
> Kind regards,
> Thomas
> 
> 
> 
> -- Originalnachricht --
> Von: "BJ Hargrave" <hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>>
> An: tim.w...@paremus.com <mailto:tim.w...@paremus.com>; 
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> Cc: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>; 
> thomas.driessen...@gmail.com <mailto:thomas.driessen...@gmail.com>
> Gesendet: 31.01.2018 15:40:53
> Betreff: Re: [osgi-dev] DS Reference injection order
> 
>> Tim correctly cites the spec regarding the order SCR must process the 
>>  elements in the XML. Since you are using annotations, there is 
>> one more thing to know. The javadoc for the Reference annotation states:
>>  
>> In the generated Component Description for a component, the references must 
>> be ordered in ascending lexicographical order (using String.compareTo ) of 
>> the reference names. 
>> 
>>  
>> So you can control the order of the reference elements in the xml by the 
>> names of the references.
>>  
>> The order of processing reference can be useful if you are using method 
>> injection and a method needs to use a previously injected reference. But 
>> since you examples show field injection, your component cannot not really 
>> observe the order of injection.
>>  
>> With 'volatile' you have a dynamic reference which can be updated at any 
>> time, so there is no order with respect to other reference.
>>  
>> --
>> 
>> 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 <mailto:hargr...@us.ibm.com>
>>  
>>  
>> - Original message -
>> From: Tim Ward via osgi-dev <osgi-dev@mail.osgi.org 
>> <mailto:osgi-dev@mail.osgi.org>>
>> Sent by: osgi-dev-boun...@mail.osgi.org 
>> <mailto:osgi-dev-boun...@mail.osgi.org>
>> To: Thomas Driessen <thomas.driessen...@gmail.com 
>> <mailto:thomas.driessen...@gmail.com>>, OSGi Developer Mail List 
>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
>> Cc:
>> Subject: Re: [osgi-dev] DS Reference injection order
>> Date: Wed, Jan 31, 2018 6:43 AM
>>  
>> Firstly

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

[Peter Kriens via osgi-dev]

Great minds think alike (and it helped we were both in this discussion) :-)

P

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

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

[Peter Kriens via osgi-dev]

You’re right. Since the impact is so low we did consider making this a MICRO 
change. 

However, in bnd we remove the micro qualifier to prevent the static transitive 
graph that Maven requires. I.e. the MICRO is the ‘oil’ between the modules, it 
may not signal incompatibility. However, this implies that a MICRO change is 
not only backward compatible but also forward compatible. Turning an interface 
method into a default method is, however, not forward compatible. A bundle 
compiled against the later MICRO version does require that version to be 
present in runtime, unlike a bug fix or documentation fix but does not require 
this micro version because the MICRO is stripped.

Kind regards,

Peter Kriens







> On 5 Dec 2017, at 07:43, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev 
> <osgi-dev@mail.osgi.org> wrote:
> 
> Hi,
>  
> IMHO it is a MINOR change because it is not a breaking change. J
>  
> With that change neither implementations of the Foo interface, nor classes 
> that extend the abstract Bar class will break.
>  
> Implementations of the Foo interface can still implement the doFoo() method 
> and by doing this override the default behavior. Overriding a default is not 
> a breaking change as you neither add a new public method or field, you just 
> give a default implementation.
>  
> Classes that extend Bar did not need to implement doFoo() before, as it was 
> implemented in Bar. Removing that method would be typically a breaking 
> change. But you are moving it as default method to the Foo interface. 
> Therefore Bar still has the doFoo() method implemented, as it is provided by 
> the Foo interface.
>  
> I have to admit that I am not 100% sure about the byte code in the end and if 
> that matters. But as a user of the interface and abstract class, nothing 
> breaks. 
>  
> Mit freundlichen Grüßen / Best regards 
> 
> Dirk Fauth
> 
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
> www.bosch.com <http://www.bosch.com/> 
> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com 
> <mailto:dirk.fa...@de.bosch.com> 
> 
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
> Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller 
> 
> 
> Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> Im Auftrag von Raymond Auge via osgi-dev
> Gesendet: Dienstag, 5. Dezember 2017 00:26
> An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Betreff: [osgi-dev] making an existing interface method default causes MINOR 
> baseline change
>  
> Hey All,
> 
> I think the answer is "Yes it's a MINOR change", but I wanted to clarify.
>  
> Assume I have the following interface in an exported package:
>  
> public interface Foo {
>public void doFoo();
> }
>  
> And in the same package I have abstract class Bar which implements Foo:
>  
> public abstract class Bar implements Foo {
>public void doFoo() {...}
>public abstract void doBar();
> }
>  
> And I want to migrate to a default method because doFoo() logic rarely 
> changes:
>  
> public interface Foo {
>public default void doFoo() {...}
> }
>  
> public abstract class Bar implements Foo {
>//public void doFoo() {...}
>public abstract void doBar();
> }
>  
> Can someone explain why this is a MINOR change?
>  
>  
> -- 
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> 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] Bndtools 3.3 enRoute distro update Jetty

[Peter Kriens via osgi-dev]

You can add the newer Jetty in your pom.xml in cnf/central.xml in your 
workspace. Need to touch build.bnd so Eclipse rebuilds. The latest distro pom 
on Github is actually 3.2 and should drag in the proper Jetty transitively? 
(https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.pom.distro/distro-pom.xml
 
<https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.pom.distro/distro-pom.xml>)

Kind regards,

    Peter Kriens








> On 1 Dec 2017, at 07:32, Paul F Fraser via osgi-dev <osgi-dev@mail.osgi.org> 
> wrote:
> 
> Hi,
> 
> The jetty bundles in the current distro (the one I have)  are version 3.1 
> which imports jetty 9.2.10.
> 
> The latest felix bundle is 3.4.6 which imports jetty 9.3.9.
> 
> What needs to be done to upgrade the distro or how can I force the resolver 
> to ignore the old version and work from a version in the local repo?
> 
> Paul Fraser
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] Upcoming Configurator Specification

[Peter Kriens via osgi-dev]

For a customer I extended the OSGi enRoute Configurer to do something like 
this. I allowed you to indicate that certain properties were ‘precious'. (See 
https://github.com/osgi/osgi.enroute/blob/310c16182abab915907b40803aa8e3377d7ae8ed/osgi.enroute.configurer.simple.provider/src/osgi/enroute/configurer/simple/provider/Configurer.java#L331-L349)

Kind regards,

Peter Kriens

> On 19 Nov 2017, at 21:12, elias vasylenko via osgi-dev 
> <osgi-dev@mail.osgi.org> wrote:
> 
> Brilliant thanks for the response, I will absolutely file this in the issue 
> tracker. I didn't expect it would be reasonable to slip into R7 at this point 
> if it wasn't already on the cards behind the scenes so I understand.
> 
> There are reasonable philosophical arguments against it ... but it's worth 
> considering.
> 
> Regards,
> 
> Eli
> 
> On Sun, 19 Nov 2017 at 09:27 Carsten Ziegeler <cziege...@apache.org 
> <mailto:cziege...@apache.org>> wrote:
> Hi,
> 
> the Configurator specification (as well as the Configuration Admin one)
> does not support merging of configurations.
> 
> Unfortunately, a use case of merging has never been brought up to the
> expert group during the discussions and therefore we didn't consider
> this at all. That said, I think it would be great if you could create an
> issue in the public OSGi issue tracker for this. This will make it
> easier to consider for the expert group and it doesn't get lost.
> 
> I think it's too late for the R7 release as we're almost done with all
> the specification work and are currently finalizing the release. But
> it's something we can consider for R8.
> 
> Regards
> 
> Carsten
> 
> 
> Osgi Developer Mail List wrote
> > I have some thoughts/questions about the upcoming configurator
> > specification in OSGi R7
> > <https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2017-10.pdf 
> > <https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2017-10.pdf>>.
> >
> > The spec talks about the concept of a configuration ranking, by which
> > the configurator service selects the most appropriate configuration to
> > apply. But what if we already have a working configuration deployed and
> > only wish to override certain values? Can we do something like the
> > following?
> >
> > [existing-baseline-configuration.json]
> > {
> > "my.pid": {
> > ":configurator:ranking": "0",
> > "key_one": "configured_value",
> > "key_two": "configured_value",
> > "key_three": "configured_value"
> > }
> > }
> >
> > [new-partial-configuration.json]
> > {
> > "my.pid": {
> > ":configurator:ranking": "1",
> > "key_three": "overriding_value"
> > }
> > }
> >
> > Normally in this scenario I assume [new-partial-configuration.json] will
> > be selected as the one to apply and the other will be completely
> > ignored. But I would hope there is a way to tell the configurator we
> > want to merge a configuration with the next-highest-ranked
> > configuration, such that the configurator will ultimately resolve
> > something like the following:
> >
> > [effective configuration]
> > {
> > "my.pid": {
> > "key_one": "configured_value",
> > "key_two": "configured_value",
> > "key_three": "overriding_value"
> > }
> > }
> >
> > I realise this behaviour isn't /always/ what we'd want, but perhaps we
> > could apply some PID-level configurator key to
> > [new-partial-configuration.json] to opt in, e.g.
> > "/:configurator:override-strategy": "complete/partial/whatever"/
> >
> > Since something like this doesn't appear to be mentioned in the latest
> > draft I assume it's not currently planned, but I'm hoping I've
> > misunderstood or misread some part of it because this seems like an easy
> > win to me. Perhaps there has been internal discussion of something like
> > this and it was dismissed for some reason? I realise it adds some
> > complexity to the implementation but I don't think it really adds any
> > confusion to the mental model for users.
> >
> > Any further comment or discussion would be welcome,
> >
> > Cheers,
> >
> > Eli
> >
> >
> > ___
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> > https://mail.osgi.org/mailman/listinfo/osgi-dev 
> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> >
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org <mailto: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] Distributed OSGi enRoute tutorial

[Peter Kriens]

You should add the @RequireEventAdminServerSentEventsWebResource to your 
application class. This drags in the bundle 
https://github.com/osgi/osgi.enroute/tree/master/osgi.enroute.easse.simple.adapter
 
<https://github.com/osgi/osgi.enroute/tree/master/osgi.enroute.easse.simple.adapter>
 . Using the OSGi enRoute Webresources, this automatically makes this module 
available to your app.

Kind regards,

    Peter Kriens


> On 26 Oct 2017, at 20:37, Jesse Rao <jesse@liferay.com> wrote:
> 
> I've worked through the Distributed OSGi tutorial up to the last section here 
> (http://enroute.osgi.org/tutorial_rsa/260-gui.html 
> <http://enroute.osgi.org/tutorial_rsa/260-gui.html>) but I'm having some 
> trouble with the JS part. Maybe I'm missing something obvious (AngularJS is 
> new to me) but I want to check if there could be a typo around the name of 
> the `enEasse` module here:
> 
>   var MODULE = angular.module(
>   'osgi.enroute.examples.chat',   // CHANGE
>  [ 'ngRoute', 'enEasse' ]);
> 
> I can find documentation for the ngRoute module but what is enEasse? It seems 
> to be used here:
> 
> var close = en$easse.handle(...
> 
> but it's not clear to me where this handle function is defined.
> 
> When I run the chat app and view the page at 
> http://localhost:8081/com.example.chat.application/index.html#/ 
> <http://localhost:8081/com.example.chat.application/index.html#/>, I get this 
> JS error:
> 
> Error: [$injector:modulerr] Failed to instantiate module 
> com.example.chat.application due to:
> [$injector:modulerr] Failed to instantiate module enEasse due to:
> [$injector:nomod] Module 'enEasse' is not available! You either misspelled 
> the module name or forgot to load it. If registering a module ensure that you 
> specify the dependencies as the second argument.
> ...
> 
> Any ideas what's going wrong?
> 
> 
> -- 
> Jesse Rao
> Software Engineer
> Liferay, Inc.
> Visit Us: www.liferay.com <https://www.liferay.com/>  |  Like Us: 
> www.facebook.com/liferay <https://www.facebook.com/liferay>  |  Follow Us: 
> www.twitter.com/liferay <https://www.twitter.com/liferay> | Share Us: 
> www.instagram.com/liferayinc <https://www.instagram.com/liferayinc>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] enRoute Test Projects

[Peter Kriens]

This does work. Sometimes the test class extends TestCase and then JUnit gets 
confused. If you’re test methods are named ’testXXX’ then they do seem to work?

Kind regards,

Peter Kriens

> On 6 Oct 2017, at 22:36, Paul F Fraser <pa...@a2zliving.com> wrote:
> 
> Hi,
> 
> Using Bndtools 3.3,
> 
> If I try to use the the annotations @BeforeClass, @AfterClass etc. using the 
> standard enRoute test project template, they are ignored.
> 
> The only annotation recognized is @Test.
> 
> Am I missing something or is this intended when running the JUnit Launcher?
> 
> Paul Fraser
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Re: [osgi-dev] How to hint the resolver to pick a certain service provider

[Peter Kriens]

The purpose of the @Reference.target is to be overridden by configuration, 
adding the filter to the requirement would basically destroy that use case.

For what you want there is a very good solution: Plain Old Java Types … I 
suspect that in your code you already do some casting to a more specific type 
from RComponent? If that is the case then you have a bad code smell, which is 
also visible in Camel I think. We ‘know’ the type but we’re forced to go to 
properties to line things up as we want.

However, I am guessing so you might need it in a different scenario. If you 
want to do what you want I think you can use the annotation support in bnd for 
requirements.

@RequireCapability( ns=“osgi.service”, 
filter=“(&(objectClass=org.apache.karaf.rcomp.api.RComponent)(name=${value}))” )
@interface ReqRc { String value(); }

@ReqRc(“mqtt” )
@Component(property=“name=mqtt”)
public class …

Hope this helps.

Kind regards,

Peter Kriens

> On 17 Aug 2017, at 10:07, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> I am currently working on a little framework that offers components with a 
> common service interface but different property value per component.
> 
> LIke:
> 
> https://github.com/cschneider/reactive-components/blob/master/rcomp-mqtt/src/main/java/org/apache/karaf/rcomp/mqtt/MqttComponent.java
> @Component(property="name=mqtt")
> 
> A user of the mqtt component will use a filter like this:
> @Reference(target="(name=mqtt)")
> 
> Bnd creates a requirement like this:
> osgi.service;filter:="(objectClass=org.apache.karaf.rcomp.api.RComponent)";effective:=active
> 
> The requirement does not include the filter.
> 
> It would be nice if bndtools or karaf later could help me by auto picking or 
> recommending the mqtt component bundle when the user bundle is required.
> 
> Can I somehow make bnd create a requirement including a filter? .. or 
> alternatively is there another easy to use way how a specific provider can 
> announce itself and a user bundle can specify the requirement for a specific 
> provider?
> 
> I think this same problem applies to Apache Camel. When a user bundle uses a 
> certain camel component then the resolver currently does not help with this 
> and the bundle fails at runtime.
> 
> 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

Re: [osgi-dev] OSGI enroute json date handling

[Peter Kriens]

The problem with LocalDate and LocalTime is that you immediately run into 
encoding the date. As a string? Which format? As a long? What timezone? Though 
there are standards non relate to JSON.

In my experience, time is best passed as a long epoch time. For local date en 
time you should best use strings and handle the conversion in your code. 

If you still want to do it then the DTOs must be adapted to provide a way to 
control the JSONifying of these types. Currently this is done via the bnd 
converter. So you could add this to the bnd Converter class, then the next 
release will support it. However, since there is no JSON standard for dates you 
will have to make a choice what encoding to use and I am not sure that will be 
easy since there is so much choice.

Kind regards,

Peter Kriens

> On 26 Jun 2017, at 14:32, vijayakumar mohan <vj.kmr.mohan.offic...@gmail.com> 
> wrote:
> 
> Hi,
>I would like to extend the date handling capability in OSGI enroute 
> framework to support the new java.time packages. 
> For example , if i want to support DTOs with LocalDate and LocalTime how do i 
> go about doing it?.
> 
> Thanks in advance,
> Vijayakumar
> ___
> 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] Help With OBR

[Peter Kriens]

One of the things that make modularity provides its benefits is that your 
modules are, eh, modules. Sadly, many third party libraries are not modules 
because they do not manage their dependencies nor do they provide a clean 
minimal API. So I would not get too excited about automatic bundle generation 
from non-modular third party libraries. Fortunately, for most problems there 
are good solutions available. (Karaf is driving a lot of good work here but 
there are also many others pushing good modules.) However, this will require 
some manual work if you’re unlucky. If this could be automated we’d all be out 
of work … :-)

The Felix resolver is nowadays also used in Equinox. In the bnd project, we 
provide a maven plugin that uses bndrun files to steer a resolution. This 
resolution checks if a set of bundles is compatible and can drag extra bundles 
from a repository. These repositories can be a Maven POM, a P2 (Eclipse) repo, 
or an OBR index. There is also a maven plugin that can generate an OBR index 
based on maven dependencies.

So the parts are there and just verifying if a set of preselected bundles will 
work on a framework is quite straightforward. If you want a more automatic 
selection process it will require curating the repositories. 

Though maybe the news that there is no magic is a bit disappointing, it does 
provide you with a system that catches most problems much earlier than 
traditional approaches.

> 1.   Do we need to implement anything, or there’re implementations that 
> we can use?
For this setup there are bnd plugins that generate the index and that can do 
the resloving.

> 2.   What is the trigger for this process to start during/instead Maven 
> build?
They are plugins part of the maven life cycle

> 3.   We use Equinox. Does the resolver is the Equinox resolver? How can I 
> activate it in the OBR process?
Equinox uses the Felix resolver nowadays. The bndrun will contain your 
specification of the runtime and a plugin will resolve it.

> 4.   What are my options for public repositories that contains known 3rd 
> parties?
Today most code ends up quickly in maven central. Actually, the maven bnd 
plugin is one of the most popular plugins. Most modern code has the OSGi 
metadata. However, remember that real models are more than just metadata.

> 5.   What happens if the 3rd party I need doesn’t exist in my bundles 
> repositories? Does the process fail?
Yes.

> 6.   There’s, for example, the Apache Felix OBR. Is it an implementation 
> of the repository or the resolver or both?
> 7.   Does OBR work fluently, or it has many issues?
I think you find that the most advanced workflow are with the bnd maven 
plugins. As I stated, properly setup this can make your product a lot more 
reliable and stable. However, there is no magic. You will still be required to 
understand the parts. 

Kind regards,

Peter Kriens

> On 21 Jun 2017, at 14:18, Eran Twili <eran.tw...@niceactimize.com> wrote:
> 
> Hi,
>  
> I approach you after spending days of research, resulted in only vague high 
> level understating of a solution to our problem.
> In my organization, we’re intending to embed OSGi into our application.
> We’re currently exploring the change that will result from moving to OSGi, in 
> aspect of provisioning / building our application.
> Till today, we’re using Maven as our build tool.
> So every developer in the team, in his day-to-day work, can make some changes 
> in the code, run maven install, and Maven will take care of pulling in the 
> transitive dependencies, compiling and building the target jars.
> Now, moving to OSGi.
> Working the same way won’t be sufficient, as Maven may pull in transitive 
> dependencies which aren’t bundles.
> In addition, Maven can successfully compile our project, although some 
> Manifest requirements are missing, which means the OSGi FW will not resolve.
> But we do want as much automation of the process as possible, so what do we 
> do?
> We want that:
> 1.   When building our project, we’ll automatically get bundle versions 
> of our 3rd parties, including bundle versions of their transitive 
> dependencies, without the need to specify transitive dependencies.
> 2.   After build we want to verify that our OSGi FW can be resolved. I.e. 
> all bundles can be in ACTIVE state.
>  
> I read a lot about it and managed to conclude that what we need is OBR.
> However, although I read a lot about OBR, I can’t get the puzzle fixed.
> I couldn’t find any hands-on tutorial of working with OBR end to end.
> I do understand that the main players in the game are: bundles repositories 
> and a resolver.
> I understand that I need to start with my own modules as the initial set of 
> bundles and that OBR should then automatically pull my missing dependencies 
>

Re: [osgi-dev] Scheduler service (enroute)

[Peter Kriens]

The snapshot is also available on 
https://oss.sonatype.org/content/repositories/osgi-snapshots/ 
<https://oss.sonatype.org/content/repositories/osgi-snapshots/>

You can include this in a BndPomRepository or MavenBndRepository.

Kind regards,

    Peter Kriens

> On 14 Jun 2017, at 22:29, M.J. Heuveling <mi...@heuveling.net> wrote:
> 
> Hi Peter,
> 
> I have cloned your fork with the fix and build the bundles. How can I 
> actually point eclipse (bndtools) to use the newly built bundles? 
> 
> Any pointers would help. Many thanks.
> 
> -
> I've created a fix, please test.
> 
>> On 12 Jun 2017, at 17:51, Karel Haeck <karel.ha...@telenet.be 
>> <mailto:karel.ha...@telenet.be>> wrote:
>> 
>> 
>> There is an error in the initialization of the enroute InternalSchedulerImpl 
>> component. It was logged as issue 70 on github repo osgi.enroute.bundles 
>> (https://github.com/osgi/osgi.enroute.bundles/issues/70 
>> <https://github.com/osgi/osgi.enroute.bundles/issues/70> 
>> <https://github.com/osgi/osgi.enroute.bundles/issues/70 
>> <https://github.com/osgi/osgi.enroute.bundles/issues/70>>)
>> but the issue probably got lost when the code was moved to github repo 
>> osgi.enroute
>> 
>> 
>> On 12/06/2017 10:28, Misja Heuveling wrote:
>>> Hi All,
>>> 
>>> I am trying to build a bundle which would run a scheduled service to do 
>>> some background tasks at a regular interval. 
>>> 
>>> I used the blog post from oktober 2015 to get started so I made the 
>>> following service:
>>> 
>>> @Component(
>>>property = CronJob.CRON + "=* * * * * * ?"
>>>  )
>>>  public class CronComponent implements CronJob
>>>@Override
>>>public void run(Object data) throws Exception {
>>>  System.out.println("Cron Component");
>>>}
>>>  }
>>> This service should run every second. When I run this bundle nothing 
>>> actually happens 
>>> When I create a service tracker for the scheduler service and initiate the 
>>> service tracker in the bundle Activator I get a NullPointerException with 
>>> the message the cron syntax is incorrect.
>>> When I stop and start the bundle in the running session all of a sudden see 
>>> the println statement output.
>>> It seems I need to start the Scheduler Service or the CronComponent service 
>>> in some different order. (I assume the Scheduler service needs to be 
>>> running first...)
>>> How could this be done? 
>>> With kind regards,
>>> Misja Heuveling
>>> 
>>> 
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> 
>>> <mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> 
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> 
>> <mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>>
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mail.osgi.org/pipermail/osgi-dev/attachments/20170613/15a83ac0/attachment-0001.html
>  
> <http://mail.osgi.org/pipermail/osgi-dev/attachments/20170613/15a83ac0/attachment-0001.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

Re: [osgi-dev] Problem with maven only tutorial

[Peter Kriens]

> On 15 Jun 2017, at 09:32, Bastian Faulhaber <bas.faulha...@gmail.com> wrote:
> Hello,
> Your suggestion worked. I wonder why I didn't need to do the input like
> that in the tutorial before, in the terminal inside Eclipe?
I actually am puzzled about it as well. Unfortunately don’t have the time to 
dive into it.

> 
> Also, what about the warning: "Unused Private-Package instructions, no
> such package(s) on the class
> path: [osgi.enroute.examples.eval.parsii.provider]” during "mvn install"?
Again, I am puzzled. It seems the maven bnd plugin now takes all the input from 
the target/classes directory. Since the 
osgi.enroute.examples.eval.parsii.provider package is compiled in there, it is 
included before Private-Package can process it. So the Private-Package detects 
that nothing matches  osgi.enroute.examples.eval.parsii.provider and whines.

You can remove the line in Private-Package with 
osgi.enroute.examples.eval.parsii.provider

Please make a PR for the tutorial if you can.

Kind regards,

Peter Kriens



> 
> Thank you!
> Bastian
> 
> On 06/14/2017 03:47 PM, Peter Kriens wrote:
>> I think the problem is that the new Gogo we included (the enRoute
>> version had some issues) does a more advanced line parsing. It does
>> something weird with a line like:
>> 
>> g! eval 2*3
>> gogo: IOException: no matches found: 2*3
>> 
>> The reason we had the enRoute version was because of the JLine
>> interface. For some reason this seems to be awfully hard because I’ve
>> seen messages fly by from Gogo mucking in this area. It seems they
>> interpret the ‘*’ before the command is called. This is pretty wrong imho.
>> 
>> So to test it, you need to put double quotes around the expression:
>> 
>> g! eval "2 * 3"
>> 6.0
>> 
>> If you want to help out file a bug on Apache Felix Gogo and provide a PR
>> on the tutorial to make this behavior clear.
>> 
>> Kind regards,
>> 
>> Peter Kriens
>> 
>>> 
>>> On 14 Jun 2017, at 09:56, Bastian Faulhaber <bas.faulha...@gmail.com
>>> <mailto:bas.faulha...@gmail.com <mailto:bas.faulha...@gmail.com>>> wrote:
>>> 
>>> Hello,
>>> 
>>> You can find it here:
>>> https://github.com/boasdi/osgi.enroute.tut.maven.eval
>>> 
>>> Thanks!
>>> Bastian
>>> 
>>> On 06/14/2017 08:55 AM, Peter Kriens wrote:
>>>> Can you share your workspace on  Github?
>>>> 
>>>> Kind regards,
>>>> 
>>>> Peter Kriens
>>>> 
>>>>> On 13 Jun 2017, at 11:22, Bastian Faulhaber
>>>>> <bas.faulha...@gmail.com> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> While following the maven onlyh tutorial I encountered a problem.
>>>>> 
>>>>> In dependencies step after including the parsii.provider when I execute
>>>>> the application the console starts successfully but the enroute logo is
>>>>> missing and when I try anything else but substraction or sum I get:
>>>>> "gogo: IOException: no matches found:"
>>>>> 
>>>>> When I do "mvn instal" in parsi provider I get the following warning:
>>>>> "Unused Private-Package instructions, no such package(s) on the class
>>>>> path: [osgi.enroute.examples.eval.parsii.provider]"
>>>>> 
>>>>> But in target/classes/osgi/enroute/examples/eval/parsii/provider/ I have
>>>>> EvalImpl.class
>>>>> 
>>>>> I also did "mvn clean" as suggested in the tutorial.
>>>>> 
>>>>> Am I missing something?
>>>>> 
>>>>> Thank you very much!
>>>>> Bastian
>>>>> ___
>>>>> 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 <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <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 maven only tutorial

[Peter Kriens]

I think the problem is that the new Gogo we included (the enRoute version had 
some issues) does a more advanced line parsing. It does something weird with a 
line like:

g! eval 2*3
gogo: IOException: no matches found: 2*3

The reason we had the enRoute version was because of the JLine interface. For 
some reason this seems to be awfully hard because I’ve seen messages fly by 
from Gogo mucking in this area. It seems they interpret the ‘*’ before the 
command is called. This is pretty wrong imho.

So to test it, you need to put double quotes around the expression:

g! eval "2 * 3"
6.0

If you want to help out file a bug on Apache Felix Gogo and provide a PR on the 
tutorial to make this behavior clear.

Kind regards,

    Peter Kriens

> 
> On 14 Jun 2017, at 09:56, Bastian Faulhaber <bas.faulha...@gmail.com> wrote:
> 
> Hello,
> 
> You can find it here:
> https://github.com/boasdi/osgi.enroute.tut.maven.eval
> 
> Thanks!
> Bastian
> 
> On 06/14/2017 08:55 AM, Peter Kriens wrote:
>> Can you share your workspace on  Github?
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>>> On 13 Jun 2017, at 11:22, Bastian Faulhaber <bas.faulha...@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> While following the maven onlyh tutorial I encountered a problem.
>>> 
>>> In dependencies step after including the parsii.provider when I execute
>>> the application the console starts successfully but the enroute logo is
>>> missing and when I try anything else but substraction or sum I get:
>>> "gogo: IOException: no matches found:"
>>> 
>>> When I do "mvn instal" in parsi provider I get the following warning:
>>> "Unused Private-Package instructions, no such package(s) on the class
>>> path: [osgi.enroute.examples.eval.parsii.provider]"
>>> 
>>> But in target/classes/osgi/enroute/examples/eval/parsii/provider/ I have
>>> EvalImpl.class
>>> 
>>> I also did "mvn clean" as suggested in the tutorial.
>>> 
>>> Am I missing something?
>>> 
>>> Thank you very much!
>>> Bastian
>>> ___
>>> 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] Problem with maven only tutorial

[Peter Kriens]

Can you share your workspace on  Github?

Kind regards,

Peter Kriens

> On 13 Jun 2017, at 11:22, Bastian Faulhaber <bas.faulha...@gmail.com> wrote:
> 
> Hello,
> 
> While following the maven onlyh tutorial I encountered a problem.
> 
> In dependencies step after including the parsii.provider when I execute
> the application the console starts successfully but the enroute logo is
> missing and when I try anything else but substraction or sum I get:
> "gogo: IOException: no matches found:"
> 
> When I do "mvn instal" in parsi provider I get the following warning:
> "Unused Private-Package instructions, no such package(s) on the class
> path: [osgi.enroute.examples.eval.parsii.provider]"
> 
> But in target/classes/osgi/enroute/examples/eval/parsii/provider/ I have
> EvalImpl.class
> 
> I also did "mvn clean" as suggested in the tutorial.
> 
> Am I missing something?
> 
> Thank you very much!
> Bastian
> ___
> 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] Scheduler service (enroute)

[Peter Kriens]

I’ve created a fix, please test.

> On 12 Jun 2017, at 17:51, Karel Haeck  wrote:
> 
>  
> There is an error in the initialization of the enroute InternalSchedulerImpl 
> component. It was logged as issue 70 on github repo osgi.enroute.bundles 
> (https://github.com/osgi/osgi.enroute.bundles/issues/70 
> )
> but the issue probably got lost when the code was moved to github repo 
> osgi.enroute
> 
> 
> On 12/06/2017 10:28, Misja Heuveling wrote:
>> Hi All,
>> 
>> I am trying to build a bundle which would run a scheduled service to do some 
>> background tasks at a regular interval. 
>> 
>> I used the blog post from oktober 2015 to get started so I made the 
>> following service:
>> 
>> @Component(
>> property = CronJob.CRON + "=* * * * * * ?"
>>   )
>>   public class CronComponent implements CronJob
>> @Override
>> public void run(Object data) throws Exception {
>>   System.out.println("Cron Component");
>> }
>>   }
>> This service should run every second. When I run this bundle nothing 
>> actually happens 
>> When I create a service tracker for the scheduler service and initiate the 
>> service tracker in the bundle Activator I get a NullPointerException with 
>> the message the cron syntax is incorrect.
>> When I stop and start the bundle in the running session all of a sudden see 
>> the println statement output.
>> It seems I need to start the Scheduler Service or the CronComponent service 
>> in some different order. (I assume the Scheduler service needs to be running 
>> first...)
>> How could this be done? 
>> With kind regards,
>> Misja Heuveling
>> 
>> 
>> ___
>> 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] Alternatives to DynamicImport for distributed events

[Peter Kriens]

- Don’t use any type not in the JVM
- Encode the version in the payload
- Don’t use Java serialisation but use JSON and use the available types on the 
receiving side to map the JSON back. If the type is not available turn it into 
a Map. Receivers can easily turn a map back into a DTO if they want to.

This is one of the most vexing problems in software. Most developers want the 
convenience of automatic serialisation but forget that it is really hard to 
ensure a consistent class space between different processes. Keeping the types 
on the wire simple makes life a lot easier imho.

Kind regards,

Peter Kriens


> On 1 Jun 2017, at 10:26, João Assunção <joao.assun...@exploitsys.com> wrote:
> 
> Hello all,
> 
> I'm working in a service to support distributed events across OSGi 
> containers. By distributed events, I mean forwarding events from one Event 
> Admin to a Event Admin running in separate OSGi container. For this purpose 
> I'm using Hazelcast.
> Due to object serialization in Hazelcast and to avoid ClassNotFoundExceptions 
> my bundle uses DynamicImport-Package: *. The reasoning behind the * is that I 
> don't know what classes might be in the event payload.
> This works but I'm not satisfied with this DynamicImport solution. 
> Can anyone suggest me alternatives?
> Thanks in advance.
>  
> Regards,
> 
> João Assunção
> 
> Email: joao.assun...@exploitsys.com <mailto:joao.assun...@exploitsys.com>
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com <http://www.exploitsys.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] Am I allowed to use OSGI-INF?

[Peter Kriens]

OSGi uses this directory for the spec so I would place your files in a 
directory that is less likely to conflict. However, if you use a subdirectory 
in OSGI-INF with a reversed domain name you’re pretty sure there will never be 
conflicts.

Kind regards,

Peter Kriens

> On 30 May 2017, at 17:59, Mark Raynsford <list+org.o...@io7m.com> wrote:
> 
> Both the core and compendium specs make references to this directory,
> but I can't find anything in either of them that states whether or not
> developers are permitted to put their own metadata in this directory.
> Is the use of this directory reserved for services defined within the
> spec?
> 
> I'd like to place a single file in this directory, the existence of
> which my bundle tracker would use to determine that it should attempt
> to process the bundle in order to register resources.
> 
> 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

Re: [osgi-dev] Publishing resources with respect to versioning

[Peter Kriens]

You can always look in your own bundle first, I cannot see how that could harm. 
Seems also nice to be able to override things.

Kind regards,

Peter Kriens

> On 29 May 2017, at 23:29, Mark Raynsford <list+org.o...@io7m.com> wrote:
> 
> I have a work-in-progress implementation that does the following:
> 
> Bundle B declares:
> 
>  Provide-Capability:\
>com.io7m.callisto.package;\
>  name:String=a.b.c;
>  version:Version=1
> 
> This is analogous to the standard Export-Package header.
> This above definition "exports" the package "a.b.c". When B is processed
> by the bundle tracker, the tracker sees the above export and inspects
> "/a/b/c/package-info.cpd". The package-info.cpd file contains a list
> of resources that will be exported along with their "resource
> identifiers". An example package-info.cpd file:
> 
>  package a.b.c
>  resource hello0 text something.txt
>  resource hello1 image example.png
> 
> The above declares that two resources will be exported with
> identifiers a.b.c.hello0 and a.b.c.hello1. The bundle tracker resolves
> the given relative filenames to their full bundle resource URLs, and
> builds and maintains a map of the resources exported by each bundle
> being tracked.
> 
> Bundle C declares:
> 
>  Require-Capability:\
>com.io7m.callisto.package;\
>  filter=(&(name=a.b.c)(version>=1)(version<2))
> 
> When C wants to access resource a.b.c.hello0, the ResourceResolver
> service inspects the wires of C in namespace com.io7m.callisto.package
> and picks the wire that provides ("exports") package a.b.c to C. A
> wire is guaranteed by the OSGi resolver to exist if C has correctly
> "imported" a.b.c using the above Require-Capability definition. The
> resource is resolved from bundle B.
> 
> This all works well except for one small issue... Bundles must manually
> require their own exported packages if they want to resolve their own
> resources via the ResourceResolver service. The OSGi resolver
> (correctly) won't wire a bundle to itself if it doesn't specify a
> Require-Capability header that effectively requires its own packages.
> 
> I could probably manually add in a hack to try resolving a resource
> directly from the requesting bundle first, and then falling back to the
> proper resolution path above if the bundle doesn't export the target
> package, but this feels untidy. I'm not sure if I'd accidentally be
> subverting the work that the OSGi resolver has done.
> 
> It seems unpleasant for users to have to redundantly "import" their own
> packages. Is there a better way to handle this?
> 
> 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

Re: [osgi-dev] Publishing resources with respect to versioning

[Peter Kriens]

> On 26 May 2017, at 17:18, Mark Raynsford <list+org.o...@io7m.com> wrote:
> Hello!
> On 2017-05-26T14:23:43 +0200
> Peter Kriens <peter.kri...@aqute.biz> wrote:
>> Yes, you can reuse the Req/Cap model in OSGi for this.
>> 
>> I understand the problem is that bundle A.1 uses bundle B.1 and A.2 uses 
>> B.2. If A.1 loads a resource X, then it should originate form B.1 and A.2 
>> should load from B.2?
> Yes, that's exactly it.
>> If you use the resource services as mandatory dependencies in DS then you 
>> must register the services with a property and use the target filter on the 
>> consuming side. A bit awkward since it should contain a version. This does 
>> not have to be the OSGi bundle version but that of course makes it easier. 
>> One trick is to make the version a Java constant. You can then refer to this 
>> constant in a bnd package version annotation AND in your target filter. 
>> (Assuming you use bnd.)
> That might not be so bad.

>> Another trick is to use a class/interface specific for each application...
> I'm not sure about this one (I think it may be impractical for reasons
> I won’t go into here), but I'll keep it in mind.
From a class space sharing technique it is the easiest :-) Everything is taken 
care of for free.

>> If the services are not involved in DS dependencies then there is another 
>> solution. First, A.1 must require B1 in some defined namespace. This can be 
>> osgi.wiring.bundle or osgi.wiring.package if you have a package name that is 
>> shared. You can also define your own namespace.
> I'm not sure what you mean by "some defined namespace". Do you mean
> something along the lines of:
> 
>  Provide-Capability:
>
> com.io7m.example.resource_package;name:String="a.b.c";version:Version="1.0.0"
> 
> ... and:
> 
>  Require-Capability:
>com.io7m.example.resource_package;filter:="(&(name=a.b.c)(version=1.0.0))"
> 
> ?
Jup.

>> You should then register as a DS service factory.
> Is this a specific reference to something in DS, or is it just a
> general term describing a service that instantiates other services?
Ok, I should have used service scopes, the @Component.servicefactory() is 
deprecated.

Service Scopes:

singleton   1 instance shared by all
bundle  instance per bundle
prototype   special, can handle 1 instances per get

>> When you get a request you get the calling bundle. Through the bundle
>> you can find out to what bundles it is wired to in the given
>> namespace. 
> Can you explain a little more about this? I don't see anything in the
> Bundle interface, is there some specific API for accessing wiring?

You can get a BundleWiring from a Bundle.adapt(BundleWiring.class). This 
provides you access to the wires.

> 
>> You can then do the resource request. Clearly, this
>> requires that one DS component is shared between all versions of
>> applications. In this model the easiest is to register a single
>> service for all resources.
> Yes, I think in practice, there'd be a single ResourceResolver service
> through which all requests are made.

So then the wiring traversing should work fine.

Kind regards,

Peter Kriens

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

Re: [osgi-dev] Publishing resources with respect to versioning

[Peter Kriens]

Yes, you can reuse the Req/Cap model in OSGi for this.

I understand the problem is that bundle A.1 uses bundle B.1 and A.2 uses B.2. 
If A.1 loads a resource X, then it should originate form B.1 and A.2 should 
load from B.2?

If you use the resource services as mandatory dependencies in DS then you must 
register the services with a property and use the target filter on the 
consuming side. A bit awkward since it should contain a version. This does not 
have to be the OSGi bundle version but that of course makes it easier. One 
trick is to make the version a Java constant. You can then refer to this 
constant in a bnd package version annotation AND in your target filter. 
(Assuming you use bnd.)

Another trick is to use a class/interface specific for each application. If B 
exports this class R then your resource service will register a B.R and A will 
require B.R. Another application consisting of C and D will use D.R. 

Since R is now versioned, A.1 will see the B.1.R and A.2 will see the B.2.R. 
Then everything works out of the box. 

interface ResourceAvailable {
URL getResource( String name );
}

interface B.R extends ResourceAvailable {}
interface D.R extends ResourceAvailable {}

If the services are not involved in DS dependencies then there is another 
solution. First, A.1 must require B1 in some defined namespace. This can be 
osgi.wiring.bundle or osgi.wiring.package if you have a package name that is 
shared. You can also define your own namespace.

You should then register as a DS service factory. When you get a request you 
get the calling bundle. Through the bundle you can find out to what bundles it 
is wired to in the given namespace. You can then do the resource request. 
Clearly, this requires that one DS component is shared between all versions of 
applications. In this model the easiest is to register a single service for all 
resources.

Hope this helps, kind regards,

Peter Kriens




> On 26 May 2017, at 13:16, Fauth Dirk (AA-AS/EIS2-EU) 
> <dirk.fa...@de.bosch.com> wrote:
> 
> Hi,
> 
> AFAIK capabilities are used to resolve bundles. They will not help to 
> restrict the referenced services. That means if you reference resource 
> services of a special type in a consumer service, you can not specify which 
> service should be injected by using capabilities.
> 
> For restricting the services that should be injected you can use the target 
> reference property. The value is an LDAP filter that can inspect service 
> properties to select the target services that should be referenced. So you 
> could for example specify a version property on your services and specify a 
> target filter in our consumer.
> 
> It is also possible to dynamically change the target filter using the 
> Configuration Admin.
> 
> I wrote about this in one of my blog posts: 
> http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/
> 
> Mit freundlichen Grüßen / Best regards
> 
> Dirk Fauth
> 
> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) 
> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | 
> www.bosch.com
> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com
> 
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; 
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
> Denner, 
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
> Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Peter Tyroller
> 
> 
> -Ursprüngliche Nachricht-
> Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> Im Auftrag von Mark Raynsford
> Gesendet: Freitag, 26. Mai 2017 12:54
> An: osgi-dev@mail.osgi.org
> Betreff: [osgi-dev] Publishing resources with respect to versioning
> 
> Hello.
> 
> As stated previously, I'm working on a commercial (but open source) game 
> project. I'm currently working on the code to load resources into the engine 
> (the "resource manager"). A "resource" in this case can be more or less 
> anything: Sounds, images, game levels, 3D models, compiled Java code, NPC 
> definitions, etc. A major design requirement for the engine is to have a 
> strongly versioned code and resource package system with proper dependency 
> handling. Obviously, I'm delegating all of this work to OSGi.
> 
> Exposing Java code as services is obviously not a problem; we use declarative 
> services and the like. However, I also wanted it to be possible to expose 
> non-code resources in some manner. A while back, I was advised to use a 
> BundleTracker to expose non-code resources inside bundles as services [0]. 
> This works well enough, but the problem is that I'm not sure how to properly 
> expose the serv

Re: [osgi-dev] enroute quickstart tutorial problems - New Bnd OSGi Workspace - Distro->org.osgi:osgi.enroute.pom.distro [!]->2.0.0.SNAPSHOT [java.lang.NullPointerException]

[Peter Kriens]

I’ve updated the next branch to not have the -SNAPSHOT. Not sure really where 
that came from anyway.

Kind regards,

Peter Kriens

> On 18 May 2017, at 17:54, BBrooks <brian.bro...@acm.org> wrote:
> 
> > It should be without the SNAPSHOT. Can you recall how the -SNAPSHOT got in 
> > there?
> 
> The "-SNAPSHOT" came from the osgi/workspace GitHub Repository.
> 
> When I did 
> 
> 1. Eclipse->File->New->Other
> 2. Eclipse shows New->Select a wizard"
> 3. Selected Bndtools->Bnd OSGi Workspace and clicked Next.
> 4. Eclipse shows "Setup Bnd Workspace".
> 5. Click Location->Create in->c:\dev\git\com.acme.prime and clicked Next.
> 6. Eclipse shows "Selecte Workspace Template".
> 7. Selected GitHub->osgi/workspace [https://github.com/osgi/workspace.git 
> <https://github.com/osgi/workspace.git> next] and clicked Next.
> 8. Eclipse shows Preview Changes.
> 9. Clicked Finish.
> 10. Eclipse creates a cnf project and switches to Bndtools Perspective.
> 
> The bnd project created by Eclipse already contains the erroneous "-SNAPSHOT" 
> in cnf/ext/enroute-distro.bnd.  I think it's getting downloaded from 
> 
> https://github.com/osgi/workspace/blob/next/cnf/ext/enroute-distro.bnd 
> <https://github.com/osgi/workspace/blob/next/cnf/ext/enroute-distro.bnd>
> 
> the current revision 
> https://github.com/osgi/workspace/commit/862f1d9bc0b6ad79ef578c85503ef17f54d60bda
>  
> <https://github.com/osgi/workspace/commit/862f1d9bc0b6ad79ef578c85503ef17f54d60bda>
>  has an -plugin.enroute.distro entry with the "-SNAPSHOT" text.  Doing Blame 
> on that file shows it has had that -SNAPSHOT for 7 months. 
> 
> Brian
> 
> 
> On Thu, May 18, 2017 at 10:16 AM, Peter Kriens <peter.kri...@aqute.biz 
> <mailto:peter.kri...@aqute.biz>> wrote:
> On the current workspace the bndpom repo looks like:
> 
> -plugin.enroute.distro = \
>   aQute.bnd.repository.maven.pom.provider.BndPomRepository; \
>   snapshotUrls=https://oss.sonatype.org/content/groups/osgi 
> <https://oss.sonatype.org/content/groups/osgi>; \
>   releaseUrls=https://repo1.maven.org/maven2/ 
> <https://repo1.maven.org/maven2/>; \
>   revision=org.osgi:osgi.enroute.pom.distro:2.0.0; \
>   name=Distro; \
>   location=${build}/cache/enroute-distro.xml
> 
> 
> 
> It should be without the SNAPSHOT. Can you recall how the -SNAPSHOT got in 
> there?
> 
> Kind regards,
> 
>   Peter Kriens
> 
> 
>> On 18 May 2017, at 16:11, BBrooks <brian.bro...@acm.org 
>> <mailto:brian.bro...@acm.org>> wrote:
>> 
>> I'm trying to follow the Enroute Quick Start Tutorial.  But I got stuck with 
>> this build error
>> 
>> Cannot find /error/osgi.enroute.base.api;version=0 Not found in [bnd-cache, 
>> Central, Local, Release, Distro]
>> 
>> I don't know how to fix this problem.  I think the root cause is that the 
>> Distro repository seems to be invalid.
>> 
>> What is the correct cnf/ext/enroute-distro.bnd?  The steps in the tutorial 
>> resulted in an enroute-distro.bnd that looks like
>> 
>> -plugin.enroute.distro = \
>>  aQute.bnd.repository.maven.pom.provider.BndPomRepository; \
>>  snapshotUrls=https://oss.sonatype.org/content/groups/osgi 
>> <https://oss.sonatype.org/content/groups/osgi>; \
>>  releaseUrls=https://repo1.maven.org/maven2/ 
>> <https://repo1.maven.org/maven2/>; \
>>  revision=org.osgi:osgi.enroute.pom.distro:2.0.0-SNAPSHOT; \
>>  name=Distro; \
>>  location=${build}/cache/enroute-distro.xml
>> 
>> I found some August 2016 information here 
>> https://disqus.com/home/discussion/osgi-enroute/forum_49/ 
>> <https://disqus.com/home/discussion/osgi-enroute/forum_49/> suggesting using 
>> the URL 
>> https://raw.githubusercontent.com/osgi/osgi.enroute/master/cnf/distro/index.xml
>>  
>> <https://raw.githubusercontent.com/osgi/osgi.enroute/master/cnf/distro/index.xml>.
>>   But using that location didn't work either.
>> 
>> Below I'm documenting what I did and some of the errors I'm 
>> noticing*
>> 
>> I noticed in this page
>> 
>> http://enroute.osgi.org/qs/200-workspace.html 
>> <http://enroute.osgi.org/qs/200-workspace.html>
>> 
>> this text
>> 
>> "WARNING: This is the BETA tutorial for OSGi enRoute 2.0.0. To use the right 
>> workspace template, go to Bndtools preferences and select Workspace 
>

Re: [osgi-dev] enroute quickstart tutorial problems - New Bnd OSGi Workspace - Distro->org.osgi:osgi.enroute.pom.distro [!]->2.0.0.SNAPSHOT [java.lang.NullPointerException]

[Peter Kriens]

On the current workspace the bndpom repo looks like:

-plugin.enroute.distro = \
aQute.bnd.repository.maven.pom.provider.BndPomRepository; \
snapshotUrls=https://oss.sonatype.org/content/groups/osgi; \
releaseUrls=https://repo1.maven.org/maven2/; \
revision=org.osgi:osgi.enroute.pom.distro:2.0.0; \
name=Distro; \
location=${build}/cache/enroute-distro.xml



It should be without the SNAPSHOT. Can you recall how the -SNAPSHOT got in 
there?

Kind regards,

Peter Kriens


> On 18 May 2017, at 16:11, BBrooks <brian.bro...@acm.org> wrote:
> 
> I'm trying to follow the Enroute Quick Start Tutorial.  But I got stuck with 
> this build error
> 
> Cannot find /error/osgi.enroute.base.api;version=0 Not found in [bnd-cache, 
> Central, Local, Release, Distro]
> 
> I don't know how to fix this problem.  I think the root cause is that the 
> Distro repository seems to be invalid.
> 
> What is the correct cnf/ext/enroute-distro.bnd?  The steps in the tutorial 
> resulted in an enroute-distro.bnd that looks like
> 
> -plugin.enroute.distro = \
>   aQute.bnd.repository.maven.pom.provider.BndPomRepository; \
>   snapshotUrls=https://oss.sonatype.org/content/groups/osgi 
> <https://oss.sonatype.org/content/groups/osgi>; \
>   releaseUrls=https://repo1.maven.org/maven2/ 
> <https://repo1.maven.org/maven2/>; \
>   revision=org.osgi:osgi.enroute.pom.distro:2.0.0-SNAPSHOT; \
>   name=Distro; \
>   location=${build}/cache/enroute-distro.xml
> 
> I found some August 2016 information here 
> https://disqus.com/home/discussion/osgi-enroute/forum_49/ 
> <https://disqus.com/home/discussion/osgi-enroute/forum_49/> suggesting using 
> the URL 
> https://raw.githubusercontent.com/osgi/osgi.enroute/master/cnf/distro/index.xml
>  
> <https://raw.githubusercontent.com/osgi/osgi.enroute/master/cnf/distro/index.xml>.
>   But using that location didn't work either.
> 
> Below I'm documenting what I did and some of the errors I'm 
> noticing*
> 
> I noticed in this page
> 
> http://enroute.osgi.org/qs/200-workspace.html 
> <http://enroute.osgi.org/qs/200-workspace.html>
> 
> this text
> 
> "WARNING: This is the BETA tutorial for OSGi enRoute 2.0.0. To use the right 
> workspace template, go to Bndtools preferences and select Workspace 
> Templates. You should edit the OSGi enRoute template and select the next 
> branch."
> 
> In response to this text, I completed these steps.
> 
> 1. Eclipse->Preferences->Bndtools->Workspace Template->GitHub Repositories
> 2. Click osgi/workspace
> 3. Click Edit.
> 4. In the Add Repository tab entered these values
> Repository Name: osgi/workspace
> Branch: next
> 5. Click Validate.
> 6. Eclipse confirms with "Validated! Clone URL is 
> 'https://github.com/osgi/workspace.git 
> <https://github.com/osgi/workspace.git>'. Default branch 'origin/master'"
> 7. Click Save.
> 8. Eclipse updates osgi/workspace to read "osgi/workspace; branch=next".
> 
> Then I executed the steps in the "Creating the bnd Workspace" section of 
> 200-workspace.html.  After clicking "Finish" in the workspace creation 
> Wizard.  I noticed that the Eclipse "Repositories" view contains a Distro 
> that appears to have a problem.  Expanding the Distro repository reveals
> 
> Distro->org.osgi:osgi.enroute.pom.distro [!]->2.0.0.SNAPSHOT 
> [java.lang.NullPointerException]
> 
> The Eclipse Error Log view contains
> Failed to query repository Distro for bundle org.osgi:osgi.enroute.pom.distro 
> version 2.0.0.SNAPSHOT.
> 
> Eclipse plugin: bndtools.core
> Caused by: java.io.FileNotFoundException: For Maven artifact 
> org.osgi:osgi.enroute.pom.distro:2.0.0-SNAPSHOT
>   at aQute.maven.provider.MavenRepository$1.run(MavenRepository.java:140)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> 
> -- 
> brian.bro...@acm.org 
> <mailto:brian.bro...@acm.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] FileSystemProvider for OSGi bundle

[Peter Kriens]

Notice that the bundle: scheme is opaque. It is not standardised that it 
follows the syntax as you showed, nor is it guaranteed to be a JAR. The only 
thing guaranteed is the hierarchical nature of the path.

Since there is no way to get the directory listing from this URL there is no 
good way to create a file system on it.

Kind regards,

Peter Kriens



> On 17 May 2017, at 20:55, Simon Chemouil <ecli...@mithrandir.net> wrote:
> 
> Michael Lipp a écrit le 16/05/2017 à 23:39 :
>> Hi,
>> 
>> I searched to no avail. Does anybody know of an implementation of
>> FileSystemProvider
>> (https://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html)
>> that supports the "bundle:" scheme (similar to the Zip File System
>> Provider:
>> https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html)?
>> 
>> I have code that relies on a directory tree of resources to be available
>> as NIO FileSystem. This is no problem when the using the "ordinary"
>> class loading. The "root" is found using a resource lookup (URI resSrc =
>> this.getClass().getResource("").toURI();). This returns a URI with
>> scheme "jar", which can be passed to FileSystems.newFileSystem. When
>> running in the OSGi environment, I get a URI with the "bundle" scheme...
> 
> Hi,
> 
> I have searched before and did not find any. Here's a summary of my
> previous exploration on the topic:
> 
> My conclusion is that there is no proper way to do it without being the
> system bundle. The thing is Nio Filesystems have non-blocking IO methods
> (eg AsynchronousFileChannels) and Bundles are opaque, might be stored in
> memory (e.g installing/updating a bundle from an InputStream). A partial
> solution for bundles only stored in disk is not reliable either, because
> the bundle "location" can be anything, and is rarely if ever an absolute
> path... recomposing an absolute path from the workingDir + the location
> might work in some cases, but that's super hackish.  Then, the only way
> to work with them is blocking (reading a resource can only be done
> through URL#openStream())
> 
> Blocking methods from the NIO filesystem provider could be implemented
> on top of those, but the non-blocking ones would have to be backed by a
> thread-pool, read extra bytes (it's possible with an
> AsyncFileChannel/RandomAccessFile to start reading at a random position)
> and in that case you might as well go for blocking methods and be "fake
> non-blocking" with your own thread-pool. Or they could throw
> UnsupportedOperationException, but that would probably break your
> consumer code, and it's a bit sad considering that's a big part of what
> Nio filesystems add to the File API!
> 
> Because this probably requires a significant refactor of existing system
> bundles, my quick solution has been to lazily copy Bundle resources,
> when asked for, to the bundle storage area, and then use the regular
> filesystem API (since the bundle storage area is on disk). You can see
> how it's used there [1] (I happen to wrap it in reactive streams [2] for
> composition)
> 
> Why go through all the trouble? First benefit is using nio.Files/Path
> API to abstract over different file-systems, another is to be able to
> have back-pressure with non-blocking consumers.
> 
> The good news is, because those URLs are of the form
> bundle://./resource, it does not need an
> update of the OSGi APIs, the system bundle can implement it, however as
> far as I know there are no implementation for open source frameworks,
> maybe there are on some proprietary ones ; and maybe it should be part
> of a future OSGi core spec, because that code is going to break on
> frameworks not implementing the extension!
> 
> While it does not seem too hard to implement for bundles that stored on
> a file system (default filesystem provider), or as a jar file (zip
> filesystem), it is probably trickier for in memory-bundles: however
> there are existing open source in-memory filesystems like jimfs that
> could be used as a back-end, and the current Bundle IO/resource methods
> could wrap Jimfs newInputStream() calls.
> 
> Hope this helps,
> 
> Simon
> 
> [1]
> https://github.com/primeval-io/primeval-codex/blob/master/src/test/java/io/primeval/codex/io/impl/ResourceFinderReaderImplTest.java
> [2] http://www.reactive-streams.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] Dep resolution fails with missing requirement controllers

[Peter Kriens]

It seems that it is looking for a package called ‘controllers’ and can’t find 
anyone exporting it.

Bndtools has a ‘Resolution view’. Select the JAR in the Repository view and it 
should give you the information of its requirements and capabilities. You can 
also search for packages in Bndtools, click on the flashlight in the repository 
view.

Once there was JPM of course :-( I’ve heard you can also search for packages on 
maven central.

Kind regards,

Peter Kriens

> On 27 Apr 2017, at 12:11, Henrik Niehaus <henrik.nieh...@gmx.de> wrote:
> 
> I'm trying to create a bundle, which contains a library with a lot of 
> dependencies. While working through all the missing dependencies, I now got 
> this error, which doesn't mean anything to me. Can someone shine some light 
> on this? What does this mean and how can I find out, which dependency causes 
> the problem?
> 
> Unable to resolve <> version=null:
>   missing requirement de.fraunhofer.abm.projectanalyzer.hermes
> ->  Unable to resolve de.fraunhofer.abm.projectanalyzer.hermes 
> version=0.0.9.201704270958:
>   missing requirement controllers]
> 
> I also took a screenshot of the bndtools resolution dialog: 
> http://i.imgur.com/Sc5TVFy.png
> 
> I'm using Eclipse Neon with bndtools 3.3.0.REL-20160922-205148-g069791c
> 
> 
> Thanks,
> 
> Henrik
> 
> ___
> 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] handling optional/dynamic imports in DS

[Peter Kriens]

How do you include the org.osgi.service.cm package? This is trivial in bnd but 
I recall it was tricky in PDE?

Did you verify that the package is inside the bundle?

Kind regards,

Peter Kriens

> On 26 Apr 2017, at 10:02, Fauth Dirk (AA-AS/EIS2-EU) 
> <dirk.fa...@de.bosch.com> wrote:
> 
> Interestingly this works fine when running from Bndtools with Felix.
>  
> If I try the same with Equinox for projects created with PDE I get a 
> NullPointerException. IIRC Private-Package is something special to Bnd. Is 
> that correct? I wonder if that exception is caused by some PDE flaws or if it 
> is an issue in Equinox Oxygen. In both cases Apache Felix SCR 2.0 is used. 
> (in Oxygen 2.0.8 and in Bndtools 2.0.2)
>  
> org.osgi.framework.ServiceException: Exception in 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService()
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:222)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
>at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624)
>at 
> org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)
>at 
> org.apache.felix.scr.impl.inject.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:985)
>at 
> org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2201)
>at 
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleStaticReluctantCustomizer.prebind(DependencyManager.java:699)
>at 
> org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1520)
>at 
> org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1006)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859)
>at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)
>at java.security.AccessController.doPrivileged(Native Method)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508)
>at 
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)
>at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624)
>at 
> org.apache.felix.gogo.runtime.CommandProxy.getTarget(CommandProxy.java:50)
>at 
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:72)
>at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>at 
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>at 
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>at org.apache.felix.gogo.shell.Console.run(Console.java:62)
>at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
>at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:498)
>at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>at 
> org.apache.felix.gogo.runtime.CommandProxy.execute(Command

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

[Peter Kriens]

I used to import the package optional and then provide it as an internal 
Private-Package. The import has priority but the internal package is used when 
the import fails to resolve. Since you’re then always wired to a package you 
can handle dependencies on the place they should be handled: services.

This keeps everybody happy internally for very little cost. I’ve included a 
bndtools/enRoute example.

Kind regards,

Peter Kriens


— bnd.bnd
Private-Package: \
org.osgi.service.cm,\
com.foo.provider

Import-Package: \
org.osgi.service.cm;resolution:=optional,\
*

-buildpath: \
osgi.enroute.base.api
-runrequires: \
osgi.identity;filter:='(osgi.identity=com.foo.provider)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)'
-runbundles: \
com.foo.provider;version=snapshot,\
org.apache.felix.log;version='[1.0.1,1.0.2)',\
org.apache.felix.scr;version='[2.0.2,2.0.3)',\
org.apache.felix.gogo.runtime,\
org.apache.felix.gogo.shell;version=0.16

— com.foo.provider.Optional
@Component
public class Optional
{
   @Reference(cardinality=ReferenceCardinality.OPTIONAL)
   ConfigurationAdmin admin;

   @Activate
   void activate() {
  System.out.println("activate " + admin);
   }
}

> On 25 Apr 2017, at 23:10, Raymond Auge <raymond.a...@liferay.com> wrote:
> 
> I'm wondering if there is a reasonable model for handling optional or dynamic 
> package imports in DS.
> 
> While optionality at the package level is not an ideal model, sometimes it 
> can't be avoided.
> 
> I'd like to know if others have come across a "reasonable" way to model this 
> in DS.
> 
> Sincerely,
> -- 
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@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] Start Ordering in OSGi

[Peter Kriens]

There only needs to be a single implementation, it will learn its properties 
from other services. If we standardize it then any developer can leverage it.

Kind regards,

Peter Kriens



> On 24 Apr 2017, at 19:12, Peter Kriens <peter.kri...@aqute.biz> wrote:
> 
> I’ve written a blog about start ordering issues in OSGi and a potential 
> solution. This likely will interest many since it is a vexing OSGi problem.
> 
> Feedback appreciated.
> 
>   http://aqute.biz/2017/04/24/aggregate-state.html 
> <http://aqute.biz/2017/04/24/aggregate-state.html>
> 
> Kind regards,
> 
>   Peter Kriens
> 

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

[osgi-dev] Start Ordering in OSGi

[Peter Kriens]

I’ve written a blog about start ordering issues in OSGi and a potential 
solution. This likely will interest many since it is a vexing OSGi problem.

Feedback appreciated.

http://aqute.biz/2017/04/24/aggregate-state.html 
<http://aqute.biz/2017/04/24/aggregate-state.html>

Kind regards,

    Peter Kriens

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

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

[Peter Kriens]

Well, the ServiceFactory is just a way to indirect the creation of the 
actual instance. I do not see why such a pattern theoretically could not be 
used for DS as well?

All the rules could stay the same, however, DS would ask the component instance 
for the service instance to register instead of assuming this is always the 
component instance. The difference would be that getService() would only be 
called once for any given instance since cardinality would be handled by DS.

Kind regards,

Peter Kriens






> On 20 Apr 2017, at 19:26, BJ Hargrave <hargr...@us.ibm.com> wrote:
> 
> When DS registers your component as a service, it already registers its own 
> object implementing ServiceFactory. This is necessary to register the service 
> while still allowing delayed activation of your component. So DS's 
> ServiceFactory object is called by the framework when someone gets the 
> service and then DS will instantiate and activate your service component. How 
> many times this is done is controlled by scope of the component: singleton, 
> bundle, prototype.
>  
> The basic point is that DS must be in charge of constructing and activating 
> component instances and so your component implemention ServiceFactory does 
> not work with that. With plans to support constructor injection in DS 1.4, 
> this is even more important to the DS component model.
> --
> 
> 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: Julian Sedding <jsedd...@gmail.com>
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Cc:
> Subject: Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?
> Date: Thu, Apr 20, 2017 9:39 AM
>  
> Hi Tim
> 
> That's an interesting approach! I hadn't considered using DS but
> handling the service registration myself.
> 
> To me it would have felt consistent if registering a ServiceFactory as
> a service using DS had just worked. Next to controlling the scope
> (singleton, bundle, prototype) of a service,  a ServiceFactory seems
> suitable to creating service objects by means other than their default
> constructor. Thus, supporting ServiceFactories in DS would make it
> very easy to provide OSGi-glue for arbitrary Java classes that are
> themselves unaware of OSGi.
> 
> Of course there is a trade-off between the usefulness of a feature and
> bloating the spec. And I'll leave this decision with you guys.
> 
> Regards
> Julian
> 
> 
> On Thu, Apr 20, 2017 at 12:35 PM, Timothy Ward <tim.w...@paremus.com> wrote:
> > DS isn’t intended to solve every single use case, rather to make common use 
> > cases simple to write and understand. In this case what you want is more 
> > advanced, and unlikely to make it into DS as a natively supported pattern. 
> > Given that you’re already tied to the core OSGi API (ServiceFactory) then 
> > registering the service programatically would still let DS help you with 
> > config and service injection.
> >
> >
> > @Component(
> >// Do not let DS provide the service
> >service = {},
> >configurationPolicy = ConfigurationPolicy.REQUIRE
> > )
> > public class FooServiceFactory implements ServiceFactory {
> >
> >@Reference // provides FooBuilder instances that are pre-configured via 
> > OSGi
> >private FooBuilderFactory fooBuilderFactory;
> >
> >private ServiceRegistration reg;
> >
> >   @Activate
> >   void start(BundleContext ctx, Map<String, Object> props, Config config) {
> >   reg = ctx.registerService(Foo.class.getName(), this, props);
> >   }
> >
> >   @Deactivate
> >   void stop() {
> >   reg.unregister();
> >   }
> >
> >@Override
> >public Foo getService() {
> >FooBuilder fooBuilder = fooBuilderFactory.builder();
> >applyConfiguration(fooBuilder);
> >return fooBuilder.build();
> >}
> >
> >private void applyConfiguration(FooBuilder fooBuilder) {
> >// apply OSGi configuration to FooBuilder object
> >}
> >
> >... // ungetService omitted for brevity
> >
> > }
> >
> >
> > Regards,
> >
> > Tim
> >
> >
> >> On 20 Apr 2017, at 11:11, Julian Sedding <jsedd...@gmail.com> wrote:
> >>
> >> Hi Timothy
> >>
> >> Thanks for your reply. Using delegation works, I currently use it to
> >> solve my use-case.
> >&g

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

[Peter Kriens]

Yes, that would solve this issue.

Kind regards,

Peter Kriens


> On 20 Apr 2017, at 14:02, Tim Ward <tim.w...@paremus.com> wrote:
> 
> Peter - I assume that you mean that there will be no auto-generated 
> osgi.service capability. Couldn't that be fixed with an additional annotation 
> on the component type to add the Provide-Capability to the manifest?
> 
> Tim Ward
> 
> Sent from my iPhone
> 
>> On 20 Apr 2017, at 12:38, Peter Kriens <peter.kri...@aqute.biz> wrote:
>> 
>> But then you loose the DS dependency management on Foo … Since your 
>> FooServiceFactory no longer promises to provide a Foo service :-(
>> 
>> Kind regards,
>> 
>>   Peter Kriens
>> 
>> 
>>> On 20 Apr 2017, at 12:35, Timothy Ward <tim.w...@paremus.com> wrote:
>>> 
>>> DS isn’t intended to solve every single use case, rather to make common use 
>>> cases simple to write and understand. In this case what you want is more 
>>> advanced, and unlikely to make it into DS as a natively supported pattern. 
>>> Given that you’re already tied to the core OSGi API (ServiceFactory) then 
>>> registering the service programatically would still let DS help you with 
>>> config and service injection.
>>> 
>>> 
>>> @Component(
>>> // Do not let DS provide the service
>>> service = {},
>>> configurationPolicy = ConfigurationPolicy.REQUIRE
>>> )
>>> public class FooServiceFactory implements ServiceFactory {
>>> 
>>> @Reference // provides FooBuilder instances that are pre-configured via OSGi
>>> private FooBuilderFactory fooBuilderFactory;
>>> 
>>> private ServiceRegistration reg;
>>> 
>>> @Activate
>>> void start(BundleContext ctx, Map<String, Object> props, Config config) {
>>>reg = ctx.registerService(Foo.class.getName(), this, props);
>>> }
>>> 
>>> @Deactivate
>>> void stop() {
>>>reg.unregister();
>>> }
>>> 
>>> @Override
>>> public Foo getService() {
>>> FooBuilder fooBuilder = fooBuilderFactory.builder();
>>> applyConfiguration(fooBuilder);
>>> return fooBuilder.build();
>>> }
>>> 
>>> private void applyConfiguration(FooBuilder fooBuilder) {
>>> // apply OSGi configuration to FooBuilder object
>>> }
>>> 
>>> ... // ungetService omitted for brevity
>>> 
>>> }
>>> 
>>> 
>>> Regards,
>>> 
>>> Tim
>>> 
>>> 
>>>> On 20 Apr 2017, at 11:11, Julian Sedding <jsedd...@gmail.com> wrote:
>>>> 
>>>> Hi Timothy
>>>> 
>>>> Thanks for your reply. Using delegation works, I currently use it to
>>>> solve my use-case.
>>>> 
>>>> However, compared to implementing a ServiceFactory, delegation adds
>>>> some overhead:
>>>> 
>>>> - delegation needs to be implemented, which is trivial, but noisy if
>>>> there are lots of methods that need delegating
>>>> - by delegating, my implementation becomes a "provider" of Foo, rather
>>>> than a "consumer", making my bundle more susceptible to changes in
>>>> Foo's API
>>>> - also: delegation is not possible if Foo is a final class
>>>> 
>>>> I brought up this topic in order to (a) confirm that my desired
>>>> approach is indeed not possible at the moment and (b) to see if adding
>>>> support for registering custom ServiceFactory implementations via DS
>>>> could be a desirable enhancement for the spec.
>>>> 
>>>> Regards
>>>> Julian
>>>> 
>>>> 
>>>>> On Thu, Apr 20, 2017 at 11:22 AM, Timothy Ward <tim.w...@paremus.com> 
>>>>> wrote:
>>>>> Have you not considered the following:
>>>>> 
>>>>> 
>>>>> @Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
>>>>> scope = ServiceScope.BUNDLE)
>>>>> public class FooImpl implements Foo {
>>>>> 
>>>>> public @interface Config {
>>>>>   // Config definition in here
>>>>> }
>>>>> 
>>>>> @Reference
>>>>> private FooBuilderFactory fooBuilderFactory;
>>>>> 
>>>>> private Foo delegate;
>>>>> 
>>>>> @Activate
>>>>> void start(

Re: [osgi-dev] Allow registering a (Prototype)ServiceFactory via DS?

[Peter Kriens]

But then you loose the DS dependency management on Foo … Since your 
FooServiceFactory no longer promises to provide a Foo service :-(

Kind regards,

Peter Kriens


> On 20 Apr 2017, at 12:35, Timothy Ward <tim.w...@paremus.com> wrote:
> 
> DS isn’t intended to solve every single use case, rather to make common use 
> cases simple to write and understand. In this case what you want is more 
> advanced, and unlikely to make it into DS as a natively supported pattern. 
> Given that you’re already tied to the core OSGi API (ServiceFactory) then 
> registering the service programatically would still let DS help you with 
> config and service injection.
> 
> 
> @Component(
>   // Do not let DS provide the service
>   service = {},
>   configurationPolicy = ConfigurationPolicy.REQUIRE
> )
> public class FooServiceFactory implements ServiceFactory {
> 
>   @Reference // provides FooBuilder instances that are pre-configured via OSGi
>   private FooBuilderFactory fooBuilderFactory;
> 
>   private ServiceRegistration reg;
> 
>  @Activate
>  void start(BundleContext ctx, Map<String, Object> props, Config config) {
>  reg = ctx.registerService(Foo.class.getName(), this, props);
>  }
> 
>  @Deactivate
>  void stop() {
>  reg.unregister();
>  }
> 
>   @Override
>   public Foo getService() {
>   FooBuilder fooBuilder = fooBuilderFactory.builder();
>   applyConfiguration(fooBuilder);
>   return fooBuilder.build();
>   }
> 
>   private void applyConfiguration(FooBuilder fooBuilder) {
>   // apply OSGi configuration to FooBuilder object
>   }
> 
>   ... // ungetService omitted for brevity
> 
> }
> 
> 
> Regards,
> 
> Tim
> 
> 
>> On 20 Apr 2017, at 11:11, Julian Sedding <jsedd...@gmail.com> wrote:
>> 
>> Hi Timothy
>> 
>> Thanks for your reply. Using delegation works, I currently use it to
>> solve my use-case.
>> 
>> However, compared to implementing a ServiceFactory, delegation adds
>> some overhead:
>> 
>> - delegation needs to be implemented, which is trivial, but noisy if
>> there are lots of methods that need delegating
>> - by delegating, my implementation becomes a "provider" of Foo, rather
>> than a "consumer", making my bundle more susceptible to changes in
>> Foo's API
>> - also: delegation is not possible if Foo is a final class
>> 
>> I brought up this topic in order to (a) confirm that my desired
>> approach is indeed not possible at the moment and (b) to see if adding
>> support for registering custom ServiceFactory implementations via DS
>> could be a desirable enhancement for the spec.
>> 
>> Regards
>> Julian
>> 
>> 
>> On Thu, Apr 20, 2017 at 11:22 AM, Timothy Ward <tim.w...@paremus.com> wrote:
>>> Have you not considered the following:
>>> 
>>> 
>>> @Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
>>>   scope = ServiceScope.BUNDLE)
>>> public class FooImpl implements Foo {
>>> 
>>>  public @interface Config {
>>> // Config definition in here
>>>  }
>>> 
>>>  @Reference
>>>  private FooBuilderFactory fooBuilderFactory;
>>> 
>>>  private Foo delegate;
>>> 
>>>  @Activate
>>>  void start(Config config) {
>>>  FooBuilder fooBuilder = fooBuilderFactory.builder();
>>>  applyConfiguration(fooBuilder, config);
>>>  delegate = fooBuilder.build();
>>>  }
>>> 
>>>  // Deactivation and Foo delegation methods go here
>>>  …
>>> }
>>> 
>>> Regards,
>>> 
>>> Tim
>>> 
>>>> On 20 Apr 2017, at 09:30, Julian Sedding <jsedd...@gmail.com> wrote:
>>>> 
>>>> Hi there
>>>> 
>>>> I have been trying to implement a use-case, but I seem to be running
>>>> into walls ;) (Disclaimer: I can see multiple ways to implement this,
>>>> but would like to re-use the dependency injection and lazy
>>>> instantiation of DS).
>>>> 
>>>> My aim is to create configured service objects in the way that is
>>>> normally achieved by using a DS factory component with
>>>> configuration-policy require.
>>>> 
>>>> The catch is that the implementation of the objects I want to
>>>> configure and register as a service is not under my control and is
>>>> instanciated via a builder obtained from a factory that is registered
>>>> as an OSGi-service. Sounds 

Re: [osgi-dev] Dokumentation Error

[Peter Kriens]

Thanks, fixed it. You can actually drag the URL on the ‘Local’ repository in 
the Repository view in Bndtools, slightly easier.

Kind regards,

Peter Kriens

> On 14 Apr 2017, at 08:43, Lothar Kluge <i...@lotharkluge.de> wrote:
> 
> Hi Peter,
> i found a Problem in the Tutorial.
> 
> The OSGi enRoute distro does not contain the Zookeeper discovery bundle. 
> We need to add this from Maven Central. 
> Look for org.amdatu.remote.discovery.zookeeper and copy the  
> element to the cnf/central.xml file.
> 
> the Problem
> 
> org.amdatu.remote.discovery.zookeeper 
> i can not find the in Maven Central
> 
> Solution
> Download the org.amdatu.remote.discovery.zookeeper.jar File from
> http://repository.amdatu.org/release/org.amdatu.remote.discovery.zookeeper/ 
> <http://repository.amdatu.org/release/org.amdatu.remote.discovery.zookeeper/>
> After the download open the Eclipse Bndtools view.
> Extend in cnf  Project the local folder.
> Drag the Download File in this local Folder.
> After Refresh the cnf Project you get a Result in Search Query from 
> Repositories.
> 
> 
> 
> Kind Regards
> 
> Lothar Kluge
> 
> Sie können verschlüsselte Mail zusenden.
> Abfrage mit UserId Lothar Kluge bei dem Keyserver
> http://pgp.mit.edu <http://pgp.mit.edu/>
> 
> Mobile +49 (0)177 3402118
> Tel +49 (0)2237 972800
> 
> 
> 
> 
> WICHTIGER HINWEIS:
> Diese Email ist vertraulich und nur für den beabsichtigten Empfänger 
> bestimmt. Der unberechtigte Zugriff, die Freigabe, Kopie oder Verteilung ist 
> strikt untersagt und kann gegen bestehende Gesetze verstoßen. Wenn sie diese 
> Nachricht irrtümlich erhalten oder sonstige Probleme damit haben, bitten wir 
> um sofortige Benachrichtigung des Absenders.
> 
> IMPORTANT NOTICE:
> This email is confidential and is for the intended recipient only. The 
> unauthorized access, disclosure, copying or distribution is strictly 
> prohibited and may be a criminal offence. If you have received this message 
> in error or if there are any problems please notify the originator 
> immediately.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] RHelp needed about Web Application with AngularJS

[Peter Kriens]

I recognise this problem … but I also recall there was a fix for this. I just 
looked at Felix but could not fid anything. I also do not see the code in the 
repository. Sigh, must have fixed it locally or it did not make the refactoring 
of this bundle.

I’ve pushed a fix for this.

Kind regards,

Peter Kriens

> On 3 Apr 2017, at 21:40, Mario Curcija <mario.curc...@gmail.com> wrote:
> 
> I noticed you both struggling with this one, so I gave it a try. While 
> debugging I ended in felix's ManifestParser class.
> 
> * Assumption:  
> Felix OSGi framework does not correctly prepares attributes for requirements. 
> 
> * enRoute part:
> The RestApplication class is annotated as follows:
> @RequireAngularWebResource(resource={"angular.js","angular-resource.js", 
> "angular-route.js"}, priority=1000)
> 
> Following enRoute method (find(String)) is responsible for finding resources 
> (*.js in this case) works correctly when running equinox based setup. The 
> object returned by attrs.get("resource") is (as expected) a List of String 
> instances with three elements as listed in annotation above. On the other 
> hand felix framework returns only plain String containing  comma separated 
> list of resources as specified in annotation.  This String will be later 
> converted to a List resulting with single element 
> ("angular.js","angular-resource.js", "angular-route.js"). It is obvious that 
> this entry does not exist bundle entries are resolved. 
>  
> osgi.enroute.web.server.provider.WebresourceServlet.find(String)
> 
> 
> BundleRequirement requirement = wire.getRequirement();
> 
> Map<String,Object> attrs = requirement.getAttributes();
> ...
> List resources = Converter.cnv(listOfStrings, 
> attrs.get("resource"));
> ... 
> for (String resource : resources) {
> if (glob.matcher(resource).matches()) {
> URL url = provider.getBundle().getEntry(root + 
> resource);
> if (url != null) {
> webresources.add(new WR(url, priority, 
> order++));
> } else {
> log.log(LogService.LOG_ERROR, "A web resource 
> " + resource + " from " + requirement + " in bundle "
> + bsn + "-" + version);
> return null;
> }
> }
> }
> ...
> 
> 
> * Felix - ManifestParser
>  
> I was able to reproduce it just by adding "following" test Method in:
> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-5.6.2/src/test/java/org/apache/felix/framework/util/manifestparser/ManifestParserTest.java
>  
> <http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-5.6.2/src/test/java/org/apache/felix/framework/util/manifestparser/ManifestParserTest.java>
> 
> org.apache.felix.framework.util.manifestparser.ManifestParserTest
> ..
> 
> @SuppressWarnings("unchecked")
> public void testAttributes() throws BundleException {
> Map<String, Object> headers = new HashMap<String, Object>();
> headers.put(Constants.BUNDLE_MANIFESTVERSION,  "2");
> headers.put(Constants.BUNDLE_SYMBOLICNAME, "com.example.test.sample");
> headers.put(Constants.PROVIDE_CAPABILITY,
> " 
> com.example;theList:List=\"red,green,blue\";theLong:Long=111");
> headers.put(Constants.REQUIRE_CAPABILITY,
> " 
> com.example.other;theList:List=\"one,two,three\";theLong:Long=999");
> 
> BundleRevision mockBundleRevision = mock(BundleRevision.class);
> 
> when(mockBundleRevision.getSymbolicName()).thenReturn("com.example.test.sample");
> 
> ManifestParser mp = new ManifestParser(null, null, 
> mockBundleRevision, headers);
> 
> BundleCapability bc = findCapability(mp.getCapabilities(), 
> "com.example");
> Long cLong = (Long) bc.getAttributes().get("theLong");
> assertEquals(Long.valueOf(111), cLong);
> List cList = (List) bc.getAttributes().get("theList");
> assertEquals(3, cList.size());
> assertTrue(cList.contains("red"));
> 
> BundleRequirement br = findRequirement(mp.getRequirements(), 
> "com.example.other");
> // 
> // fails with java.lang.Cla

Re: [osgi-dev] RHelp needed about Web Application with AngularJS

[Peter Kriens]

Ok, send me the zip file … but it would really be a lot easier to help you when 
you worked in bndtools. It is pretty likely that if you set it up in bndtools 
it will tell you what is wrong … A setup of bundles in a directory is very 
unmanaged and likely to hide many errors tools could have told you. 

Send the zip to me personally or send a link so I can download it.

Kind regards,

Peter Kriens






> On 30 Mar 2017, at 16:47, HENRY Cedric D <cedric.d.he...@alstom.com> wrote:
> 
> Hello,
>  
> The only bndrun file I have used is the one from the 
> ‘osgi.enroute.examples.rest.application’ project 
> fromhttps://github.com/osgi/osgi.enroute.examples 
> <https://github.com/osgi/osgi.enroute.examples> without changing any code, 
> and then I manually extracted the bundles to put them in a clean Felix 
> instance.
>  
> I can send the ZIP containing the examples I used, and I can create a ZIP 
> with the end result of the Felix Instance, but I do not see nor do I know how 
> to make a bndrun file replicating the manual steps I did (as described in my 
> previous email) in order to ease your work in helping me.
>  
> 
> Please let me know what would be useful to you so I can help you in helping 
> me.
> 
> Best Regards,
> 
> Cédric
>  
> From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> On Behalf Of Peter Kriens
> Sent: Thursday, March 30, 2017 11:04 AM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] RHelp needed about Web Application with AngularJS
>  
> Well, there are million of tutorials about Git(hub). It really is hard for me 
> to try to retrace your steps and be sure I end up in the same place.
>  
> I am more than willing to help but I will not to be able to quickly recreate 
> the exact environment you’ve created.
>  
> And anyway, wouldn’t it be easier to create a bndrun file with this setup?
>  
> Kind regards,
>  
> Peter Kriens
>  
> On 22 Mar 2017, at 12:24, HENRY Cedric D <cedric.d.he...@alstom.com 
> <mailto:cedric.d.he...@alstom.com>> wrote:
>  
> I am not very familiar (yet) with Github nor with bndtools workspace.
>  
> Still,  related to what I mentioned in my initial email, my steps were as 
> follow:
> 1.   Downloaded https://github.com/osgi/osgi.enroute.examples 
> <https://github.com/osgi/osgi.enroute.examples> (as ZIP and extracted it 
> locally)
> 2.   Follow prerequisites from 
> http://enroute.osgi.org/qs/100-prerequisites.html 
> <http://enroute.osgi.org/qs/100-prerequisites.html>
> a.   Java 8
> b.   Eclipse Mars
> c.   Bndtools installation (using URL 
> http://dl.bintray.com/bndtools/bndtools/latest 
> <http://dl.bintray.com/bndtools/bndtools/latest> as HTTPS failing)
> d.   Installed Git for windows
> 3.   Imported the download at step 1 in Eclipse
> 4.   Followed steps from http://enroute.osgi.org/qs/300-application.html 
> <http://enroute.osgi.org/qs/300-application.html>,on the 
> osgi.enroute.examples.rest.application project:
> a.   Double-click the ‘osgi.enroute.examples.rest.bndrun’ file + Click 
> ‘Resolve’ then ‘Finish’
> b.   Click ‘Run OSGi’/’Debug OSGi’ and check 
> http://localhost:8080/osgi.enroute.examples.rest/index.html 
> <http://localhost:8080/osgi.enroute.examples.rest/index.html>
> c.   Stopped the run/debug
> d.   Click ‘Export’ and followed the wizard
> 5.   Extracted content of uber-JAR resulting from the ‘Export’ action 
> (http://enroute.osgi.org/qs/300-application.html 
> <http://enroute.osgi.org/qs/300-application.html>, ‘Creating an 
> Executable’section)
> 6.   Copied following extracted JAR files into ‘bundle’ directory of 
> local Felix (v 5.6.2):
> · org.apache.felix.http.servlet-api-1.1.2.jar
> · org.apache.felix.log-1.0.1.jar
> · org.apache.felix.configadmin-1.8.8.jar
> · org.apache.felix.http.jetty-3.2.0.jar
> · org.apache.felix.scr-2.0.2.jar
> · osgi.enroute.examples.rest.application.jar
> · osgi.enroute.twitter.bootstrap.webresource-3.3.5.jar
> · osgi.enroute.configurer.simple.provider-2.0.0.jar
> · osgi.enroute.dtos.bndlib.provider-2.0.0.jar
> · osgi.enroute.executor.simple.provider-2.0.0.jar
> · osgi.enroute.google.angular.webresource-1.5.7.jar
> · osgi.enroute.logger.simple.provider-2.0.0.jar
> · osgi.enroute.rest.simple.provider-2.0.0.jar
> · osgi.enroute.stackexchange.pagedown.webresource-1.1.1.jar
> · osgi.enroute.web.simple.provider-2.0.0.jar
> 7.   Added the following Felix sub-projects into the ‘bundle’ directory:
&g

Re: [osgi-dev] RHelp needed about Web Application with AngularJS

[Peter Kriens]

Well, there are million of tutorials about Git(hub). It really is hard for me 
to try to retrace your steps and be sure I end up in the same place.

I am more than willing to help but I will not to be able to quickly recreate 
the exact environment you’ve created.

And anyway, wouldn’t it be easier to create a bndrun file with this setup?

Kind regards,

Peter Kriens

> On 22 Mar 2017, at 12:24, HENRY Cedric D <cedric.d.he...@alstom.com> wrote:
> 
> I am not very familiar (yet) with Github nor with bndtools workspace.
>  
> Still,  related to what I mentioned in my initial email, my steps were as 
> follow:
> 1.   Downloaded https://github.com/osgi/osgi.enroute.examples 
> <https://github.com/osgi/osgi.enroute.examples> (as ZIP and extracted it 
> locally)
> 2.   Follow prerequisites from 
> http://enroute.osgi.org/qs/100-prerequisites.html 
> <http://enroute.osgi.org/qs/100-prerequisites.html>
> a.   Java 8
> b.   Eclipse Mars
> c.   Bndtools installation (using URL 
> http://dl.bintray.com/bndtools/bndtools/latest 
> <http://dl.bintray.com/bndtools/bndtools/latest> as HTTPS failing)
> d.   Installed Git for windows
> 3.   Imported the download at step 1 in Eclipse
> 4.   Followed steps from http://enroute.osgi.org/qs/300-application.html 
> <http://enroute.osgi.org/qs/300-application.html>,on the 
> osgi.enroute.examples.rest.application project:
> a.   Double-click the ‘osgi.enroute.examples.rest.bndrun’ file + Click 
> ‘Resolve’ then ‘Finish’
> b.   Click ‘Run OSGi’/’Debug OSGi’ and check 
> http://localhost:8080/osgi.enroute.examples.rest/index.html 
> <http://localhost:8080/osgi.enroute.examples.rest/index.html>
> c.   Stopped the run/debug
> d.   Click ‘Export’ and followed the wizard
> 5.   Extracted content of uber-JAR resulting from the ‘Export’ action 
> (http://enroute.osgi.org/qs/300-application.html 
> <http://enroute.osgi.org/qs/300-application.html>, ‘Creating an 
> Executable’section)
> 6.   Copied following extracted JAR files into ‘bundle’ directory of 
> local Felix (v 5.6.2):
> · org.apache.felix.http.servlet-api-1.1.2.jar
> · org.apache.felix.log-1.0.1.jar
> · org.apache.felix.configadmin-1.8.8.jar
> · org.apache.felix.http.jetty-3.2.0.jar
> · org.apache.felix.scr-2.0.2.jar
> · osgi.enroute.examples.rest.application.jar
> · osgi.enroute.twitter.bootstrap.webresource-3.3.5.jar
> · osgi.enroute.configurer.simple.provider-2.0.0.jar
> · osgi.enroute.dtos.bndlib.provider-2.0.0.jar
> · osgi.enroute.executor.simple.provider-2.0.0.jar
> · osgi.enroute.google.angular.webresource-1.5.7.jar
> · osgi.enroute.logger.simple.provider-2.0.0.jar
> · osgi.enroute.rest.simple.provider-2.0.0.jar
> · osgi.enroute.stackexchange.pagedown.webresource-1.1.1.jar
> · osgi.enroute.web.simple.provider-2.0.0.jar
> 7.   Added the following Felix sub-projects into the ‘bundle’ directory:
> a.   
> http://ftp.tudelft.nl/apache/felix/org.apache.felix.bundlerepository-2.0.8.jar
>  
> <http://ftp.tudelft.nl/apache/felix/org.apache.felix.bundlerepository-2.0.8.jar>
> b.   
> http://ftp.tudelft.nl/apache/felix/org.apache.felix.coordinator-1.0.2.jar 
> <http://ftp.tudelft.nl/apache/felix/org.apache.felix.coordinator-1.0.2.jar>
> c.   org.apache.felix.dependencymanager-4.4.0.jar from 
> http://ftp.tudelft.nl/apache//felix/org.apache.felix.dependencymanager-r9-bin.zip
>  
> <http://ftp.tudelft.nl/apache/felix/org.apache.felix.dependencymanager-r9-bin.zip>
> d.   
> http://ftp.tudelft.nl/apache//felix/org.apache.felix.eventadmin-1.4.8.jar 
> <http://ftp.tudelft.nl/apache/felix/org.apache.felix.eventadmin-1.4.8.jar>
> e.   
> http://ftp.tudelft.nl/apache//felix/org.apache.felix.metatype-1.1.2.jar 
> <http://ftp.tudelft.nl/apache/felix/org.apache.felix.metatype-1.1.2.jar>
> f.
> http://ftp.tudelft.nl/apache//felix/org.apache.felix.webconsole-4.3.0-all.jar 
> <http://ftp.tudelft.nl/apache/felix/org.apache.felix.webconsole-4.3.0-all.jar>
> 8.   Added the following OSGi bundles from Maven:
> a.   
> http://central.maven.org/maven2/org/osgi/org.osgi.service.coordinator/1.0.2/org.osgi.service.coordinator-1.0.2.jar
>  
> <http://central.maven.org/maven2/org/osgi/org.osgi.service.coordinator/1.0.2/org.osgi.service.coordinator-1.0.2.jar>
> b.   
> http://central.maven.org/maven2/org/osgi/org.osgi.service.event/1.3.1/org.osgi.service.event-1.3.1.jar
>  
> <http://central.maven.org/maven2/org/osgi/org.osgi.service.event/1.3.1/org.osgi.service.event-1.3.1.jar>
> c.   
&g

[osgi-dev] Writing Gogo Commands

[Peter Kriens]

Most of the Gogo commands I see written do not take advantage of Gogo at all. 
Gogo basically allows you to write plain old Java code that is 
indistinguishable from your normal service code. In fact, you can often 
directly use your service code. This works because Gogo has a powerful 
underlying formatting and conversion technique.

I’ve written, with the help of SMA and Ray Augé, an App note. If you ever wrote 
a Gogo command suggest you read it. If you’ve not, a good time to start:

http://enroute.osgi.org/appnotes/gogo-cmd.html 
<http://enroute.osgi.org/appnotes/gogo-cmd.html>

There is also an app note about how to use Gogo, which is also often a surprise 
to people. For this next app note I’ve extended the this app note with an 
explanation of the Gogo functions/lambdas.

http://enroute.osgi.org/appnotes/gogo.html 
<http://enroute.osgi.org/appnotes/gogo.html>

Enjoy! And please submit a PR to improve these app notes.

Kind regards,

    Peter Kriens

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

Re: [osgi-dev] RHelp needed about Web Application with AngularJS

[Peter Kriens]

Hmm, manifest looks ok. The fact that your bundle runs means Felix must have 
resolved this. 

I vaguely recall that there was a bug in Felix wiring custom namespaces but 
that same vague recall says in my head it was fixed.

The easiest for me is if you create a Github bndtools workspace.

Kind regards,

Peter Kriens



> On 22 Mar 2017, at 08:18, HENRY Cedric D <cedric.d.he...@alstom.com> wrote:
> 
> Hello,
>  
> I left the code downloaded from GIT as-is and followed the steps from the 
> tutorial in order to see it working in full, which it did in when ran from 
> Eclipse or when running the exported JAR.
>  
> As per angular the Require-Capability header, the osgi.enroute.examples.rest 
> bundle has the following (see manifest attached) amongst others:
> · 
> effective:=active,osgi.enroute.webresource;resource:List="angular.js,angular-resource.js,angular-route.js"
> · 
> priority:Long=1000;filter:="(&(osgi.enroute.webresource=/google/angular)(&(version>=1.5.7)(!(version>=2.0.0",osgi.enroute.webresource
>  
> If it helps with the investigation, I can archive the Felix instance included 
> all the bundles and sent it over.
>  
> Best Regards,
> 
> Cédric
>  
> From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> On Behalf Of Peter Kriens
> Sent: Tuesday, March 21, 2017 7:10 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] RHelp needed about Web Application with AngularJS
>  
> Your GUI bundle must require the angular code and the bootstrap code. Since 
> you can see the CSS this seems to work fine for Twitter but not angular.
>  
> * Did you remove or change the RequireAngular annotation from the application 
> class?
> * Verify that your osgi.enroute.rest.application bundle requires angular in 
> the header (Require-Capability header)
>  
> Otherwise make a Github repo with the project and I can take a look. Kind 
> regards,
>  
> Peter Kriens
>  
>  
> On 21 Mar 2017, at 18:01, HENRY Cedric D <cedric.d.he...@alstom.com 
> <mailto:cedric.d.he...@alstom.com>> wrote:
>  
> Hello,
>  
> I have followed the tutorial http://enroute.osgi.org/qs/050-start.html 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__enroute.osgi.org_qs_050-2Dstart.html=DwMFaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=P6euiOIUTiHGeCo834UpUN15FXdgxZVSdSwprP_eqOo=7tDGLFT8Y4SL1Hbi9pYPSF30fCXvShawNw2TQArioZw=BVpIxOXWBdZ4T2IGnu0wJ5WS05rMgUUxH7qZd3eX17Q=>
>  using the examples available on GIT without any problem.
>  
> Then, I have extracted the content of the JAR generated at the end of the 
> page http://enroute.osgi.org/qs/300-application.html 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__enroute.osgi.org_qs_300-2Dapplication.html=DwMFaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=P6euiOIUTiHGeCo834UpUN15FXdgxZVSdSwprP_eqOo=7tDGLFT8Y4SL1Hbi9pYPSF30fCXvShawNw2TQArioZw=aMOj06IaufFeItw5hnwlF2mNvvfIzETbxZIgsikB3OQ=>
>  to use it content with a clean instance of Felix (v 5.6.2, configured to 
> have on port 8889).
> The intent is to better the dependencies required in order to create a Web 
> application (with AngularJS) using OSGi in order to create a similar 
> application using Maven on Intellij IDEA.
>  
> The Problem is as below:
>  
> After some struggle, I have succeeded to have all bundles active, but the web 
> application does not work as when ran from Eclipse.
> NOTE that none of the org.eclipse.* bundles got used.
>  
> Opening http://localhost:8889/osgi.enroute.examples.rest/index.html#/ 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8889_osgi.enroute.examples.rest_index.html-23_=DwMFaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=P6euiOIUTiHGeCo834UpUN15FXdgxZVSdSwprP_eqOo=7tDGLFT8Y4SL1Hbi9pYPSF30fCXvShawNw2TQArioZw=V_W98i93Z69Cc5LnyjAXLxPZyFSeWIY_J2DCABsg-eQ=>
>  only the content of the index.html file is rendered as-is:
> 
>  
> Looking into the Source View, I have followed the CSS link and the JS link:
> · 
> http://localhost:8889/osgi.enroute.webresource/osgi.enroute.examples.rest.application/1.0.0/*.css
>  
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8889_osgi.enroute.webresource_osgi.enroute.examples.rest.application_1.0.0_-2A.css=DwMFaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=P6euiOIUTiHGeCo834UpUN15FXdgxZVSdSwprP_eqOo=7tDGLFT8Y4SL1Hbi9pYPSF30fCXvShawNw2TQArioZw=kgzYhTlXSCzRmOmKO_hVP4uaKIKikISnKd3vvUZbrDI=>:
>  returns the CSS content
> · 
> http://localhost:8889/osgi.enroute.webresource/osgi.enroute.examples.rest.application/1.0.0/*.js
>  
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8889_osgi.e

Re: [osgi-dev] RHelp needed about Web Application with AngularJS

[Peter Kriens]

Your GUI bundle must require the angular code and the bootstrap code. Since you 
can see the CSS this seems to work fine for Twitter but not angular.

* Did you remove or change the RequireAngular annotation from the application 
class?
* Verify that your osgi.enroute.rest.application bundle requires angular in the 
header (Require-Capability header)

Otherwise make a Github repo with the project and I can take a look. Kind 
regards,

Peter Kriens


> On 21 Mar 2017, at 18:01, HENRY Cedric D <cedric.d.he...@alstom.com> wrote:
> 
> Hello,
>  
> I have followed the tutorial http://enroute.osgi.org/qs/050-start.html 
> <http://enroute.osgi.org/qs/050-start.html> using the examples available on 
> GIT without any problem.
>  
> Then, I have extracted the content of the JAR generated at the end of the 
> page http://enroute.osgi.org/qs/300-application.html 
> <http://enroute.osgi.org/qs/300-application.html> to use it content with a 
> clean instance of Felix (v 5.6.2, configured to have on port 8889).
> The intent is to better the dependencies required in order to create a Web 
> application (with AngularJS) using OSGi in order to create a similar 
> application using Maven on Intellij IDEA.
>  
> The Problem is as below:
>  
> After some struggle, I have succeeded to have all bundles active, but the web 
> application does not work as when ran from Eclipse.
> NOTE that none of the org.eclipse.* bundles got used.
>  
> Opening http://localhost:8889/osgi.enroute.examples.rest/index.html#/ 
> <http://localhost:8889/osgi.enroute.examples.rest/index.html#/> only the 
> content of the index.html file is rendered as-is:
> 
>  
> Looking into the Source View, I have followed the CSS link and the JS link:
> · 
> http://localhost:8889/osgi.enroute.webresource/osgi.enroute.examples.rest.application/1.0.0/*.css
>  
> <http://localhost:8889/osgi.enroute.webresource/osgi.enroute.examples.rest.application/1.0.0/*.css>:
>  returns the CSS content
> · 
> http://localhost:8889/osgi.enroute.webresource/osgi.enroute.examples.rest.application/1.0.0/*.js
>  
> <http://localhost:8889/osgi.enroute.webresource/osgi.enroute.examples.rest.application/1.0.0/*.js>:
>  returns HTTP ERROR: 404
> Note that http://localhost:8889/rest/upper <http://localhost:8889/rest/upper> 
> is working fine.
>  
> I am puzzled about the fact that the CSS file content is returned, but not 
> the JS file content event though they are under the same directory within the 
> osgi.enroute.examples.rest.application bundle, and I would appreciate some 
> help in solving and understand the cause of this problem.
>  
> Here is a snapshot of all the bundles under ‘bundle’ directory used by Felix:
> 
>  
> Best Regards,
> 
> Cédric
>  
> 
> CONFIDENTIALITY : This e-mail and any attachments are confidential and may be 
> privileged. If you are not a named recipient, please notify the sender 
> immediately and do not disclose the contents to another person, use it for 
> any purpose or store or copy the information in any medium.
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <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] requirements capabilities and resolver for general purpose provisioning

[Peter Kriens]

The design of the capability model has always been with more in mind than OSGi 
… Clearly the underlying model allows you to model a lot of things. The only 
thing that might be missing is an evaluation function that could grade 
solutions. In the OSGi context any solution is ok since there is no cost 
difference. However, in many scenarios the cost of different solutions could 
vary.

Kind regards,

Peter Kriens

> On 15 Mar 2017, at 11:38, Milen Dyankov <milendyan...@gmail.com> wrote:
> 
> Hi all,
> 
> Is anyone aware of any attempt to use the requirements, 
> repositories and resolver specs for anything other than provisioning OSGi 
> runtime? It seams to me the specs are generic enough to be used in other 
> scenarios. 
> 
> One example that comes to my mind is provisioning a telecommunication offer. 
> Say user purchase "plan A" which requires things like "text messaging", 
> "roaming", ... and then resolver finds services  with such capabilities which 
> on the other hand have their own requirements.   
> 
> The above is just an example I made up, it's not something I'm really 
> interested in. I'm rather looking for any example of usage of those concepts 
> outside the scope of their original purpose.
> 
> Best,
> Milen  
> 
> 
> -- 
> http://about.me/milen 
> <http://about.me/milen>___
> 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] Building a "profile" system with declarative services and configuration admin?

[Peter Kriens]

:-)

> On 13 Mar 2017, at 16:21, Daghan ACAY <daghana...@hotmail.com> wrote:
> 
> Thanks for your comments. I agree the last one was an edge case and not very 
> useful in practical scenarios. It was only question to understand life cycle 
> in a better way and not abuse it unnecessarily.
> 
> Regards
> - Daghan
> 
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails 
> as clean, short chats.
> 
> 
> 
>  Original Message 
> From: Peter Kriens <peter.kri...@aqute.biz>
> Sent: Monday, March 13, 2017 07:25 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
> and configuration admin?
> 
>> On 13 Mar 2017, at 12:57, Daghan ACAY <daghana...@hotmail.com 
>> <mailto:daghana...@hotmail.com>> wrote:
>> Hi peter,
>> 
>> As a clarification, i can see this design allows multiple ProfileRunner 
>> instances (actually as  many as IRCProfile configurations) at runtime where 
>> each ProfileRunner has zero or more IRFfilters whose properties obeys the 
>> LDAP filter defined by the filters_target value. Now for each ProfileRunner 
>> instance filters_target value can be configured at runtime through web 
>> console or @ConfigurerExtender using filters.target in json. Am i right?
>> 
> Yes
>> My second clarification is about life cycle of ProfileRunner. If i change 
>> the IRCProfile configuration of an existing ProfileRunner instance then that 
>> instance will be recreated and IRFFilters will be injected to the newly 
>> created instance. Am i right?
>> 
> Yes
>> Now two tricky ones. 
>> 
>> 1- if we had defined configuration for IRFFilter as you have suggested and 
>> assume we have for a single IRFFilter component e.g "filter=log". Again 
>> assume this IRFFilter instance  is already injected to one of the existing 
>> ProfileRunner instance. If i change the IRFFilter component’s property to 
>> "filter=uppercase", is this IRFFilter removed from the List 
>> without destroying the existing ProfileRunner instance?
> Yes because it is a volatile list. This makes the reference dynamic
> 
>> 2- If you had @updated method defined for ProfileRunner and changed the 
>> filters_target value for an existing ProfileRunner instance from 
>> (filter=uppercase) to (filter=log), what happens to the List 
>> member, are they refreshed according to the new filters_target value, 
>> without destroying the existing ProfileRunner instance?
>> 
> I expect they should be updated dynamically but I am not a 100% sure about 
> it. And if I felt this was an important distinction I might read through the 
> spec, but to be honest, who cares? I would never optimize a system to prevent 
> an object from being recreated until I had a real problem. Recreating an 
> object works very nice and imho has hardly any consequences in a well 
> designed OSGi system.
> 
> Kind regards,
> 
> Peter Kriens
> 
> 
>> Thanks in advance. 
>> 
>> -daghan
>> 
>> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails 
>> as clean, short chats.
>> 
>> 
>> 
>>  Original Message 
>> From: list+org.o...@io7m.com <mailto:list+org.o...@io7m.com>
>> Sent: Monday, March 13, 2017 03:05 PM
>> To: Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>>
>> Subject: Re: [osgi-dev] Building a "profile" system with declarative 
>> services and configuration admin?
>> CC: OSGi Developer Mail List <osgi-dev@mail.osgi.org 
>> <mailto:osgi-dev@mail.osgi.org>>
>> 
>> On 2017-03-13T09:03:49 +0100
>> Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>> wrote:
>> 
>> > Just use configuration admin. So first define your profile configuration:
>> > 
>> >@ObjectClassDefinition
>> >@interface IRCProfile {
>> >String username();
>> >String password();
>> >String host();
>> >String filters_target() default “(filter=uppercase)“;
>> >}
>> > 
>> > You then create a a runner that does the work:
>> > 
>> >@Designate( ocd= IRCProfile.class, factory=true )
>> >@Component(service=ProfileRunner.class)
>> >public class ProfileRunner {
>> > 
>> >@Reference
>> >volatile List fil

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Peter Kriens]

> On 13 Mar 2017, at 12:57, Daghan ACAY <daghana...@hotmail.com> wrote:
> Hi peter,
> 
> As a clarification, i can see this design allows multiple ProfileRunner 
> instances (actually as  many as IRCProfile configurations) at runtime where 
> each ProfileRunner has zero or more IRFfilters whose properties obeys the 
> LDAP filter defined by the filters_target value. Now for each ProfileRunner 
> instance filters_target value can be configured at runtime through web 
> console or @ConfigurerExtender using filters.target in json. Am i right?
> 
Yes
> My second clarification is about life cycle of ProfileRunner. If i change the 
> IRCProfile configuration of an existing ProfileRunner instance then that 
> instance will be recreated and IRFFilters will be injected to the newly 
> created instance. Am i right?
> 
Yes
> Now two tricky ones. 
> 
> 1- if we had defined configuration for IRFFilter as you have suggested and 
> assume we have for a single IRFFilter component e.g "filter=log". Again 
> assume this IRFFilter instance  is already injected to one of the existing 
> ProfileRunner instance. If i change the IRFFilter component’s property to 
> "filter=uppercase", is this IRFFilter removed from the List 
> without destroying the existing ProfileRunner instance?
> 
Yes because it is a volatile list. This makes the reference dynamic

> 2- If you had @updated method defined for ProfileRunner and changed the 
> filters_target value for an existing ProfileRunner instance from 
> (filter=uppercase) to (filter=log), what happens to the List 
> member, are they refreshed according to the new filters_target value, without 
> destroying the existing ProfileRunner instance?
> 
I expect they should be updated dynamically but I am not a 100% sure about it. 
And if I felt this was an important distinction I might read through the spec, 
but to be honest, who cares? I would never optimize a system to prevent an 
object from being recreated until I had a real problem. Recreating an object 
works very nice and imho has hardly any consequences in a well designed OSGi 
system.

Kind regards,

Peter Kriens


> Thanks in advance. 
> 
> -daghan
> 
> 
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails 
> as clean, short chats.
> 
> 
> 
>  Original Message 
> From: list+org.o...@io7m.com
> Sent: Monday, March 13, 2017 03:05 PM
> To: Peter Kriens <peter.kri...@aqute.biz>
> Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
> and configuration admin?
> CC: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> 
> On 2017-03-13T09:03:49 +0100
> Peter Kriens <peter.kri...@aqute.biz> wrote:
> 
> > Just use configuration admin. So first define your profile configuration:
> > 
> >@ObjectClassDefinition
> >@interface IRCProfile {
> >String username();
> >String password();
> >String host();
> >String filters_target() default “(filter=uppercase)“;
> >}
> > 
> > You then create a a runner that does the work:
> > 
> >@Designate( ocd= IRCProfile.class, factory=true )
> >@Component(service=ProfileRunner.class)
> >public class ProfileRunner {
> > 
> >@Reference
> >volatile List filters;
> >
> >@Activate
> >void activate( IRCProfile profile ) {
> >…
> >// start a thread?
> >}
> > 
> >}
> > 
> > This runner can now be created as many times as you want with WebConsole. 
> > Each configuration you create is automatically cause a ProfileRunner to be 
> > instantiated when its filters are registered. The filters are coupled to 
> > the component via the `filters.target` configuration field. The default 
> > currently shows that it needs the ‘uppercase’ filter. However, with the or 
> > (|) operator you can make it any number of filters: 
> > (|(filter=uppercase)(filter=log)). If you need ordering in the filters, use 
> > the service.ranking property on the filter components.
> > 
> > You can now make any number of filters that look like:
> > 
> >@Component( property={“filter=uppercase”, “service.ranking=-100”}) 
> >public class UpperCaseFilter implements IRCFilterType {
> > 
> >String process( String s) {
> >return s.toUpperCase();
> >}
> >}
> > 
> &

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Peter Kriens]

Just use configuration admin. So first define your profile configuration:

@ObjectClassDefinition
@interface IRCProfile {
String username();
String password();
String host();
String filters_target() default “(filter=uppercase)“;
}

You then create a a runner that does the work:

@Designate( ocd= IRCProfile.class, factory=true )
@Component(service=ProfileRunner.class)
public class ProfileRunner {

@Reference
volatile List filters;

@Activate
void activate( IRCProfile profile ) {
…
// start a thread?
}

}

This runner can now be created as many times as you want with WebConsole. Each 
configuration you create is automatically cause a ProfileRunner to be 
instantiated when its filters are registered. The filters are coupled to the 
component via the `filters.target` configuration field. The default currently 
shows that it needs the ‘uppercase’ filter. However, with the or (|) operator 
you can make it any number of filters: (|(filter=uppercase)(filter=log)). If 
you need ordering in the filters, use the service.ranking property on the 
filter components.

You can now make any number of filters that look like:

@Component( property={“filter=uppercase”, “service.ranking=-100”}) 
public class UpperCaseFilter implements IRCFilterType {

String process( String s) {
return s.toUpperCase();
}
}

I do not think you need anything more? Of course your IRCFilterType are now 
components so they can be configured independently in a similar vein as the 
ProfileRunner.

Having file based configuration is always a bad smell in OSGi. Configuration 
Admin looks different from what most developers know but it is quite powerful.

Kind regards,

Peter Kriens



> On 12 Mar 2017, at 21:52, list+org.o...@io7m.com wrote:
> 
> Hello.
> 
> I'm putting together a small experimental application (an IRC client)
> and would like to fundamentally base it on the idea of _profiles_. A
> profile in this case is basically a set of configuration options such
> as the username, IRC server address, a set of filters, a configuration
> for logging, etc. There can be [0, n] profiles active at any given time.
> A "filter" in this case can be thought of as a function that's evaluated
> for each received message (possibly only for the function's side
> effects). In practice, it'd be an implementation of a published
> IRCFilterType interface.
> 
> I'm running up against various architectural questions.
> 
> I think what I should do is create a Profile component that
> instantiates a tree of services/components in the whiteboard pattern: A
> component for maintaining a connection to an IRC server, a component
> that handles logging of messages, a set of components for filtering,
> etc, etc.
> 
> In my case, I'm using Felix as the OSGi container and I think what I
> need to do is create various configuration files in a directory
> monitored by the fileinstall and configuration admin services.
> For example, if the directory is "etc", then:
> 
>  etc/com.io7m.eirc.logger-PROFILE1.cfg
> 
> ... results in an instantiation of the component with service pid
> "com.io7m.eirc.logger". However, it doesn't seem like anything in the
> OSGi standards allow me to get access to the "PROFILE1" name. I'm not
> sure if this is deliberate, or an oversight, or something else.
> 
> It seems like I'd quickly need a ton of different configuration files
> and am not sure how it would be obvious to the user how all of the
> configuration files are tied together to form a profile. Do I need to
> declare some form of "profile identifier" myself? What happens if, for
> example, I want to instantiate two instances of the same component with
> different configurations within a single profile?
> 
> Is there some way to express "instantiate all required components
> that have an application-specific profile ID of P" with declarative
> services? I feel like, normally, the answer would be filtering based on
> a given "profile ID" property. In my case, though, the value of the
> property would only be known at run-time and therefore I couldn't do
> this purely through annotations.
> 
> What happens if the configuration data for a specific component is
> missing? With the configuration data spread over multiple files, can I
> get good error reporting in that case? I suspect what I'd get is
> basically silent failure... A required component can't be started up,
> so everything just sits there doing nothing.
&

Re: [osgi-dev] OSGI support needed bundling web application

[Peter Kriens]

> On 8 Mar 2017, at 11:37, rama.g <ram...@utthunga.com> wrote:
> Dear Peterus
> We discarded OSGI enroute, decided to go with OSGI framework.
Well, OSGi enRoute IS an OSGi framework, there is nothing specia? OSGi enRoute 
just collects best practices but is nothing but a normal OSGi framework with 
open source bundles.

> We created plugins related to both backend (RESR APIS) and front end (angular 
> JS static files) are bundled using OSGI framework. UI components are bundled 
> separately. 
So what is the difference? This is exactly the OSGi model?

> Using HTTP services we are able to register resources like HTML/JS/CSS static 
> files in the main application. When a second plugin (which has static files 
> same structure as that of main application) is created, we are unable to 
> invoke the static files using localhost, getting 404 error
Why? I’ve seen applications with multiple bundles providing resources. 

The OSGi enRoute supports a bundle that maps the static directory to the local 
web server using the extender pattern. It allows overlapping directories with 
different resources, it will merge them. Except for the caching and compression 
that it does this is quite a simple mechanism. It clearly works in setups with 
different static resource providers. It would be nice if you could find out why 
you get a 404. In the case that it is really something in OSGi enRoute, which I 
find very unlikely, then we could at least fix it?

A bit puzzled? Kind regards,

Peter Kriens



>  
> Thanks and Regards
> Rama G
>  
>  
> From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> On Behalf Of Peter Kriens
> Sent: Tuesday, March 07, 2017 6:36 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] OSGI support needed bundling web application
>  
> A bit confused about the terminology … So let me verify:
>  
> backend   Java code wrapped in a bundle 
> implementing a REST API
> frontend  Angular Java code
>  
> In enRoute the frontend would be stored in the application project. (In the 
> static directory.) Your REST backend would be provided as a provider. The 
> application project would depend on the provider so that if you resolve the 
> REST provider is dragged in with its dependencies.
>  
> Kind regards,
>  
> Peter Kriens
>  
>  
> 
> 
>>  
>> On 7 Mar 2017, at 12:23, rama.g <ram...@utthunga.com 
>> <mailto:ram...@utthunga.com>> wrote:
>>  
>> Dear Peter
>> You are right. this example. In this case  both front end and backend are 
>> bundled together. My use case is backend to be bundled separately, front end 
>> to be bundled separately as they are developed by two different vendors. 
>> My current scenario is that, backend rest APIs are bundled on OSGI 
>> framework. Front end I have used OSGI Enroute?. I want an interface between 
>> the backend plugin and frontend plugin. How can this be established
>>  
>> Is it easy to port the backend from OSGI to OSGI Enroute
>>  
>> Thanks and Regards
>> Rama G
>>  
>> From: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org> 
>> [mailto:osgi-dev-boun...@mail.osgi.org 
>> <mailto:osgi-dev-boun...@mail.osgi.org>] On Behalf Of Peter Kriens
>> Sent: Tuesday, March 07, 2017 4:08 PM
>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org 
>> <mailto:osgi-dev@mail.osgi.org>>
>> Subject: Re: [osgi-dev] OSGI support needed bundling web application
>>  
>> Did you follow the OSGi enRoute tutorials? The application template seems to 
>> do exactly what you want.
>>  
>> Kind regards,
>>  
>> Peter Kriens
>>  
>>> On 7 Mar 2017, at 11:35, rama.g <ram...@utthunga.com 
>>> <mailto:ram...@utthunga.com>> wrote:
>>>  
>>> Dear sir / madam
>>> I need to know the kind of support OSGI framework provides to host web 
>>> application for the given use case.
>>> I have my backend (rest APIs) developed independently using modular 
>>> approach . I have set of User components developed using Angular java 
>>> corresponding to each backend module. We are required to bundle the backend 
>>> and UI components separately for ease of maintenance , but when I deploy 
>>> the product to the user he should visualize as a single plugin (combination 
>>> of backend and UI)
>>> Please suggest OSGI solution  required to meet the above use case
>>>  
>>> Assuming that  the backend is already bundled in OSGI framework, suggest a 
>>>

Re: [osgi-dev] Bndtool Debug: attach source with class

[Peter Kriens]

Except for manually adding the sources to the Build Path, the only solution 
well supported is to include the sources in the bundle. (-sources=true in the 
build.bnd or bnd.bnd file).

There are some huge advantages to this model and it is widely supported by 
debuggers. If you do not want to deploy sources for some reason, e.g. IPR, then 
you could remove them quite easily from the final JARs. However, the benefits 
to have the exact source code in production has saved my ass several times.

Kind regards,

Peter Kriens


> On 7 Mar 2017, at 21:06, Tanvir <tanvir.ah...@oracle.com> wrote:
> 
> I have separate jar for class and source files. What is the easiest way to 
> associate them for debug in bndtool, preferably not creating a combined 
> bundle?
> 
> 
> -- 
> Best,
> Tanvir
> 
> ___
> 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 support needed bundling web application

[Peter Kriens]

A bit confused about the terminology … So let me verify:

backend Java code wrapped in a bundle implementing a REST API
frontendAngular Java code

In enRoute the frontend would be stored in the application project. (In the 
static directory.) Your REST backend would be provided as a provider. The 
application project would depend on the provider so that if you resolve the 
REST provider is dragged in with its dependencies.

Kind regards,

Peter Kriens



> 
> On 7 Mar 2017, at 12:23, rama.g <ram...@utthunga.com> wrote:
> 
> Dear Peter
> You are right. this example. In this case  both front end and backend are 
> bundled together. My use case is backend to be bundled separately, front end 
> to be bundled separately as they are developed by two different vendors. 
> My current scenario is that, backend rest APIs are bundled on OSGI framework. 
> Front end I have used OSGI Enroute?. I want an interface between the backend 
> plugin and frontend plugin. How can this be established
>  
> Is it easy to port the backend from OSGI to OSGI Enroute
>  
> Thanks and Regards
> Rama G
>  
> From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] 
> On Behalf Of Peter Kriens
> Sent: Tuesday, March 07, 2017 4:08 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] OSGI support needed bundling web application
>  
> Did you follow the OSGi enRoute tutorials? The application template seems to 
> do exactly what you want.
>  
> Kind regards,
>  
> Peter Kriens
>  
>> On 7 Mar 2017, at 11:35, rama.g <ram...@utthunga.com 
>> <mailto:ram...@utthunga.com>> wrote:
>>  
>> Dear sir / madam
>> I need to know the kind of support OSGI framework provides to host web 
>> application for the given use case.
>> I have my backend (rest APIs) developed independently using modular approach 
>> . I have set of User components developed using Angular java corresponding 
>> to each backend module. We are required to bundle the backend and UI 
>> components separately for ease of maintenance , but when I deploy the 
>> product to the user he should visualize as a single plugin (combination of 
>> backend and UI)
>> Please suggest OSGI solution  required to meet the above use case
>>  
>> Assuming that  the backend is already bundled in OSGI framework, suggest a 
>> method to bundle UI components which works in collaboration with the backend
>>  
>> Thanks and Regards
>> Rama G 
>>  
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>  
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <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