Ok, our bundles are resolved ... so there is no issue at all; thanks; /pierre
On Fri, Apr 23, 2010 at 10:18 PM, Richard S. Hall <[email protected]>wrote: > On 4/23/10 16:05, Pierre De Rop wrote: > >> 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 ? >> >> > > If your bundles appear to be resolved correctly when doing "ps", then > everything is probably ok. > > The resolver still needs some cleaning up. Right now for debug purposes I > am reporting intermediate resolve exceptions (e.g., such as when I encounter > a constraint violation). It is not clear if I should log these at all, so I > will have to think about that in the final code, but for now you will see > them. I understand it is a little confusing since it may look like your > bundle didn't resolve successfully, but as long as its state is RESOLVED or > ACTIVE, then the error log was just an intermediate result. > > So, hopefully the result is correct and it is not taking it a long time to > calculate it. :-) > > -> richard > > > > 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 >>> >>> >>> >>> >> >> >
