Bug 778725 (SOA-1186)

Summary: mep="OneWay" on a published webservice results in a zero-length wsdl returned by <web service URL>?wsdl
Product: [JBoss] JBoss Enterprise SOA Platform 4 Reporter: Len DiMaggio <ldimaggi>
Component: JBossESBAssignee: Kevin Conner <kevin.conner>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 4.3 CP01   
Target Milestone: ---   
Target Release: 4.3 CP02   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-1186
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
SOA 4.3 CP01 CR2
Last Closed: 2009-08-28 16:17:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 778726    

Description Len DiMaggio 2009-02-20 20:01:35 UTC
Date of First Response: 2009-02-25 06:42:27
project_key: SOA

I'm seeing this with the publish_as_webservice_inonly quickstart.

In this listener definition:

           <actions mep="OneWay" inXsd="/request.xsd" faultXsd="/fault.xsd" >
                   <action name="action" class="org.jboss.soa.esb.samples.quickstart.publishAsWebservice.ESBWSListenerAction" process="displayMessage"/>  
            
The only way I've been able to get the quickstart to run successfully is to remove the mep="OneWay" clause. With mep="OneWay" in the listener definition, 

http://127.0.0.1:8080/Quickstart_publish_as_webservice_inonly/ESBServiceSample/HelloWorldPubService?wsdl

returns nothing. Is this intentional?

Comment 1 Len DiMaggio 2009-02-20 20:05:53 UTC
Link: Added: This issue is a dependency of JBESB-2434


Comment 2 Len DiMaggio 2009-02-20 20:06:37 UTC
Link: Added: This issue is a dependency of SOA-1187


Comment 3 Tom Fennelly 2009-02-25 11:42:27 UTC
This would be a bug fix (see comment just added to JBESB-2434).  As such, is this a valid addition for an FP?

Comment 4 Mark Little 2009-03-09 10:41:07 UTC
Moving to CP.

Comment 5 Kevin Conner 2009-08-10 10:54:37 UTC
In addition, the code in the deployer uses the service mep to determine whether to apply the filter or not and this is not valid.

It should be using the service info (and indeed was at one point).

The filter is also testing the mep rather than trusting the deployment, another source of error.

Comment 6 Kevin Conner 2009-08-10 10:59:30 UTC
To clarify, the filter is actually using a parameter that is set as a consequence of the previous mep test in the deployer and not testing the mep directly.  This parameter is always true, if deployed.

Comment 7 Kevin Conner 2009-08-10 13:06:46 UTC
Link: Added: This issue depends JBESB-2434


Comment 8 Kevin Conner 2009-08-10 13:06:59 UTC
Link: Removed: This issue is a dependency of JBESB-2434 


Comment 9 Jiri Pechanec 2009-08-28 16:17:35 UTC
Verified in CR2