On Apr 11, 2007, at 6:55 PM, Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
Yes, if you try to install a bundle with a symbolic name/version it
will fail, no matter what the location string is.
I may have misquoted Mr. Hargrave, but I think he refined this
situation to say, if the location string of the new bundle and the
currently installed bundle's location strings match, no error is
signaled, and the current Bundle is returned.
Yes, sorry, that is the case. If location strings matches it returns
the existing bundle object and no other actions is taken. This has
always been the case, since R1.
To summarize:
You cannot install two bundles with the same location string.
You cannot install two bundles with the same symbolic name/version.
The two statements are independent of each other.
Got it.
If you wanted to be sure that it wouldn't fail for this reason, then
yes you would have to. But what is the point? It could fail for
other reasons too, so are you going to check all of those reasons in
advance too?
Here's why it's different: If it fails for the first reason, because
the bundle is already installed, then I know I can carry on knowing
all is well. The intention was to get some bundle installed. If it
turns out it was already installed, then there is no problem; I was
done before I started.
But if installation fails for some other reason, I'm stuck unable to
discern whether the installation failed due to a duplication conflict
or due to data corruption. I don't know afterward whether I can assume
this bundle is already installed.
Yes, that sounds reasonable. So, then i am back to my other point
that you should probably accept that you have to have additional
metadata on the server side to perform this check before you try to
install. This is not unreasonable, I don't think.
To further disclose the motivating situation, my current design for my
client-server interaction has the server saying, "Here are a bunch of
resources (which are probably all bundles). These resources are
prerequisites for some services I want you to use." The server wants
the client to locate some registered services by providing key-value
pairs to form a filter string. The server knows which bundles host
these services, but the server doesn't know if the client already has
these bundles installed, so it recommends the client install these
bundles every time it recommends the client use some services hosted
by these bundles.
One simple way to solve this problem is to have the client try out
using the filter string before trying to install the associated
bundles. If the filter gets a hit, the bundle is probably already
installed. If the filter gets no hits, the client should try
downloading and installing the bundles, then try the filter
again. This approach misses out on the possibility of updating an
installed bundle that provides a superseded version of the service --
but then services should really be versioned to catch that case.
You may also ask why the server isn't telling the client explicitly
which symbolic-name/version pairs to install. I'm trying to keep OSGi
out of the protocol, by not explicitly mentioning concepts that are
specific to OSGi. Hence my preference for the server to prescribe
opaque resources for the client to download, with a MIME type (via an
HTTP Content-Type header) hinting as to whether to try installing the
resource as an OSGi bundle.
Best of all would be to push all the bundle procurement into OBR. The
server could specify a symbolic-name/version pair as a prerequisite
(or, more abstractly, package names and versions) to construct a
filter to pass to RepositoryAdmin.discoverResources(), then adding
those Resources to a Resolver for resolution and deployment. OBR
handles the case of locally-installed resources filling
requirements. I'm just not sold on the idea of maintaining a
repository.xml file that each client must download.
Yes. Ultimately it sounds like you will be re-implementing a bunch of
stuff that OBR already tries to do for you, so you would probably be
better off just using it in the first place.
It might be possible for you to create a modified OBR that you pass
in the repository you want it to use (or the XML file), that way you
could just get this information directly from the server and pass it
to OBR to do its calculations, if you don't want it to download the
repository file.
However, if your repository file isn't large, it doesn't seem like an
issue to worry about now.
-> richard
--
Steven E. Harris
