Looks similar to https://issues.jboss.org/browse/JBWS-2174 although this was fixed in jbossws-cxf 3.0.2.

Updated version of the dynpartner main BPEL process, which uses an explicit URL assignment for the first interaction.

Currently there is a bug in riftsaw (https://issues.jboss.org/browse/SOA-3535) where the EPR is essentially cached with the partner link, so any subsequent changes after the first invoke would not take effect - so this updated version of the example ensures an explicit EPR is used.

This can be used for two tests (relevant to both stacks) - (a) just to check that an explicitly provided EPR works fine, to call the responder service, and (b) by modifying the URL (e.g. adding XXX at the end), to check that a HTTP 404 response is received, to ensure that it is attempting to use the invalid URL.

Attachment: Added: DynPartnerMain.bpel

When using this attached example against riftsaw 2.3.1.Final with jbossws-native 3.4.0.SP1 and the modified xalan.jar attached to RIFTSAW-325, the example runs fine.

However when run on ER4, it results in the following:

6:36:32,500 ERROR [WebServiceClient] WS invocation failed
javax.xml.ws.WebServiceException: Cannot find port: null
	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getEndpointMetaData(ServiceDelegateImpl.java:356)
	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.createDispatch(ServiceDelegateImpl.java:530)
	at javax.xml.ws.Service.createDispatch(Service.java:437)
	at org.jboss.soa.bpel.runtime.ws.WebServiceClient.getDispatcher(WebServiceClient.java:467)

This is the same behaviour seen with riftsaw+jbossws-native 3.1.2 (i.e. default native stack). So not sure whether all of the patches/changes made in 3.4.0.SP1 have been applied to SOA-P 5.2?

Link: Added: This issue is related to SOA-2974

This problem also exists with ER6 running jbossws-native. The problem appears to be that the EPR does not contain the ServiceName metadata element with the EndpointName attribute (i.e. port):

2011-11-01 09:34:43,235 DEBUG [org.jboss.soa.bpel.runtime.ws.WebServiceClient] (ODEServer-2) EPR = <?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/dynpartner/DynResponderService</Address><ReferenceParameters/><Metadata/></EndpointReference>

This EPR is built using javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder utility, which delegates the task to the underlying provider implementation: org.jboss.ws.core.jaxws.spi.ProviderImpl

Without use CXF I have some another issues. Log says:

09:54:08,525 WARN  [EndpointFactory] Couldnt create any endpoint for element <?xml version="1.0" encoding="UTF-8"?>
<service-ref xmlns="http://docs.oasis-open.org/wsbpel/2.0/serviceref"><url xmlns="http://ode/bpel/responder.wsdl">http://localhost:8080/dynpartner/DynResponderService</url></service-ref>
09:54:08,526 ERROR [BpelRuntimeContextImpl] Couldn't find endpoint for partner EPR <?xml version="1.0" encoding="UTF-8"?>
<service-ref xmlns="http://docs.oasis-open.org/wsbpel/2.0/serviceref"><url xmlns="http://ode/bpel/responder.wsdl">http://localhost:8080/dynpartner/DynResponderService</url></service-ref>
09:54:08,528 ERROR [INVOKE] Failure during invoke: UnknownEndpoint

for previous partnerlink invoke test, all other tests passes (wsa and serviceref) - I'm going to add new process definition...

Attachment: Added: NewDynPartnerMain.bpel

ER6 with jbossws-cxf results in what appears to be a correct EPR:

2011-11-01 10:05:35,007 DEBUG [org.jboss.soa.bpel.runtime.ws.WebServiceClient] (ODEServer-2) EPR = <?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/dynpartner/DynResponderService</Address><ReferenceParameters/><Metadata><wsam:ServiceName EndpointName="DynResponderPort" xmlns:ns2="http://ode/bpel/responder.wsdl" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">ns2:DynResponderService</wsam:ServiceName></Metadata></EndpointReference>

but for some reason, even though the called service is available, it appears to be using an invalid URL:

2011-11-01 10:05:39,788 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/dynpartner/DynResponderService].[Endpoint-8ec961e5-605c-4912-84ec-539afe3e0784]] (http-127.0.0.1-8080-2) Servlet.service() for servlet Endpoint-8ec961e5-605c-4912-84ec-539afe3e0784 threw exception
javax.servlet.ServletException: Cannot obtain destination for: //dynpartner/DynResponderService
	at org.jboss.wsf.stack.cxf.ServletControllerExt.findDestination(ServletControllerExt.java:114)
	at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:168)
	at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:61)
	at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:185)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)

Hi Ivo

This updated process appears to require a different responder process, as it uses information in the payload to determine what EPR to use?

Can you also include any instructions on how to reproduce the problem, or will the responder process be setup to automatically request the EPR that is failing?

I added whole test. Yes It uses information in the payload to determine what EPR to use. There is DynamicPartnerLinkTest which contains how to reproduce issue in testPreviousInvoke() method. Request messages are in test/resources/messages

Attachment: Added: bpel_dynpartner.zip

Added bpel_dynpartner sample for easy reproduce my issue with ant deploy, ant runtest.

Attachment: Added: dynpartner_sample.zip

Ok thanks Ivo - could you also raise a jira against riftsaw with this example.

np Gary, I created new jira issue here RIFTSAW-459.

Further info: ER6 with cxf - when using the simple_invoke_assignment_error example from RIFTSAW-325, it works. However the modified dynpartner main process (attached to this jira) still causes the error in the original information.

ER6 with native, when using the simple_invoke_assignment_error has the same problem as with the dynpartner example - Port Not Found: null.

The original stack trace reported for this issue is possibly uddi related. With ER6+cxf, if uddi lookup/registration is set to false in bpel.properties, the modified dynpartner example works.

So will create a separate issue for the ER6/native port not found problem.

Fixed on the trunk, not yet committed to the prod branch (waiting for approval)

Link: Added: This issue Cloned to RIFTSAW-426

Link: Removed: This issue Cloned to RIFTSAW-426 

Link: Added: This issue Cloned to RIFTSAW-462

This issue is approved for the SOA 5.2 release. It is deemed low risk. 

Release Notes Docs Status: Added: Not Required
Writer: Added: dlesage

Hello Gary and Kurt, We still have the issue in SOA 5.2.CR1. How did you fix it? I think we should reopen it, because of RIFTSAW-462, which is dependency and still open.
Thanks

The change definitely was included in tag Riftsaw-2.3.1.Final.

Tested with CR1+CXF and problem does still occur. If uddi lookup/registration properties set to false, then works - so if cannot be resolved for release, then this could be a workaround.

Workaround Description: Added: Set properties

bpel.uddi.registration=false
bpel.uddi.lookup=false

in ${server.home}/server/${server.config}/deploy/riftsaw.sar/bpel.properties
Workaround: Added: Workaround Exists

Gary - thanks for checking this out

Release Notes Docs Status: Removed: Not Required Added: Not Yet Documented
Affects: Removed: Interactive Demo/Tutorial Added: Interactive Demo/Tutorial,Release Notes

Workaround confirmed.

Hi David - can you please put the workaroung into the release notes? Thanks. Regards Marek

second attempt

Attachment: Added: SOA-3466-patch.txt

Hi guys,

Not sure why this broke again, but I have attached a patch.

--Kurt

Hi Kurt,

we will test and confirm ASAP.

Regards
Marek

Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Known Issue
Release Notes Text: Added: https://issues.jboss.org/browse/SOA-3466

The dynapartner quick start fails to invoke dynamically-assigned endpoint references. Currently there is a bug in the BPEL engine where the EPR is essentially cached with the partner link, so any subsequent changes after the first invoke do not take effect  As a workaround, users should set the UDDI lookup/registration properties to false. It will then work. 

If the workaround is not employed, the user will not be able to use the UDDI register to look up partner web-services from a BPEL process, but  will still be able to call local/remote web-services by including the WSDL of the service in the Java archive deployed on the server. Also, If a user wants to reuse a BPEL process as a web-service he or she must manually register the end-point in the UDDI as the engine will not do it automatically.

Hi David

The bug is that an incorrect URL is stored in UDDI, when registering the BPEL process, not the caching problem.

Also in the second para, it should start: "If the workaround is employed......"

Hello Kurt, I tested your patch on bpel_dynpartner qs and It *works* in SOA 5.2.CR1 with CXF.

Link: Added: This issue depends SOA-3588

Thanks Ivo, I have now committed the patch to the RiftSaw-2.3.x branch as well. --Kurt