Red Hat Bugzilla – Bug 779700
SOAPProxy Contains Major Logic in Constructor
Last modified: 2011-05-18 10:55:31 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.
At the moment you should be able to achieve this through the help of static methods.
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.
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?
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.
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.
Help Desk Ticket Reference: Removed: https://support.redhat.com/jbossnetwork/restricted/caseDetail.html?caseId=832723 Added: https://enterprise.redhat.com/issue-tracker/832723
This has been triaged for SOA 5.1.0. Not in SOA 5.1.0
new related salesforce ticket: https://na7.salesforce.com/500A00000043OkA
Link: Added: This issue is related to PRODMGT-16