You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Tang Yong <ta...@cn.fujitsu.com> on 2013/12/17 10:36:33 UTC
[Discuss]About "Unable to acquire global lock for resolve"
Hi All,
I met an issue as the following,
...
Caused by: org.osgi.framework.BundleException: Unable to acquire global
lock for resolve.
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
...
Richard said the issue is not a bug[1] of felix, and I also agree with him.
However, I want to say once we truely met the issue and try to catch the
exception on upper layer, how can we do?
I think that best way should be: felix offered some api to let us
retrieve whether bundle lock has been released by other thread.
The second way can be: do a loop and wait for the changing of current
bundle state, and set a timeout to avoid infinite loop.
The third way should be: adjusting upper layer's bundles and decoupling
them to avoid the case...
Want to listen your ideas.
[1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
Thanks
Tang
--
−−−−−−−−−−−−−−−−−−−−−−
Tang Yong
Senior Engineer
GlassFish Committer (OSGi & OSGi-JavaEE)
OSGi Alliance Supporter
Blog: http://osgizone.typepad.com/tangyong/
Nanjing Fujitsu NanDa Software Tec CO.,LTD
http://www.fujitsu.com/cn/fnst
Tel: +86-25-86630566-8310
Fax: +86-25-83317685
−−−−−−−−−−−−−−−−−−−−−−
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: [Discuss]About "Unable to acquire global lock for resolve"
Posted by Guillaume Nodet <gn...@apache.org>.
One real problematic use of the global lock is when a bundle attemps to
resolve a dynamic import package.
This can lead to deadlocks because this can happen whenever a class is
loaded, and that can't be controlled.
This is a common use case when using asynchronous extenders, see
https://issues.apache.org/jira/browse/FELIX-4308.
2013/12/17 Richard S. Hall <he...@ungoverned.org>
> On 12/17/13, 04:36 , Tang Yong wrote:
> > Hi All,
> >
> > I met an issue as the following,
> >
> > ...
> > Caused by: org.osgi.framework.BundleException: Unable to acquire global
> > lock for resolve.
> > at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> > ...
> >
> > Richard said the issue is not a bug[1] of felix, and I also agree with
> him.
> >
> > However, I want to say once we truely met the issue and try to catch the
> > exception on upper layer, how can we do?
> >
> > I think that best way should be: felix offered some api to let us
> > retrieve whether bundle lock has been released by other thread.
> >
> > The second way can be: do a loop and wait for the changing of current
> > bundle state, and set a timeout to avoid infinite loop.
> >
> > The third way should be: adjusting upper layer's bundles and decoupling
> > them to avoid the case...
> >
> > Want to listen your ideas.
>
> The main way I'd like to address this issue is to simply avoid it by
> eliminating the use of the global lock altogether. What I had thought
> about long ago was to simply make resolving optimistic so that it would
> work on a copy of the framework state and if the framework state changed
> at the end of the resolve, it would try to resolve again until the
> framework state didn't change (perhaps with a retry limit).
>
> The only other place that uses the global lock is for refreshing, but we
> could probably eliminate it there in a somewhat similar fashion by
> calculating all needed bundle locks in advance and locking all bundles
> individually (you'd still need to double check the calculation to make
> sure nothing changed and potentially release and try again).
>
> -> richard
>
> >
> > [1]:
> http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
> >
> > Thanks
> > Tang
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: [Discuss]About "Unable to acquire global lock for resolve"
Posted by Tang Yong <ta...@cn.fujitsu.com>.
Thanks all's reply very much!
Felix Meschberger wrote:
> Hi
>
> Am 17.12.2013 um 14:25 schrieb Richard S. Hall <he...@ungoverned.org>:
>
>> On 12/17/13, 04:36 , Tang Yong wrote:
>>> Hi All,
>>>
>>> I met an issue as the following,
>>>
>>> ...
>>> Caused by: org.osgi.framework.BundleException: Unable to acquire global
>>> lock for resolve.
>>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>> ...
>>>
>>> Richard said the issue is not a bug[1] of felix, and I also agree with him.
>>>
>>> However, I want to say once we truely met the issue and try to catch the
>>> exception on upper layer, how can we do?
>>>
>>> I think that best way should be: felix offered some api to let us
>>> retrieve whether bundle lock has been released by other thread.
>>>
>>> The second way can be: do a loop and wait for the changing of current
>>> bundle state, and set a timeout to avoid infinite loop.
>>>
>>> The third way should be: adjusting upper layer's bundles and decoupling
>>> them to avoid the case…
>
> I think there is a patch around somewhere in the issues where I proposed to actually implement such a loop and timeout in the acquireGlobalLock method itself. Yet, it does not solve the problem really so we never applied.
Surly, loop and timeout can not resolve truly issue. Often, these issues
is caused by upper layer's bad design...
>
>>> Want to listen your ideas.
>> The main way I'd like to address this issue is to simply avoid it by
>> eliminating the use of the global lock altogether. What I had thought
>> about long ago was to simply make resolving optimistic so that it would
>> work on a copy of the framework state and if the framework state changed
>> at the end of the resolve, it would try to resolve again until the
>> framework state didn't change (perhaps with a retry limit).
>
> This sounds promising.
>
> Unfortunately we hit this deadlock every now and then, even though we try hard to setup our system to prevent (for example by carefully leveraging the start level service on startup; nasty but pragmatic) them.
Yes, I am applying some patch for my case by adjusting some modules's
starting levels or virtually, these modules should have starting orders.
Thanks
Tang
>
> Regrds
> Felix
>
>
>> The only other place that uses the global lock is for refreshing, but we
>> could probably eliminate it there in a somewhat similar fashion by
>> calculating all needed bundle locks in advance and locking all bundles
>> individually (you'd still need to double check the calculation to make
>> sure nothing changed and potentially release and try again).
>>
>> -> richard
>>
>>> [1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
>>>
>>> Thanks
>>> Tang
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
−−−−−−−−−−−−−−−−−−−−−−
Tang Yong
Senior Engineer
GlassFish Committer (OSGi & OSGi-JavaEE)
OSGi Alliance Supporter
Blog: http://osgizone.typepad.com/tangyong/
Nanjing Fujitsu NanDa Software Tec CO.,LTD
http://www.fujitsu.com/cn/fnst
Tel: +86-25-86630566-8310
Fax: +86-25-83317685
−−−−−−−−−−−−−−−−−−−−−−
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: [Discuss]About "Unable to acquire global lock for resolve"
Posted by Tang Yong <ta...@cn.fujitsu.com>.
+1 agree with Richard.
Tang
Richard S. Hall wrote:
> On 12/18/13, 09:06 , Daniel McGreal wrote:
>> Hi,
>> I wonder if this issue could be the cause, or related to problems when running on JamVM (e.g. GNU Classpath) described here: https://www.mail-archive.com/dev@felix.apache.org/msg31518.html
>> Best, Dan.
>
> I don't think they are related. Your issue deals with class loader
> locks, not the global lock (which is a Felix framework-specific thing).
>
> -> richard
>
>> On 18 Dec 2013, at 13:57, Felix Meschberger <fm...@adobe.com> wrote:
>>
>>> Hi
>>>
>>> Am 17.12.2013 um 14:25 schrieb Richard S. Hall <he...@ungoverned.org>:
>>>
>>>> On 12/17/13, 04:36 , Tang Yong wrote:
>>>>> Hi All,
>>>>>
>>>>> I met an issue as the following,
>>>>>
>>>>> ...
>>>>> Caused by: org.osgi.framework.BundleException: Unable to acquire global
>>>>> lock for resolve.
>>>>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
>>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>>>> ...
>>>>>
>>>>> Richard said the issue is not a bug[1] of felix, and I also agree with him.
>>>>>
>>>>> However, I want to say once we truely met the issue and try to catch the
>>>>> exception on upper layer, how can we do?
>>>>>
>>>>> I think that best way should be: felix offered some api to let us
>>>>> retrieve whether bundle lock has been released by other thread.
>>>>>
>>>>> The second way can be: do a loop and wait for the changing of current
>>>>> bundle state, and set a timeout to avoid infinite loop.
>>>>>
>>>>> The third way should be: adjusting upper layer's bundles and decoupling
>>>>> them to avoid the case…
>>> I think there is a patch around somewhere in the issues where I proposed to actually implement such a loop and timeout in the acquireGlobalLock method itself. Yet, it does not solve the problem really so we never applied.
>>>
>>>>> Want to listen your ideas.
>>>> The main way I'd like to address this issue is to simply avoid it by
>>>> eliminating the use of the global lock altogether. What I had thought
>>>> about long ago was to simply make resolving optimistic so that it would
>>>> work on a copy of the framework state and if the framework state changed
>>>> at the end of the resolve, it would try to resolve again until the
>>>> framework state didn't change (perhaps with a retry limit).
>>> This sounds promising.
>>>
>>> Unfortunately we hit this deadlock every now and then, even though we try hard to setup our system to prevent (for example by carefully leveraging the start level service on startup; nasty but pragmatic) them.
>>>
>>> Regrds
>>> Felix
>>>
>>>
>>>> The only other place that uses the global lock is for refreshing, but we
>>>> could probably eliminate it there in a somewhat similar fashion by
>>>> calculating all needed bundle locks in advance and locking all bundles
>>>> individually (you'd still need to double check the calculation to make
>>>> sure nothing changed and potentially release and try again).
>>>>
>>>> -> richard
>>>>
>>>>> [1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
>>>>>
>>>>> Thanks
>>>>> Tang
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
−−−−−−−−−−−−−−−−−−−−−−
Tang Yong
Senior Engineer
GlassFish Committer (OSGi & OSGi-JavaEE)
OSGi Alliance Supporter
Blog: http://osgizone.typepad.com/tangyong/
Nanjing Fujitsu NanDa Software Tec CO.,LTD
http://www.fujitsu.com/cn/fnst
Tel: +86-25-86630566-8310
Fax: +86-25-83317685
−−−−−−−−−−−−−−−−−−−−−−
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: [Discuss]About "Unable to acquire global lock for resolve"
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/18/13, 09:06 , Daniel McGreal wrote:
> Hi,
> I wonder if this issue could be the cause, or related to problems when running on JamVM (e.g. GNU Classpath) described here: https://www.mail-archive.com/dev@felix.apache.org/msg31518.html
> Best, Dan.
I don't think they are related. Your issue deals with class loader
locks, not the global lock (which is a Felix framework-specific thing).
-> richard
>
> On 18 Dec 2013, at 13:57, Felix Meschberger <fm...@adobe.com> wrote:
>
>> Hi
>>
>> Am 17.12.2013 um 14:25 schrieb Richard S. Hall <he...@ungoverned.org>:
>>
>>> On 12/17/13, 04:36 , Tang Yong wrote:
>>>> Hi All,
>>>>
>>>> I met an issue as the following,
>>>>
>>>> ...
>>>> Caused by: org.osgi.framework.BundleException: Unable to acquire global
>>>> lock for resolve.
>>>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>>> ...
>>>>
>>>> Richard said the issue is not a bug[1] of felix, and I also agree with him.
>>>>
>>>> However, I want to say once we truely met the issue and try to catch the
>>>> exception on upper layer, how can we do?
>>>>
>>>> I think that best way should be: felix offered some api to let us
>>>> retrieve whether bundle lock has been released by other thread.
>>>>
>>>> The second way can be: do a loop and wait for the changing of current
>>>> bundle state, and set a timeout to avoid infinite loop.
>>>>
>>>> The third way should be: adjusting upper layer's bundles and decoupling
>>>> them to avoid the case…
>> I think there is a patch around somewhere in the issues where I proposed to actually implement such a loop and timeout in the acquireGlobalLock method itself. Yet, it does not solve the problem really so we never applied.
>>
>>>> Want to listen your ideas.
>>> The main way I'd like to address this issue is to simply avoid it by
>>> eliminating the use of the global lock altogether. What I had thought
>>> about long ago was to simply make resolving optimistic so that it would
>>> work on a copy of the framework state and if the framework state changed
>>> at the end of the resolve, it would try to resolve again until the
>>> framework state didn't change (perhaps with a retry limit).
>> This sounds promising.
>>
>> Unfortunately we hit this deadlock every now and then, even though we try hard to setup our system to prevent (for example by carefully leveraging the start level service on startup; nasty but pragmatic) them.
>>
>> Regrds
>> Felix
>>
>>
>>> The only other place that uses the global lock is for refreshing, but we
>>> could probably eliminate it there in a somewhat similar fashion by
>>> calculating all needed bundle locks in advance and locking all bundles
>>> individually (you'd still need to double check the calculation to make
>>> sure nothing changed and potentially release and try again).
>>>
>>> -> richard
>>>
>>>> [1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
>>>>
>>>> Thanks
>>>> Tang
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: [Discuss]About "Unable to acquire global lock for resolve"
Posted by Daniel McGreal <da...@redbite.com>.
Hi,
I wonder if this issue could be the cause, or related to problems when running on JamVM (e.g. GNU Classpath) described here: https://www.mail-archive.com/dev@felix.apache.org/msg31518.html
Best, Dan.
On 18 Dec 2013, at 13:57, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Am 17.12.2013 um 14:25 schrieb Richard S. Hall <he...@ungoverned.org>:
>
>> On 12/17/13, 04:36 , Tang Yong wrote:
>>> Hi All,
>>>
>>> I met an issue as the following,
>>>
>>> ...
>>> Caused by: org.osgi.framework.BundleException: Unable to acquire global
>>> lock for resolve.
>>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>> ...
>>>
>>> Richard said the issue is not a bug[1] of felix, and I also agree with him.
>>>
>>> However, I want to say once we truely met the issue and try to catch the
>>> exception on upper layer, how can we do?
>>>
>>> I think that best way should be: felix offered some api to let us
>>> retrieve whether bundle lock has been released by other thread.
>>>
>>> The second way can be: do a loop and wait for the changing of current
>>> bundle state, and set a timeout to avoid infinite loop.
>>>
>>> The third way should be: adjusting upper layer's bundles and decoupling
>>> them to avoid the case…
>
> I think there is a patch around somewhere in the issues where I proposed to actually implement such a loop and timeout in the acquireGlobalLock method itself. Yet, it does not solve the problem really so we never applied.
>
>>>
>>> Want to listen your ideas.
>>
>> The main way I'd like to address this issue is to simply avoid it by
>> eliminating the use of the global lock altogether. What I had thought
>> about long ago was to simply make resolving optimistic so that it would
>> work on a copy of the framework state and if the framework state changed
>> at the end of the resolve, it would try to resolve again until the
>> framework state didn't change (perhaps with a retry limit).
>
> This sounds promising.
>
> Unfortunately we hit this deadlock every now and then, even though we try hard to setup our system to prevent (for example by carefully leveraging the start level service on startup; nasty but pragmatic) them.
>
> Regrds
> Felix
>
>
>>
>> The only other place that uses the global lock is for refreshing, but we
>> could probably eliminate it there in a somewhat similar fashion by
>> calculating all needed bundle locks in advance and locking all bundles
>> individually (you'd still need to double check the calculation to make
>> sure nothing changed and potentially release and try again).
>>
>> -> richard
>>
>>>
>>> [1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
>>>
>>> Thanks
>>> Tang
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: [Discuss]About "Unable to acquire global lock for resolve"
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 17.12.2013 um 14:25 schrieb Richard S. Hall <he...@ungoverned.org>:
> On 12/17/13, 04:36 , Tang Yong wrote:
>> Hi All,
>>
>> I met an issue as the following,
>>
>> ...
>> Caused by: org.osgi.framework.BundleException: Unable to acquire global
>> lock for resolve.
>> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>> ...
>>
>> Richard said the issue is not a bug[1] of felix, and I also agree with him.
>>
>> However, I want to say once we truely met the issue and try to catch the
>> exception on upper layer, how can we do?
>>
>> I think that best way should be: felix offered some api to let us
>> retrieve whether bundle lock has been released by other thread.
>>
>> The second way can be: do a loop and wait for the changing of current
>> bundle state, and set a timeout to avoid infinite loop.
>>
>> The third way should be: adjusting upper layer's bundles and decoupling
>> them to avoid the case…
I think there is a patch around somewhere in the issues where I proposed to actually implement such a loop and timeout in the acquireGlobalLock method itself. Yet, it does not solve the problem really so we never applied.
>>
>> Want to listen your ideas.
>
> The main way I'd like to address this issue is to simply avoid it by
> eliminating the use of the global lock altogether. What I had thought
> about long ago was to simply make resolving optimistic so that it would
> work on a copy of the framework state and if the framework state changed
> at the end of the resolve, it would try to resolve again until the
> framework state didn't change (perhaps with a retry limit).
This sounds promising.
Unfortunately we hit this deadlock every now and then, even though we try hard to setup our system to prevent (for example by carefully leveraging the start level service on startup; nasty but pragmatic) them.
Regrds
Felix
>
> The only other place that uses the global lock is for refreshing, but we
> could probably eliminate it there in a somewhat similar fashion by
> calculating all needed bundle locks in advance and locking all bundles
> individually (you'd still need to double check the calculation to make
> sure nothing changed and potentially release and try again).
>
> -> richard
>
>>
>> [1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
>>
>> Thanks
>> Tang
>>
>
>
> ---------------------------------------------------------------------
> 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: [Discuss]About "Unable to acquire global lock for resolve"
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/17/13, 04:36 , Tang Yong wrote:
> Hi All,
>
> I met an issue as the following,
>
> ...
> Caused by: org.osgi.framework.BundleException: Unable to acquire global
> lock for resolve.
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> ...
>
> Richard said the issue is not a bug[1] of felix, and I also agree with him.
>
> However, I want to say once we truely met the issue and try to catch the
> exception on upper layer, how can we do?
>
> I think that best way should be: felix offered some api to let us
> retrieve whether bundle lock has been released by other thread.
>
> The second way can be: do a loop and wait for the changing of current
> bundle state, and set a timeout to avoid infinite loop.
>
> The third way should be: adjusting upper layer's bundles and decoupling
> them to avoid the case...
>
> Want to listen your ideas.
The main way I'd like to address this issue is to simply avoid it by
eliminating the use of the global lock altogether. What I had thought
about long ago was to simply make resolving optimistic so that it would
work on a copy of the framework state and if the framework state changed
at the end of the resolve, it would try to resolve again until the
framework state didn't change (perhaps with a retry limit).
The only other place that uses the global lock is for refreshing, but we
could probably eliminate it there in a somewhat similar fashion by
calculating all needed bundle locks in advance and locking all bundles
individually (you'd still need to double check the calculation to make
sure nothing changed and potentially release and try again).
-> richard
>
> [1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3C4D498058.7080104@ungoverned.org%3E
>
> Thanks
> Tang
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org