There is a deadlock in (Abstract)BusFactory (& SpringBusFactory) when attempting to load in the same FraSCAti instance both composites of HttpProxy and SmartTravel (Galaxy) demo.
What happens is that HttpProxyImpl's binding.http asks CXF for getDefaultBus() and gets a lock on it but also on the threadBusses var, while Trip's binding.ws also asks CXF for a bus which actually gets built all the way by Spring but only to be unable to be set because of the threadBusses lock, see BusFactory.java ...
So we've made this ugly hack that merely removes one "synchronized" : EasySOABusFactory.java
Report by mdutoo
There is a deadlock in (Abstract)BusFactory (& SpringBusFactory) when attempting to load in the same FraSCAti instance both composites of HttpProxy and SmartTravel (Galaxy) demo.
What happens is that HttpProxyImpl's binding.http asks CXF for getDefaultBus() and gets a lock on it but also on the threadBusses var, while Trip's binding.ws also asks CXF for a bus which actually gets built all the way by Spring but only to be unable to be set because of the threadBusses lock, see BusFactory.java ...
So we've made this ugly hack that merely removes one "synchronized" : EasySOABusFactory.java
The deadlock can be tested in FraSCAtiCompositeDemoTestStarter.setUp() by removing the following line :
A better solution involves working with FraSCAti (and / or CXF) guys to improve the bus init cycle & put it in their repos.
Update by jguillemotte:
Reported in FraSCAti Jira at http://jira.ow2.org/browse/FRASCATI-58
Update by philippemerle:
I have tried this issue on my MacOS with Java 1.6. Commenting this line setting the Apache CXF bus factory does not imply a deadlock.
Perhaps this is a phenoma specific to a certain OS.