Hello Richard, Recently, we discovered a performance issue during the start up of our application server (we are using the recent 2.0.5 felix version). So, after investigating, I found that so far, we were uselessly starting the org.osgi.core.jar bundle. Indeed, the framework already exports the packages that are exported by org.osgi.core (except security packages). So, after removing the org.osgi.core bundle, it turned out that the start up performance issue just disappeared.
Now, looking at your mail, I gave a try to the latest felix from trunk + the org.osgi.core.jar bundle, as before. And the good news is that I don't have the start up performance problem anymore (with the org.osgi.core bundle). however, now, I have this warning: RE: org.apache.felix.framework.resolver.ResolveException: Constraint violation for package 'javax.xml.bind' when resolving module 201.0 between existing imported constraint 0.javax.xml.bind BLAMED ON [[201.0] package; (&(package=javax.xml.bind)(bundle-symbolic-name=system.bundle))] and uses constraint 22.0.javax.xml.bind BLAMED ON [[201.0] package; (package= com.alcatel_lucent.as.geored.site.info), [203.0] package; (package=javax.xml.bind)] So, I am now trying to investigate, in order to check if the new felix-trunk has found an error from our side, which we did not notice so far ... But can you please explain me what this warning means ? Is it a DEBUG message ? or a WARN message ? thanks; /pierre On Fri, Apr 23, 2010 at 9:07 PM, Richard S. Hall <[email protected]>wrote: > Hello, > > Just a word to say I just committed some significant changes to the > framework resolver, almost another rewrite. :-( > > This became necessary over the last month when I came upon a scenario that > was creating difficulties for the previous prototype resolver which resulted > first from some bugs and then once these bugs were fixed there were > performance issues. > > This latest resolver algorithm is conceptually very similar, so it is not a > complete rewrite, but the changes were fairly substantial. I am optimistic, > as always. All known scenarios now appear to be working and resolving fairly > quickly and the code passes the R4.2 CT. I'll keep my fingers crossed that > this will be the last major change needed to the core algorithm. > > I deployed new snapshots. Let me know if you start experiencing any > issues...I do know that handling of conflicting fragments is a little > different...among other things I am sure. > > -> richard > >
