"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. > 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. 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. -- Steven E. Harris