You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Rajan Parthasarathy <Ra...@rapid7.com> on 2013/10/03 16:24:50 UTC
Help with "Unresolved constraint" error
Hello,
I'm running into an "Unresolved constraint in bundle" error, and hoping to get some insight into it. I'm using Felix system bundle 4.0.3.
The application uses an OBR, with a thread that periodically checks for updates. Bundles are updated using Resolver. Here's the code which performs the updates (with null checks, etc. removed):
repositoryAdmin.addRepository(new URL(repositoryUrl));
Resolver resolver = repositoryAdmin.resolver();
Resource resource = ... get the resource we want to update ...
resolver.add(resource);
if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | Resolver.START);
}
The application is running in Felix with the following bundles:
collector-api (0.2.2) - exports itself
collector-engine (0.2.10) - imports collector-api >= 0.2.2
port-watcher (0.2.2) - imports collector-api >= 0.2.0
I updated the OBR in the following manner:
- replaced collector-api 0.2.2 with collector-api 0.2.3
- replaced engine 0.2.10 with 0.2.11, which imports collector-api >= 0.2.3
When I resolve and deploy engine 0.2.11 with the above code, it throws the following error:
ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) - Resolver: Start error - com.rapid7.razor.collector.engine
org.osgi.framework.BundleException: Unresolved constraint in bundle com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29: missing requirement [8.29] osgi.wiring.package; (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)(!(version>=1.0.0)))
If I replicate the above scenario without the port-watcher bundle installed, then it works - the engine gets updated successfully. Any hints as to what is happening here?
Thank you,
Raj
This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help with "Unresolved constraint" error
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/3/13 18:02 , Rajan Parthasarathy wrote:
> So I rewrote the code to not rely on Resolver.deploy to start the bundles. Instead, I'm refreshing the bundles prior to restarting them, and it seems to work.
>
> The code looks like this:
>
> repositoryAdmin.addRepository(new URL(repositoryUrl));
> Resolver resolver = repositoryAdmin.resolver();
> Resource resource = ... get resource to update ...;
> resolver.add(resource);
>
> if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
> stopBundles(resolver); // stops bundles associated with added or required resources
> resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES); // do not automatically start bundles
> refreshBundles(resolver); // refreshes bundles associated with required resources
> startBundles(resolver); // starts bundles associated with added or required resources
> }
>
> The stopBundles() call is needed because ResolverImpl.deploy will start any bundles that were in active state prior to being updated. In my scenario, it would do this:
> - stop collector-api and collector-engine
> - deploy collector-engine and collector-api
> - refresh collector-api
> - start collector-api and collector-engine
>
> I need to run more tests (adding new bundles, etc.) but if you see anything wonky with this approach, please let me know.
Yes, I believe that is the correct approach.
-> richard
>
> Thanks again for all the help,
> Raj
>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, October 03, 2013 3:49 PM
> To: users@felix.apache.org
> Subject: Re: Help with "Unresolved constraint" error
>
> On 10/3/13 14:55 , Rajan Parthasarathy wrote:
>> In the tests I was running yesterday, the presence of the port-watcher dependency seemed to be making a difference. However, I just reproduced the issue without the port-watcher. Huh!
>>
>> Here's the full stack trace:
>>
>> ERROR 2013-10-03 14:44:35.979 (org.apache.felix.bundlerepository:?) -
>> Resolver: Start error - com.rapid7.razor.collector.engine
>> org.osgi.framework.BundleException: Unresolved constraint in bundle com.rapid7.razor.collector.engine [8]: Unable to resolve 8.1: missing requirement [8.1] osgi.wiring.package; (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)(!(version>=1.0.0)))
>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
>> at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
>> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.deployEngine(BootstrapEngineManager.java:93)
>> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.access$200(BootstrapEngineManager.java:25)
>> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager$UpdateWorker.run(BootstrapEngineManager.java:215)
>> at java.lang.Thread.run(Thread.java:722)
>>
>> In Gogo, I see this when I do an lb:
>>
>> 8|Installed | 1|Razor Collector Engine (0.2.11)
>> 9|Active | 1|Razor Collector API (0.2.3)
>>
>> If I do this:
>> g! refresh 9
>> g! start 8
>> g! lb
>>
>> then it seems to have started properly.
>>
>> I'm confused because 0.2.3 is listed as active, yet the exception specifies it's not able to resolve the requirement for 0.2.3. Also, I do call Resolver.resolve() before calling Resolver.deploy(), and the first call returned true to indicate that resolution was successful.
> If the bundle exports what it imports, then it won't actually start providing the new versions of the package until the refresh occurs. That might explain what you are seeing.
>
> OBR doesn't handle refreshing very well. Generally, speaking you should always do a refreshing after updating one or more bundles...OBR doesn't do this.
>
> -> richard
>
>> Thank you for your help,
>> Raj
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Thursday, October 03, 2013 1:10 PM
>> To: users@felix.apache.org
>> Subject: Re: Help with "Unresolved constraint" error
>>
>> On 10/3/13 10:24 , Rajan Parthasarathy wrote:
>>> Hello,
>>>
>>> I'm running into an "Unresolved constraint in bundle" error, and hoping to get some insight into it. I'm using Felix system bundle 4.0.3.
>>>
>>> The application uses an OBR, with a thread that periodically checks for updates. Bundles are updated using Resolver. Here's the code which performs the updates (with null checks, etc. removed):
>>>
>>> repositoryAdmin.addRepository(new URL(repositoryUrl));
>>> Resolver resolver = repositoryAdmin.resolver();
>>> Resource resource = ... get the resource we want to update ...
>>> resolver.add(resource);
>>> if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
>>> resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | Resolver.START);
>>> }
>>>
>>> The application is running in Felix with the following bundles:
>>> collector-api (0.2.2) - exports itself collector-engine (0.2.10) -
>>> imports collector-api >= 0.2.2 port-watcher (0.2.2) - imports
>>> collector-api >= 0.2.0
>>>
>>> I updated the OBR in the following manner:
>>> - replaced collector-api 0.2.2 with collector-api 0.2.3
>>> - replaced engine 0.2.10 with 0.2.11, which imports collector-api >=
>>> 0.2.3
>>>
>>> When I resolve and deploy engine 0.2.11 with the above code, it throws the following error:
>>> ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) -
>>> Resolver: Start error - com.rapid7.razor.collector.engine
>>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>>> com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29:
>>> missing requirement [8.29] osgi.wiring.package;
>>> (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3
>>> )
>>> (!(version>=1.0.0)))
>>>
>>> If I replicate the above scenario without the port-watcher bundle installed, then it works - the engine gets updated successfully. Any hints as to what is happening here?
>> Not sure. There is code in OBR that tries to update a bundle instead
>> of deploying a second version. Perhaps it tries to update
>> collector-api to
>> 0.2.3 but determines that it breaks the port-watcher dependency if it does that so it fails. If that is the case, then that would be a bug since it shouldn't fail, it should deploy a second version of collector-api.
>>
>> When you run your example without port-watcher is the existing version of collector-api updated to 0.2.3 or are there two versions of the bundle deployed?
>>
>> -> richard
>>
>>> Thank you,
>>> Raj
>>> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Help with "Unresolved constraint" error
Posted by Rajan Parthasarathy <Ra...@rapid7.com>.
So I rewrote the code to not rely on Resolver.deploy to start the bundles. Instead, I'm refreshing the bundles prior to restarting them, and it seems to work.
The code looks like this:
repositoryAdmin.addRepository(new URL(repositoryUrl));
Resolver resolver = repositoryAdmin.resolver();
Resource resource = ... get resource to update ...;
resolver.add(resource);
if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
stopBundles(resolver); // stops bundles associated with added or required resources
resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES); // do not automatically start bundles
refreshBundles(resolver); // refreshes bundles associated with required resources
startBundles(resolver); // starts bundles associated with added or required resources
}
The stopBundles() call is needed because ResolverImpl.deploy will start any bundles that were in active state prior to being updated. In my scenario, it would do this:
- stop collector-api and collector-engine
- deploy collector-engine and collector-api
- refresh collector-api
- start collector-api and collector-engine
I need to run more tests (adding new bundles, etc.) but if you see anything wonky with this approach, please let me know.
Thanks again for all the help,
Raj
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Thursday, October 03, 2013 3:49 PM
To: users@felix.apache.org
Subject: Re: Help with "Unresolved constraint" error
On 10/3/13 14:55 , Rajan Parthasarathy wrote:
> In the tests I was running yesterday, the presence of the port-watcher dependency seemed to be making a difference. However, I just reproduced the issue without the port-watcher. Huh!
>
> Here's the full stack trace:
>
> ERROR 2013-10-03 14:44:35.979 (org.apache.felix.bundlerepository:?) -
> Resolver: Start error - com.rapid7.razor.collector.engine
> org.osgi.framework.BundleException: Unresolved constraint in bundle com.rapid7.razor.collector.engine [8]: Unable to resolve 8.1: missing requirement [8.1] osgi.wiring.package; (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)(!(version>=1.0.0)))
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.deployEngine(BootstrapEngineManager.java:93)
> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.access$200(BootstrapEngineManager.java:25)
> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager$UpdateWorker.run(BootstrapEngineManager.java:215)
> at java.lang.Thread.run(Thread.java:722)
>
> In Gogo, I see this when I do an lb:
>
> 8|Installed | 1|Razor Collector Engine (0.2.11)
> 9|Active | 1|Razor Collector API (0.2.3)
>
> If I do this:
> g! refresh 9
> g! start 8
> g! lb
>
> then it seems to have started properly.
>
> I'm confused because 0.2.3 is listed as active, yet the exception specifies it's not able to resolve the requirement for 0.2.3. Also, I do call Resolver.resolve() before calling Resolver.deploy(), and the first call returned true to indicate that resolution was successful.
If the bundle exports what it imports, then it won't actually start providing the new versions of the package until the refresh occurs. That might explain what you are seeing.
OBR doesn't handle refreshing very well. Generally, speaking you should always do a refreshing after updating one or more bundles...OBR doesn't do this.
-> richard
>
> Thank you for your help,
> Raj
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, October 03, 2013 1:10 PM
> To: users@felix.apache.org
> Subject: Re: Help with "Unresolved constraint" error
>
> On 10/3/13 10:24 , Rajan Parthasarathy wrote:
>> Hello,
>>
>> I'm running into an "Unresolved constraint in bundle" error, and hoping to get some insight into it. I'm using Felix system bundle 4.0.3.
>>
>> The application uses an OBR, with a thread that periodically checks for updates. Bundles are updated using Resolver. Here's the code which performs the updates (with null checks, etc. removed):
>>
>> repositoryAdmin.addRepository(new URL(repositoryUrl));
>> Resolver resolver = repositoryAdmin.resolver();
>> Resource resource = ... get the resource we want to update ...
>> resolver.add(resource);
>> if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
>> resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | Resolver.START);
>> }
>>
>> The application is running in Felix with the following bundles:
>> collector-api (0.2.2) - exports itself collector-engine (0.2.10) -
>> imports collector-api >= 0.2.2 port-watcher (0.2.2) - imports
>> collector-api >= 0.2.0
>>
>> I updated the OBR in the following manner:
>> - replaced collector-api 0.2.2 with collector-api 0.2.3
>> - replaced engine 0.2.10 with 0.2.11, which imports collector-api >=
>> 0.2.3
>>
>> When I resolve and deploy engine 0.2.11 with the above code, it throws the following error:
>> ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) -
>> Resolver: Start error - com.rapid7.razor.collector.engine
>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>> com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29:
>> missing requirement [8.29] osgi.wiring.package;
>> (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3
>> )
>> (!(version>=1.0.0)))
>>
>> If I replicate the above scenario without the port-watcher bundle installed, then it works - the engine gets updated successfully. Any hints as to what is happening here?
> Not sure. There is code in OBR that tries to update a bundle instead
> of deploying a second version. Perhaps it tries to update
> collector-api to
> 0.2.3 but determines that it breaks the port-watcher dependency if it does that so it fails. If that is the case, then that would be a bug since it shouldn't fail, it should deploy a second version of collector-api.
>
> When you run your example without port-watcher is the existing version of collector-api updated to 0.2.3 or are there two versions of the bundle deployed?
>
> -> richard
>
>> Thank you,
>> Raj
>> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help with "Unresolved constraint" error
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/3/13 14:55 , Rajan Parthasarathy wrote:
> In the tests I was running yesterday, the presence of the port-watcher dependency seemed to be making a difference. However, I just reproduced the issue without the port-watcher. Huh!
>
> Here's the full stack trace:
>
> ERROR 2013-10-03 14:44:35.979 (org.apache.felix.bundlerepository:?) - Resolver: Start error - com.rapid7.razor.collector.engine
> org.osgi.framework.BundleException: Unresolved constraint in bundle com.rapid7.razor.collector.engine [8]: Unable to resolve 8.1: missing requirement [8.1] osgi.wiring.package; (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)(!(version>=1.0.0)))
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.deployEngine(BootstrapEngineManager.java:93)
> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.access$200(BootstrapEngineManager.java:25)
> at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager$UpdateWorker.run(BootstrapEngineManager.java:215)
> at java.lang.Thread.run(Thread.java:722)
>
> In Gogo, I see this when I do an lb:
>
> 8|Installed | 1|Razor Collector Engine (0.2.11)
> 9|Active | 1|Razor Collector API (0.2.3)
>
> If I do this:
> g! refresh 9
> g! start 8
> g! lb
>
> then it seems to have started properly.
>
> I'm confused because 0.2.3 is listed as active, yet the exception specifies it's not able to resolve the requirement for 0.2.3. Also, I do call Resolver.resolve() before calling Resolver.deploy(), and the first call returned true to indicate that resolution was successful.
If the bundle exports what it imports, then it won't actually start
providing the new versions of the package until the refresh occurs. That
might explain what you are seeing.
OBR doesn't handle refreshing very well. Generally, speaking you should
always do a refreshing after updating one or more bundles...OBR doesn't
do this.
-> richard
>
> Thank you for your help,
> Raj
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, October 03, 2013 1:10 PM
> To: users@felix.apache.org
> Subject: Re: Help with "Unresolved constraint" error
>
> On 10/3/13 10:24 , Rajan Parthasarathy wrote:
>> Hello,
>>
>> I'm running into an "Unresolved constraint in bundle" error, and hoping to get some insight into it. I'm using Felix system bundle 4.0.3.
>>
>> The application uses an OBR, with a thread that periodically checks for updates. Bundles are updated using Resolver. Here's the code which performs the updates (with null checks, etc. removed):
>>
>> repositoryAdmin.addRepository(new URL(repositoryUrl));
>> Resolver resolver = repositoryAdmin.resolver();
>> Resource resource = ... get the resource we want to update ...
>> resolver.add(resource);
>> if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
>> resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | Resolver.START);
>> }
>>
>> The application is running in Felix with the following bundles:
>> collector-api (0.2.2) - exports itself collector-engine (0.2.10) -
>> imports collector-api >= 0.2.2 port-watcher (0.2.2) - imports
>> collector-api >= 0.2.0
>>
>> I updated the OBR in the following manner:
>> - replaced collector-api 0.2.2 with collector-api 0.2.3
>> - replaced engine 0.2.10 with 0.2.11, which imports collector-api >=
>> 0.2.3
>>
>> When I resolve and deploy engine 0.2.11 with the above code, it throws the following error:
>> ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) -
>> Resolver: Start error - com.rapid7.razor.collector.engine
>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>> com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29: missing
>> requirement [8.29] osgi.wiring.package;
>> (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)
>> (!(version>=1.0.0)))
>>
>> If I replicate the above scenario without the port-watcher bundle installed, then it works - the engine gets updated successfully. Any hints as to what is happening here?
> Not sure. There is code in OBR that tries to update a bundle instead of deploying a second version. Perhaps it tries to update collector-api to
> 0.2.3 but determines that it breaks the port-watcher dependency if it does that so it fails. If that is the case, then that would be a bug since it shouldn't fail, it should deploy a second version of collector-api.
>
> When you run your example without port-watcher is the existing version of collector-api updated to 0.2.3 or are there two versions of the bundle deployed?
>
> -> richard
>
>> Thank you,
>> Raj
>> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Help with "Unresolved constraint" error
Posted by Rajan Parthasarathy <Ra...@rapid7.com>.
In the tests I was running yesterday, the presence of the port-watcher dependency seemed to be making a difference. However, I just reproduced the issue without the port-watcher. Huh!
Here's the full stack trace:
ERROR 2013-10-03 14:44:35.979 (org.apache.felix.bundlerepository:?) - Resolver: Start error - com.rapid7.razor.collector.engine
org.osgi.framework.BundleException: Unresolved constraint in bundle com.rapid7.razor.collector.engine [8]: Unable to resolve 8.1: missing requirement [8.1] osgi.wiring.package; (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)(!(version>=1.0.0)))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.deployEngine(BootstrapEngineManager.java:93)
at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.access$200(BootstrapEngineManager.java:25)
at com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager$UpdateWorker.run(BootstrapEngineManager.java:215)
at java.lang.Thread.run(Thread.java:722)
In Gogo, I see this when I do an lb:
8|Installed | 1|Razor Collector Engine (0.2.11)
9|Active | 1|Razor Collector API (0.2.3)
If I do this:
g! refresh 9
g! start 8
g! lb
then it seems to have started properly.
I'm confused because 0.2.3 is listed as active, yet the exception specifies it's not able to resolve the requirement for 0.2.3. Also, I do call Resolver.resolve() before calling Resolver.deploy(), and the first call returned true to indicate that resolution was successful.
Thank you for your help,
Raj
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Thursday, October 03, 2013 1:10 PM
To: users@felix.apache.org
Subject: Re: Help with "Unresolved constraint" error
On 10/3/13 10:24 , Rajan Parthasarathy wrote:
> Hello,
>
> I'm running into an "Unresolved constraint in bundle" error, and hoping to get some insight into it. I'm using Felix system bundle 4.0.3.
>
> The application uses an OBR, with a thread that periodically checks for updates. Bundles are updated using Resolver. Here's the code which performs the updates (with null checks, etc. removed):
>
> repositoryAdmin.addRepository(new URL(repositoryUrl));
> Resolver resolver = repositoryAdmin.resolver();
> Resource resource = ... get the resource we want to update ...
> resolver.add(resource);
> if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
> resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | Resolver.START);
> }
>
> The application is running in Felix with the following bundles:
> collector-api (0.2.2) - exports itself collector-engine (0.2.10) -
> imports collector-api >= 0.2.2 port-watcher (0.2.2) - imports
> collector-api >= 0.2.0
>
> I updated the OBR in the following manner:
> - replaced collector-api 0.2.2 with collector-api 0.2.3
> - replaced engine 0.2.10 with 0.2.11, which imports collector-api >=
> 0.2.3
>
> When I resolve and deploy engine 0.2.11 with the above code, it throws the following error:
> ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) -
> Resolver: Start error - com.rapid7.razor.collector.engine
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29: missing
> requirement [8.29] osgi.wiring.package;
> (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)
> (!(version>=1.0.0)))
>
> If I replicate the above scenario without the port-watcher bundle installed, then it works - the engine gets updated successfully. Any hints as to what is happening here?
Not sure. There is code in OBR that tries to update a bundle instead of deploying a second version. Perhaps it tries to update collector-api to
0.2.3 but determines that it breaks the port-watcher dependency if it does that so it fails. If that is the case, then that would be a bug since it shouldn't fail, it should deploy a second version of collector-api.
When you run your example without port-watcher is the existing version of collector-api updated to 0.2.3 or are there two versions of the bundle deployed?
-> richard
>
> Thank you,
> Raj
> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help with "Unresolved constraint" error
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/3/13 10:24 , Rajan Parthasarathy wrote:
> Hello,
>
> I'm running into an "Unresolved constraint in bundle" error, and hoping to get some insight into it. I'm using Felix system bundle 4.0.3.
>
> The application uses an OBR, with a thread that periodically checks for updates. Bundles are updated using Resolver. Here's the code which performs the updates (with null checks, etc. removed):
>
> repositoryAdmin.addRepository(new URL(repositoryUrl));
> Resolver resolver = repositoryAdmin.resolver();
> Resource resource = ... get the resource we want to update ...
> resolver.add(resource);
> if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
> resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | Resolver.START);
> }
>
> The application is running in Felix with the following bundles:
> collector-api (0.2.2) - exports itself
> collector-engine (0.2.10) - imports collector-api >= 0.2.2
> port-watcher (0.2.2) - imports collector-api >= 0.2.0
>
> I updated the OBR in the following manner:
> - replaced collector-api 0.2.2 with collector-api 0.2.3
> - replaced engine 0.2.10 with 0.2.11, which imports collector-api >= 0.2.3
>
> When I resolve and deploy engine 0.2.11 with the above code, it throws the following error:
> ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) - Resolver: Start error - com.rapid7.razor.collector.engine
> org.osgi.framework.BundleException: Unresolved constraint in bundle com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29: missing requirement [8.29] osgi.wiring.package; (&(osgi.wiring.package=com.rapid7.razor.collector.api)(version>=0.2.3)(!(version>=1.0.0)))
>
> If I replicate the above scenario without the port-watcher bundle installed, then it works - the engine gets updated successfully. Any hints as to what is happening here?
Not sure. There is code in OBR that tries to update a bundle instead of
deploying a second version. Perhaps it tries to update collector-api to
0.2.3 but determines that it breaks the port-watcher dependency if it
does that so it fails. If that is the case, then that would be a bug
since it shouldn't fail, it should deploy a second version of collector-api.
When you run your example without port-watcher is the existing version
of collector-api updated to 0.2.3 or are there two versions of the
bundle deployed?
-> richard
>
> Thank you,
> Raj
> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at (postmaster@rapid7.com) immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org