Hi, Am 05.09.2012 um 17:06 schrieb David Jencks:
> As noted in the issue i can't find where the DS 1.0 or 1.2 spec describes > this behavior. It looks to me like the specs say if a bind method is > specified but missing, you just don't call it. (after logging that it's > missing). Hmm, yeah. I want to prove you wrong but instead proved myself wrong: This is what the spec says: > If no suitable method is located, SCR must log an error message with the Log > Service, if present, and there will be no bind, updated, or unbind > notification. This has been added in DS 1.1 obviously to clarify. But then it looks like the CT has wrong expectation. I think I go ask the experts before rushing ;-) Regards Felix > > Anyway I'll look into restoring the behavior.... > > thanks > david jencks > > On Sep 5, 2012, at 3:28 PM, Felix Meschberger wrote: > >> Hi >> >> Thanks alot. This looks great. >> >> Unfortunately your refactoring of binding services broke existing >> functionality: If a bind method cannot be called a component must not be >> activated (at least if it involves required services). See my comment in the >> issue. >> >> Regards >> Felix >> >> Am 05.09.2012 um 16:20 schrieb David Jencks (JIRA): >> >>> >>> [ >>> https://issues.apache.org/jira/browse/FELIX-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449194#comment-13449194 >>> ] >>> >>> David Jencks commented on FELIX-3645: >>> ------------------------------------- >>> >>> I made a lot of changes and think I have this problem solved. >>> >>> I think your integration test can produce some expected errors and warnings >>> as services disappear between the time we think a component is satisfied >>> and when we actually get the service from the service reference. Felix >>> logs an error in this case, and we do some logging too. So I modified the >>> test to ignore the "expected" errors due to this. >>> >>> I also moved the very useful logging code into the base itest so I could >>> use it for all the other problems I was having :-) >>> >>> The current state of the code is that we release all locks (including read >>> locks) when registering the service and when collecting dependencies for a >>> component instance. Then we take a write lock to actually create the >>> component instance using these collected dependencies. >>> >>> I'm storing the collected dependencies in a map in >>> AbstractComponentManager. This now holds most of the state for the >>> dependency managers. I think we could move the rest of the state into this >>> map and make the bind/unbind/updated methods even more permanent and share >>> the dependency managers between ImmediateComponentManagers for different >>> configurations for the same Component. >>> >>>> SCR could not obtain lock in 5000 ms >>>> ------------------------------------ >>>> >>>> Key: FELIX-3645 >>>> URL: https://issues.apache.org/jira/browse/FELIX-3645 >>>> Project: Felix >>>> Issue Type: Bug >>>> Components: Declarative Services (SCR) >>>> Environment: linux fc16, bipro, Java(TM) SE Runtime Environment >>>> (build 1.6.0_32-b05) >>>> Reporter: Pierre De Rop >>>> Assignee: David Jencks >>>> Attachments: >>>> TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml >>>> >>>> >>>> I finally made an integration test and committed it in the trunk. >>>> This test sounds to reproduce the problem described in >>>> http://www.mail-archive.com/[email protected]/msg26360.html. >>>> the test contains the following files: >>>> src/test/resources/integration_test_component_concurrency.xml >>>> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java >>>> src/test/java/org/apache/felix/scr/integration/components/concurrency/A.java >>>> src/test/java/org/apache/felix/scr/integration/components/concurrency/B.java >>>> src/test/java/org/apache/felix/scr/integration/components/concurrency/C.java >>>> src/test/java/org/apache/felix/scr/integration/components/concurrency/AFactory.java >>>> src/test/java/org/apache/felix/scr/integration/components/concurrency/CFactory.java >>>> I also slightly modified >>>> src/test/java/org/apache/felix/scr/integration/ComponentTestBase.java >>>> in order to use the apache log service, and also to declare the new >>>> package from org/apache/felix/scr/integration/components/concurrency. >>>> The test does the following: >>>> A optionally depends on B (dynamic=true, cardinality=0..N) >>>> B depends on C >>>> A is a factory component and is created by the AFactory class, in an >>>> infinite loop and in a dedicated thread. >>>> C is also a factory component and is created/disposed for ever, by the >>>> CFactory class. >>>> the integration test uses the log service in order to track logged errors, >>>> and runs 30 seconds. >>>> If after 30 seconds, some errors are detected, then the test fail. >>>> It seems that we have many exceptions when the test fail, which I did not >>>> reproduced so far. (see many IllegalMonitorState Exceptions). >>>> The initial exception discussed from the post in the @dev list is also >>>> reproduced. >>>> For example, I attached to this post my >>>> target/failsafe-reports/TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml, >>>> when the problem takes place. >>>> Please take a look starting at line 951, as well as at the corresponding >>>> dumpstack at line 713, and also the "Locking activity before >>>> IllegalMonitorStateException" log, line 887. >>>> Hope this will help. >>>> /pierre >>> >>> -- >>> 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 >> >
