Re: Framework trunk changes
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. Hallwrote: 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 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
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 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> >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
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. Hallwrote: 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
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 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 > >
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
On Mon, Mar 22, 2010 at 9:06 PM, David Jencks wrote: > It would be really great if someone could apply FELIX-2195 so geronimo > developers who use macs can also try this out. Its in trunk now (r926330). Please close the jira if it works for you. regards, Karl > thanks > david jencks > > On Mar 22, 2010, at 11:30 AM, Jarek Gawor wrote: > >> On Sun, Mar 21, 2010 at 4:30 AM, Richard S. Hall >> wrote: >>> >>> On 3/9/10 10:26, Richard S. Hall wrote: Just a follow up...I think I see what is going wrong here...not exactly sure how I will fix it yet, but I see the issue at any rate. In short, the new resolver thinks there is a conflict because the two exports are different capabilities, but since they come from the same bundle this isn't really a conflict. So, I will need to put some sort of check in there to special case this situation I think. Hopefully, I will have a fix tomorrow. >>> >>> Sorry that this took me a little longer than I anticipated, but I just >>> committed what I believe is a fix for this issue. The example bundles now >>> resolve for me. >>> >>> I have deployed new snapshots for framework and main that include this >>> fix >>> and fixes for a few other issues. Let me know if you still have issues. >> >> Great! I tested a few things in Geronimo with latest framework and >> things do appear to be working much better now. >> >> Thanks a lot, >> Jarek > > -- Karl Pauls karlpa...@gmail.com
Re: Framework trunk
It would be really great if someone could apply FELIX-2195 so geronimo developers who use macs can also try this out. thanks david jencks On Mar 22, 2010, at 11:30 AM, Jarek Gawor wrote: On Sun, Mar 21, 2010 at 4:30 AM, Richard S. Hall wrote: On 3/9/10 10:26, Richard S. Hall wrote: Just a follow up...I think I see what is going wrong here...not exactly sure how I will fix it yet, but I see the issue at any rate. In short, the new resolver thinks there is a conflict because the two exports are different capabilities, but since they come from the same bundle this isn't really a conflict. So, I will need to put some sort of check in there to special case this situation I think. Hopefully, I will have a fix tomorrow. Sorry that this took me a little longer than I anticipated, but I just committed what I believe is a fix for this issue. The example bundles now resolve for me. I have deployed new snapshots for framework and main that include this fix and fixes for a few other issues. Let me know if you still have issues. Great! I tested a few things in Geronimo with latest framework and things do appear to be working much better now. Thanks a lot, Jarek
Re: Framework trunk
On Sun, Mar 21, 2010 at 4:30 AM, Richard S. Hall wrote: > On 3/9/10 10:26, Richard S. Hall wrote: >> >> >> Just a follow up...I think I see what is going wrong here...not exactly >> sure how I will fix it yet, but I see the issue at any rate. >> >> In short, the new resolver thinks there is a conflict because the two >> exports are different capabilities, but since they come from the same bundle >> this isn't really a conflict. So, I will need to put some sort of check in >> there to special case this situation I think. >> >> Hopefully, I will have a fix tomorrow. > > Sorry that this took me a little longer than I anticipated, but I just > committed what I believe is a fix for this issue. The example bundles now > resolve for me. > > I have deployed new snapshots for framework and main that include this fix > and fixes for a few other issues. Let me know if you still have issues. Great! I tested a few things in Geronimo with latest framework and things do appear to be working much better now. Thanks a lot, Jarek
Re: Framework trunk
On 3/9/10 10:26, Richard S. Hall wrote: On 3/5/10 10:55, Jarek Gawor wrote: Hi, In Geronimo we also running into some problems with the latest framework/resolver. Specifically, a bundle that exports the same package with different versions seems to be causing problems. You can reproduce the problem we are seeing by installing the following bundles: http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.eventadmin/1.2.2/org.apache.felix.eventadmin-1.2.2.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-api/1.4.1-SNAPSHOT/pax-logging-api-1.4.1-20100213.165007-16.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-service/1.4.1-SNAPSHOT/pax-logging-service-1.4.1-20100213.165007-16.jar http://repo2.maven.org/maven2/org/apache/mina/mina-core/2.0.0-RC1/mina-core-2.0.0-RC1.jar When starting the mina-core package you'll see "ResolveException: Constraint violation for package 'org.slf4j.helpers' " Same set of bundles resolve/start fine on Felix 2.0.4 or Equinox. Just a follow up...I think I see what is going wrong here...not exactly sure how I will fix it yet, but I see the issue at any rate. In short, the new resolver thinks there is a conflict because the two exports are different capabilities, but since they come from the same bundle this isn't really a conflict. So, I will need to put some sort of check in there to special case this situation I think. Hopefully, I will have a fix tomorrow. Sorry that this took me a little longer than I anticipated, but I just committed what I believe is a fix for this issue. The example bundles now resolve for me. I have deployed new snapshots for framework and main that include this fix and fixes for a few other issues. Let me know if you still have issues. -> richard -> richard Jarek On Fri, Mar 5, 2010 at 7:33 AM, David Bosschaert wrote: Yes, it's quite simple to reproduce. 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk 2. First simply do a build with 'mvn install' from the root to get everything ready (you may have to set MAVEN_OPTS=-Xmx512m) 3. cd into systests2/multi-bundle 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. You will see that it runs some test (which uses a fairly large number of bundles). It's currently configured to use Equinox via Pax Exam. 5. Applying the attached patch will change it to use Felix. 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll see that just after 'Welcome to Felix' it hangs. Cheers, David On 3 March 2010 17:30, Richard S. Hall wrote: On 3/3/10 12:13 PM, David Bosschaert wrote: Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... If you can find a simple way to reproduce any long resolves, let me know since I'd like to play with them... -> richard Thanks, David On 3 March 2010 16:55, Richard S. Hall wrote: For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. ->richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk).
Re: Framework trunk
On 3/5/10 10:55, Jarek Gawor wrote: Hi, In Geronimo we also running into some problems with the latest framework/resolver. Specifically, a bundle that exports the same package with different versions seems to be causing problems. You can reproduce the problem we are seeing by installing the following bundles: http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.eventadmin/1.2.2/org.apache.felix.eventadmin-1.2.2.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-api/1.4.1-SNAPSHOT/pax-logging-api-1.4.1-20100213.165007-16.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-service/1.4.1-SNAPSHOT/pax-logging-service-1.4.1-20100213.165007-16.jar http://repo2.maven.org/maven2/org/apache/mina/mina-core/2.0.0-RC1/mina-core-2.0.0-RC1.jar When starting the mina-core package you'll see "ResolveException: Constraint violation for package 'org.slf4j.helpers' " Same set of bundles resolve/start fine on Felix 2.0.4 or Equinox. Just a follow up...I think I see what is going wrong here...not exactly sure how I will fix it yet, but I see the issue at any rate. In short, the new resolver thinks there is a conflict because the two exports are different capabilities, but since they come from the same bundle this isn't really a conflict. So, I will need to put some sort of check in there to special case this situation I think. Hopefully, I will have a fix tomorrow. -> richard Jarek On Fri, Mar 5, 2010 at 7:33 AM, David Bosschaert wrote: Yes, it's quite simple to reproduce. 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk 2. First simply do a build with 'mvn install' from the root to get everything ready (you may have to set MAVEN_OPTS=-Xmx512m) 3. cd into systests2/multi-bundle 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. You will see that it runs some test (which uses a fairly large number of bundles). It's currently configured to use Equinox via Pax Exam. 5. Applying the attached patch will change it to use Felix. 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll see that just after 'Welcome to Felix' it hangs. Cheers, David On 3 March 2010 17:30, Richard S. Hall wrote: On 3/3/10 12:13 PM, David Bosschaert wrote: Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... If you can find a simple way to reproduce any long resolves, let me know since I'd like to play with them... -> richard Thanks, David On 3 March 2010 16:55, Richard S. Hallwrote: For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. ->richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk).
Re: Framework trunk
I will try to look into it. Thanks. -> richard On 3/5/10 10:55, Jarek Gawor wrote: Hi, In Geronimo we also running into some problems with the latest framework/resolver. Specifically, a bundle that exports the same package with different versions seems to be causing problems. You can reproduce the problem we are seeing by installing the following bundles: http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.eventadmin/1.2.2/org.apache.felix.eventadmin-1.2.2.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-api/1.4.1-SNAPSHOT/pax-logging-api-1.4.1-20100213.165007-16.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-service/1.4.1-SNAPSHOT/pax-logging-service-1.4.1-20100213.165007-16.jar http://repo2.maven.org/maven2/org/apache/mina/mina-core/2.0.0-RC1/mina-core-2.0.0-RC1.jar When starting the mina-core package you'll see "ResolveException: Constraint violation for package 'org.slf4j.helpers' " Same set of bundles resolve/start fine on Felix 2.0.4 or Equinox. Jarek On Fri, Mar 5, 2010 at 7:33 AM, David Bosschaert wrote: Yes, it's quite simple to reproduce. 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk 2. First simply do a build with 'mvn install' from the root to get everything ready (you may have to set MAVEN_OPTS=-Xmx512m) 3. cd into systests2/multi-bundle 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. You will see that it runs some test (which uses a fairly large number of bundles). It's currently configured to use Equinox via Pax Exam. 5. Applying the attached patch will change it to use Felix. 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll see that just after 'Welcome to Felix' it hangs. Cheers, David On 3 March 2010 17:30, Richard S. Hall wrote: On 3/3/10 12:13 PM, David Bosschaert wrote: Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... If you can find a simple way to reproduce any long resolves, let me know since I'd like to play with them... -> richard Thanks, David On 3 March 2010 16:55, Richard S. Hallwrote: For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. ->richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk).
Re: Framework trunk
Hi, In Geronimo we also running into some problems with the latest framework/resolver. Specifically, a bundle that exports the same package with different versions seems to be causing problems. You can reproduce the problem we are seeing by installing the following bundles: http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.eventadmin/1.2.2/org.apache.felix.eventadmin-1.2.2.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-api/1.4.1-SNAPSHOT/pax-logging-api-1.4.1-20100213.165007-16.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-service/1.4.1-SNAPSHOT/pax-logging-service-1.4.1-20100213.165007-16.jar http://repo2.maven.org/maven2/org/apache/mina/mina-core/2.0.0-RC1/mina-core-2.0.0-RC1.jar When starting the mina-core package you'll see "ResolveException: Constraint violation for package 'org.slf4j.helpers' " Same set of bundles resolve/start fine on Felix 2.0.4 or Equinox. Jarek On Fri, Mar 5, 2010 at 7:33 AM, David Bosschaert wrote: > Yes, it's quite simple to reproduce. > > 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk > 2. First simply do a build with 'mvn install' from the root to get > everything ready (you may have to set MAVEN_OPTS=-Xmx512m) > 3. cd into systests2/multi-bundle > 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. > You will see that it runs some test (which uses a fairly large number > of bundles). It's currently configured to use Equinox via Pax Exam. > 5. Applying the attached patch will change it to use Felix. > 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll > see that just after 'Welcome to Felix' it hangs. > > Cheers, > > David > > On 3 March 2010 17:30, Richard S. Hall wrote: >> On 3/3/10 12:13 PM, David Bosschaert wrote: >>> >>> Nice :) I've had lots of hangs (or extremely long resolves) in the >>> CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how >>> to get Pax Exam to use this latest build? Currently I'm using: >>> CoreOptions.frameworks(CoreOptions.felix()) >>> to simply select felix... >>> >> >> If you can find a simple way to reproduce any long resolves, let me know >> since I'd like to play with them... >> >> -> richard >> >>> Thanks, >>> >>> David >>> >>> On 3 March 2010 16:55, Richard S. Hall wrote: >>> For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. -> richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk). >> >
Re: Framework trunk
Thanks! On Fri, Mar 5, 2010 at 2:37 PM, David Bosschaert wrote: > FELIX-2172 > > Cheers, > > David > > On 5 March 2010 12:49, Karl Pauls wrote: >> The patch didn't make it. Can you create a jira and attach it there >> please? We have high hopes that the new resolver in trunk will work >> with this kind of scenarios... >> >> regards, >> >> Karl >> >> On Fri, Mar 5, 2010 at 1:33 PM, David Bosschaert >> wrote: >>> Yes, it's quite simple to reproduce. >>> >>> 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk >>> 2. First simply do a build with 'mvn install' from the root to get >>> everything ready (you may have to set MAVEN_OPTS=-Xmx512m) >>> 3. cd into systests2/multi-bundle >>> 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. >>> You will see that it runs some test (which uses a fairly large number >>> of bundles). It's currently configured to use Equinox via Pax Exam. >>> 5. Applying the attached patch will change it to use Felix. >>> 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll >>> see that just after 'Welcome to Felix' it hangs. >>> >>> Cheers, >>> >>> David >>> >>> On 3 March 2010 17:30, Richard S. Hall wrote: On 3/3/10 12:13 PM, David Bosschaert wrote: > > Nice :) I've had lots of hangs (or extremely long resolves) in the > CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how > to get Pax Exam to use this latest build? Currently I'm using: > CoreOptions.frameworks(CoreOptions.felix()) > to simply select felix... > If you can find a simple way to reproduce any long resolves, let me know since I'd like to play with them... -> richard > Thanks, > > David > > On 3 March 2010 16:55, Richard S. Hall wrote: > >> >> For those using framework from trunk, I've merged work from my sandbox >> into >> the trunk...the changes are fairly substantial. >> >> The changes are not complete and the API will likely be in flux for a >> while, >> but the framework should be reasonably stable (i.e., still passing the >> CT). >> The big change for now is the introduction of a new resolver >> implementation. >> >> If you are someone experiencing "hangs" from long resolver cycles, feel >> free >> to try the snapshot and see if it makes a difference for you. In fact, >> any >> usage and reporting of issues would be helpful. >> >> Thanks. >> >> -> richard >> >> p.s. Currently, I am unable to publish a snapshot, but I will try to do >> that >> later (for the time being you can build from trunk). >> >> >>> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> > -- Karl Pauls karlpa...@gmail.com
Re: Framework trunk
FELIX-2172 Cheers, David On 5 March 2010 12:49, Karl Pauls wrote: > The patch didn't make it. Can you create a jira and attach it there > please? We have high hopes that the new resolver in trunk will work > with this kind of scenarios... > > regards, > > Karl > > On Fri, Mar 5, 2010 at 1:33 PM, David Bosschaert > wrote: >> Yes, it's quite simple to reproduce. >> >> 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk >> 2. First simply do a build with 'mvn install' from the root to get >> everything ready (you may have to set MAVEN_OPTS=-Xmx512m) >> 3. cd into systests2/multi-bundle >> 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. >> You will see that it runs some test (which uses a fairly large number >> of bundles). It's currently configured to use Equinox via Pax Exam. >> 5. Applying the attached patch will change it to use Felix. >> 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll >> see that just after 'Welcome to Felix' it hangs. >> >> Cheers, >> >> David >> >> On 3 March 2010 17:30, Richard S. Hall wrote: >>> On 3/3/10 12:13 PM, David Bosschaert wrote: Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... >>> >>> If you can find a simple way to reproduce any long resolves, let me know >>> since I'd like to play with them... >>> >>> -> richard >>> Thanks, David On 3 March 2010 16:55, Richard S. Hall wrote: > > For those using framework from trunk, I've merged work from my sandbox > into > the trunk...the changes are fairly substantial. > > The changes are not complete and the API will likely be in flux for a > while, > but the framework should be reasonably stable (i.e., still passing the > CT). > The big change for now is the introduction of a new resolver > implementation. > > If you are someone experiencing "hangs" from long resolver cycles, feel > free > to try the snapshot and see if it makes a difference for you. In fact, > any > usage and reporting of issues would be helpful. > > Thanks. > > -> richard > > p.s. Currently, I am unable to publish a snapshot, but I will try to do > that > later (for the time being you can build from trunk). > > >>> >> > > > > -- > Karl Pauls > karlpa...@gmail.com >
Re: Framework trunk
The patch didn't make it. Can you create a jira and attach it there please? We have high hopes that the new resolver in trunk will work with this kind of scenarios... regards, Karl On Fri, Mar 5, 2010 at 1:33 PM, David Bosschaert wrote: > Yes, it's quite simple to reproduce. > > 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk > 2. First simply do a build with 'mvn install' from the root to get > everything ready (you may have to set MAVEN_OPTS=-Xmx512m) > 3. cd into systests2/multi-bundle > 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. > You will see that it runs some test (which uses a fairly large number > of bundles). It's currently configured to use Equinox via Pax Exam. > 5. Applying the attached patch will change it to use Felix. > 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll > see that just after 'Welcome to Felix' it hangs. > > Cheers, > > David > > On 3 March 2010 17:30, Richard S. Hall wrote: >> On 3/3/10 12:13 PM, David Bosschaert wrote: >>> >>> Nice :) I've had lots of hangs (or extremely long resolves) in the >>> CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how >>> to get Pax Exam to use this latest build? Currently I'm using: >>> CoreOptions.frameworks(CoreOptions.felix()) >>> to simply select felix... >>> >> >> If you can find a simple way to reproduce any long resolves, let me know >> since I'd like to play with them... >> >> -> richard >> >>> Thanks, >>> >>> David >>> >>> On 3 March 2010 16:55, Richard S. Hall wrote: >>> For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. -> richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk). >> > -- Karl Pauls karlpa...@gmail.com
Re: Framework trunk
Yes, it's quite simple to reproduce. 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk 2. First simply do a build with 'mvn install' from the root to get everything ready (you may have to set MAVEN_OPTS=-Xmx512m) 3. cd into systests2/multi-bundle 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. You will see that it runs some test (which uses a fairly large number of bundles). It's currently configured to use Equinox via Pax Exam. 5. Applying the attached patch will change it to use Felix. 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll see that just after 'Welcome to Felix' it hangs. Cheers, David On 3 March 2010 17:30, Richard S. Hall wrote: > On 3/3/10 12:13 PM, David Bosschaert wrote: >> >> Nice :) I've had lots of hangs (or extremely long resolves) in the >> CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how >> to get Pax Exam to use this latest build? Currently I'm using: >> CoreOptions.frameworks(CoreOptions.felix()) >> to simply select felix... >> > > If you can find a simple way to reproduce any long resolves, let me know > since I'd like to play with them... > > -> richard > >> Thanks, >> >> David >> >> On 3 March 2010 16:55, Richard S. Hall wrote: >> >>> >>> For those using framework from trunk, I've merged work from my sandbox >>> into >>> the trunk...the changes are fairly substantial. >>> >>> The changes are not complete and the API will likely be in flux for a >>> while, >>> but the framework should be reasonably stable (i.e., still passing the >>> CT). >>> The big change for now is the introduction of a new resolver >>> implementation. >>> >>> If you are someone experiencing "hangs" from long resolver cycles, feel >>> free >>> to try the snapshot and see if it makes a difference for you. In fact, >>> any >>> usage and reporting of issues would be helpful. >>> >>> Thanks. >>> >>> -> richard >>> >>> p.s. Currently, I am unable to publish a snapshot, but I will try to do >>> that >>> later (for the time being you can build from trunk). >>> >>> >
Re: Framework trunk
On 3/3/10 12:13 PM, David Bosschaert wrote: Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... If you can find a simple way to reproduce any long resolves, let me know since I'd like to play with them... -> richard Thanks, David On 3 March 2010 16:55, Richard S. Hall wrote: For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. -> richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk).
Re: Framework trunk
Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... Thanks, David On 3 March 2010 16:55, Richard S. Hall wrote: > For those using framework from trunk, I've merged work from my sandbox into > the trunk...the changes are fairly substantial. > > The changes are not complete and the API will likely be in flux for a while, > but the framework should be reasonably stable (i.e., still passing the CT). > The big change for now is the introduction of a new resolver implementation. > > If you are someone experiencing "hangs" from long resolver cycles, feel free > to try the snapshot and see if it makes a difference for you. In fact, any > usage and reporting of issues would be helpful. > > Thanks. > > -> richard > > p.s. Currently, I am unable to publish a snapshot, but I will try to do that > later (for the time being you can build from trunk). >
Framework trunk
For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing "hangs" from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. -> richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk).
