You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2011/06/14 00:00:49 UTC

Re: Domain testing

On Tue, Apr 26, 2011 at 6:12 PM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Apr 26, 2011 at 5:33 PM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>> Setting the HTTP port is just the degenerated case to configure base binding
>> URIs. There are a lot of use cases:
>> 1) Allow the embedded HTTP server (Tomcat/Jetty) to use a specific HTTP
>> port
>> 2) For multi-homed machine, configure which IP addresses the HTTP server
>> should listen
>> 3) For virtual hosts, we need to set the base URI to use the virtual host
>> name
>> 4) For a cluster environment, we need to set the base URI to use the cluster
>> name
>> As we know, some of the knowledge cannot be acquired by runtime to look up
>> the hostname/IP. They need to be configured/customized.
>
> +1 I agree that we cannot always know.
>
>> IMO, we should generalize the plugin here to introduce something like a
>> BindingURIResolver so that it can:
>> * Configure the base binding URIs based on the binding and protocol
>> * Resolve the "uri" of a binding to a deployed URI (in some cases, maybe
>> even more than one deployed URIs)
>
> Not sure what "the plugin" means in this sense but if we provide an
> API through which such data can be retrieved by the bindings or the
> URI generation code then that data can be provided/injected in any one
> of a number of ways. Through an XML file, through command line
> parameters, through system properties etc.
>
>> On the client side, now we have Node.getEndpointAddress() which provides a
>> reliable way to look up the deployed URIs without hard-coding. I would like
>> to see something symmetric on the side side to handle the deployed URI.
>
> Are there other bits of information that we might need to retrieve in
> this way, e.g. any of the configuration info like domain name. If so
> we could look at generalizing access to such information.
>
>> Thanks,
>> Raymond
>> ________________________________________________________________
>> Raymond Feng
>> rfeng@apache.org
>> Apache Tuscany PMC member and committer: tuscany.apache.org
>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>> Personal Web Site: www.enjoyjava.com
>> ________________________________________________________________
>> On Apr 26, 2011, at 1:08 AM, Simon Laws wrote:
>>
>> On Thu, Apr 21, 2011 at 9:09 AM, ant elder <an...@apache.org> wrote:
>>
>> On Wed, Apr 20, 2011 at 3:28 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>> What is it needed for? If its just for tests to set the http port to
>>
>> default to 8085 instead of 8080 then there is a static field on the
>>
>> http server class which tests can set.
>>
>>   ...ant
>>
>>
>> So here's a scenario. One the same machine start two Tuscany nodes to
>>
>> run two composites from the same domain that have components that talk
>>
>> to each other over the default binding remoted using web services.
>>
>>
>> I can't see why that scenario shouldn't work ok with whats there now.
>>
>> Anyway, like i said earlier i didn't implement anything for the base
>>
>> URIs but it shouldn't be hard to do. It doesn't seem like the best
>>
>> approach to me though and i don't remember any scenarios being given
>>
>> in the past that explained why its necessary.
>>
>>   ...ant
>>
>>
>> I think we first need to agree (or not) whether we need to be able to
>> set HTTP port numbers. Only then can we establish what a suitable
>> mechanism is. Otherwise the two points become confused.
>>
>> Based on previous (and current based on the "Allow the lookup of
>> endpoint address by component/service/binding name from the Node API"
>> thread) experience I'm first asserting that we need to be able to set
>> HTTP port numbers in order that the user of the runtime is able to set
>> values other than the defaults chosen by Tuscany. I'm not saying how
>> these values should be set by the user.
>>

Remembering an old thread...

The bit about this that i've wanted is to have the base uri able to
include the domain name so that you can run multiple domains in the
same host without getting endpoint conflicts.

I've just updated Tuscany so this works now when using the domain Node.

Presently the domain name is only included if its not the default
domain, and then only if its not the default binding. So if you had a
helloworld component in the default domain using binding.ws then the
endpoint might be

   http://localhost:8080/HelloworldComponent/HelloService

and the same component in a domain named MyDomain would have:

   http://localhost:8080/MyDomain/HelloworldComponent/HelloService

   ...ant