Bug 779700 - (SOA-2064) SOAPProxy Contains Major Logic in Constructor
SOAPProxy Contains Major Logic in Constructor
Status: NEW
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.0.0 GA
Unspecified Unspecified
medium Severity medium
: ---
: FUTURE
Assigned To: Ken Johnson
http://jira.jboss.org/jira/browse/SOA...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-03 12:10 EDT by Brad Davis
Modified: 2011-05-18 10:55 EDT (History)
1 user (show)

See Also:
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:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SOA-2064 Minor Closed SOAPProxy Contains Major Logic in Constructor 2012-09-11 07:02:56 EDT

  None (edit)
Description Brad Davis 2010-05-03 12:10:48 EDT
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 03:23:42 EDT
At the moment you should be able to achieve this through the help of static methods.
Comment 2 Kevin Conner 2010-05-04 04:19:35 EDT
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 08:19:47 EDT
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 08:27:25 EDT
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 08:27:49 EDT
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 7 Anne-Louise Tangring 2010-09-21 16:47:01 EDT
This has been triaged for SOA 5.1.0. Not in SOA 5.1.0
Comment 8 Colin Mondesir 2010-10-05 09:04:34 EDT
new related salesforce ticket: https://na7.salesforce.com/500A00000043OkA
Comment 9 Darran Lofthouse 2010-10-27 10:22:35 EDT
Link: Added: This issue is related to PRODMGT-16

Note You need to log in before you can comment on or make changes to this bug.