3 Replies Latest reply: Apr 24, 2012 6:48 PM by Keith Babo RSS

BPM Service with SOAP reference

jmorr003 Newbie

With SwitchYard 0.4.0 I tried adding a SOAP reference to the bean-service quickstart, into the bpm-service quickstart. Both quickstarts are deployed to the Switchyard JBoss AS7 instance. When making a SOAP call to kick off the bpm process (ProcessOrder), I get the following error:


21:43:51,047 ERROR [stderr] (pool-12-thread-6) Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.switchyard.common.type.CompoundClassLoader@1446af8. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           at org.jboss.weld.Container.instance(Container.java:54)

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:67)

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:104)

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           at org.jboss.weld.proxies.OrderService$1366014918$Proxy$_$$_WeldClientProxy.submitOrder(OrderService$1366014918$Proxy$_$$_WeldClientProxy.java)

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           at org.switchyard.quickstarts.bpm.service.InventoryBean.checkAvailability(InventoryBean.java:35)

21:43:51,047 ERROR [stderr] (pool-12-thread-6)           ... 66 more


In the bpm-service quickstart, the call to the bean-service quickstart OrderService is made in the InventoryBean class. For example:


public class InventoryBean implements
                    org.switchyard.quickstarts.bpm.service.Inventory {
private OrderService orderService;
public boolean checkAvailability(Order order) {
if (orderService != null) {
                              org.switchyard.quickstarts.bean.service.Order newOrder = new org.switchyard.quickstarts.bean.service.Order();


return inventory.containsKey(order.getItemId().toLowerCase())
                                        && inventory.get(order.getItemId().toLowerCase()) >= order

and in the switchyard.xml the following was added (nothing else changed):


        <reference name="OrderService" promote="Inventory/OrderService" multiplicity="1..1">
            <interface.wsdl interface=""/>
            <binding.soap xmlns="urn:switchyard-component-soap:config:1.0">

If the call is made directly to the InventoryBean (not part of the bpm binding), again using SOAP, the call from InventoryBean to the OrderService of the bean-service quickstart works. This requires a few changes to expose the InventoryBean.


I don't think this was an issue with version 0.3.0. Any ideas?

  • 1. Re: BPM Service with SOAP reference
    Keith Babo Master

    Hmm ... my guess is there's a CDI service proxy that's getting overwritten between the two apps.   Could be a bug, could be configuration error.  I should say the configuration error would probably be considered a bug anyway, since we should catch duplicate reference registrations and report that during deployment.  I could probably recreate this based on the information you've provided, but it would be better if you could just attach the two projects exactly as they are now to make sure I'm comparing apples and apples.




  • 2. Re: BPM Service with SOAP reference
    jmorr003 Newbie

    Here they are, the bean and bpm service.

  • 3. Re: BPM Service with SOAP reference
    Keith Babo Master

    Looks like the pom.xml for bpm-service is creating a dependency on the bean-service app. I suspect the @Inject of OrderService in Inventory is resolving the actual bean from bean-service instead of creating a proxy.  If you want to share Java classes between deployments, particularly if they are service interfaces, I would recommend creating a separate deployable and adding a dependency to that from all the applications that use it.  An example of this can be found here:




    The order-service, order-consumer, and web projects all declare a deployment dependency on the artifacts module.