Re: [DS] Feedback wanted on some ideas

[David Jencks]

In felix ds you can use the ScrService to enable or disable any component no 
matter what bundle it is in.  So I don't think adding another non-spec way to 
do this is a good idea.

With regard to the configuration ;pd/factory pid I'm not an expert but I think 
there were some R4.3 changes in how configurationPIDs might be sharable, but I 
thought previously the first bundle to consume a configurationPID got to use it 
exclusively.

Also in DS 1.2 you can specify the configurationPID separately from the 
component name.

david jencks

On Oct 3, 2012, at 11:31 AM, Andrei Pozolotin wrote:

> I do not know.
> 
> how is this addressed by ConfigurationAdmin?
> service.pid and factory.pid are supposed to be framework-global? how one
> bundle is creating a config entry for another?
> DS component.name with configurationPolicy=required is mapped to
> ConfigurationAdmin service.pid/factory.pid - means it is already global?
> 
>  Original Message 
> Subject: Re: [DS] Feedback wanted on some ideas
> From: David Jencks 
> To: dev@felix.apache.org
> Date: Wed 03 Oct 2012 12:49:24 PM CDT
>> As of DS 1.1, the component name is only unique per bundle.  So I'm not sure 
>> how this would work, wouldn't you need to include the bundle in the method 
>> signature?
>> 
>> david jencks
>> 
>> On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote:
>> 
>>> great ideas; one more for your consideration
>>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>>> 
>>> """
>>> 
>>> public void *enableComponent*(java.lang.String name)
>>> 
>>>   Enables the specified component name. The specified component name
>>>   must be in the same bundle as this component.
>>> 
>>> """
>>> 
>>> instead, I suggest to permit traversal of bundle boundaries, so
>>> enable/disable target can be anywhere.
>>> 
>>>  Original Message 
>>> Subject: [DS] Feedback wanted on some ideas
>>> From: David Jencks 
>>> To: dev@felix.apache.org
>>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
 I've had several ideas about DS enhancements, some of which I've 
 implemented, and would like some feedback about how desirable they are 
 before committing or proceeding with them.
 
 1.  (FELIX-3692)  If you manually enable/disable components some of the 
 work gets done asynchronously.  I propose an api for finding out whether 
 this work is done or waiting for it, something like
 
  boolean tasksCompleted();
 
  void waitForTasksCompleted();
 
 
 on ScrService.   (suggestions for better names welcome :-)  One use would 
 be in our tests to replace the delay() call.
 
 2.  (FELIX-3557) There are several circumstances in which, as the spec 
 warns, you can't establish a circular dependency between components.  In 
 some of these cases, the order in which the components are activated 
 determines whether all the references are established.  This is hard to 
 understand from a users point of view :-).  Sometimes it's possible to 
 detect these situations and establish the reference asynchronously.  The 
 patch attached to the issue does this but needs a little more work to only 
 try with services from DS components.
 
 For these two, I'm wondering if they would be useful enough to propose for 
 the DS 1.3 spec.
 
 3. (re-proposal)  I'd like to propose moving the implementation to java 5 
 again with generics etc.  The last time I suggested this there was a lot 
 of pushback on the grounds that there are a lot of people using DS on 
 limited platforms.  However, none of these alleged :-) people is using 
 trunk, because for several months the classes pulled from the concurrent 
 library were wrong and trunk just didn't run on pre-java-5 vms.  Are the 
 compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
 
 4.  (radical idea I haven't tried yet)  I'm becoming increasingly 
 convinced that the state objects in AbstractComponentManager mostly cause 
 confusion and make the code more complicated and less reliable.  The spec 
 really only describes two states, enabled and disabled.  The variations on 
 enabled -- whether the component has all its dependencies satisfied, 
 whether the service is registered, whether there are any implementation 
 objects created -- all seem somewhat orthogonal and depend very much on 
 the environment  and don't seem to relate well to a single "dimension" of 
 state.  I'm considering trying to refactor the code that responds to 
 outside actions (activate/deactivate and dependencies 
 appearing/disappearing) to be more "straight-through" with checks on the 
 specific aspects of state that they need.  Possibly we would want to put 

[jira] [Commented] (FELIX-3680) Exceptions in SCR using concurrent service activation/deactivation

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468763#comment-13468763
 ] 

David Jencks commented on FELIX-3680:
-

I found a couple more problems that I fixed in rev 1393716.  If I run the 
standalone test with ds.loglevel=debug then I get OOM errors from the lock 
logging.  If I disable this I can run the standalone test for several minutes 
without errors.  The testsuite test still fails but I haven't looked at why yet.

> Exceptions in SCR using concurrent service activation/deactivation
> --
>
> Key: FELIX-3680
> URL: https://issues.apache.org/jira/browse/FELIX-3680
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: linux fc16, jdk1.6.032
>Reporter: Pierre De Rop
> Attachments: logs_with_could_not_get_service_from_ref.txt.gz, 
> test.scr.tgz, test_with_fwk.tgz
>
>
> This issue contains a sample code which reproduces many various exceptions, 
> using a concurrent
> scenario, where some services are enabled/disabled concurrently.
> I did not have time to commit an integration test about these exceptions but 
> I will try to do.
> In the meantime, I join to this issue my scenario ... 
> Before trying to make an integration test, could you please run the scenario, 
> in order to confirm the problems, and that the scenario is valid ?
> To execute the scenario
> 1) first, since the framework is not currently using any available log 
> service, you have to make a modification in the framework, in order to force 
> the framework to use a log service, when displaying caught exceptions. If you 
> don't do this, then you will get many exceptions thrown by many threads and 
> displayed in the console; and this is then not easy to diagnose problems.
> So, in the framework, in the file 
> src/main/java/org/apache/felix/framework/Logger.java, in method 
> setBundleContext, just uncomment the following code, which activate the fwk 
> log service listener:
> protected void setSystemBundleContext(BundleContext context)
> {
> // TODO: Find a way to log to a log service inside the framework.
> // The issue is that we log messages while holding framework
> // internal locks -- hence, when a log service calls back into 
> // the framework (e.g., by loading a class) we might deadlock. 
> // One instance of this problem is tracked in FELIX-536.
> // For now we just disable logging to log services inside the
> // framework. 
> m_context = context;
> startListeningForLogService();
> }
> -> this will make sure all logs caught by the framework are redirected to the 
> log service, and I did not find any deadlock issue, as described in the 
> comments.
> Notice that even if you don't activate the log service listener, then the 
> Exceptions are also taking place ...
> 2) next, compile the attached concurrent scenario (it's a simple maven 
> project).
> 3) run the framework with the following bundles:
> org.apache.felix.scr from trunk
> org.apache.felix.configadmin-1.4.0.jar
> 4) wait for about 20 seconds, then suspend the framework, and kill it (using 
> kill -9)
> Don't do "Ctrl-C", because this might interrupt some locked threads and some 
> exceptions might be generated because of the Ctlr-C ... So doing a "Kill -9" 
> is better.
> 5) Then take a look at the produced "./logs.txt" file.
> scenario description:
> ===
> here is a description of the Components used in the scenario:
> A: delayed component, enabled, depending on B,C,D,E,F
> B,C,D,E: delayed components, disabled, without any dependencies
> F: delayed component, disabled, depending on G
> G: delayed component, disabled, depending on H
> I: delayed component, disabled, depending on J
> J: delayed component, disabled, depending on K
> Main: depends on A. 
> "Main" is the main scenario component: it uses a thread pool in order to 
> enable B,C,D,E,F,G,H,I,J,K in parallel, randomly. 
> "Main" depends on A.
> When B,C,D,E,F,G,H,I,J,K are enabled, then A becomes satisfied, provided and 
> injected in the "Main" component.
> Once "A" is bound to "Main", then B,C,D,E,F,G,H,I,J,K are then disabled in 
> parallel, randomly. "Main" also checks that "A" is properly unbound.
> LogService logs are written to "./logs.txt".
> So, running the test using scr 1.6.0 runs seamlessly. But with trunk we have 
> many various exceptions.
> For example, I have noticed the three following exceptions:
> 1) we have some IllegalMontorStateException:
> =
> log level: 1 D=Mon Sep 24 11:07:45 CEST 2012, T=Thread-1: [F] Locking 
> activity before IllegalMonitorStateException: 
>   obtainWriteLock failure from: ImmediateComponentManager.

Re: [DS] Feedback wanted on some ideas

[Andrei Pozolotin]

I do not know.

how is this addressed by ConfigurationAdmin?
service.pid and factory.pid are supposed to be framework-global? how one
bundle is creating a config entry for another?
DS component.name with configurationPolicy=required is mapped to
ConfigurationAdmin service.pid/factory.pid - means it is already global?

 Original Message 
Subject: Re: [DS] Feedback wanted on some ideas
From: David Jencks 
To: dev@felix.apache.org
Date: Wed 03 Oct 2012 12:49:24 PM CDT
> As of DS 1.1, the component name is only unique per bundle.  So I'm not sure 
> how this would work, wouldn't you need to include the bundle in the method 
> signature?
>
> david jencks
>
> On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote:
>
>> great ideas; one more for your consideration
>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>> 
>> """
>>
>> public void *enableComponent*(java.lang.String name)
>>
>>Enables the specified component name. The specified component name
>>must be in the same bundle as this component.
>>
>> """
>>
>> instead, I suggest to permit traversal of bundle boundaries, so
>> enable/disable target can be anywhere.
>>
>>  Original Message 
>> Subject: [DS] Feedback wanted on some ideas
>> From: David Jencks 
>> To: dev@felix.apache.org
>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>> I've had several ideas about DS enhancements, some of which I've 
>>> implemented, and would like some feedback about how desirable they are 
>>> before committing or proceeding with them.
>>>
>>> 1.  (FELIX-3692)  If you manually enable/disable components some of the 
>>> work gets done asynchronously.  I propose an api for finding out whether 
>>> this work is done or waiting for it, something like
>>>
>>>   boolean tasksCompleted();
>>>
>>>   void waitForTasksCompleted();
>>>
>>>
>>> on ScrService.   (suggestions for better names welcome :-)  One use would 
>>> be in our tests to replace the delay() call.
>>>
>>> 2.  (FELIX-3557) There are several circumstances in which, as the spec 
>>> warns, you can't establish a circular dependency between components.  In 
>>> some of these cases, the order in which the components are activated 
>>> determines whether all the references are established.  This is hard to 
>>> understand from a users point of view :-).  Sometimes it's possible to 
>>> detect these situations and establish the reference asynchronously.  The 
>>> patch attached to the issue does this but needs a little more work to only 
>>> try with services from DS components.
>>>
>>> For these two, I'm wondering if they would be useful enough to propose for 
>>> the DS 1.3 spec.
>>>
>>> 3. (re-proposal)  I'd like to propose moving the implementation to java 5 
>>> again with generics etc.  The last time I suggested this there was a lot of 
>>> pushback on the grounds that there are a lot of people using DS on limited 
>>> platforms.  However, none of these alleged :-) people is using trunk, 
>>> because for several months the classes pulled from the concurrent library 
>>> were wrong and trunk just didn't run on pre-java-5 vms.  Are the compendium 
>>> 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>
>>> 4.  (radical idea I haven't tried yet)  I'm becoming increasingly convinced 
>>> that the state objects in AbstractComponentManager mostly cause confusion 
>>> and make the code more complicated and less reliable.  The spec really only 
>>> describes two states, enabled and disabled.  The variations on enabled -- 
>>> whether the component has all its dependencies satisfied, whether the 
>>> service is registered, whether there are any implementation objects created 
>>> -- all seem somewhat orthogonal and depend very much on the environment  
>>> and don't seem to relate well to a single "dimension" of state.  I'm 
>>> considering trying to refactor the code that responds to outside actions 
>>> (activate/deactivate and dependencies appearing/disappearing) to be more 
>>> "straight-through" with checks on the specific aspects of state that they 
>>> need.  Possibly we would want to put the "dynamic state" such as 
>>> dependencies + instances in a single state object, but this is a different 
>>> approach to the current state objects which have no internal state.
>>>
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>

Re: [DS] Feedback wanted on some ideas

[David Jencks]

As of DS 1.1, the component name is only unique per bundle.  So I'm not sure 
how this would work, wouldn't you need to include the bundle in the method 
signature?

david jencks

On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote:

> great ideas; one more for your consideration
> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
> 
> """
> 
> public void *enableComponent*(java.lang.String name)
> 
>Enables the specified component name. The specified component name
>must be in the same bundle as this component.
> 
> """
> 
> instead, I suggest to permit traversal of bundle boundaries, so
> enable/disable target can be anywhere.
> 
>  Original Message 
> Subject: [DS] Feedback wanted on some ideas
> From: David Jencks 
> To: dev@felix.apache.org
> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>> I've had several ideas about DS enhancements, some of which I've 
>> implemented, and would like some feedback about how desirable they are 
>> before committing or proceeding with them.
>> 
>> 1.  (FELIX-3692)  If you manually enable/disable components some of the work 
>> gets done asynchronously.  I propose an api for finding out whether this 
>> work is done or waiting for it, something like
>> 
>>   boolean tasksCompleted();
>> 
>>   void waitForTasksCompleted();
>> 
>> 
>> on ScrService.   (suggestions for better names welcome :-)  One use would be 
>> in our tests to replace the delay() call.
>> 
>> 2.  (FELIX-3557) There are several circumstances in which, as the spec 
>> warns, you can't establish a circular dependency between components.  In 
>> some of these cases, the order in which the components are activated 
>> determines whether all the references are established.  This is hard to 
>> understand from a users point of view :-).  Sometimes it's possible to 
>> detect these situations and establish the reference asynchronously.  The 
>> patch attached to the issue does this but needs a little more work to only 
>> try with services from DS components.
>> 
>> For these two, I'm wondering if they would be useful enough to propose for 
>> the DS 1.3 spec.
>> 
>> 3. (re-proposal)  I'd like to propose moving the implementation to java 5 
>> again with generics etc.  The last time I suggested this there was a lot of 
>> pushback on the grounds that there are a lot of people using DS on limited 
>> platforms.  However, none of these alleged :-) people is using trunk, 
>> because for several months the classes pulled from the concurrent library 
>> were wrong and trunk just didn't run on pre-java-5 vms.  Are the compendium 
>> 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>> 
>> 4.  (radical idea I haven't tried yet)  I'm becoming increasingly convinced 
>> that the state objects in AbstractComponentManager mostly cause confusion 
>> and make the code more complicated and less reliable.  The spec really only 
>> describes two states, enabled and disabled.  The variations on enabled -- 
>> whether the component has all its dependencies satisfied, whether the 
>> service is registered, whether there are any implementation objects created 
>> -- all seem somewhat orthogonal and depend very much on the environment  and 
>> don't seem to relate well to a single "dimension" of state.  I'm considering 
>> trying to refactor the code that responds to outside actions 
>> (activate/deactivate and dependencies appearing/disappearing) to be more 
>> "straight-through" with checks on the specific aspects of state that they 
>> need.  Possibly we would want to put the "dynamic state" such as 
>> dependencies + instances in a single state object, but this is a different 
>> approach to the current state objects which have no internal state.
>> 
>> 
>> thanks
>> david jencks
>> 
>> 
>> 
> 

Re: [DS] Feedback wanted on some ideas

[Andrei Pozolotin]

 Original Message 
Subject: [DS] Feedback wanted on some ideas
From: David Jencks 
To: dev@felix.apache.org
Date: Wed 03 Oct 2012 12:28:49 PM CDT
> 4.  (radical idea I haven't tried yet)  I'm becoming increasingly convinced 
> that the state objects in AbstractComponentManager mostly cause confusion and 
> make the code more complicated and less reliable.  The spec really only 
> describes two states, enabled and disabled.  The variations on enabled -- 
> whether the component has all its dependencies satisfied, whether the service 
> is registered, whether there are any implementation objects created -- all 
> seem somewhat orthogonal and depend very much on the environment  and don't 
> seem to relate well to a single "dimension" of state.  I'm considering trying 
> to refactor the code that responds to outside actions (activate/deactivate 
> and dependencies appearing/disappearing) to be more "straight-through" with 
> checks on the specific aspects of state that they need.  Possibly we would 
> want to put the "dynamic state" such as dependencies + instances in a single 
> state object, but this is a different approach to the current state objects 
> which have no internal state.
>
yes, as a dumb user :-) I have hard time understanding both old and new
state transitions.
would it be possible to produce proposed scr state diagram in a form
similar to this:

http://devangelist.blogspot.com/2011/04/osgi-bundle-lifecycles.html

Re: [DS] Feedback wanted on some ideas

[Andrei Pozolotin]

great ideas; one more for your consideration
http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)

"""

public void *enableComponent*(java.lang.String name)

Enables the specified component name. The specified component name
must be in the same bundle as this component.

"""

instead, I suggest to permit traversal of bundle boundaries, so
enable/disable target can be anywhere.

 Original Message 
Subject: [DS] Feedback wanted on some ideas
From: David Jencks 
To: dev@felix.apache.org
Date: Wed 03 Oct 2012 12:28:49 PM CDT
> I've had several ideas about DS enhancements, some of which I've implemented, 
> and would like some feedback about how desirable they are before committing 
> or proceeding with them.
>
> 1.  (FELIX-3692)  If you manually enable/disable components some of the work 
> gets done asynchronously.  I propose an api for finding out whether this work 
> is done or waiting for it, something like
>
>boolean tasksCompleted();
>
>void waitForTasksCompleted();
>
>
> on ScrService.   (suggestions for better names welcome :-)  One use would be 
> in our tests to replace the delay() call.
>
> 2.  (FELIX-3557) There are several circumstances in which, as the spec warns, 
> you can't establish a circular dependency between components.  In some of 
> these cases, the order in which the components are activated determines 
> whether all the references are established.  This is hard to understand from 
> a users point of view :-).  Sometimes it's possible to detect these 
> situations and establish the reference asynchronously.  The patch attached to 
> the issue does this but needs a little more work to only try with services 
> from DS components.
>
> For these two, I'm wondering if they would be useful enough to propose for 
> the DS 1.3 spec.
>
> 3. (re-proposal)  I'd like to propose moving the implementation to java 5 
> again with generics etc.  The last time I suggested this there was a lot of 
> pushback on the grounds that there are a lot of people using DS on limited 
> platforms.  However, none of these alleged :-) people is using trunk, because 
> for several months the classes pulled from the concurrent library were wrong 
> and trunk just didn't run on pre-java-5 vms.  Are the compendium 4.3 spec 
> classes we pull in even compatible with pre-java-5 vms?
>
> 4.  (radical idea I haven't tried yet)  I'm becoming increasingly convinced 
> that the state objects in AbstractComponentManager mostly cause confusion and 
> make the code more complicated and less reliable.  The spec really only 
> describes two states, enabled and disabled.  The variations on enabled -- 
> whether the component has all its dependencies satisfied, whether the service 
> is registered, whether there are any implementation objects created -- all 
> seem somewhat orthogonal and depend very much on the environment  and don't 
> seem to relate well to a single "dimension" of state.  I'm considering trying 
> to refactor the code that responds to outside actions (activate/deactivate 
> and dependencies appearing/disappearing) to be more "straight-through" with 
> checks on the specific aspects of state that they need.  Possibly we would 
> want to put the "dynamic state" such as dependencies + instances in a single 
> state object, but this is a different approach to the current state objects 
> which have no internal state.
>
>
> thanks
> david jencks
>
>
>

[DS] Feedback wanted on some ideas

[David Jencks]

I've had several ideas about DS enhancements, some of which I've implemented, 
and would like some feedback about how desirable they are before committing or 
proceeding with them.

1.  (FELIX-3692)  If you manually enable/disable components some of the work 
gets done asynchronously.  I propose an api for finding out whether this work 
is done or waiting for it, something like

   boolean tasksCompleted();

   void waitForTasksCompleted();


on ScrService.   (suggestions for better names welcome :-)  One use would be in 
our tests to replace the delay() call.

2.  (FELIX-3557) There are several circumstances in which, as the spec warns, 
you can't establish a circular dependency between components.  In some of these 
cases, the order in which the components are activated determines whether all 
the references are established.  This is hard to understand from a users point 
of view :-).  Sometimes it's possible to detect these situations and establish 
the reference asynchronously.  The patch attached to the issue does this but 
needs a little more work to only try with services from DS components.

For these two, I'm wondering if they would be useful enough to propose for the 
DS 1.3 spec.

3. (re-proposal)  I'd like to propose moving the implementation to java 5 again 
with generics etc.  The last time I suggested this there was a lot of pushback 
on the grounds that there are a lot of people using DS on limited platforms.  
However, none of these alleged :-) people is using trunk, because for several 
months the classes pulled from the concurrent library were wrong and trunk just 
didn't run on pre-java-5 vms.  Are the compendium 4.3 spec classes we pull in 
even compatible with pre-java-5 vms?

4.  (radical idea I haven't tried yet)  I'm becoming increasingly convinced 
that the state objects in AbstractComponentManager mostly cause confusion and 
make the code more complicated and less reliable.  The spec really only 
describes two states, enabled and disabled.  The variations on enabled -- 
whether the component has all its dependencies satisfied, whether the service 
is registered, whether there are any implementation objects created -- all seem 
somewhat orthogonal and depend very much on the environment  and don't seem to 
relate well to a single "dimension" of state.  I'm considering trying to 
refactor the code that responds to outside actions (activate/deactivate and 
dependencies appearing/disappearing) to be more "straight-through" with checks 
on the specific aspects of state that they need.  Possibly we would want to put 
the "dynamic state" such as dependencies + instances in a single state object, 
but this is a different approach to the current state objects which have no 
internal state.


thanks
david jencks

[jira] [Commented] (FELIX-3680) Exceptions in SCR using concurrent service activation/deactivation

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468576#comment-13468576
 ] 

Pierre De Rop commented on FELIX-3680:
--

in revision r1393476, the latches are now called from activate/deactivate 
methods from B/C/D/E/F/G/H/I/J/K.

This makes sure that the latches are incremented or decremented from the 
component actor thread, where async enable/disable tasks are executed.

Now, it's better: I successfully ran 93 times the loop in the Main.run method.

But then after the test 94,  I'm getting null returned by getService(sr) from 
the Main.bindA() method, 
or sometimes, A is never injected to Main.









> Exceptions in SCR using concurrent service activation/deactivation
> --
>
> Key: FELIX-3680
> URL: https://issues.apache.org/jira/browse/FELIX-3680
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: linux fc16, jdk1.6.032
>Reporter: Pierre De Rop
> Attachments: logs_with_could_not_get_service_from_ref.txt.gz, 
> test.scr.tgz, test_with_fwk.tgz
>
>
> This issue contains a sample code which reproduces many various exceptions, 
> using a concurrent
> scenario, where some services are enabled/disabled concurrently.
> I did not have time to commit an integration test about these exceptions but 
> I will try to do.
> In the meantime, I join to this issue my scenario ... 
> Before trying to make an integration test, could you please run the scenario, 
> in order to confirm the problems, and that the scenario is valid ?
> To execute the scenario
> 1) first, since the framework is not currently using any available log 
> service, you have to make a modification in the framework, in order to force 
> the framework to use a log service, when displaying caught exceptions. If you 
> don't do this, then you will get many exceptions thrown by many threads and 
> displayed in the console; and this is then not easy to diagnose problems.
> So, in the framework, in the file 
> src/main/java/org/apache/felix/framework/Logger.java, in method 
> setBundleContext, just uncomment the following code, which activate the fwk 
> log service listener:
> protected void setSystemBundleContext(BundleContext context)
> {
> // TODO: Find a way to log to a log service inside the framework.
> // The issue is that we log messages while holding framework
> // internal locks -- hence, when a log service calls back into 
> // the framework (e.g., by loading a class) we might deadlock. 
> // One instance of this problem is tracked in FELIX-536.
> // For now we just disable logging to log services inside the
> // framework. 
> m_context = context;
> startListeningForLogService();
> }
> -> this will make sure all logs caught by the framework are redirected to the 
> log service, and I did not find any deadlock issue, as described in the 
> comments.
> Notice that even if you don't activate the log service listener, then the 
> Exceptions are also taking place ...
> 2) next, compile the attached concurrent scenario (it's a simple maven 
> project).
> 3) run the framework with the following bundles:
> org.apache.felix.scr from trunk
> org.apache.felix.configadmin-1.4.0.jar
> 4) wait for about 20 seconds, then suspend the framework, and kill it (using 
> kill -9)
> Don't do "Ctrl-C", because this might interrupt some locked threads and some 
> exceptions might be generated because of the Ctlr-C ... So doing a "Kill -9" 
> is better.
> 5) Then take a look at the produced "./logs.txt" file.
> scenario description:
> ===
> here is a description of the Components used in the scenario:
> A: delayed component, enabled, depending on B,C,D,E,F
> B,C,D,E: delayed components, disabled, without any dependencies
> F: delayed component, disabled, depending on G
> G: delayed component, disabled, depending on H
> I: delayed component, disabled, depending on J
> J: delayed component, disabled, depending on K
> Main: depends on A. 
> "Main" is the main scenario component: it uses a thread pool in order to 
> enable B,C,D,E,F,G,H,I,J,K in parallel, randomly. 
> "Main" depends on A.
> When B,C,D,E,F,G,H,I,J,K are enabled, then A becomes satisfied, provided and 
> injected in the "Main" component.
> Once "A" is bound to "Main", then B,C,D,E,F,G,H,I,J,K are then disabled in 
> parallel, randomly. "Main" also checks that "A" is properly unbound.
> LogService logs are written to "./logs.txt".
> So, running the test using scr 1.6.0 runs seamlessly. But with trunk we have 
> many various exceptions.
> For example, I have noticed the three following exceptions:
> 1) we have some IllegalMontorStateException:
> =

[jira] [Closed] (FELIX-2637) Monitor Admin Service contribution

[Richard S. Hall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall closed FELIX-2637.
--

Resolution: Incomplete

At this point in time, it is not possible to secure the software grant, so this 
issue is closed.

> Monitor Admin Service contribution
> --
>
> Key: FELIX-2637
> URL: https://issues.apache.org/jira/browse/FELIX-2637
> Project: Felix
>  Issue Type: New Feature
>Reporter: Nick Wilson
>Priority: Minor
> Attachments: monitoradmin-1.0.2.zip, monitoradmin.zip
>
>
> Attached is the initial contribution of a Monitor Admin Service 
> implementation.
> The zip file contains 3 projects:
> uk.co.card.osgi.monitor - The main implementation project.
> uk.co.card.osgi.monitor.build   - The parent pom.
> uk.co.card.osgi.monitor.test - Pax-exam based integration tests.
> MD5: CF023CF49909B2E318D834073C0C4A97

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-3643) Use BuildContext for scanning changed files

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated FELIX-3643:
---

Attachment: FELIX-3643-incremental-build-2.txt

> Use BuildContext for scanning changed files
> ---
>
> Key: FELIX-3643
> URL: https://issues.apache.org/jira/browse/FELIX-3643
> Project: Felix
>  Issue Type: Sub-task
>  Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.8.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.8.2
>
> Attachments: FELIX-3643-incremental-build-2.txt, 
> FELIX-3643-incremental-build.txt
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3643) Use BuildContext for scanning changed files

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468469#comment-13468469
 ] 

Robert Munteanu commented on FELIX-3643:


The second patch removes some TODOs and enabled resource refresh in Eclipse. 
The previously commented out code worked for me.

With this patch the code works as expected but I've noticed two changes which 
are not properly handled.

# A component changes from metaType = true to metaType = false and the metatype 
descriptor is not deleted
# A java class is no longer a component ( e.g. @Component annotation removed ) 
but the metatype and component descriptors are not removed

However, I'm not sure if we can detect these changes at all, since we don't 
have the previous build state.

> Use BuildContext for scanning changed files
> ---
>
> Key: FELIX-3643
> URL: https://issues.apache.org/jira/browse/FELIX-3643
> Project: Felix
>  Issue Type: Sub-task
>  Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.8.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.8.2
>
> Attachments: FELIX-3643-incremental-build-2.txt, 
> FELIX-3643-incremental-build.txt
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-3680) Exceptions in SCR using concurrent service activation/deactivation

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468466#comment-13468466
 ] 

Pierre De Rop commented on FELIX-3680:
--

I have updated what I committed yesterday in order to use only static/required 
References in A.

Now I'm thinking about the following, and wonder if it is related to what you 
observed:

I realize that that when disabling components, then the disable task (that is: 
ComponentContext.disable method call) is done asynchronously (using the 
component actor thread).
Am I correct ? (I think you already explained this but I did not catch it ... 
sorry).

So, it is then possible that when the Main.unbind method is called, then the 
_disableLatch.countDown() is called while some disable tasks are not yet 
executed and still scheduled in the component actor thread. At this point, the 
Main.run method is then unblocked form the _disableLatch, and then try to 
re-enable components ... while the previous disable tasks are not yet executed 
by the component actor thread. However, since enable tasks are also scheduled 
in the component actor thread queue, then all pending disable tasks should be 
executed before the new enable tasks ...

I now start to understand why you asked me to try the (not yet committed) 
ScrService.waitForTasksCompleted.

So, did you try to use your ScrService.waitForTasksCompleted() method from the 
standalone version ?




> Exceptions in SCR using concurrent service activation/deactivation
> --
>
> Key: FELIX-3680
> URL: https://issues.apache.org/jira/browse/FELIX-3680
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: linux fc16, jdk1.6.032
>Reporter: Pierre De Rop
> Attachments: logs_with_could_not_get_service_from_ref.txt.gz, 
> test.scr.tgz, test_with_fwk.tgz
>
>
> This issue contains a sample code which reproduces many various exceptions, 
> using a concurrent
> scenario, where some services are enabled/disabled concurrently.
> I did not have time to commit an integration test about these exceptions but 
> I will try to do.
> In the meantime, I join to this issue my scenario ... 
> Before trying to make an integration test, could you please run the scenario, 
> in order to confirm the problems, and that the scenario is valid ?
> To execute the scenario
> 1) first, since the framework is not currently using any available log 
> service, you have to make a modification in the framework, in order to force 
> the framework to use a log service, when displaying caught exceptions. If you 
> don't do this, then you will get many exceptions thrown by many threads and 
> displayed in the console; and this is then not easy to diagnose problems.
> So, in the framework, in the file 
> src/main/java/org/apache/felix/framework/Logger.java, in method 
> setBundleContext, just uncomment the following code, which activate the fwk 
> log service listener:
> protected void setSystemBundleContext(BundleContext context)
> {
> // TODO: Find a way to log to a log service inside the framework.
> // The issue is that we log messages while holding framework
> // internal locks -- hence, when a log service calls back into 
> // the framework (e.g., by loading a class) we might deadlock. 
> // One instance of this problem is tracked in FELIX-536.
> // For now we just disable logging to log services inside the
> // framework. 
> m_context = context;
> startListeningForLogService();
> }
> -> this will make sure all logs caught by the framework are redirected to the 
> log service, and I did not find any deadlock issue, as described in the 
> comments.
> Notice that even if you don't activate the log service listener, then the 
> Exceptions are also taking place ...
> 2) next, compile the attached concurrent scenario (it's a simple maven 
> project).
> 3) run the framework with the following bundles:
> org.apache.felix.scr from trunk
> org.apache.felix.configadmin-1.4.0.jar
> 4) wait for about 20 seconds, then suspend the framework, and kill it (using 
> kill -9)
> Don't do "Ctrl-C", because this might interrupt some locked threads and some 
> exceptions might be generated because of the Ctlr-C ... So doing a "Kill -9" 
> is better.
> 5) Then take a look at the produced "./logs.txt" file.
> scenario description:
> ===
> here is a description of the Components used in the scenario:
> A: delayed component, enabled, depending on B,C,D,E,F
> B,C,D,E: delayed components, disabled, without any dependencies
> F: delayed component, disabled, depending on G
> G: delayed component, disabled, depending on H
> I: delayed component, disabled, depending on J
> J: delayed component, 

[jira] [Created] (FELIX-3699) Allow annotations to handle custom component definitions.

[Issac Garcia (JIRA)]

Issac Garcia created FELIX-3699:
---

 Summary: Allow annotations to handle custom component definitions.
 Key: FELIX-3699
 URL: https://issues.apache.org/jira/browse/FELIX-3699
 Project: Felix
  Issue Type: New Feature
  Components: iPOJO
Reporter: Issac Garcia


Custom components are well handled in iPOJO using the metadata.xml, for example:





The custom component definition will, for example, add handlers and so on. It 
works very well and is nice that iPOJO allows that kind of extensions. 

But we can't declare a custom component by using annotations, for example doing:

@CustomComponent
public class MyClass {...}

It will be a nice if iPOJO allows to do it using annotations, since the same 
functionality must be possible with the metadata.mxl and with annotations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira