On Nov 30, 2007 4:44 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

>
>
> On Nov 30, 2007 4:38 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Nov 30, 2007 2:46 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > > On Nov 30, 2007 2:09 PM, ant elder < [EMAIL PROTECTED]> wrote:
> > >
> > > > On Nov 30, 2007 1:52 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > > We have discussed this behaviour before and I was sort of
> > convinced
> > > last
> > > > > time but now I'm playing with the store sample I'm not so sure.
> > This
> > > > > features comes about because of the store composite, for example,
> > > > >
> > > > >    <component name="Store">
> > > > >        <t:implementation.widget location="uiservices/store.html"/>
> > > > >        <service name="Widget">
> > > > >            <t:binding.http uri=" http://localhost:8101/ui"/>
> > > > >        </service>
> > > > >        <reference name="catalog" target="Catalog">
> > > > >             <t:binding.jsonrpc/>
> > > > >         </reference>
> > > > >         <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > >             <t: binding.atom/>
> > > > >         </reference>
> > > > >         <reference name="shoppingTotal"
> > target="ShoppingCart/Total">
> > > > >             <t:binding.jsonrpc />
> > > > >         </reference>
> > > > >    </component>
> > > > >
> > > > > To keep the composite tidy many of the URIs are omitted and they
> > rely
> > > on
> > > > > the
> > > > > default value. However the URI for one of the bindings is provided
> > so
> > > > that
> > > > > the node will detect this and use this as the default for all
> > service
> > > > > bindings (where this kind of URI is applicable). All the bindings
> > must
> > > > be
> > > > > the same here as store.html relies on the services being
> > accessible
> > > from
> > > > > the
> > > > > same root.
> > > > >
> > > > > There are several places that the default port for the servlet
> > host
> > > > comes
> > > > > from when setting up the SCA runtime.
> > > > >
> > > > > 1. The web app container. In this case no matter how you configure
> > SCA
> > > > you
> > > > > will get whatever the web app container gives you
> > > > > 2. Node URI. This is used to tell what endpoints SCA should use by
> > > > default
> > > > > and also as a unique ID for the node. When running inside a web
> > app
> > > this
> > > > > must be the host/port you expect the web app to expose your
> > services
> > > on.
> > > > > Otherwise SCA can't tell what values the web app container is
> > going to
> > > > use
> > > > > and hence can't register services with the domain. In the case
> > that
> > > SCA
> > > > > starts Tomcat/Jetty itself then the Node URI is just the default
> > value
> > > > > that
> > > > > will be used if a URI is not provided explicitly on a binding.
> > > > > 3. Binding uri attribute. If SCA is running inside a web app
> > container
> > > > > this
> > > > > value is ignored and Node URI is used (see 2). If SCA has started
> > > > > Tomcat/Jetty itself this value will be used to configure the
> > endpoint
> > > of
> > > > > the
> > > > > service. If no value is provided then the default value is used
> >  (see
> > > 1
> > > > > and
> > > > > 2).
> > > > >
> > > > > So what's the drawback of using
> > > > >
> > > > >    <component name="Store">
> > > > >        <t:implementation.widget location="uiservices/store.html"/>
> > > > >        <service name="Widget">
> > > > >            <t:binding.http uri="/ui"/>
> > > > >        </service>
> > > > >        <reference name="catalog" target="Catalog">
> > > > >             <t: binding.jsonrpc/>
> > > > >         </reference>
> > > > >         <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > >             <t:binding.atom />
> > > > >         </reference>
> > > > >         <reference name="shoppingTotal"
> > target="ShoppingCart/Total">
> > > > >             <t:binding.jsonrpc/>
> > > > >         </reference>
> > > > >    </component>
> > > > >
> > > > > And setting Node URI = http://localhost:8101
> > > > >
> > > > > I'm uncomfortable about the current feature because I could easily
> > > > include
> > > > > a
> > > > > component in front of the existing component, e.g.
> > > > >
> > > > > <component name"SomeComponent"
> > > > >   <implementation .../>
> > > > >   <service name="SomeService">
> > > > >     < binding.ws url="http://localhost:8100/SomeService"/>
> > > > >   </service>
> > > > > </component>
> > > > >
> > > > >
> > > > >    <component name="Store">
> > > > >        <t:implementation.widget location="uiservices/store.html"/>
> > > > >        <service name="Widget">
> > > > >            <t:binding.http uri="http://localhost:8101/ui"/>
> > > > >        </service>
> > > > >        <reference name="catalog" target="Catalog">
> > > > >             <t:binding.jsonrpc/>
> > > > >         </reference>
> > > > >         <reference name="shoppingCart" target="ShoppingCart/Cart">
> > > > >             <t: binding.atom/>
> > > > >         </reference>
> > > > >         <reference name="shoppingTotal"
> > target="ShoppingCart/Total">
> > > > >             <t:binding.jsonrpc />
> > > > >         </reference>
> > > > >    </component>
> > > > >
> > > > > And mess it up as now the majority services in the composite are
> > at
> > > 8100
> > > > > and
> > > > > not 8101 where store.html expects them to be.
> > > > >
> > > > > Regards
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > > I agree. We've never come up with a very consistent story about
> > default
> > > > URLs
> > > > that works well everywhere, would be great if we could as its always
> > > > causing
> > > > problems with getting all the runtimes and nodes and service
> > endpoints
> > > > working consistently everywhere.
> > > >
> > > > Can we change so that the ServletHost implementation controls the
> > > default
> > > > base URL and have everything tries to use relative URLs with that?
> > > >
> > > >   ...ant
> > > >
> > > I think we can be relatively consistent using the three sources of
> > > endpoint
> > > information I put in the original mail.Now I think about it there is a
> > > number 4 that I didn't include so the list would be.
> > >
> > > 1. The web app container. In this case no matter how you configure SCA
> > you
> > > will get whatever the web app container gives you
> > > 2. Node URI. This is used to tell what endpoints SCA should use by
> > default
> > > and also as a unique ID for the node. When running inside a web app
> > this
> > > must be the host/port you expect the web app to expose your services
> > on.
> > > Otherwise SCA can't tell what values the web app container is going to
> > use
> > > and hence can't register services with the domain. In the case that
> > SCA
> > > starts Tomcat/Jetty itself then the Node URI is just the default value
> > > that
> > > will be used if a URI is not provided explicitly on a binding.
> > > 3. Binding uri attribute. If SCA is running inside a web app container
> > > this
> > > value is ignored and Node URI is used (see 2). If SCA has started
> > > Tomcat/Jetty itself this value will be used to configure the endpoint
> > of
> > > the
> > > service. If no value is provided then the default value is used  (see
> > 1
> > > and
> > > 2).
> > > 4. Free port. If not running inside a web app container and no Node
> > URI is
> > > provided then a free port is selected automatically as the default
> > port
> > >
> > > The default is set into the servlet host when the node starts and the
> > > bindings which use servlet host tend to use the servlet host interface
> > to
> > > calculate their endpoint.  So we are pretty close to what you suggest
> > but
> > > we
> > > need to check that it is applied everywhere.
> > >
> > > I tried to represent the algorithm in psuedo code (
> > >
> > >
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Binding+URI+Construction
> > > )
> > > is this correct?
> > >
> > > Simon
> > >
> >
> > If (1) is made to be generic instead of webapp container specific, eg
> > "the
> > default from the ServletHost" then (4) could be dropped as it can be
> > done by
> > the ServletHost impl if it chooses as part of (1).
> >
> > I'm still not really clear why (2) must be an absolute URI instead of
> > just a
> > relative one (ie just the Node name) and be relative to the absolute URI
> > from (1)? To me that seems simpler to understand and would then always
> > work
> > the same way no matter what the environment. I'm just trying to
> > understand
> > the options, I guess it doesn't make so much difference.
> >
> As a servlet running in a servlet container, for example, how do you get
> the host and port on which you are running?
>
> >
> >
> >   ...ant
>
>

The HttpServletRequest includes all that information i think.

   ...ant

Reply via email to