Ok, Richard;
Thank's a lot for your help. I think I have now a clear understanding
about the OBR.
As you suggested, may be the best thing to do is to make a sort of
"application installer" on top of the BundleRepository service.
Regards;
/Pierre.
Richard S. Hall wrote:
Pierre De Rop wrote:
I think I understand what is going on:
In the OBR, I have:
* B1.jar (with "Import-Package: com.b2" and Import-Service: B2") ->
installed from OBR
* B2.jar (with "Export-Package: com.b2") -> installed from OBR
* B2Impl.jar (with "Export-Service: B2") -> installed from OBR
* B2OtherImpl.jar (with "Export-Service: B2") -> *not* installed
from OBR
After having looked at the BundleRepository code, it sounds like
*only one* preferred resource is resolved for each required
capabilities.
That is: when resolving B1.jar, the BundleRepository will choose the
best resource for the "Import-Service: B2" requirement ... and it will
only install B2Impl.jar.
Is that right ?
It is not that a single "preferred" implementation is installed, but
currently OBR just does not handle that case and it probably still
wouldn't be exactly what you want even if it did.
In the OBR metadata, we currently support the notion of cardinality
(i.e., multiple=true), so it is/was the intent to modify OBR so that
it would be able to deal with installing more than one provider for
aggregate requirements. This is something that should still be done.
However, OBR would still only be able to handle them in a simplistic
way with a couple of predefined policies, e.g., one or all. It would
be likely, though, that you would want to describe an application
where you had a specific aggregate dependency, but you only wanted a
subset of providers installed, for example, and then this would still
not be possible with OBR.
In the end, it still sounds like you are asking for a more advanced
"application" installer that would be a layer above OBR, which is
something that I would like to work on if I had the time. The best we
could do with OBR is implement support for aggregates.
-> richard
/Pierre.
Pierre De Rop wrote:
Thanks Richard;
Fortunately, we are also using bindex; and I have made a quick test
which seems to work:
* I have inserted the header "Import-Service: ..." in B1.jar
* and "Export-Service: ..." in B2Impl.jar
And after having deployed B1.jar from the OBR, I can now see that
B1.jar, B2.jar and B2Impl.jar are now properly installed in my fwk (
:-) )
However ... I have a case where B2.jar service is implemented by two
different implementation bundle (for ex: B2OtherImpl.jar).
Actually, B1.jar tracks the B2 service using a service property in
order to load the convenient implementation.
So, I also inserted the header "Export-Service" in B2OtherImpl.jar
(with the same service name as in B2Impl.jar) ...
But unfortunately, B2OtherImpl.jar has not been installed from the
OBR !
Do you think this could be a bug from the BundleRepository bundle ?
(Notice that If I remove B2Impl.jar from the OBR, then
B2OtherImpl.jar is properly installed !)
/Pierre.
Richard S. Hall wrote:
It sounds like what you want is some way to install "applications".
OBR was not intended to support applications...I figured this would
be a layer above OBR.
I think that some people have experimented with approaches for
deploying sets of bundles, perhaps they can respond.
As a simple solution to your situation mentioned below, you could
have your client bundle require a B2 service, since B2Impl should
provide a B2 service, then OBR should correctly deploy it.
In other words, your B1 metadata is incomplete, since it only
states that it requires the packages, not a service. OBR
capabilities also allow you to specify that you require and/or
provide a service, which will then be included in the resolve process.
I think the bindex tool correctly converts Import-Service and
Export-Service manifest entries into requirements and capabilities...
-> richard
Pierre De Rop wrote:
Hello everyone;
We are using the felix OBR (1.0.0) for deploying bundles into our
application server.
So, we store all our bundles into an OBR http server, and we uses
a GUI obr browser which allows to install some bundles from the
OBR into the application server.
Now, assuming that the following bundles are stored in the OBR
repository:
* B1.jar (which imports package from B2.jar. The ServiceTracker
will
be used to get B2 instance)
* B2.jar (only contains an API interface)
* B2Impl.jar (contains an activator which registers into the
service
registry an implementation for B2.jar)
So; using a GUI, I deploy B1.jar from the OBR into my cluster -->
the OBR will install both B1.jar and B2.jar because
B1.jar imports packages from B2.jar ... But what about B2Impl.jar ?
B2Impl.jar won't be installed because there is not direct
dependencies between B1.jar/B2.jar and B2Impl.jar.
I could use the "Require-Bundle: B2Impl" header in B2.jar, but
this is not a good practice (see Peter Kriens remarks about that,
and also the specification, which details many problems about
using Require-Bundle header) ...
You could just tell me that the only solution consists in clicking
on B2Impl.jar in order to install it too ... But the point is : we
have potentially many bundles to deploy and the administrator does
not necessarily always have knowledge about all bundles to be
installed ...
So the question is: how to simplify the deployment of a complex
application from the OBR ? Is there any other headers than
"Require-Bundle" that could ease deployment of bundles from the OBR ?
/Pierre.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
