Deploying Bnd Bundles to Application Server

[Christian Vogel]

Hi guys,

Currently I'm researching what kind of possibilities I have to deploy bundles developed with Bndtools to an application server like JBoss. Has anyone experiences and could help me out?

What I'm thinking so far:

I could add a new Ant "deploy-remote" target which builds all projects and then copies the created bundles to an application server folder. Question: How could I also copy the dependend bundles from cnf to this folder as well? All what I need could come from the *.bndrun properly?!

Are there any other possibilities?

Regards.

Christian

[Christian Vogel]

What I've forgot to mention. It's not a web application I want to deploy. Maybe one component/bundle could be a webservice yes, but the others are normal bundles. So I guess a WAB archive is not what I'm looking for?! 

[Peter Kriens]

bnd has the package command that creates a runnable JAR (with Main-Class). The way this is packaged is not hard coded in bnd but it is delegated to the launcher, which is pluggable. When bnd(tools) launches, it searches the -runpath for a manifest entry that identifies the launcher plugin. This launcher plugin is then instantiated in the bnd process and handles the communication to the runtime launcher. I.e, bnd itself is oblivious what happens during launching. This same plugin can also implement a method to create a JAR that is a standalone representation.

If you want to experiment, look at the aQute.launcher project. The code to do the packaging is actually quite small. I guess if you put your launcher on the -runpath then bndtools will automatically export your bndrun file with its policy, I am sure bnd does it from the command line.

Kind regards,

Peter Kriens

[Andrei Pozolotin]

Peter, hello

1) I have a factory component question, if I may:

re : http://www.osgi.org/download/r4v42/r4.enterprise.pdf

112.2.4 Factory Component

SCR must register a Component Factory service on behalf of the component as soon as the component factory is satisfied. The service properties must be:
• component.name – The name of the component.
• component.factory – The factory identifier.

The service properties of the Component Factory service must not include the component properties

2) why the decision "must NOT include the component properties" was made and can it be undone?

I need these properties, and I do get them, but to get them,
I need to jump through quite a few hoops, and I keep asking myself - why? :-)

here is the specific example I want to have it in DS:
https://gist.github.com/3608800

Thank you,

Andrei

[David Jencks]

Andrei,

The properties and references all show up in the components created by componentFactory.newInstance(props).  Looking at your gist, I see that you appear to want the properties to show up in the component factory too, as you state below, but I don't see any reason or explanation why this would be useful in any way.  Could you explain what they would allow you to do and how?

thanks

david jencks

[Christian Vogel]

Hi Peter,

A one executable Jar is not what I want since the execution environment comes from the application server and the executable jar has its own depending on what the -runfw flag in the bndrun, right?

I'm thinking about reading a bndrun, taking -runbundles and deploy the all bundles to the application server (just copy) in the given order. What do you think about it?

Regards.

Christian  

[Peter Kriens]

Obviously you do not have to repeat the current model. However, the model also allows a launcher to create a WAR and deploy it on a remote server. The interaction is quite easy. When launching, bnd just builds the jars, and then finds the LauncherPlugin on the -runpath to handle the launching. What that thing does, is its concern, it can turn it into any format it wants. The executable() method on the LauncherPlugin is just a way to get a standalone deploy artifact. You could turn into a Karaf feature, an OSGi subsystem, a WAR, etc.

So what you want, you can clearly do. In general, I would follow the way the current launcher works since it packages the jars together in some shape, but it also takes care of -runproperties, setting up the env, etc. 

Kind regards,

Peter Kriens

[Peter Kriens]

If it included the service properties the factory would be confused with the instances. The instances will have the service properties (and parameter properties).

I feel your pain but having them on  both is potentially very confusing. 

Kind regards,

Peter Kriens

[Rafał Krzewski]

Christian, 

you might want to take a look at Paul Bakkers contribution: PR #386

I don't know if ACE would fit your particular workflow or not, but in any case it's a practical example of integration of third party application with Bnd lanucher.

Regarding using -runbundles from your own standalone launcher - you probably should take a look at <proj>/generated/<desc>.bndrun.resolved file - it contains complete URLs to all necessary bundles.

There's a problem however: file: URLs to workspace bundles are broken. See Issue #510. I managed to track it down and fixing, my PR is waiting for review: PR #522

Cheers,

Rafał

[Rafał Krzewski]

OSGi subsystem! After having read about Eclipse Virgo PARs, Karaf features, Aries applications etc, I was really impressed with OSGi subsystems spec. 

Just in case someone around here haven't read about those earlier here's nice presentation from OSGiCon 2011:

http://www.slideshare.net/mfrancis/subsystems-for-those-occasions-where-bundles-are-just-too-small-graham-charters 

Apache Aries is working on an reference implementation: https://issues.apache.org/jira/browse/ARIES/component/12313494 I'm looking at their Jira & SVN from time to time and the project seems to be shaping up very nicely. It will probably take a while before the implementation finds its way into OSGi container / appserver projects like Apache Karaf or Apache ACE, but one can always whip up a little framework launcher and try it :) OSGi is supposed to make things easy, right? ;)

I don't know what kind of tooling support will be useful for producing esa bundles, but I have a feeling that BND and especially R5 Resolver will be indispensable ingredients. 

This is exciting stuff. Can't wait to see how it turns out in practice!

Cheers,
Rafał

[Christian Vogel]

Hi Rafał,

I already had a look to Apache ACE as a provisioning server for OSGi, but I'm having problems to run it, since there is no documentation how to making for example application server as targets :( But I'm continously trying it. I also thought about a headless deployment, but from what I see, that is more difficult as just using a custom Launcher and preparing a nice view in Eclipse :)

CV

[Rafał Krzewski]

I've noticed that there's significantly more documentation present in the Wiki than the published static site.

For example look here: https://cwiki.apache.org/confluence/display/ACE/User+Documentation

It seems that you should be able to drop "mangement agent bundle" into, say, Glasssfish or JBoss 7+ and have it connect to a provisioning server to pull application bundles from there. I haven't tried that though. Did you try asking on the ace-users list? The devs seem to be a friendly bunch.

Cheers,

Rafał

[Christian Vogel]

Thank you so much for the wiki. Did'nt find it for myself ^^ It explains a lot and showed me I'm moving in the dright direction :) I will try it further later and maybe I will come with some news later than. If you want I can be in touch with you on this topic?!

Cheers,
Christian

[Rafał Krzewski]

No problem :) Please, share your experiences!

Cheers,
Rafał

[Marcel Offermans]

On Sep 4, 2012, at 15:53 PM, Rafał Krzewski <rafal.k...@gmail.com> wrote:

I've noticed that there's significantly more documentation present in the Wiki than the published static site.

For example look here: https://cwiki.apache.org/confluence/display/ACE/User+Documentation

It seems that you should be able to drop "mangement agent bundle" into, say, Glasssfish or JBoss 7+ and have it connect to a provisioning server to pull application bundles from there. I haven't tried that though. Did you try asking on the ace-users list? The devs seem to be a friendly bunch.

Rafał, Christian, please do contact us on that mailing list. We are aware that documentation is lacking in some areas and your questions and input help us improve that.

Greetings, Marcel

[Christian Vogel]

Hi Marcel,

You're absolutly right. Some discussion should go to the ace-user mailing list and I will mail there for sure, because I'm facing some issues which should'nt be discussed here.

@Rafał: It works now. I only had to add the managementagent bundle to JBoss plus changing the standalone.sh for providing system properties (explained in the ACE wiki) used to connect to Apache ACE server.

cheers,

Christian 

[Andrei Pozolotin]

David:

re: "explain what they would allow you to do and how"

when DS component declares " @Component(factory = CompFactory.FACTORY)"
you have a semantic overload:
a) some properties could belong to the "factory"
b) and some to the "instance" made by the "factory";

the ComponentFactory
http://www.osgi.org/javadoc/r4v42/org/osgi/service/component/ComponentFactory.html

is not flexible enough - " red herring" according do Neil:
http://njbartlett.name/2010/07/19/factory-components-in-ds.html

exactly because there is no easy way to customize it;

the way I would use custom factory properties is for dynamic bind / filtering
of ComponentFactory injections:
https://gist.github.com/3608800

@Reference( //
	target = "(component.factory=bench.*)", //
	cardinality = ReferenceCardinality.MULTIPLE, //
	policy = ReferencePolicy.DYNAMIC //
	)
	protected void bind(final Compon
entFactory s,
			final Map<String, Object> props) 

you could take a look on my work around here:
https://github.com/carrot-garden/carrot-osgi/tree/master/carrot-osgi-scr-factory-ds

all I am trying to achieve is to find a simple use pattern
for DS + ComponentFactory, which seems to be missing form OSGI spec;

thank you;

Andrei

[Andrei Pozolotin]

Peter

1) please take a look on my answer to David - below;

2) it seems people are more confused by the current spec:
http://floriansblog.wordpress.com/category/osgi-3/

3) simple way to "unconfuse" would be to clarify this in the osgi spec
and provide one simple use case on www.osgi.org or osgi wiki;
currently missing topic there: "DS + ComponentFactory"

4) same applies to "DS + ConfigAdmin"

5) I have both cases covered here:

config admin driven declarative services factory manager
https://github.com/carrot-garden/carrot-osgi/tree/master/carrot-osgi-scr-factory-cm

component factory driven declarative services factory manager
https://github.com/carrot-garden/carrot-osgi/tree/master/carrot-osgi-scr-factory-ds

thank you;

Andrei


#################################

#################################

[David Jencks]

Andrei,

Sorry, but I still don't understand what problem you are trying to solve.

I agree that the DS spec doesn't explain all that well how you use config admin to create lots of instances of a component.

Can you explain in words a concrete problem that can be solved by having custom service properties  on a component factory?  I'm still at the point of understanding that you want these extra properties but not understanding what problem you want to use them to solve.

It's possible to make all sorts of more complex configuration methods, but without knowing what they might be good for in a really clearly understandable way I think what's there now might be complex enough.

thanks

david jencks

[BJ Hargrave]

On Sep 12, 2012, at 13:21 , Andrei Pozolotin <andrei.p...@gmail.com> wrote:

3) simple way to "unconfuse" would be to clarify this in the osgi spec
and provide one simple use case on www.osgi.org or osgi wiki;
currently missing topic there: "DS + ComponentFactory"

4) same applies to "DS + ConfigAdmin"

Did you look at OSGi in Action? They have a chapter on DS which includes discussion of these topics.

-- 

BJ

[Andrei Pozolotin]

David:

re: "problem you want to use them to solve"

problems:

1) I would like to have simple component factory inside the DS metaphor;

2) I do NOT want ConfigAdmin / configuration persistence approach;

3) I DO want org.osgi.service.component.ComponentFactory approach instead;

4) for that, I will declare my DS ComponentFactory " @Component(factory = CompFactory.FACTORY)" DS components;

5) and manage DS component life cycles via a "factory manager", which would need to collect all appropriate DS factories via a dynamic bind, like this:

@Reference( //
	target = "(component.factory=bench.*)", //
	cardinality = ReferenceCardinality.MULTIPLE, //
	policy = ReferencePolicy.DYNAMIC //
	)
	protected void bind(final Compon
entFactory s, final Map<String, Object> props) 

6) specific problem is that [ target = "(component.factory=bench.*)" ] filter
is a very crude/static tool to collect appropriate ComponentFactory injections in the "factory manager";"
 
7) ideally,

I would like to filter ComponentFactory bind dynamically by some interface name,
which is determined by the "factory manager" dynamically, at run time only;

and this interface name is communicated from the DS ComponentFactory declaration
" @Component(factory = CompFactory.FACTORY)"

into a DS factory manager via the bind properties "props":

protected void bind(final ComponentFactory s, final Map<String, Object> props) 

which come form the DS ComponentFactory @Property,
and interpreted as properties of the factory itself, not of a factory-produced instance;

again, this is a prototype:
https://gist.github.com/3608800

thank you;

Andrei.

[Andrei Pozolotin]

BJ:

yes, book example is great, but does not answer my major complaint (see below):

------------------

6) specific problem is that [ target = "(component.factory=bench.*)" ] filter
is a very crude/static tool to collect appropriate ComponentFactory injections in the "factory manager";"

------------------

this is just one of few scenarios I can not do with ComponentFactory due to $ 112.2.4 limitation;

one more example you replied to already:
http://floriansblog.wordpress.com/category/osgi-3/

thank you;

Andrei


#################################


David:

re: "problem you want to use them to solve"

problems:

1) I would like to have simple component factory inside the DS metaphor;

2) I do NOT want ConfigAdmin / configuration persistence approach;

3) I DO want org.osgi.service.component.ComponentFactory approach instead;

4) for that, I will declare my DS ComponentFactory " @Component(factory = CompFactory.FACTORY)" DS components;

5) and manage DS component life cycles via a "factory manager", which would need to collect all appropriate DS factories via a dynamic bind, like this:

@Reference( //
	target = "(component.factory=bench.*)", //
	cardinality = ReferenceCardinality.MULTIPLE, //
	policy = ReferencePolicy.DYNAMIC //
	)
	protected void bind(final Compon
entFactory s, final Map<String, Object> props)

6) specific problem is that [ target = "(component.factory=bench.*)" ] filter
is a very crude/static tool to collect appropriate ComponentFactory injections in the "factory manager";"
 
7) ideally,

I would like to filter ComponentFactory bind dynamically by some interface name,
which is determined by the "factory manager" dynamically, at run time only;

and this interface name is communicated from the DS ComponentFactory declaration
" @Component(factory = CompFactory.FACTORY)"

into a DS factory manager via the bind properties "props":

protected void bind(final ComponentFactory s, final Map<String, Object> props) 

which come form the DS ComponentFactory @Property,
and interpreted as properties of the factory itself, not of a factory-produced instance;

again, this is a prototype:
https://gist.github.com/3608800

thank you;

#################################

-------- Original Message --------
Subject: Re: 112.2.4 Factory Component: "The service properties of the Component Factory service must not include the component properties"

From: BJ Hargrave <b...@bjhargrave.com>
To: bndtool...@googlegroups.com

[Andrei Pozolotin]

Peter:

is it too late to have it changed, say via a property name space agreement:

if a property looks like "factory.*" then it will be injected into the ComponentFactory properties;

?

Thank you;

Andrei

-------- Original Message --------
Subject: Re: 112.2.4 Factory Component: "The service properties of the Component Factory service must not include the component properties"
From: Peter Kriens <peter....@aqute.biz>
To: bndtool...@googlegroups.com
Date: Tue 04 Sep 2012 01:25:12 AM CDT

If it included the service properties the factory would be confused with the instances. The instances will have the service properties (and parameter properties).

[Peter Kriens]

I have no idea what you try to achieve in the "real world"? Can you give a practical concrete example/use case and show what you're missing? I.e. you're currently complaining about lacking features, not really the showing the concrete real world problem you're trying to solve. My intuition is that you have a model in mind and want to bend to the tool to your model instead of going with the flow ... Have done this (too many times) myself and I can assure you it usually does not work out :-)

Kind regards,

Peter Kriens

[Andrei Pozolotin]

BJ:

re: "DS is not designed to solve all service problems."

despite ipojo and blueprint, DS refuses to die; i.e.:

http://www.linkedin.com/groupItem?view=&gid=122461&type=member&item=98797625

Which OSGi Dependency Injection Framework Do You Use?

posted 6 months ago • 76 votes

• Declarative Services (OSGi 112)

  26 (34%)« your vote

• Blueprint / Spring DM (OSGi 121)

  28 (36%)

• Apache Felix iPOJO / SCR

  19 (25%)

• Stuart's Peaberry (Guice)

  0 (0%)

• None or Other (please comment)

  3 (3%)

I am curious if you plan to expand it,
or if you consider it a "legacy" technology?

thank you;

Andrei.

-------- Original Message --------
Subject: Re: 112.2.4 Factory Component: "The service properties of the Component Factory service must not include the component properties"
From: BJ Hargrave <b...@bjhargrave.com>

To: Andrei Pozolotin <andrei.p...@gmail.com>
Date: Wed 12 Sep 2012 03:51:16 PM CDT

On Sep 12, 2012, at 16:39 , Andrei Pozolotin <andrei.p...@gmail.com> wrote:

BJ:

yes, book example is great, but does not answer my major complaint (see below):

------------------
6) specific problem is that [ target = "(component.factory=bench.*)" ] filter
is a very crude/static tool to collect appropriate ComponentFactory injections in the "factory manager";"
------------------

this is just one of few scenarios I can not do with ComponentFactory due to $ 112.2.4 limitation;

one more example you replied to already:
http://floriansblog.wordpress.com/category/osgi-3/

So more properties to describe the factory (besides the component.factory property whose value you get to set) is somehow less crude and less static?

How is 2 or n properties on the ComponentFactory service more useful than just 1? You can cram a lot of information in the 1 property.

As for static-ness, you don't have access to the ComponentFactory service to be able to alter its properties once the ComponentFactory service is registered by DS. So even if you could set more than one property, you could not change it dynamically.

DS is not designed to solve all service problems. It hopefully addresses the most common use cases of using OSGi services. But we understood that very special/complicated use cases will require the use of the service API.

-- 

BJ

[Andrei Pozolotin]

Peter:

my "real world" problems are similar to this:
http://floriansblog.wordpress.com/category/osgi-3/

thank you;

[BJ Hargrave]

Yes, we plan to extend it. It is not legacy technology. However, we don't plan to extends it to cover every possible use case with services.

You can do what you want with DS today. You just don't like only one property on the ComponentFactory service. You ask for more but don't explain why you can't do what you want with what you already have. You mention dynamism but don't explain what you mean.

From the blog post you link, you can select the factory based upon the factory property. Just include the shape type in the factory property: factory="study1.shapesfactory.circle", factory="study1.shapesfactory.square". Then the IShapeFactory class can select the desired Component property with "study1.shapesfactory."+type.

So as far as I can see, DS will do what you want today using only the single factory property.

Finally, you are advocating a change to the OSGi spec in the bndtools mail list. It would be far better to have this discussion in osgi-dev.

-- 

BJ

[Andrei Pozolotin]

ok; got it; thank you.

-------- Original Message --------
Subject: Re: 112.2.4 Factory Component: "The service properties of the Component Factory service must not include the component properties"
From: BJ Hargrave <b...@bjhargrave.com>
To: Andrei Pozolotin <andrei.p...@gmail.com>

[Andrei Pozolotin]

Peter:

thanks for getting back;

what you say makes sense, can you please share some code links that demonstrate your approach?

I still believe that ComponentFactory could be resurrected with "All these goodies" included - may be some other time :-)

Andrei.

-------- Original Message --------
Subject: Re: 112.2.4 Factory Component: "The service properties of the Component Factory service must not include the component properties"
From: Peter Kriens <peter....@aqute.biz>
To: Andrei Pozolotin <andrei.p...@gmail.com>

Date: Sat 15 Sep 2012 06:41:32 AM CDT

The problems still contrived but I think I understand the point. The thing is that I do not think this is the optimal approach to this class of problems. The key rationale for services is that the provider can offer an implementation of a contract (the service interface) allowing the consumer of the contract to be completely oblivious of the provider, linking the two dynamically when they are hosted in the same system. 

For a given problem this connection should only be made once, however in the blog the author wants to do the dynamic linking for each domain object. In my experience, it is much better to register single ShapeFactory service with createCircle, etc, than to try to instantiate each shape separately. A few years ago I tried to come up with a general model for this factory problem but in the end concluded that registering a service that's a factory makes a lot more sense. Suddenly you get all the type safety of the language and the corresponding IDE support. All these goodies are absent when you have to use the ComponentFactory. 

In the case of Vaadin the component factory makes sense to give you a ShapeFactory because you need to maintain them by session, however, there is no need I think to have that overhead for each shape. Once you have a ShapeFactory bound to the session you're ok.

Peter Kriens

Sent from my iPad