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 <[email protected]> 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?
Thanks,
Sahoo
