On Fri, May 16, 2008 at 9:26 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:
> ...snip
>
> >
> > The two sets of SPIs could co-exist for a while with BindingProviders
> > working with bindings and ServiceProviders (I just made up that name)
> with
> > service endpoints.
> > --
> > Jean-Sebastien
>
>
> At r656959 I've just enabled some changes to take a step toward using an
> Endpoint representation in the model as an alternative to using cloned
> bindings as the representation of valid reference targets. It's not
> replacing the cloned binding approach just yet, to avoid breaking anything,
> but is the first step on the road. This is what I have done.
>
> Made a new Endpoint model type
> Created a separate factory for it (separate as I though the model may need
> to be pluggable as some point)
> Created a new EndpointProvider type and associated factory.
> Created an Endpoint module to provide a provider implementation.
> Created an Endpoint wire to trap attempted calls over unresolved endpoints
> Separated off the Endpoint builder code into a new builder class. Same code
> but easier to identify.
> Added an endpoint collection to references
> Used the Endpoint in the wire builder in place of the old internal target
> structure. The logic is weaved in to the existing logic as follows.
> For references with no target, put the binding into reference binding as
> before
> Create an Endpoint for all explicit reference targets
> For resolved endpoints (Endpoints where the target is resolved) put the
> binding into reference bindings, i.e. the same as before
> For unresolved endpoints create an endpoint provider and a wire. We don't
> have unresolved targets in tuscany (except in the sca binding test) so
> should not happen. If you do put a target name in that can't be matched
> with
> a service you'll get a warning.
>
> If there is no Endpoint module on the classpath it will not create a
> provider or a wire hence disabling any Endpoint based processing. The
> Endpoint model will still be used though
>
> As part of this change I've updated the logic that looks for target names
> in
> binding uri. It's now applied to all binding types which I believe is what
> the spec says, There is though an issue here. I'll raise a separate thread.
>
> There are also a couple of thoughts I had.
>
> Can we make the CompositeBuilderImpl have just one constructor?
> Should builders be pluggable?
> I've used some of the CompoisteActivator functions in the EndpointWire that
> could do with moving into the activator interface.
>
> Simon
>
Last week i updated the runtime-tomcat module to use this Endpoint code to
get the Tomcat deep integration with webapps talking to each other as being
discussed in [1] and [2]. Its a complete hack at the moment but at least
gives a start at something more real to be talking about in those threads.
You can try it by building the runtime-tomcat module, and the doing a "mvn
dependency:copy-dependencies"
- in tomcat conf/catalina.properties add the runtime-tomcat jar and
dependencies:
common.loader=${catalina.home}/lib,${catalina
.home}/lib/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/dependency/*.jar
- in tomcat conf/server.xml add the TuscanyHost class name to the localhost
definition, eg:
<Host name="localhost" appBase="webapps"
className="org.apache.tuscany.sca.runtime.tomcat.TuscanyHost"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
Now you can deploy webapps to tomcat without needing to include _any_
Tuscany stuff in the webapp - no tuscany jars or web.xml config. You can try
it with the calculator-webapp and calculator-ws-webapp samples, delete all
the jars and Tuscany web.xml config from the webapps and delete the subtract
component and impl from the calculator-ws-webapp and it should all still
work with the caclulator-ws-webapp using the subtract component in the
calculator-webapp sample.
...ant
[1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
[2] http://apache.markmail.org/message/l7pgz2sxuitdhmxm
