1 2 3 4 Previous Next 55 Replies Latest reply on May 6, 2010 5:09 PM by dward Go to original post
      • 15. Re: SOAPProxy initialization and deployment ordering
        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

        • 16. Re: SOAPProxy initialization and deployment ordering
          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.

          • 17. Re: SOAPProxy initialization and deployment ordering
            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

            • 18. Re: SOAPProxy initialization and deployment ordering
              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?

              • 19. Re: SOAPProxy initialization and deployment ordering
                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.

                • 20. Re: SOAPProxy initialization and deployment ordering
                  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?"

                  • 21. Re: SOAPProxy initialization and deployment ordering
                    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.

                    • 22. Re: SOAPProxy initialization and deployment ordering
                      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

                      • 23. Re: SOAPProxy initialization and deployment ordering
                        kconner

                        We have both read the post, in full.

                         

                        Kev

                        • 24. Re: SOAPProxy initialization and deployment ordering
                          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.

                          • 25. Re: SOAPProxy initialization and deployment ordering
                            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

                            • 26. Re: SOAPProxy initialization and deployment ordering
                              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.

                              • 27. Re: SOAPProxy initialization and deployment ordering
                                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.

                                • 28. Re: SOAPProxy initialization and deployment ordering
                                  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.

                                  • 29. Re: SOAPProxy initialization and deployment ordering
                                    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