Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
In truth, I wasn't much of a fan of the whole "start" flag in the
first place. I think OBR should be a deployment tool only.
That would be fine, but at present there's no connection in the OBR
interface between the Resources consumed and exposed and what actually
gets deployed -- the actual Bundle instances. OBR talks in Resources,
which are obviously related to Bundles, but, as I've made much noise
about here, jumping back and forth between the two is not well
supported.
Are you suggesting removing the "start" flag from the OBR Resolver?
Well, I wouldn't be against it. The main reason it is there is to have
some capability with OBR1, which had the capability. In fact, when I
first did OBR1, it didn't have the capability either and I believe
someone requested it.
That's exactly what I need: Some way to identify the transitive
closure of the bundles involved in a deployment. I don't care whether
the bundle was already installed or if it just got downloaded; I want
to start them all, or stated alternately, make sure they are all
marked to be started.
But now we're talking again about hypothetical future facilities. I
arrived at the problem in this thread by more or less giving up on the
other deployment approach I've described, trying to stick to the
facilities available today. And now we're considering removing another
facility, pushing success even further away.
Sorry, that's certainly not the goal. We have limited resources, so it
is hard to get everything done at once. And, in general, it is not a
good idea to make expedient decisions because then it is hard to back
away from them later.
Here's the problem with removing the "start" flag: How does the user
know which Bundles got deployed? The Resolver.getAddedResources(),
Resolver.getRequiredResources(), and Resolver.getOptionalResources()
methods give the set of which /Resources/ were deployed, but we can't
get from a Resource to a Bundle. (Just as I've been pining for a way
to get from a Bundle to a Resource.)
The resource gives you the symbolic name and version, which uniquely
identifies the bundle.
The only way I see to map a Resource to a Bundle is to call
BundleContext.getBundles(), the walk the array, looking for one that
"matches" the Resource, I guess by way of symbolic name and
version. Again, that seems like too much work for the /user/, trying
to make these vague associations between the "world of the OSGi
framework" and the "world of OBR", when under the covers these
associations are already established.
I'm not complaining about having to call Bundle.start() myself. I'm
complaining about how I'm supposed to get the Bundle in hand.
I believe there is a PackageAdmin method to get a bundle by symbolic
name and version, but all it does is loop through the installed bundles
like you describe. There is no association between a resource and an
installed bundle under the covers as you imply other than this. At some
point, someone needs to write the low-level mechanism and then someone
else needs to write the next layer on top of that and so on. Right now,
we are at the lower layers, that's all.
A thought, I could imagine another possibility, where the deploy()
method could return some sort of mapping between its resources and the
bundles it deployed or there could be another method that returned this
mapping after deploy() was invoked, since the resolver would be able to
construct this mapping while deploying the resources.
-> richard
