SwitchYard BPEL to Bean Service routing question| JBoss.org Content Archive (Read Only)

15. Re: SwitchYard BPEL to Bean Service routing question

adamdva Feb 6, 2013 9:20 PM (in response to kcbabo)

Thank you for your attention.

You're correct, the loanService invoke was a leftover from the test project I'm trying.

I commented it out on my local copy and built/deployed, then tested, but still got the same issue.

However, next I deployed on a clean SwitchYard/JBoss installation and then it worked.

Besides having the test project redeployed many times, the only other difference is that I have PicketLink installed on my original JBoss, and a secure-saml quickstart deployed.

So I don't know why it wasn't working on the original JBoss instance. It is stranger still, since I had an earlier version of the project with the logService which would work, but when I replaced it with the one I sent, it broke. They both work on the fresh instance.

Would the presence of PicketLink effect this project somehow, even if it wasn't being utilized by the project?

I'm a little converned that I'm getting different results between the instances.

thanks again for your time looking into this.

Adam

16. Re: SwitchYard BPEL to Bean Service routing question

objectiser Feb 7, 2013 3:57 AM (in response to adamdva)

Hi Adam

These additional factors shouldn't have an impact. Could you setup a separate fresh switchyard environment, add picketlink and the secure-saml quickstart, and then deploy your testcase to confirm?

Regards

Gary

17. Re: SwitchYard BPEL to Bean Service routing question

kcbabo Feb 7, 2013 8:09 AM (in response to adamdva)

Only thing I can think of is that the deployment on the original instance got corrupted in some way and was preventing a clean deploy/undeploy.

18. Re: SwitchYard BPEL to Bean Service routing question

adamdva Feb 7, 2013 10:13 AM (in response to kcbabo)

The original issue that lead me down the path where I was stuck before was a simple assign of a value to a request element. (I assumed it would be simple)

Using the Designer I've added an assign and created a 'Fixed Value to Variable'. The Designer said the value was not initialized and asked to create one, which I accepted. This is strange because the variable is initialized when it's defined previously. It produced the following:

        <bpel:assign validate="no" name="AssignTest">
            <bpel:copy>
                <bpel:from><bpel:literal><tns:addLog xmlns:tns="urn:com.example.switchyard:ADR-ProtoType:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns:log>tns:log</tns:log>
</tns:addLog>
</bpel:literal></bpel:from>
                <bpel:to variable="loggingPartnerLinkRequest" part="sendLog"></bpel:to>
            </bpel:copy>
            <bpel:copy>
                <bpel:from>
                    <bpel:literal xml:space="preserve">Logging Test</bpel:literal>
                </bpel:from>
                <bpel:to part="sendLog" variable="loggingPartnerLinkRequest">
                    <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[log:log]]></bpel:query>
                </bpel:to>
            </bpel:copy>
        </bpel:assign>
        <bpel:assign validate="no" name="Assign TestRequest">

When I then build, deploy and execute my test SoupUI client, I get the following error:

09:57:30,283 INFO [org.apache.ode.utils.WatchDog] (http--127.0.0.1-8080-1) [End
point files for {DeploymentUnit bpel-service-ADR-Prototype_ADRSearch-0}] updated

09:57:30,320 ERROR [org.apache.ode.jacob.vpu.JacobVPU] (ODEServer-1) Method "run
" in class "org.apache.ode.bpel.runtime.ASSIGN" threw an unexpected exception.:
java.lang.NullPointerException
        at org.apache.ode.bpel.runtime.AssignHelper.copy(AssignHelper.java:501)
[riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.runtime.ASSIGN.run(ASSIGN.java:88) [riftsaw-bpel-
runtime-3.0.0.20121217-M4.jar:]
        at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) [:1.6.0_
38]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25) [rt.jar:1.6.0_38]
        at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
        at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:4
51) [riftsaw-jacob-3.0.0.20121217-M4.jar:]
        at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) [riftsaw
-jacob-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntime
ContextImpl.java:1089) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(Pa
rtnerLinkMyRoleImpl.java:208) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess$1.invoke(BpelProcess.java:302)
[riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java
:255) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java
:298) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess.handleJobDetails(BpelProcess.j
ava:457) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineIm
pl.java:478) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineIm
pl.java:417) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerIm
pl.java:455) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable$1.call
(SimpleScheduler.java:576) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable$1.call
(SimpleScheduler.java:566) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(Simpl
eScheduler.java:294) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(Simpl
eScheduler.java:251) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable.proces
sInTransactionContext(SimpleScheduler.java:566) [riftsaw-scheduler-simple-3.0.0.
20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable.call(S
impleScheduler.java:546) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable.call(S
impleScheduler.java:533) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [r
t.jar:1.6.0_38]
        at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.
0_38]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:886) [rt.jar:1.6.0_38]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:908) [rt.jar:1.6.0_38]
        at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]

09:57:30,360 ERROR [org.apache.ode.bpel.engine.BpelEngineImpl] (ODEServer-1) Sch
eduled job failed; jobDetail=JobDetails( instanceId: null mexId: hqejbhcnphr815i
9n6gf3w processId: {http://www.nga.gov/afa/adr/services/search}ADRSearch-0 type:
INVOKE_INTERNAL channel: null correlatorId: null correlationKeySet: null retryC
ount: null inMem: false detailsExt: {}): java.lang.RuntimeException: java.lang.N
ullPointerException
        at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:4
64) [riftsaw-jacob-3.0.0.20121217-M4.jar:]
        at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139) [riftsaw
-jacob-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntime
ContextImpl.java:1089) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.invokeNewInstance(Pa
rtnerLinkMyRoleImpl.java:208) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess$1.invoke(BpelProcess.java:302)
[riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java
:255) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java
:298) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelProcess.handleJobDetails(BpelProcess.j
ava:457) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineIm
pl.java:478) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineIm
pl.java:417) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerIm
pl.java:455) [riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable$1.call
(SimpleScheduler.java:576) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable$1.call
(SimpleScheduler.java:566) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(Simpl
eScheduler.java:294) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(Simpl
eScheduler.java:251) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable.proces
sInTransactionContext(SimpleScheduler.java:566) [riftsaw-scheduler-simple-3.0.0.
20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable.call(S
impleScheduler.java:546) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at org.apache.ode.scheduler.simple.SimpleScheduler$RunJobCallable.call(S
impleScheduler.java:533) [riftsaw-scheduler-simple-3.0.0.20121217-M4.jar:]
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [r
t.jar:1.6.0_38]
        at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.
0_38]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:886) [rt.jar:1.6.0_38]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:908) [rt.jar:1.6.0_38]
        at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
Caused by: java.lang.NullPointerException
        at org.apache.ode.bpel.runtime.AssignHelper.copy(AssignHelper.java:501)
[riftsaw-bpel-runtime-3.0.0.20121217-M4.jar:]
        at org.apache.ode.bpel.runtime.ASSIGN.run(ASSIGN.java:88) [riftsaw-bpel-
runtime-3.0.0.20121217-M4.jar:]
        at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) [:1.6.0_
38]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25) [rt.jar:1.6.0_38]
        at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
        at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:4
51) [riftsaw-jacob-3.0.0.20121217-M4.jar:]
        ... 22 more

Which hangs the request and it eventually times out.

Can you suggest what the tool is doing wrong in generating this assign?

Can you suggest a better way to debug this development process? Getting undefined Null Pointer Exceptions makes progress extremely diffecult using this system.

thanks again for all your assistence,

Adam

19. Re: SwitchYard BPEL to Bean Service routing question

objectiser Feb 7, 2013 10:32 AM (in response to adamdva)

Hi Adam

I think more static validation in the Eclipse BPEL tool may help, if the problem is what I think it is. If so, you might want to raise a feature request on that project submitting your example.

But first lets test my assumption..... the null pointer exception relates to the assign, and it looks like the second copy part is attempting to copy the value to an element log:log. However the initialised message uses tns:log as the element.

Are both prefixes tns and log defined, and have the same value?

Regards

Gary

20. Re: SwitchYard BPEL to Bean Service routing question

kcbabo Feb 7, 2013 10:37 AM (in response to adamdva)

The BPEL editor and runtime come from the Riftsaw project, which are then integrated into SY. If there's an issue with the editor, then Gary can probably point to the right place to raise an issue. With that said, we do want to make people as productive as possible with BPEL in SwitchYard, so if there are additional things we can do in our integration then we're all ears.

One thing I can think of which might help tighten the debug cycle for you is to use our unit test framework to submit XML payloads directly to the BPEL service instead of having to go through the entire code, build, deploy, test with soapUI lifecycle. A number of our quickstarts have examples of using this capability. I looked just now and noticed that the BPEL quickstarts do not do this; there is a unit test for submitting the request message via SOAP/HTTP, but not a direct invocation of the service implementation with the XML payload. It's simple enough to add an example if you feel it would be helpful.

21. Re: SwitchYard BPEL to Bean Service routing question

rcernich Feb 7, 2013 10:53 AM (in response to kcbabo)

I went through the pain of this yesterday. You can find a project which uses simple tests here: https://community.jboss.org/message/796433#796433

That said, the project itself is a prototype for some future work on SwitchYard, but the LoanServiceTest.java should be just fine.

22. Re: SwitchYard BPEL to Bean Service routing question

adamdva Feb 7, 2013 11:10 AM (in response to objectiser)

Gary,

I did not notice the different NS uses, they were both defined, but with different values.
I changed the NS used in the assign to 'log' which is also defined and ensured it was consistent in the assign, I still get the same error.

I also commented out the second copy in the assign, to further restrict the issue, and still get the same error.

Keith,

The unit test framework for BPEL sounds like it would help greatly. Our current process is very inefficient, and along with the issues we're having is making us reconsider using the system.

Rob,

Thanks for the link, I will check it out.

thanks again,

Adam

23. Re: SwitchYard BPEL to Bean Service routing question

objectiser Feb 7, 2013 11:24 AM (in response to adamdva)

Hi Adam

If you could attach your latest project, I'll have a look.

Regards

Gary

24. Re: SwitchYard BPEL to Bean Service routing question

rcernich Feb 7, 2013 11:37 AM (in response to objectiser)

Hey Adam,

One other thing, make sure you copy the bpel.properties file into your src/test/resources folder. If you're seeing errors about not being able to resolve TransactionManager, you're missing this file.

It makes the turnaround much faster for debugging your process logic.

Good luck!

Rob

25. Re: SwitchYard BPEL to Bean Service routing question

adamdva Feb 7, 2013 11:57 AM (in response to objectiser)

Gary,

I've uploaded the latest project to https://issues.jboss.org/browse/SWITCHYARD-1298

The only things changed are the deletion of the leftover invoke and the addition of the assign.

thanks,

Adam

26. Re: SwitchYard BPEL to Bean Service routing question

objectiser Feb 7, 2013 12:25 PM (in response to adamdva)

Hi Adam

I just ran the example as is, and it worked fine on 0.7.0.Final. I then looked at the bpel and saw a commented out assign, so thought that may be the problem area, so uncommented it - but it also worked fine. The output I got on the console was:

{noformat}

17:19:01,168 INFO [org.switchyard.handlers.MessageTrace] (http--127.0.0.1-8080-1)

------- Begin Message Trace -------

Service -> {urn:com.example.switchyard:ADR-ProtoType:1.0}LoggingServicePT

Operation -> sendLog

Phase -> IN

State -> OK

Exchange Context ->

Message Context ->

org.switchyard.contentType : {urn:com.example.switchyard:ADR-ProtoType:1.0}addLog

org.switchyard.messageId : fa05dcbc-f140-4138-82d7-b76edd35a573

org.switchyard.soap.messageName : loggingService_addLog

Message Content ->

<?xml version="1.0" encoding="UTF-8"?><urn:addLog xmlns:urn="urn:com.example.switchyard:ADR-ProtoType:1.0">

<urn:log>hello</urn:log>

</urn:addLog>

------ End Message Trace -------

17:19:01,174 INFO [stdout] (http--127.0.0.1-8080-1) *** transformAddLogToString

17:19:01,175 INFO [stdout] (http--127.0.0.1-8080-1) WARNING: Element had more than 1 node [5]

17:19:01,177 INFO [stdout] (http--127.0.0.1-8080-1) ##### Log Start: Feb 7, 2013 5:19:01 PM

17:19:01,177 INFO [stdout] (http--127.0.0.1-8080-1)

17:19:01,178 INFO [stdout] (http--127.0.0.1-8080-1) ##### End

17:19:01,179 INFO [org.switchyard.handlers.MessageTrace] (http--127.0.0.1-8080-1)

------- Begin Message Trace -------

Service -> {urn:com.example.switchyard:ADR-ProtoType:1.0}LoggingServicePT

Operation -> sendLog

Phase -> OUT

State -> OK

Exchange Context ->

org.switchyard.exchange.transaction.beforeInvoked : true

org.switchyard.exchangeDurationMS : 19

Message Context ->

org.switchyard.relatesTo : fa05dcbc-f140-4138-82d7-b76edd35a573

org.switchyard.messageId : d8051c45-56a9-45ff-9c9b-5d305eaebe7a

org.switchyard.contentType : java:java.lang.String

Message Content ->

Log complete

------ End Message Trace -------

17:19:01,183 INFO [stdout] (http--127.0.0.1-8080-1) *** transformStringToAddLogResponse: Log complete

17:19:01,187 INFO [stdout] (http--127.0.0.1-8080-1) *** transformAddLogToString.toElement(): <tns:addLogResponse xmlns:tns="urn:com.example.switchyard:ADR-ProtoType:1.0"><tns:return>Log complete</tns:return></tns:addLogResponse>

17:19:01,199 INFO [stdout] (http--127.0.0.1-8080-1) *** transformAddLogToString.getNodeName(): tns:addLogResponse

17:19:01,200 INFO [stdout] (http--127.0.0.1-8080-1) *** transformAddLogToString.getFirstChild(): tns:return

17:19:01,200 INFO [stdout] (http--127.0.0.1-8080-1) *** transformAddLogToString.getTextContent(): Log complete

{noformat}

Just a thought - when you are testing a new version of the bpel process, do you build the switchyard app and then deploy it over the top of the previous version?

If so, then it could be a versioning issue - if the version of a bpel process is not changed, then it will not overwrite the existing version of the process that is being executed. If no version is specified, then it just has the default version of 0, which is what you process has. The version is defined in the file name, so ADRSearch-1.bpel and ADRSearch-2.bpel, to enable multiple versions to be deployed at the same time, where long running instances for an old version of the process definition still exists.

In a test environment however, this may give a false impression that changes made to an unversioned process definition are having no effect - just wondered if this explained the things you are seeing?

Regards

Gary

27. Re: SwitchYard BPEL to Bean Service routing question

kcbabo Feb 7, 2013 1:02 PM (in response to objectiser)

Here's an example of writing a unit test that hits the BPEL process service directly without SOAP:

https://github.com/kcbabo/quickstarts/commit/bb9273abc444dc81b48d5247cd3bf0817a1cb619

Keep in mind that you are just sending the contents of the SOAP:Body in these tests, which is the same thing that happens in a deployed instance once our SOAP gateway has peeled off the SOAP envelope.

Aside from making the test cycle much faster, it might alleviate some of the deployment issues you've been hitting with old versions of the app. Perhaps this might be related to Gary's comment above? In any case, I've filed a JIRA to add some of these tests to the BPEL quickstarts:

https://issues.jboss.org/browse/SWITCHYARD-1303

If you find it useful, let us know.

28. Re: SwitchYard BPEL to Bean Service routing question

adamdva Feb 7, 2013 1:17 PM (in response to objectiser)

Gary,

I have been just redeploying over the previous bpel process, so that might explain why my previous problem was resolved by installing on a fresh instance. I didn't see any documentation of the versioning configuration.

What would you suggest as the best strategy for handling the BPEL development, where I need to redeploy constantly?

I've deployed the project I've uploaded to a fresh 0.7.0.Final instance and am still getting the error I referenced before. I assue any cached BPEL processes are stored under the delpoyment, if that's not true, where should I look to remove the old versions?

Did you make any other chages to the bpel, because I did not log 'hello', but I'm just grasping at straws.

What OS and JRE are you testing on? Are you using the jboss-as-7.1.1.Final.zip directly, or deploying SY into an existing AS?

thanks,

Adam

29. Re: SwitchYard BPEL to Bean Service routing question

objectiser Feb 7, 2013 3:49 PM (in response to adamdva)

adamdva wrote:

I have been just redeploying over the previous bpel process, so that might explain why my previous problem was resolved by installing on a fresh instance. I didn't see any documentation of the versioning configuration.

https://docs.jboss.org/author/display/SWITCHYARD/BPEL+Services

The third section "Maintain Multiple Version of a BPEL Process" discusses how to version process definitions. It warns about not undeploying, as this removes active process instances - however it does not warn about the overwrite issue, so I need to update the docs to also warn about this.

adamdva wrote:

What would you suggest as the best strategy for handling the BPEL development, where I need to redeploy constantly?

I think the best approach is the one suggested by Keith and Rob. Rob posted an attachment on another thread (https://community.jboss.org/message/796433#796433) that provides an example of the switchyard test harness, and Keith has also referenced some examples. The other approach is the one currently used by the BPEL quickstarts, which launches a server for the tests and sends a SOAP request - so it is still better than having to manually deploy and restart a server.

adamdva wrote:

I've deployed the project I've uploaded to a fresh 0.7.0.Final instance and am still getting the error I referenced before. I assue any cached BPEL processes are stored under the delpoyment, if that's not true, where should I look to remove the old versions?
Did you make any other chages to the bpel, because I did not log 'hello', but I'm just grasping at straws.
What OS and JRE are you testing on? Are you using the jboss-as-7.1.1.Final.zip directly, or deploying SY into an existing AS?

thanks,
Adam

Deployments are unpacked into a unique temp location - so if the server is restarted, the deployments are redeployed using a fresh tmp location each time.

Only change I made was to uncomment the commented out region. However the process also worked without change. The 'hello' comes from the request message I sent to the service.

I am using Fedora 17. JDK info:

java version "1.7.0_07"

Java(TM) SE Runtime Environment (build 1.7.0_07-b10)

Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)

I used the all in one distribution, rather than installing switchyard into AS7.

Hope this info helps.

Regards

Gary