Hi, Am 05.09.2012 um 17:33 schrieb David Jencks:
> I think I restored the previous behavior, but the more i think about it the > less I like it. CT passes. > > It only obstructs activation for required dependencies. I think that if > we're going to prevent activation due to a missing bind method, it shouldn't > matter whether the dependency is optional. In either case the component > isn't getting info it expects. And in all cases the component can get the > dependency using the lookup strategy. The longer I think of it the more I agree. At the end of the day it is fortunately an edge case, happening due to misconfiguration on one (code) or the other (declaration) level. > > we'll see what happens with arguing with the experts ;-) Right. Regards Felix > > thanks! > david jencks > > On Sep 5, 2012, at 4:17 PM, Felix Meschberger wrote: > >> 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 >>>> >>> >> >
