felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sahoo <Sa...@Sun.COM>
Subject Re: Patch for File Install issues #FELIX-937, 938 & 939
Date Wed, 18 Feb 2009 18:39:05 GMT
Hi Filippo,

Thanks for taking time to look at the patch and try it out at your end. 
See comments in line...

Filippo Diotalevi wrote:
> On Wed, Feb 18, 2009 at 4:50 AM, Sahoo <Sahoo@sun.com> wrote:
>> Sahoo wrote:
>>> I have attached the patch to FELIX-939. I did not want to separate the
>>> patch into three because while trying to address 939, I took care of the
>>> other two issues.
>> Any comments about this patch?
> Hi Sahoo, I notice a couple of strange behaviors in the patched code;
> I had to change my code to be able to run it with the patched version,
> I'm not sure they're bugs though.
> 1) I installed by bundles using a relative path formatted as
> "file:bundles/mybundle.jar"
> Felix doesn't complain and install the bundle correctly. On the other
> side, the plain Java code
> String location = new URI(bundles[i].getLocation()).normalize().getPath()
> (DirectoryWatcher, line 493) returns null
> Of course, I get a NPE on the following instruction.
> Note that bundle[i].getLocation() returns the correct
> "file:bundles/mybundle.jar" String.
> To fix that I used the absolute path (
> "file:///absolutepath/bundles/mybundle.jar"
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,

Should we check if the URI is opaque (uri.isOpaque()) before attempting 
to use its path component? That will avoid the NPE for sure, but we will 
end up installing and possibly starting the bundle again (issue 
#FELIX-937). Do you have any suggestion?
> 2) I have bundle who is dependent on externally provided services that
> is not started (I can start it later manually, and it works).
> I haven't investigated on this issue, but it seems to be related to
> the order bundles are started.
This behavior should not have changed. It is essentially the same: we 
install in one round and then start all installed bundles in the same 
order as they are installed. The order in which we install depends on 
the order in which they are stored in the map and hence unpredictable. 
If your bundle depends on another bundle to be started, should you not 
be using a service tracker or something like that?


View raw message