Bug 779700 (SOA-2064)

Summary:	SOAPProxy Contains Major Logic in Constructor
Product:	[JBoss] JBoss Enterprise SOA Platform 5	Reporter:	Brad Davis <brad.davis>
Component:	JBossESB	Assignee:	Ken Johnson <kejohnso>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.0.0 GA	CC:	brad.davis
Target Milestone:	---
Target Release:	FUTURE
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/SOA-2064
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Brad Davis 2010-05-03 16:10:48 UTC

Date of First Response: 2010-05-04 03:23:42
Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/832723
project_key: SOA

org.jboss.soa.esb.actions.soap.proxy.SOAPProxy performs major setup logic in constructor.  This keeps us from being able to extend the class to add more features, as the call to the super(ConfigTree ) constructor must be the first line of our constructor. 

We want to be able to add some simple logic to load the URL from a system property, to enable use to move between environments without impact of the codebase.

My suggestion is to move all major setup logic into the initialize method.

Comment 1 Kevin Conner 2010-05-04 07:23:42 UTC

At the moment you should be able to achieve this through the help of static methods.

Comment 2 Kevin Conner 2010-05-04 08:19:35 UTC

One more comment, why are you not using properties within your jboss-esb.xml file???

This should already enable the functionality you are trying to achieve.

Comment 3 Brad Davis 2010-05-04 12:19:47 UTC

Kevin, what does this mean:
At the moment you should be able to achieve this through the help of static methods. 

I have tried the properties within the jboss-esb.xml the way you suggested by email, and it works, so I dropped that out of my codebase.  However, I did not attempt this in my code until I went through JBoss Support, which said it was not possible:  See: https://support.redhat.com/jbossnetwork/restricted/caseDetail.html?caseId=832723  As far as properties in the ESB file, can you point me to the point in the documentation where that is noted?

Comment 4 Brad Davis 2010-05-04 12:27:25 UTC

As far as this bug goes, the logic being in the constructor also leads to the issue of the whole service failing when the proxied web service is temporarily unavailable on server restart.  You suggested: "It is currently a requirement that the wsdl exist when starting the service, although it should be possible to handle this through a barrier of sorts.  What is your scenario?"

The scenario is that, if SOA-P is bounced, and a webservice is unavailable that it should be proxying, it leads to an exception on deployment of the ESB service, and *no way* to recover the service, even if the remote service comes back online.  If this is a requirement of the SoapProxy, it is a design flaw.  The SoapProxy should return a SoapFault until the point that the service becomes available.

Comment 5 Kevin Conner 2010-05-04 12:27:49 UTC

Sorry, you need to continue this through support or take it to the forums.  I have already followed up on the support case but will do so again.

Comment 6 Darran Lofthouse 2010-05-11 15:26:30 UTC

Help Desk Ticket Reference: Removed: https://support.redhat.com/jbossnetwork/restricted/caseDetail.html?caseId=832723 Added: https://enterprise.redhat.com/issue-tracker/832723

Comment 7 Anne-Louise Tangring 2010-09-21 20:47:01 UTC

This has been triaged for SOA 5.1.0. Not in SOA 5.1.0

Comment 8 Colin Mondesir 2010-10-05 13:04:34 UTC

new related salesforce ticket: https://na7.salesforce.com/500A00000043OkA

Comment 9 Darran Lofthouse 2010-10-27 14:22:35 UTC

Link: Added: This issue is related to PRODMGT-16