I'd rather keep this vote open as it seems like to be a corner case which can be addressed with a 4.0.3 which we can shortly after the aries bug in JPA is fixed.
regards, Achim 2015-10-11 21:10 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > By the way, I upgraded to new Blueprint release for 4.0.2 (as it fixed > couple of "important" issues). I will take a look and a diff between the > two versions. > > Regards > JB > > On 10/11/2015 08:18 PM, Christian Schneider wrote: > >> I think that I found the problem. >> >> When the blueprint context is created the future for the timeout of >> dependencies is canceled. >> >> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L379 >> >> >> In Aries JPA I use a ComponentDefinitionRegistryProcessor to scan for >> the @PersistenceContext annoations and register a service reference for >> these. I think that this triggers >> the future for the timeout of such dependencies again. If this processor >> is called after the future is canceled above then the future will not be >> canceled anymore. So after the timeout (5min) it will >> trigger and stop the blueprintcontainer even if all dependencies are >> satisfied now. >> >> This is the code that is executed after the timeout: >> >> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L341 >> >> >> It matches the exception and explains why there are no unresolved >> dependencies. >> >> I would be happy about feedback from anyone with deeper blueprint >> knowledge. Is what I do there in Aries JPA incorrect? If yes then we >> need a new Aries JPA release .. though I am not sure how to better >> address the problem. >> If it is correct then we need to fix this in blueprint core. >> A simple fix/workaround would be to check if there are no unresolved >> dependencies when the future times out and not stop the container in >> this case. A better fix would cancel the future as soon as all >> dependencies are fulfilled. >> >> In any case I propose we cancel the release and try to include a fix in >> karaf 4.0.2. So I revert my vote to >> >> -1 (non binding) >> >> Christian >> >> On 11.10.2015 19:24, Christian Schneider wrote: >> >>> I just did some more testing and found a problem. >>> >>> When I run my tasklist-blueprint-cdi example it works fine at the >>> start but after some time I see this exception: >>> 2015-10-11 19:08:43,371 | ERROR | rint Extender: 2 | >>> BlueprintContainerImpl | 12 - >>> org.apache.aries.blueprint.core - 1.4.4 | Unable to start blueprint >>> container for bundle >>> net.lr.tasklist.cdi.tasklist-persistence/1.0.0.SNAPSHOT due to >>> unresolved dependencies [] >>> java.util.concurrent.TimeoutException >>> at >>> >>> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336)[12:org.apache.aries.blueprint.core:1.4.4] >>> >>> at >>> >>> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.4] >>> >>> at >>> >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60] >>> >>> at >>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] >>> at >>> >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60] >>> >>> at >>> >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60] >>> >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] >>> >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] >>> >>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] >>> >>> After this the tasklist-persistence bundle does not work anymore. If >>> this does not only happen with my example then it would be a pretty >>> critical bug. >>> >>> I am not yet sure what the reason is but I will dig some more. I think >>> the problem could be either in blueprint core or in blueprint jpa. >>> >>> If you want to test yourself you should use the branch jpa-2.1.0 (old >>> name ... it uses jpa 2.2.0 now). >>> >>> https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-blueprint-cdi >>> >>> >>> >>> Christian >>> >>> >>> On 11.10.2015 16:53, Christian Schneider wrote: >>> >>>> +1 (non binding) >>>> >>>> Tested my blueprint and DS examples (jpa,transaction, hibernate, >>>> cxf, jaxrs-connector) >>>> >>>> Looks all good. >>>> >>>> Christian >>>> >>> >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
