[kconner]

Did you consider at the time that if 10  services

Funnily enough, yes.  This is why you have a way of working around it.

Kev

[bradsdavis]

It is irrelevant because it tells you nothing, you cannot base any decision on it.

Again, I would rather you address the issue, which is that if a service is deployed on the same box, a server will literally not start because of this plus the SoapProxy.

[kconner]

One of the problems of having conflicting requirements is that we sometimes have to take a middle ground.  This is one of those areas.

This is also why alternatives were put in place, allowing you to do what you wish.

Kev

[dward]

Brad Davis wrote:

Precisely my point.  localhost is really irrelevant; the point is, the SoapProxy should not freeze a deployment, no matter if the service lies on the same server or a different server.

If it's in the same VM, use internal://.  If it's on another server, use http:// or https://.  If you don't want to be dependent on the availability of the other server, use file:// or classpath://.  What's the problem here?

[bradsdavis]

I can work around issue; all I am wanting is someone to say yes, this is a problem, and here is the JIRA number we will use to fix it in the next release.

[dward]

Kevin Conner wrote:

This is also why alternatives were put in place, allowing you to do what you wish.

Kev has it exactly right.  As I said up above, "If it's in the same VM, use internal://.  If it's on another server, use http:// or https://.  If you don't want to be dependent on the availability of the other server, use file:// or classpath://.  What's the problem here?"

[bradsdavis]

David, read the full post.  I have addressed why I dont think our clients should need to know about some special protocol for addressing web services.

Additionally, I have discussed why I don't think we should assume everyone will use JBossWS.

[kconner]

which is that if a service is deployed on the same box

No, what you really mean is if it is deployed within the same VM and, even then, using JBossWS and not some other SOAP stack.

The box and IP addresses are irrelevant.  I can have multiple servers running on the same IP address, just as I can have the same server running on multiple IP addresses.

Kev

[kconner]

We have both read the post, in full.

Kev

[bradsdavis]

One of the problems of having conflicting requirements is that we sometimes have to take a middle ground.  This is one of those areas.

This is also why alternatives were put in place, allowing you to do what you wish.

I understand this arguement on every point; I fully agree that you can not make everyone happy.  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.

[kconner]

all I am wanting is someone to say yes, this is a problem, and here is the JIRA number

Sorry, best we can do is what we have already done and said.

- it was a deliberate decision made after taking all your points into consideration, they are certainly not new.

- we did this *because* doing what you want is not currently possible in all circumstances.

Kev

[bradsdavis]

Kev has it exactly right.  As I said up above, "If it's in the same VM, use internal://.  If it's on another server, use http:// or https://.  If you don't want to be dependent on the availability of the other server, use file:// or classpath://.  What's the problem here?"

The problem is that you introduce a special protocol for the same server, which is overkill.  This complicates things for people, who will likely not know about this "special feature".  They will also have to be aware of this when services get moved between environments, and update it accordingly.  All of this knowledge overhead to avoid a server freeze.

[bradsdavis]

I am going to have to disagree.  You can and should fix this.  This is a huge issue; it should not matter where a service is deployed to avoid a server freeze.  It is very irresponsible to not fix this issue.

[dward]

Brad Davis wrote:

David, read the full post.

I have read the full post.

I have addressed why I dont think our clients should need to know about some special protocol for addressing web services.

The need for the internal:// scheme is because you need to be able to specify the MBean name of the target internal WS.  You can't deduce that from an http URI.

Additionally, I have discussed why I don't think we should assume everyone will use JBossWS.

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

[kconner]

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