Ultimately, you will need a "custom" solution as you suggest at the
bottom, but it can still be based on OBR to some degree or the other.
The OBR API allows you to provide repositories, so you just need to
define your own which don't have to be XML based. Then you can pass them
to the OBR resolver. As far as deployment, you'd have to handle any
additional work you need, but you can inspect the resolved result to
know what bundles will be deployed when you call deploy()...the only
trick is that the deploy() method tries to update in some cases and
install in others and I don't think it tells you in advance which it is
going to do (it actually calculates if an update is possible during
deployment).
You could always write your own code to do the deployment based on the
resolver result. Regardless, what you want to do is possible, but will
require you to do a bit more work since it is not the use case that OBR
specifically targeted.
-> richard
On 10/8/11 4:24 AM, DEBROUX Lionel wrote:
Hello,
I have a use case for deploying bundles (which may have transitive,
versioned dependencies) accross several LAN nodes all installed with
the Felix framework.
The main goal is to have, for each node, the ability of:
- (1) acting as a server for bundles towards other nodes
- (2) downloading and installing bundles from other nodes, since all
nodes provide (1)
Each node would also be expected to:
- (3) have every downloaded and/or installed bundle automatically
appearing as available for download to other nodes.
Therefore, the use case is a step beyond the standard model, where
client nodes are in most cases constantly downloading from a known
and predefined "central" OBR.
The point is to:
- enhance robustness, in case remote OBRs are unreachable when the
need to deploy bundles to other nodes arise.
- favor deployments within local node neighbourhood, by exposing
bundles to a set of nearby nodes.
Example:
Nodes A, B and C belong to the same network neighbourhood N1
Nodes C, D and E belong to the same network neighbourhood N2
- C gets and deploys bundle Foo from E using (2)
- as a member of both N1 and N2, bundle Foo becomes then available
to all members of N1 and N2 because of (3) and (1)
- E dies
- A and B can get and deploy bundle Foo from C rather than from E.
I'd like hints on how to best use the OBR infrastructure to achieve
(1), (2) and especially (3). Maybe it needs to be modified ?
Or maybe there are better solutions than the OBR infrastructure ?
I looked at OBRs because the OBR client can download from multiple
OBRs, and transitive dependencies are handled.
However, I noticed that:
* updating OBR XML files takes some work. There's the Maven plugin,
but I'd rather not use that in production, there should be
something leaner;
* when deploying a bundle, ResolverImpl.deploy() calls
BundleContext.installBundle() but does not keep a separate copy
of the bundle, which I'd like to do;
* dumping the local repository to XML form, through
DataModelHelper.writeRepository(), is easy, but there are no
URIs for the bundles in there. As a consequence, even if I
exposed the local repository XML file on the network, OBR
clients wouldn't be able to install the bundles.
For demo purposes, I can build a custom solution, starting by exposing
through servlets directories containing bundles. In fact, I have been
given some code that does just that. From that point, I have made some
rough code to download and install individual bundles into the target
framework.
But for production use, I'll want to provide some higher-level
information (bundle symbolic names, dependencies, etc.) and handle
transitive dependencies... which brings me back to the already
invented OBR wheel :)
Thanks in advance for replies,
Lionel.
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant
être assurée sur Internet, la responsabilité du groupe Atos ne pourra être
engagée quant au contenu de ce message. Bien que les meilleurs efforts soient
faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne
donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée
pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for
the addressee; it may also be privileged. If you receive this e-mail in error,
please notify the sender immediately and destroy it. As its integrity cannot be
secured on the Internet, the Atos group liability cannot be triggered for the
message content. Although the sender endeavors to maintain a computer
virus-free network, the sender does not warrant that this transmission is
virus-free and will not be liable for any damages resulting from any virus
transmitted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
