Diagnosing bundle consistency issues.
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
I'm getting an exception on a bundle start indicating there is a
constraint violation with no details on where the problem might lie: org.osgi.framework.BundleException: Unable to resolve due to constraint violation. I tweaked the Felix code a bit to contain the original exception cause, and got this stack trace: Caused by: org.apache.felix.framework.searchpolicy.ResolveException: Unable to r esolve due to constraint violation. at org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo nfiguration(Resolver.java:1555) at org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS pace(Resolver.java:610) at org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav a:104) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 6) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) ... 47 more So this looks like there's an issue with a consistent class space. There are a lot of imports/exports involved with this bundle...are there any tools that can help determine where the consistency issues are? Rick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
Richard S. Hall wrote:
> Unfortunately, there isn't much to do other than tweaking Felix. > > The exception you are getting is due to the fact that the framework > has tried all combinations and could not find one that worked. > > Do you have the log level set to DEBUG? I think it tries to print some > messages if it detects anything. I do have the log level set to debug, but all I see related to this bundle is the INSTALLED message from the FelixDispatchQueue before the exception. Any suggestions on where in the code I can locate the names of packages that might be a problem with each combination? Rick > > -> richard > > On 11/4/09 9:11, Rick McGuire wrote: >> I'm getting an exception on a bundle start indicating there is a >> constraint violation with no details on where the problem might lie: >> >> org.osgi.framework.BundleException: Unable to resolve due to >> constraint violation. >> >> I tweaked the Felix code a bit to contain the original exception >> cause, and got this stack trace: >> >> Caused by: org.apache.felix.framework.searchpolicy.ResolveException: >> Unable to r >> esolve due to constraint violation. >> at >> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >> nfiguration(Resolver.java:1555) >> at >> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >> pace(Resolver.java:610) >> at >> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >> a:104) >> at >> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >> 6) >> at >> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >> ... 47 more >> >> So this looks like there's an issue with a consistent class space. >> There are a lot of imports/exports involved with this bundle...are >> there any tools that can help determine where the consistency issues >> are? >> >> Rick >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
Richard S. Hall wrote:
> On 11/4/09 10:02, Rick McGuire wrote: >> Richard S. Hall wrote: >>> Unfortunately, there isn't much to do other than tweaking Felix. >>> >>> The exception you are getting is due to the fact that the framework >>> has tried all combinations and could not find one that worked. >>> >>> Do you have the log level set to DEBUG? I think it tries to print >>> some messages if it detects anything. >> I do have the log level set to debug, but all I see related to this >> bundle is the INSTALLED message from the FelixDispatchQueue before >> the exception. Any suggestions on where in the code I can locate the >> names of packages that might be a problem with each combination? > > Odd, since there are places were debug messages are logged when > conflicts are detected. Can you send me offline a set of bundles to > install to reproduce the issue? If so, I can try to improve the debug > message situation if possible for the next framework release. This is Apache Geronimo, plus all of its dependencies, so this is an rather large set of dependencies. I'm trolling through the Resolver code now, and found at least one code path where things don't appear to get logged. I'll see if I can get some useful information out for diagnosing this and submit a patch for any logging additions I end up making. Rick > > -> richard > >> Rick >> >>> >>> -> richard >>> >>> On 11/4/09 9:11, Rick McGuire wrote: >>>> I'm getting an exception on a bundle start indicating there is a >>>> constraint violation with no details on where the problem might lie: >>>> >>>> org.osgi.framework.BundleException: Unable to resolve due to >>>> constraint violation. >>>> >>>> I tweaked the Felix code a bit to contain the original exception >>>> cause, and got this stack trace: >>>> >>>> Caused by: >>>> org.apache.felix.framework.searchpolicy.ResolveException: Unable to r >>>> esolve due to constraint violation. >>>> at >>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>> nfiguration(Resolver.java:1555) >>>> at >>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>> pace(Resolver.java:610) >>>> at >>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>> a:104) >>>> at >>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>> 6) >>>> at >>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>> ... 47 more >>>> >>>> So this looks like there's an issue with a consistent class space. >>>> There are a lot of imports/exports involved with this bundle...are >>>> there any tools that can help determine where the consistency >>>> issues are? >>>> >>>> Rick >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Richard S. Hall
::
Rate this Message:
Unfortunately, there isn't much to do other than tweaking Felix.
The exception you are getting is due to the fact that the framework has tried all combinations and could not find one that worked. Do you have the log level set to DEBUG? I think it tries to print some messages if it detects anything. -> richard On 11/4/09 9:11, Rick McGuire wrote: > I'm getting an exception on a bundle start indicating there is a > constraint violation with no details on where the problem might lie: > > org.osgi.framework.BundleException: Unable to resolve due to > constraint violation. > > I tweaked the Felix code a bit to contain the original exception > cause, and got this stack trace: > > Caused by: org.apache.felix.framework.searchpolicy.ResolveException: > Unable to r > esolve due to constraint violation. > at > org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo > nfiguration(Resolver.java:1555) > at > org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS > pace(Resolver.java:610) > at > org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav > a:104) > at > org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 > 6) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) > ... 47 more > > So this looks like there's an issue with a consistent class space. > There are a lot of imports/exports involved with this bundle...are > there any tools that can help determine where the consistency issues are? > > Rick > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Richard S. Hall
::
Rate this Message:
On 11/4/09 10:02, Rick McGuire wrote:
> Richard S. Hall wrote: >> Unfortunately, there isn't much to do other than tweaking Felix. >> >> The exception you are getting is due to the fact that the framework >> has tried all combinations and could not find one that worked. >> >> Do you have the log level set to DEBUG? I think it tries to print >> some messages if it detects anything. > I do have the log level set to debug, but all I see related to this > bundle is the INSTALLED message from the FelixDispatchQueue before the > exception. Any suggestions on where in the code I can locate the > names of packages that might be a problem with each combination? Odd, since there are places were debug messages are logged when conflicts are detected. Can you send me offline a set of bundles to install to reproduce the issue? If so, I can try to improve the debug message situation if possible for the next framework release. -> richard > Rick > >> >> -> richard >> >> On 11/4/09 9:11, Rick McGuire wrote: >>> I'm getting an exception on a bundle start indicating there is a >>> constraint violation with no details on where the problem might lie: >>> >>> org.osgi.framework.BundleException: Unable to resolve due to >>> constraint violation. >>> >>> I tweaked the Felix code a bit to contain the original exception >>> cause, and got this stack trace: >>> >>> Caused by: org.apache.felix.framework.searchpolicy.ResolveException: >>> Unable to r >>> esolve due to constraint violation. >>> at >>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>> nfiguration(Resolver.java:1555) >>> at >>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>> pace(Resolver.java:610) >>> at >>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>> a:104) >>> at >>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>> 6) >>> at >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>> ... 47 more >>> >>> So this looks like there's an issue with a consistent class space. >>> There are a lot of imports/exports involved with this bundle...are >>> there any tools that can help determine where the consistency issues >>> are? >>> >>> Rick >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Richard S. Hall
::
Rate this Message:
On 11/4/09 10:16, Rick McGuire wrote:
> Richard S. Hall wrote: >> On 11/4/09 10:02, Rick McGuire wrote: >>> Richard S. Hall wrote: >>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>> >>>> The exception you are getting is due to the fact that the framework >>>> has tried all combinations and could not find one that worked. >>>> >>>> Do you have the log level set to DEBUG? I think it tries to print >>>> some messages if it detects anything. >>> I do have the log level set to debug, but all I see related to this >>> bundle is the INSTALLED message from the FelixDispatchQueue before >>> the exception. Any suggestions on where in the code I can locate >>> the names of packages that might be a problem with each combination? >> >> Odd, since there are places were debug messages are logged when >> conflicts are detected. Can you send me offline a set of bundles to >> install to reproduce the issue? If so, I can try to improve the debug >> message situation if possible for the next framework release. > I'm not sure this is an a state where I can send you something now. > This is Apache Geronimo, plus all of its dependencies, so this is an > rather large set of dependencies. I'm trolling through the Resolver > code now, and found at least one code path where things don't appear > to get logged. I'll see if I can get some useful information out for > diagnosing this and submit a patch for any logging additions I end up > making. Ok, let me know if you need any help. The methods related to consistency checking are pretty obvious, even if what they are doing is less so. :-) -> richard > > Rick >> >> -> richard >> >>> Rick >>> >>>> >>>> -> richard >>>> >>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>> I'm getting an exception on a bundle start indicating there is a >>>>> constraint violation with no details on where the problem might lie: >>>>> >>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>> constraint violation. >>>>> >>>>> I tweaked the Felix code a bit to contain the original exception >>>>> cause, and got this stack trace: >>>>> >>>>> Caused by: >>>>> org.apache.felix.framework.searchpolicy.ResolveException: Unable to r >>>>> esolve due to constraint violation. >>>>> at >>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>> nfiguration(Resolver.java:1555) >>>>> at >>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>> pace(Resolver.java:610) >>>>> at >>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>> a:104) >>>>> at >>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>> 6) >>>>> at >>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>> ... 47 more >>>>> >>>>> So this looks like there's an issue with a consistent class >>>>> space. There are a lot of imports/exports involved with this >>>>> bundle...are there any tools that can help determine where the >>>>> consistency issues are? >>>>> >>>>> Rick >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
Richard S. Hall wrote:
> On 11/4/09 10:16, Rick McGuire wrote: >> Richard S. Hall wrote: >>> On 11/4/09 10:02, Rick McGuire wrote: >>>> Richard S. Hall wrote: >>>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>>> >>>>> The exception you are getting is due to the fact that the >>>>> framework has tried all combinations and could not find one that >>>>> worked. >>>>> >>>>> Do you have the log level set to DEBUG? I think it tries to print >>>>> some messages if it detects anything. >>>> I do have the log level set to debug, but all I see related to this >>>> bundle is the INSTALLED message from the FelixDispatchQueue before >>>> the exception. Any suggestions on where in the code I can locate >>>> the names of packages that might be a problem with each combination? >>> >>> Odd, since there are places were debug messages are logged when >>> conflicts are detected. Can you send me offline a set of bundles to >>> install to reproduce the issue? If so, I can try to improve the >>> debug message situation if possible for the next framework release. >> I'm not sure this is an a state where I can send you something now. >> This is Apache Geronimo, plus all of its dependencies, so this is an >> rather large set of dependencies. I'm trolling through the Resolver >> code now, and found at least one code path where things don't appear >> to get logged. I'll see if I can get some useful information out for >> diagnosing this and submit a patch for any logging additions I end up >> making. > > Ok, let me know if you need any help. The methods related to > consistency checking are pretty obvious, even if what they are doing > is less so. :-) entries were showing up, only the ones from the FelixDispatchQueue. I tweaked the level to ERROR and was able to get the information I needed. One other thing I changed to make life easier was to have the ModuleImpl toString() method display both the symbolic name and id....trying to map the id back to the actual bundle in an environment this complex was a bit of a pain. Rick > > -> richard > >> >> Rick >>> >>> -> richard >>> >>>> Rick >>>> >>>>> >>>>> -> richard >>>>> >>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>> I'm getting an exception on a bundle start indicating there is a >>>>>> constraint violation with no details on where the problem might lie: >>>>>> >>>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>>> constraint violation. >>>>>> >>>>>> I tweaked the Felix code a bit to contain the original exception >>>>>> cause, and got this stack trace: >>>>>> >>>>>> Caused by: >>>>>> org.apache.felix.framework.searchpolicy.ResolveException: Unable >>>>>> to r >>>>>> esolve due to constraint violation. >>>>>> at >>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>> >>>>>> nfiguration(Resolver.java:1555) >>>>>> at >>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>> >>>>>> pace(Resolver.java:610) >>>>>> at >>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>> >>>>>> a:104) >>>>>> at >>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>> >>>>>> 6) >>>>>> at >>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>> ... 47 more >>>>>> >>>>>> So this looks like there's an issue with a consistent class >>>>>> space. There are a lot of imports/exports involved with this >>>>>> bundle...are there any tools that can help determine where the >>>>>> consistency issues are? >>>>>> >>>>>> Rick >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
Richard S. Hall wrote:
> On 11/5/09 8:49, Rick McGuire wrote: >> Richard S. Hall wrote: >>> On 11/4/09 10:16, Rick McGuire wrote: >>>> Richard S. Hall wrote: >>>>> On 11/4/09 10:02, Rick McGuire wrote: >>>>>> Richard S. Hall wrote: >>>>>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>>>>> >>>>>>> The exception you are getting is due to the fact that the >>>>>>> framework has tried all combinations and could not find one that >>>>>>> worked. >>>>>>> >>>>>>> Do you have the log level set to DEBUG? I think it tries to >>>>>>> print some messages if it detects anything. >>>>>> I do have the log level set to debug, but all I see related to >>>>>> this bundle is the INSTALLED message from the FelixDispatchQueue >>>>>> before the exception. Any suggestions on where in the code I can >>>>>> locate the names of packages that might be a problem with each >>>>>> combination? >>>>> >>>>> Odd, since there are places were debug messages are logged when >>>>> conflicts are detected. Can you send me offline a set of bundles >>>>> to install to reproduce the issue? If so, I can try to improve the >>>>> debug message situation if possible for the next framework release. >>>> I'm not sure this is an a state where I can send you something >>>> now. This is Apache Geronimo, plus all of its dependencies, so >>>> this is an rather large set of dependencies. I'm trolling through >>>> the Resolver code now, and found at least one code path where >>>> things don't appear to get logged. I'll see if I can get some >>>> useful information out for diagnosing this and submit a patch for >>>> any logging additions I end up making. >>> >>> Ok, let me know if you need any help. The methods related to >>> consistency checking are pretty obvious, even if what they are doing >>> is less so. :-) >> Thanks for the pointers. For some reason, not all of the DEBUG log >> entries were showing up, only the ones from the FelixDispatchQueue. >> I tweaked the level to ERROR and was able to get the information I >> needed. > > That sounds odd. > >> One other thing I changed to make life easier was to have the >> ModuleImpl toString() method display both the symbolic name and >> id....trying to map the id back to the actual bundle in an >> environment this complex was a bit of a pain. > > Yeah, BundleImpl now does this too...recent refactoring of IModule has > made this easier to do in ModuleImpl than previously. I will commit > such a change. > > -> richard > > p.s. I am still interested in your use case, since I have been playing > around with a new resolver algorithm that [tries] to handle "uses" > constraints better/more efficiently. So, if you have a complicated use > case, i'd still like to be able to play with it at some point. because it would take a very long time to get everything set up and all of the dependencies in your local maven repository. I turned out to have two problems that were causing the error. The first problem was a build error in one of our bundles that caused bnd to pull in a bunch of class files that it should have just been importing. This resulted in two bundles that exported the same classes, and once I hit a scenario where both bundles were getting loaded together, it was causing issues. Because of some other issues, Required-Bundle was involved in this two. Generally pretty messy, but easy to correct once I had determined where the problem was. The other issues were caused by loading jars with some of the javax.* packages that we were also picking up from the boot configuration. I just needed to suppress the loading of the bundle containing the redundant classes. Rick >> Rick >> >>> >>> -> richard >>> >>>> >>>> Rick >>>>> >>>>> -> richard >>>>> >>>>>> Rick >>>>>> >>>>>>> >>>>>>> -> richard >>>>>>> >>>>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>>>> I'm getting an exception on a bundle start indicating there is >>>>>>>> a constraint violation with no details on where the problem >>>>>>>> might lie: >>>>>>>> >>>>>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>>>>> constraint violation. >>>>>>>> >>>>>>>> I tweaked the Felix code a bit to contain the original >>>>>>>> exception cause, and got this stack trace: >>>>>>>> >>>>>>>> Caused by: >>>>>>>> org.apache.felix.framework.searchpolicy.ResolveException: >>>>>>>> Unable to r >>>>>>>> esolve due to constraint violation. >>>>>>>> at >>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>>>> >>>>>>>> nfiguration(Resolver.java:1555) >>>>>>>> at >>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>>>> >>>>>>>> pace(Resolver.java:610) >>>>>>>> at >>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>>>> >>>>>>>> a:104) >>>>>>>> at >>>>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>>>> >>>>>>>> 6) >>>>>>>> at >>>>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>>>> ... 47 more >>>>>>>> >>>>>>>> So this looks like there's an issue with a consistent class >>>>>>>> space. There are a lot of imports/exports involved with this >>>>>>>> bundle...are there any tools that can help determine where the >>>>>>>> consistency issues are? >>>>>>>> >>>>>>>> Rick >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Richard S. Hall
::
Rate this Message:
On 11/5/09 8:49, Rick McGuire wrote:
> Richard S. Hall wrote: >> On 11/4/09 10:16, Rick McGuire wrote: >>> Richard S. Hall wrote: >>>> On 11/4/09 10:02, Rick McGuire wrote: >>>>> Richard S. Hall wrote: >>>>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>>>> >>>>>> The exception you are getting is due to the fact that the >>>>>> framework has tried all combinations and could not find one that >>>>>> worked. >>>>>> >>>>>> Do you have the log level set to DEBUG? I think it tries to print >>>>>> some messages if it detects anything. >>>>> I do have the log level set to debug, but all I see related to >>>>> this bundle is the INSTALLED message from the FelixDispatchQueue >>>>> before the exception. Any suggestions on where in the code I can >>>>> locate the names of packages that might be a problem with each >>>>> combination? >>>> >>>> Odd, since there are places were debug messages are logged when >>>> conflicts are detected. Can you send me offline a set of bundles to >>>> install to reproduce the issue? If so, I can try to improve the >>>> debug message situation if possible for the next framework release. >>> I'm not sure this is an a state where I can send you something now. >>> This is Apache Geronimo, plus all of its dependencies, so this is an >>> rather large set of dependencies. I'm trolling through the Resolver >>> code now, and found at least one code path where things don't appear >>> to get logged. I'll see if I can get some useful information out >>> for diagnosing this and submit a patch for any logging additions I >>> end up making. >> >> Ok, let me know if you need any help. The methods related to >> consistency checking are pretty obvious, even if what they are doing >> is less so. :-) > Thanks for the pointers. For some reason, not all of the DEBUG log > entries were showing up, only the ones from the FelixDispatchQueue. I > tweaked the level to ERROR and was able to get the information I needed. That sounds odd. > One other thing I changed to make life easier was to have the > ModuleImpl toString() method display both the symbolic name and > id....trying to map the id back to the actual bundle in an environment > this complex was a bit of a pain. Yeah, BundleImpl now does this too...recent refactoring of IModule has made this easier to do in ModuleImpl than previously. I will commit such a change. -> richard p.s. I am still interested in your use case, since I have been playing around with a new resolver algorithm that [tries] to handle "uses" constraints better/more efficiently. So, if you have a complicated use case, i'd still like to be able to play with it at some point. > Rick > >> >> -> richard >> >>> >>> Rick >>>> >>>> -> richard >>>> >>>>> Rick >>>>> >>>>>> >>>>>> -> richard >>>>>> >>>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>>> I'm getting an exception on a bundle start indicating there is a >>>>>>> constraint violation with no details on where the problem might >>>>>>> lie: >>>>>>> >>>>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>>>> constraint violation. >>>>>>> >>>>>>> I tweaked the Felix code a bit to contain the original exception >>>>>>> cause, and got this stack trace: >>>>>>> >>>>>>> Caused by: >>>>>>> org.apache.felix.framework.searchpolicy.ResolveException: Unable >>>>>>> to r >>>>>>> esolve due to constraint violation. >>>>>>> at >>>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>>> >>>>>>> nfiguration(Resolver.java:1555) >>>>>>> at >>>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>>> >>>>>>> pace(Resolver.java:610) >>>>>>> at >>>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>>> >>>>>>> a:104) >>>>>>> at >>>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>>> >>>>>>> 6) >>>>>>> at >>>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>>> ... 47 more >>>>>>> >>>>>>> So this looks like there's an issue with a consistent class >>>>>>> space. There are a lot of imports/exports involved with this >>>>>>> bundle...are there any tools that can help determine where the >>>>>>> consistency issues are? >>>>>>> >>>>>>> Rick >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Richard S. Hall
::
Rate this Message:
On 11/5/09 9:19, Rick McGuire wrote:
> Richard S. Hall wrote: >> On 11/5/09 8:49, Rick McGuire wrote: >>> Richard S. Hall wrote: >>>> On 11/4/09 10:16, Rick McGuire wrote: >>>>> Richard S. Hall wrote: >>>>>> On 11/4/09 10:02, Rick McGuire wrote: >>>>>>> Richard S. Hall wrote: >>>>>>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>>>>>> >>>>>>>> The exception you are getting is due to the fact that the >>>>>>>> framework has tried all combinations and could not find one >>>>>>>> that worked. >>>>>>>> >>>>>>>> Do you have the log level set to DEBUG? I think it tries to >>>>>>>> print some messages if it detects anything. >>>>>>> I do have the log level set to debug, but all I see related to >>>>>>> this bundle is the INSTALLED message from the FelixDispatchQueue >>>>>>> before the exception. Any suggestions on where in the code I >>>>>>> can locate the names of packages that might be a problem with >>>>>>> each combination? >>>>>> >>>>>> Odd, since there are places were debug messages are logged when >>>>>> conflicts are detected. Can you send me offline a set of bundles >>>>>> to install to reproduce the issue? If so, I can try to improve >>>>>> the debug message situation if possible for the next framework >>>>>> release. >>>>> I'm not sure this is an a state where I can send you something >>>>> now. This is Apache Geronimo, plus all of its dependencies, so >>>>> this is an rather large set of dependencies. I'm trolling through >>>>> the Resolver code now, and found at least one code path where >>>>> things don't appear to get logged. I'll see if I can get some >>>>> useful information out for diagnosing this and submit a patch for >>>>> any logging additions I end up making. >>>> >>>> Ok, let me know if you need any help. The methods related to >>>> consistency checking are pretty obvious, even if what they are >>>> doing is less so. :-) >>> Thanks for the pointers. For some reason, not all of the DEBUG log >>> entries were showing up, only the ones from the FelixDispatchQueue. >>> I tweaked the level to ERROR and was able to get the information I >>> needed. >> >> That sounds odd. >> >>> One other thing I changed to make life easier was to have the >>> ModuleImpl toString() method display both the symbolic name and >>> id....trying to map the id back to the actual bundle in an >>> environment this complex was a bit of a pain. >> >> Yeah, BundleImpl now does this too...recent refactoring of IModule >> has made this easier to do in ModuleImpl than previously. I will >> commit such a change. >> >> -> richard >> >> p.s. I am still interested in your use case, since I have been >> playing around with a new resolver algorithm that [tries] to handle >> "uses" constraints better/more efficiently. So, if you have a >> complicated use case, i'd still like to be able to play with it at >> some point. > This is not something I can easily provide for you, unfortunately, > because it would take a very long time to get everything set up and > all of the dependencies in your local maven repository. I turned out > to have two problems that were causing the error. The first problem > was a build error in one of our bundles that caused bnd to pull in a > bunch of class files that it should have just been importing. This > resulted in two bundles that exported the same classes, and once I hit > a scenario where both bundles were getting loaded together, it was > causing issues. Because of some other issues, Required-Bundle was > involved in this two. Generally pretty messy, but easy to correct > once I had determined where the problem was. > The other issues were caused by loading jars with some of the javax.* > packages that we were also picking up from the boot configuration. I > just needed to suppress the loading of the bundle containing the > redundant classes. Yep, these are exactly the sort of scenarios I want to try to handle more efficiently...although it is not clear if I will be able to give better diagnostics, but that remains to be seen. -> richard > > > Rick > > >>> Rick >>> >>>> >>>> -> richard >>>> >>>>> >>>>> Rick >>>>>> >>>>>> -> richard >>>>>> >>>>>>> Rick >>>>>>> >>>>>>>> >>>>>>>> -> richard >>>>>>>> >>>>>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>>>>> I'm getting an exception on a bundle start indicating there is >>>>>>>>> a constraint violation with no details on where the problem >>>>>>>>> might lie: >>>>>>>>> >>>>>>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>>>>>> constraint violation. >>>>>>>>> >>>>>>>>> I tweaked the Felix code a bit to contain the original >>>>>>>>> exception cause, and got this stack trace: >>>>>>>>> >>>>>>>>> Caused by: >>>>>>>>> org.apache.felix.framework.searchpolicy.ResolveException: >>>>>>>>> Unable to r >>>>>>>>> esolve due to constraint violation. >>>>>>>>> at >>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>>>>> >>>>>>>>> nfiguration(Resolver.java:1555) >>>>>>>>> at >>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>>>>> >>>>>>>>> pace(Resolver.java:610) >>>>>>>>> at >>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>>>>> >>>>>>>>> a:104) >>>>>>>>> at >>>>>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>>>>> >>>>>>>>> 6) >>>>>>>>> at >>>>>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>>>>> ... 47 more >>>>>>>>> >>>>>>>>> So this looks like there's an issue with a consistent class >>>>>>>>> space. There are a lot of imports/exports involved with this >>>>>>>>> bundle...are there any tools that can help determine where the >>>>>>>>> consistency issues are? >>>>>>>>> >>>>>>>>> Rick >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
Richard S. Hall wrote:
> On 11/5/09 9:19, Rick McGuire wrote: >> Richard S. Hall wrote: >>> On 11/5/09 8:49, Rick McGuire wrote: >>>> Richard S. Hall wrote: >>>>> On 11/4/09 10:16, Rick McGuire wrote: >>>>>> Richard S. Hall wrote: >>>>>>> On 11/4/09 10:02, Rick McGuire wrote: >>>>>>>> Richard S. Hall wrote: >>>>>>>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>>>>>>> >>>>>>>>> The exception you are getting is due to the fact that the >>>>>>>>> framework has tried all combinations and could not find one >>>>>>>>> that worked. >>>>>>>>> >>>>>>>>> Do you have the log level set to DEBUG? I think it tries to >>>>>>>>> print some messages if it detects anything. >>>>>>>> I do have the log level set to debug, but all I see related to >>>>>>>> this bundle is the INSTALLED message from the >>>>>>>> FelixDispatchQueue before the exception. Any suggestions on >>>>>>>> where in the code I can locate the names of packages that might >>>>>>>> be a problem with each combination? >>>>>>> >>>>>>> Odd, since there are places were debug messages are logged when >>>>>>> conflicts are detected. Can you send me offline a set of bundles >>>>>>> to install to reproduce the issue? If so, I can try to improve >>>>>>> the debug message situation if possible for the next framework >>>>>>> release. >>>>>> I'm not sure this is an a state where I can send you something >>>>>> now. This is Apache Geronimo, plus all of its dependencies, so >>>>>> this is an rather large set of dependencies. I'm trolling >>>>>> through the Resolver code now, and found at least one code path >>>>>> where things don't appear to get logged. I'll see if I can get >>>>>> some useful information out for diagnosing this and submit a >>>>>> patch for any logging additions I end up making. >>>>> >>>>> Ok, let me know if you need any help. The methods related to >>>>> consistency checking are pretty obvious, even if what they are >>>>> doing is less so. :-) >>>> Thanks for the pointers. For some reason, not all of the DEBUG log >>>> entries were showing up, only the ones from the >>>> FelixDispatchQueue. I tweaked the level to ERROR and was able to >>>> get the information I needed. >>> >>> That sounds odd. >>> >>>> One other thing I changed to make life easier was to have the >>>> ModuleImpl toString() method display both the symbolic name and >>>> id....trying to map the id back to the actual bundle in an >>>> environment this complex was a bit of a pain. >>> >>> Yeah, BundleImpl now does this too...recent refactoring of IModule >>> has made this easier to do in ModuleImpl than previously. I will >>> commit such a change. >>> >>> -> richard >>> >>> p.s. I am still interested in your use case, since I have been >>> playing around with a new resolver algorithm that [tries] to handle >>> "uses" constraints better/more efficiently. So, if you have a >>> complicated use case, i'd still like to be able to play with it at >>> some point. >> This is not something I can easily provide for you, unfortunately, >> because it would take a very long time to get everything set up and >> all of the dependencies in your local maven repository. I turned out >> to have two problems that were causing the error. The first problem >> was a build error in one of our bundles that caused bnd to pull in a >> bunch of class files that it should have just been importing. This >> resulted in two bundles that exported the same classes, and once I >> hit a scenario where both bundles were getting loaded together, it >> was causing issues. Because of some other issues, Required-Bundle >> was involved in this two. Generally pretty messy, but easy to >> correct once I had determined where the problem was. >> The other issues were caused by loading jars with some of the javax.* >> packages that we were also picking up from the boot configuration. I >> just needed to suppress the loading of the bundle containing the >> redundant classes. > > Yep, these are exactly the sort of scenarios I want to try to handle > more efficiently...although it is not clear if I will be able to give > better diagnostics, but that remains to be seen. able to get them to appear and get the names of the bundles involved. It might be nice to somehow capture that information in the constraint violation exception, but given that a problem might show up in multiple iterations, it could be difficult. I was also getting multiple hits on packages while working through all of the issues I had, which is another problem. Rick > > -> richard > >> >> >> Rick >> >> >>>> Rick >>>> >>>>> >>>>> -> richard >>>>> >>>>>> >>>>>> Rick >>>>>>> >>>>>>> -> richard >>>>>>> >>>>>>>> Rick >>>>>>>> >>>>>>>>> >>>>>>>>> -> richard >>>>>>>>> >>>>>>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>>>>>> I'm getting an exception on a bundle start indicating there >>>>>>>>>> is a constraint violation with no details on where the >>>>>>>>>> problem might lie: >>>>>>>>>> >>>>>>>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>>>>>>> constraint violation. >>>>>>>>>> >>>>>>>>>> I tweaked the Felix code a bit to contain the original >>>>>>>>>> exception cause, and got this stack trace: >>>>>>>>>> >>>>>>>>>> Caused by: >>>>>>>>>> org.apache.felix.framework.searchpolicy.ResolveException: >>>>>>>>>> Unable to r >>>>>>>>>> esolve due to constraint violation. >>>>>>>>>> at >>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>>>>>> >>>>>>>>>> nfiguration(Resolver.java:1555) >>>>>>>>>> at >>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>>>>>> >>>>>>>>>> pace(Resolver.java:610) >>>>>>>>>> at >>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>>>>>> >>>>>>>>>> a:104) >>>>>>>>>> at >>>>>>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>>>>>> >>>>>>>>>> 6) >>>>>>>>>> at >>>>>>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>>>>>> ... 47 more >>>>>>>>>> >>>>>>>>>> So this looks like there's an issue with a consistent class >>>>>>>>>> space. There are a lot of imports/exports involved with this >>>>>>>>>> bundle...are there any tools that can help determine where >>>>>>>>>> the consistency issues are? >>>>>>>>>> >>>>>>>>>> Rick >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Richard S. Hall
::
Rate this Message:
On 11/5/09 10:39, Rick McGuire wrote:
> Richard S. Hall wrote: >> On 11/5/09 9:19, Rick McGuire wrote: >>> Richard S. Hall wrote: >>>> On 11/5/09 8:49, Rick McGuire wrote: >>>>> Richard S. Hall wrote: >>>>>> On 11/4/09 10:16, Rick McGuire wrote: >>>>>>> Richard S. Hall wrote: >>>>>>>> On 11/4/09 10:02, Rick McGuire wrote: >>>>>>>>> Richard S. Hall wrote: >>>>>>>>>> Unfortunately, there isn't much to do other than tweaking Felix. >>>>>>>>>> >>>>>>>>>> The exception you are getting is due to the fact that the >>>>>>>>>> framework has tried all combinations and could not find one >>>>>>>>>> that worked. >>>>>>>>>> >>>>>>>>>> Do you have the log level set to DEBUG? I think it tries to >>>>>>>>>> print some messages if it detects anything. >>>>>>>>> I do have the log level set to debug, but all I see related to >>>>>>>>> this bundle is the INSTALLED message from the >>>>>>>>> FelixDispatchQueue before the exception. Any suggestions on >>>>>>>>> where in the code I can locate the names of packages that >>>>>>>>> might be a problem with each combination? >>>>>>>> >>>>>>>> Odd, since there are places were debug messages are logged when >>>>>>>> conflicts are detected. Can you send me offline a set of >>>>>>>> bundles to install to reproduce the issue? If so, I can try to >>>>>>>> improve the debug message situation if possible for the next >>>>>>>> framework release. >>>>>>> I'm not sure this is an a state where I can send you something >>>>>>> now. This is Apache Geronimo, plus all of its dependencies, so >>>>>>> this is an rather large set of dependencies. I'm trolling >>>>>>> through the Resolver code now, and found at least one code path >>>>>>> where things don't appear to get logged. I'll see if I can get >>>>>>> some useful information out for diagnosing this and submit a >>>>>>> patch for any logging additions I end up making. >>>>>> >>>>>> Ok, let me know if you need any help. The methods related to >>>>>> consistency checking are pretty obvious, even if what they are >>>>>> doing is less so. :-) >>>>> Thanks for the pointers. For some reason, not all of the DEBUG >>>>> log entries were showing up, only the ones from the >>>>> FelixDispatchQueue. I tweaked the level to ERROR and was able to >>>>> get the information I needed. >>>> >>>> That sounds odd. >>>> >>>>> One other thing I changed to make life easier was to have the >>>>> ModuleImpl toString() method display both the symbolic name and >>>>> id....trying to map the id back to the actual bundle in an >>>>> environment this complex was a bit of a pain. >>>> >>>> Yeah, BundleImpl now does this too...recent refactoring of IModule >>>> has made this easier to do in ModuleImpl than previously. I will >>>> commit such a change. >>>> >>>> -> richard >>>> >>>> p.s. I am still interested in your use case, since I have been >>>> playing around with a new resolver algorithm that [tries] to handle >>>> "uses" constraints better/more efficiently. So, if you have a >>>> complicated use case, i'd still like to be able to play with it at >>>> some point. >>> This is not something I can easily provide for you, unfortunately, >>> because it would take a very long time to get everything set up and >>> all of the dependencies in your local maven repository. I turned >>> out to have two problems that were causing the error. The first >>> problem was a build error in one of our bundles that caused bnd to >>> pull in a bunch of class files that it should have just been >>> importing. This resulted in two bundles that exported the same >>> classes, and once I hit a scenario where both bundles were getting >>> loaded together, it was causing issues. Because of some other >>> issues, Required-Bundle was involved in this two. Generally pretty >>> messy, but easy to correct once I had determined where the problem was. >>> The other issues were caused by loading jars with some of the >>> javax.* packages that we were also picking up from the boot >>> configuration. I just needed to suppress the loading of the bundle >>> containing the redundant classes. >> >> Yep, these are exactly the sort of scenarios I want to try to handle >> more efficiently...although it is not clear if I will be able to give >> better diagnostics, but that remains to be seen. > The diagnostics you have were enough to solve the problem, once I was > able to get them to appear and get the names of the bundles involved. > It might be nice to somehow capture that information in the constraint > violation exception, but given that a problem might show up in > multiple iterations, it could be difficult. Yes, this has always been the difficulty, since there are often many wrong answers. > I was also getting multiple hits on packages while working through all > of the issues I had, which is another problem. Not sure I understand. -> richard > > Rick >> >> -> richard >> >>> >>> >>> Rick >>> >>> >>>>> Rick >>>>> >>>>>> >>>>>> -> richard >>>>>> >>>>>>> >>>>>>> Rick >>>>>>>> >>>>>>>> -> richard >>>>>>>> >>>>>>>>> Rick >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -> richard >>>>>>>>>> >>>>>>>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>>>>>>> I'm getting an exception on a bundle start indicating there >>>>>>>>>>> is a constraint violation with no details on where the >>>>>>>>>>> problem might lie: >>>>>>>>>>> >>>>>>>>>>> org.osgi.framework.BundleException: Unable to resolve due to >>>>>>>>>>> constraint violation. >>>>>>>>>>> >>>>>>>>>>> I tweaked the Felix code a bit to contain the original >>>>>>>>>>> exception cause, and got this stack trace: >>>>>>>>>>> >>>>>>>>>>> Caused by: >>>>>>>>>>> org.apache.felix.framework.searchpolicy.ResolveException: >>>>>>>>>>> Unable to r >>>>>>>>>>> esolve due to constraint violation. >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>>>>>>> >>>>>>>>>>> nfiguration(Resolver.java:1555) >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>>>>>>> >>>>>>>>>>> pace(Resolver.java:610) >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>>>>>>> >>>>>>>>>>> a:104) >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>>>>>>> >>>>>>>>>>> 6) >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>>>>>>> ... 47 more >>>>>>>>>>> >>>>>>>>>>> So this looks like there's an issue with a consistent class >>>>>>>>>>> space. There are a lot of imports/exports involved with >>>>>>>>>>> this bundle...are there any tools that can help determine >>>>>>>>>>> where the consistency issues are? >>>>>>>>>>> >>>>>>>>>>> Rick >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Diagnosing bundle consistency issues.
by Rick McGuire
::
Rate this Message:
Richard S. Hall wrote:
> On 11/5/09 10:39, Rick McGuire wrote: >> Richard S. Hall wrote: >>> On 11/5/09 9:19, Rick McGuire wrote: >>>> Richard S. Hall wrote: >>>>> On 11/5/09 8:49, Rick McGuire wrote: >>>>>> Richard S. Hall wrote: >>>>>>> On 11/4/09 10:16, Rick McGuire wrote: >>>>>>>> Richard S. Hall wrote: >>>>>>>>> On 11/4/09 10:02, Rick McGuire wrote: >>>>>>>>>> Richard S. Hall wrote: >>>>>>>>>>> Unfortunately, there isn't much to do other than tweaking >>>>>>>>>>> Felix. >>>>>>>>>>> >>>>>>>>>>> The exception you are getting is due to the fact that the >>>>>>>>>>> framework has tried all combinations and could not find one >>>>>>>>>>> that worked. >>>>>>>>>>> >>>>>>>>>>> Do you have the log level set to DEBUG? I think it tries to >>>>>>>>>>> print some messages if it detects anything. >>>>>>>>>> I do have the log level set to debug, but all I see related >>>>>>>>>> to this bundle is the INSTALLED message from the >>>>>>>>>> FelixDispatchQueue before the exception. Any suggestions on >>>>>>>>>> where in the code I can locate the names of packages that >>>>>>>>>> might be a problem with each combination? >>>>>>>>> >>>>>>>>> Odd, since there are places were debug messages are logged >>>>>>>>> when conflicts are detected. Can you send me offline a set of >>>>>>>>> bundles to install to reproduce the issue? If so, I can try to >>>>>>>>> improve the debug message situation if possible for the next >>>>>>>>> framework release. >>>>>>>> I'm not sure this is an a state where I can send you something >>>>>>>> now. This is Apache Geronimo, plus all of its dependencies, so >>>>>>>> this is an rather large set of dependencies. I'm trolling >>>>>>>> through the Resolver code now, and found at least one code path >>>>>>>> where things don't appear to get logged. I'll see if I can get >>>>>>>> some useful information out for diagnosing this and submit a >>>>>>>> patch for any logging additions I end up making. >>>>>>> >>>>>>> Ok, let me know if you need any help. The methods related to >>>>>>> consistency checking are pretty obvious, even if what they are >>>>>>> doing is less so. :-) >>>>>> Thanks for the pointers. For some reason, not all of the DEBUG >>>>>> log entries were showing up, only the ones from the >>>>>> FelixDispatchQueue. I tweaked the level to ERROR and was able to >>>>>> get the information I needed. >>>>> >>>>> That sounds odd. >>>>> >>>>>> One other thing I changed to make life easier was to have the >>>>>> ModuleImpl toString() method display both the symbolic name and >>>>>> id....trying to map the id back to the actual bundle in an >>>>>> environment this complex was a bit of a pain. >>>>> >>>>> Yeah, BundleImpl now does this too...recent refactoring of IModule >>>>> has made this easier to do in ModuleImpl than previously. I will >>>>> commit such a change. >>>>> >>>>> -> richard >>>>> >>>>> p.s. I am still interested in your use case, since I have been >>>>> playing around with a new resolver algorithm that [tries] to >>>>> handle "uses" constraints better/more efficiently. So, if you have >>>>> a complicated use case, i'd still like to be able to play with it >>>>> at some point. >>>> This is not something I can easily provide for you, unfortunately, >>>> because it would take a very long time to get everything set up and >>>> all of the dependencies in your local maven repository. I turned >>>> out to have two problems that were causing the error. The first >>>> problem was a build error in one of our bundles that caused bnd to >>>> pull in a bunch of class files that it should have just been >>>> importing. This resulted in two bundles that exported the same >>>> classes, and once I hit a scenario where both bundles were getting >>>> loaded together, it was causing issues. Because of some other >>>> issues, Required-Bundle was involved in this two. Generally pretty >>>> messy, but easy to correct once I had determined where the problem >>>> was. >>>> The other issues were caused by loading jars with some of the >>>> javax.* packages that we were also picking up from the boot >>>> configuration. I just needed to suppress the loading of the bundle >>>> containing the redundant classes. >>> >>> Yep, these are exactly the sort of scenarios I want to try to handle >>> more efficiently...although it is not clear if I will be able to >>> give better diagnostics, but that remains to be seen. >> The diagnostics you have were enough to solve the problem, once I was >> able to get them to appear and get the names of the bundles >> involved. It might be nice to somehow capture that information in >> the constraint violation exception, but given that a problem might >> show up in multiple iterations, it could be difficult. > > Yes, this has always been the difficulty, since there are often many > wrong answers. > >> I was also getting multiple hits on packages while working through >> all of the issues I had, which is another problem. > > Not sure I understand. that are causing issues. The first couple of runs when I was trying to diagnose this I had multiple log entries for packages that were issues. Hard to distill that into just a single exception message. Rick > > -> richard > >> >> Rick >>> >>> -> richard >>> >>>> >>>> >>>> Rick >>>> >>>> >>>>>> Rick >>>>>> >>>>>>> >>>>>>> -> richard >>>>>>> >>>>>>>> >>>>>>>> Rick >>>>>>>>> >>>>>>>>> -> richard >>>>>>>>> >>>>>>>>>> Rick >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -> richard >>>>>>>>>>> >>>>>>>>>>> On 11/4/09 9:11, Rick McGuire wrote: >>>>>>>>>>>> I'm getting an exception on a bundle start indicating there >>>>>>>>>>>> is a constraint violation with no details on where the >>>>>>>>>>>> problem might lie: >>>>>>>>>>>> >>>>>>>>>>>> org.osgi.framework.BundleException: Unable to resolve due >>>>>>>>>>>> to constraint violation. >>>>>>>>>>>> >>>>>>>>>>>> I tweaked the Felix code a bit to contain the original >>>>>>>>>>>> exception cause, and got this stack trace: >>>>>>>>>>>> >>>>>>>>>>>> Caused by: >>>>>>>>>>>> org.apache.felix.framework.searchpolicy.ResolveException: >>>>>>>>>>>> Unable to r >>>>>>>>>>>> esolve due to constraint violation. >>>>>>>>>>>> at >>>>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.incrementCandidateCo >>>>>>>>>>>> >>>>>>>>>>>> nfiguration(Resolver.java:1555) >>>>>>>>>>>> at >>>>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.findConsistentClassS >>>>>>>>>>>> >>>>>>>>>>>> pace(Resolver.java:610) >>>>>>>>>>>> at >>>>>>>>>>>> org.apache.felix.framework.searchpolicy.Resolver.resolve(Resolver.jav >>>>>>>>>>>> >>>>>>>>>>>> a:104) >>>>>>>>>>>> at >>>>>>>>>>>> org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:387 >>>>>>>>>>>> >>>>>>>>>>>> 6) >>>>>>>>>>>> at >>>>>>>>>>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3264) >>>>>>>>>>>> >>>>>>>>>>>> ... 47 more >>>>>>>>>>>> >>>>>>>>>>>> So this looks like there's an issue with a consistent class >>>>>>>>>>>> space. There are a lot of imports/exports involved with >>>>>>>>>>>> this bundle...are there any tools that can help determine >>>>>>>>>>>> where the consistency issues are? >>>>>>>>>>>> >>>>>>>>>>>> Rick >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
