Hi Richard,
Unfortunately, using the last snasphot of Felix gives me a
StackOverflowError at runtime which doesn't occur with Felix 1.4.1.
I've made the test by installing the fragment bundle before starting the
host bundle.
Below the stack trace:
ERROR: EventDispatcher: Error during dispatch.
(java.lang.StackOverflowError)
java.lang.StackOverflowError
at java.lang.Character.toUpperCase(Character.java:4274)
at java.lang.String$CaseInsensitiveComparator.compare(String.java:1053)
at java.lang.String$CaseInsensitiveComparator.compare(String.java:1042)
at java.lang.String.compareToIgnoreCase(String.java:1089)
at
org.apache.felix.framework.util.StringMap$StringComparator.compare(StringMap.java:81)
at java.util.TreeMap.compare(TreeMap.java:1093)
at java.util.TreeMap.getEntry(TreeMap.java:347)
at java.util.TreeMap.containsKey(TreeMap.java:204)
at org.apache.felix.framework.util.Util.isFragment(Util.java:538)
at
org.apache.felix.framework.searchpolicy.Resolver.populateWireMap(Resolver.java:1541)
at
org.apache.felix.framework.searchpolicy.Resolver.populateWireMap(Resolver.java:1632)
at
org.apache.felix.framework.searchpolicy.Resolver.populateWireMap(Resolver.java:1632)
at
org.apache.felix.framework.searchpolicy.Resolver.populateWireMap(Resolver.java:1632)
at
org.apache.felix.framework.searchpolicy.Resolver.populateWireMap(Resolver.java:1632)
at
org.apache.felix.framework.searchpolicy.Resolver.populateWireMap(Resolver.java:1632)
This error can easily be reproduced by deploying the two following bundles:
- Install the fragement bundle :
http://repo1.maven.org/maven2/org/slf4j/slf4j-jcl/1.5.2/slf4j-jcl-1.5.2.jar
- Start the host bundle :
http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.5.2/slf4j-api-1.5.2.jar
Thank you.
François
Richard S. Hall a écrit :
Could you try on trunk or the latest released snapshot?
There was a bug fixed recently, perhaps it is related:
http://issues.apache.org/jira/browse/FELIX-852
-> richard
François Fornaciari wrote:
Hi,
I know that the fragment bundle support is on going, but I would like
to submit a case that I have encountered.
It seems that the installation order of a host bundle and its
fragment bundle modify the fragment support behaviour.
I have made some tests and if the fragment bundle is installed before
the host bundle, everything goes fine. The host bundle can load a
class from its fragment and the classloader used to load the class
corresponds to the classloader of the host bundle. This case works
also fine when getting a resource.
If I invert the installation order, that means if the host bundle is
installed before the fragment bundle, the host bundle fails to get
the same resource from the fragment. The class loading seems to work
but if try to print the used classloader, the host bundle loads the
class using the classloader of the fragment host.
Is this behaviour expected?
Regards,
François
