2009/2/19 Sahoo <[email protected]> > Filippo Diotalevi wrote: > >> On Wed, Feb 18, 2009 at 7:39 PM, Sahoo <[email protected]> wrote: >> >> >>> file:bundles/mybundle.jar is not a hierarchical URI (more details at >>> http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html). I have not >>> looked at Felix code to see how it interprets such a URI, but I assume it >>> parses it on its own and makes some assumption about the format of the >>> URI >>> it can handle. I say this because if you try to create a File object out >>> of >>> a non-hierarchical URI by calling new File(aNonHierarchicalURI), you will >>> get "java.lang.IllegalArgumentException: URI is not hierarchical." On the >>> other hand,... >>> >>> >> >> Yes, you are right, file:bundles/mybundles.jar is not hierarchical. >> However the behavior of the system is a bit inconsistent, since it is >> possible to install and run a bundle in a way that makes the >> fileinstaller not working. >> >> > I think I have a solution for this. We will check if the URI is > hierarchical before using the path component. That will avoid the NPE. To > avoid the issue raised in FELIX-937, we shall not attempt to install the > bundle again if we get an exception while trying to install for the first > time. I will attach a modified patch soon. > >> Do you know if it's a inconsistency of the specification (osgi allows >> opaque URI vs hierarchichal URI only in java), or maybe is just a >> Felix design choice? >> >> > AFAIK, the location argument is interpreted in a framework specific way. > So, I believe it is a Felix design choice to support such a URI. This is > what the javadocs of BundleContext.installBundle(String location) says: > /A bundle is obtained from <code>location</code> as interpreted by the > Framework in > an implementation dependent manner. Every installed bundle is uniquely > identified by its location string, > typically in the form of a URL. > / > I have never understood why the spec left it wide open. How can anyone use > this API and expect their program to be portable. At least they could > mandated it to be a URL. >
umm, according to the spec (4.3.3 Installing Bundles): "installBundle(String) – Installs a bundle from the specified location string (which should be a URL)." however, the companion method that accepts an InputStream does allow flexible/non-URL location strings: "installBundle(String,InputStream) – Installs a bundle from the specified InputStream object." but here the framework is just being agnostic about the location, because it's the client's responsibility to define it (because the framework will get the bundle content from the supplied InputStream handle) so if you want to guarantee 100% portability, you could use the "installBundle(String,InputStream)" API Thanks, > Sahoo > -- Cheers, Stuart
