You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2010/04/23 21:07:00 UTC
Framework trunk changes
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
Re: Framework trunk changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/23/10 16:29, Pierre De Rop wrote:
> Ok, our bundles are resolved ... so there is no issue at all;
>
Excellent!
-> richard
> thanks;
> /pierre
>
> On Fri, Apr 23, 2010 at 10:18 PM, Richard S. Hall<he...@ungoverned.org>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<heavy@ungoverned.org
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: Framework trunk changes
Posted by Pierre De Rop <pi...@gmail.com>.
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 <he...@ungoverned.org>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<heavy@ungoverned.org
>> >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
>>>
>>>
>>>
>>>
>>
>>
>
Re: Framework trunk changes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<he...@ungoverned.org>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
>>
>>
>>
>
Re: Framework trunk changes
Posted by Pierre De Rop <pi...@gmail.com>.
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 <he...@ungoverned.org>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
>
>