|
Here is my scenario (100% reproducible):
I have the following bundles: 36 ACTIVE org.springframework.bundle.osgi.extender_1.1.0.m2 40 ACTIVE org.springframework.bundle.osgi.web.extender_1.1.0.m2 I then install a fragment bundle which needs to be attached to 40: install file:/Users/ypujante/.m2/repository/com/linkedin/kernel-core/lispring-osgi-web/1.0.0-SNAPSHOT/lispring-osgi-web-1.0.0-SNAPSHOT.jar Bundle id is 61 I then do a refresh 40 so that the fragment gets attached to 40 40 ACTIVE org.springframework.bundle.osgi.web.extender_1.1.0.m2 Fragments=61 I see the following on the console: com.linkedin.lispring.osgi.web.OsgiJettyComponentWarDeployer@871d3e com.linkedin.lispring.osgi.web.OsgiJettyComponentWarDeployer@b9b888 (the constructor for my war deployer implementation simply does a system.out.println(this) As you can see the object is being created twice. And it makes sense. I agree with you that a fragment cannot be started, but as soon as you do 'refresh 40' 2 things happen: 1) bundle 40 extender pattern detects the META-INF/spring/*.xml and correctly loads the beans in them to discover the war depoyer 2) but bundle 36 now sees a new bundle: bundle 40 + fragment 61... for bundle 36 it does not know that the META-INF/spring/*.xml are coming from a bundle... that is the beauty of osgi... it is transparent: bundle 40 + fragment 61 is a new whole bundle... the extender pattersn (for 36) kicks in because ConfigUtils.isSpringOsgiPoweredBundle(40) now returns true... as a result the same beans get instantiated a second time as demonstrated by the output. In other words 36 is not acting on 61 but on 40 which is a valid, started bundle... The spring file in bundle 61 is simply doing: <bean id="warDeployer" class="com.linkedin.lispring.osgi.web.OsgiJettyComponentWarDeployer"/> Yan, I've modified the extender configuration locations to META-INF/spring/extender/*.xml. This should avoid confusion with both users and other extenders.
The change is available in the latest nightly build. It would be swell if you could give the TRUNK a try and report back. Thanks, Costin, that should definitely fix the problem. I am not sure how to get a trunk build. I was able to checkout the source code from the trunk but not compile it... is there a nightly build somewhere ?
Getting this error at build time (mvn install): Missing: ---------- 1) net.java.dev.jets3t:jets3t:jar:0.5.1-20080115 I am definitely not a pro of maven... so if there is a premade nightly build I will be more than happy to try it out. Hmm - haven't seen that before. However, see the home page for repositories: http://www.springframework.org/osgi#repos
Hmmm. My company policy does not allow me to get snapshots :( from maven... as soon as it is available as a milestone I will test it out.
Okay - the code is going into freezing state and it will be come out as an RC. You can download the code yourself if you want to try it out - you can build locally for example.
Cheers, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Extender pattern in ...osgi.extender and ...osgi.web.extender conflict with each other
Since a fragment can be attached to only one host, it means that the files are picked only by the extender to which they are attached.
Moreover, the osgi extender looks for this pattern only on bundles that are started. Fragments cannot be started only resolved.
This being said, I'd be interested in any tests or examples that you have that expose the problem you described.