[bradsdavis]

Just fixing documentation or a quickstart is not an appropriate fix.  While it is a fix that should happen for the meantime until the underlying issue is resolved, it doesn't solve the fact that with a simple combination of webservice + ESB, your server could be unresponsive.

[dward]

Kevin Conner wrote:

I am just not understanding that when a situation has been brought to the forefront that could literally freeze a server start, no one will own it and log a JIRA.

We did own it and we created a way in which it could be handled.  If the documentation is weak in this area, or if our quickstarts do not show it, then we can certainly address those issues.

Kev

The quickstarts do show it.  However I will admit that the documentation is weak in this area.  I will create a JIRA for it.

[kconner]

CXF is only Tech Preview.

CXF is not supported in ESB nor SOA 5.  It will be coming in SOA 5.1 though.

Kev

[dward]

This complicates things for people, who will likely not know about this "special feature".

Then they should look in the docs, which I will be enhancing.

They will also have to be aware of this when services get moved between environments, and update it accordingly.

Moving anything between environments is not, and should not be treated as, trivial.  They should be aware of all aspects and dependencies.

[bradsdavis]

Well, at the moment, we only support JBossWS inside SOA-P for our paying subscribers.  CXF is only Tech Preview.

David, I have described why an ESB should not rely on a certain technology for interactivity.  Primarily because in the field we are often using ESBs to integrate legacy systems, which generally don't use JBossWS for web services.  This could be Axis providing the WSDL, or CXF, or even a ColdFusion application deployed on JBoss.

The point is, none of our actions should be called SoapProxy and then make it so it only works in certain cases.

Another point is, just by making the thing lazy load, the whole issue and special protocol and the lot could be simply avoided.

[bradsdavis]

Moving anything between environments is not, and should not be treated as, trivial.  They should be aware of all aspects and dependencies.

I can not believe you are still arguing the point.  System administrators should be able to assume they can move a WAR to JBoss ESB and not receive a hung server.  Of course it is not trivial, but the ESB should not be so rigid that it should hang in the case that this happens.

[kconner]

We have tried to explain how we got to the current position, and also why the points you have raised are not new.

Kev

[dward]

David, I have described why an ESB should not rely on a certain technology for interactivity.  Primarily because in the field we are often using ESBs to integrate legacy systems, which generally don't use JBossWS for web services.  This could be Axis providing the WSDL, or CXF, or even a ColdFusion application deployed on JBoss.

The point is, none of our actions should be called SoapProxy and then make it so it only works in certain cases.

Only the internal:// scheme is specific to JBossWS.

Another point is, just by making the thing lazy load, the whole issue and special protocol and the lot could be simply avoided.

In your words, "Brad, read the full post."  I have explained why using lazy load would not simply work.

[bradsdavis]

Again, this has nothing to do with CXF or any specific stack.  This has to do with the fact that putting any stack other than JBossWS on a JBoss ESB, and then using the bind address for JBoss as part of the URL will lead to server hangs.

[bradsdavis]

We have tried to explain how we got to the current position, and also why the points you have raised are not new.

If they are not new issues, open a JIRA.  Take the JIRA, put it into the development plan moving forward, and it will be a non issue.  Otherwise, another paying customer will open the issue again and again.

[dward]

the ESB should not be so rigid that it should hang in the case that this happens.

I actually agree with the "hanging is bad" point.  In fact, there is a jira on this, which - per your tone you might find surprising - I am actually working on right now:

https://jira.jboss.org/jira/browse/JBESB-3172

My belief is that it is not bad for the service to FAIL with an Exception.  I do believe that it should not hang, however, thus the jira item above.

[dward]

My fix for this will address the hanging:

https://jira.jboss.org/jira/browse/JBESB-3172

However, I still believe the SOAPProxy initialization should fail with an Exception if it can't get what it needs.  That's why there are the non-http/s schemes (classpath, file, internal).

[bradsdavis]

I actually agree with the "hanging is bad" point.  In fact, there is a jira on this, which - per your tone you might find surprising - I am actually working on right now:

For whatever reason, I do not have access to that JIRA [perhaps you could give me permission considering I am a Red Hat Employee].

I am glad to hear that is a JIRA; and I did not know it was a JIRA considering I have opened two Service Requests and argued the points with you both throughout the morning without acknowledgement of the issue.

My belief is that it is not bad for the service to FAIL with an Exception.  I do believe that it should not hang, however, thus the jira item above.

I do think failing is an issue in the sense that even if the remote service comes back online, this one never will.

[kconner]

Take the JIRA, put it into the development plan moving forward

We did, and it was done.

Kev

[dward]

For whatever reason, I do not have access to that JIRA [perhaps you could give me permission considering I am a Red Hat Employee].

I have changed the visibility of the issue to public; I found out there was no reason why it wasn't in the first place.  You should see it now.

I do think failing is an issue in the sense that even if the remote service comes back online, this one never will.

Sounds like a Feature Request to me.