On Tue, Jun 3, 2008 at 4:37 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:
>
>
> On Wed, May 21, 2008 at 2:56 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
>> 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
>>
>
> I've been thinking about Raymond's suggestion for changing the
> EndpointProvider to be EndpointResolver. My only slight qualm is that target
> resolution is not performed during what Tuscany refers to as the resolve
> phase other than that it sounds OK. Thoughts?
>
> There was also a suggestion that the factory mechanism should be removed
> which I'm less keen on. I created the EndpointProvider(Resolver) as a
> provider of endpoints that people could create an implementation of to do
> resolution for all candidate bindings in the endpoint. I also had it in the
> back of my mind to allow binding spcific endpoint providers so that the
> developer of the endpoint provider can perform the endpoint resolution in an
> binding specific way. The processing would go something like.
>
> EndpointWire.getInvocationChains()
> EndpointResolver.resolve() (was EndpointProvider.start())
> maybe do some generic endpoint resolution
> for each candidate binding
> Find the binding endpoint resolver
> binding endpoint provider.resolve()
> if (resolution successful)
> endpoint is successfully resolved
> break
>
> To make this work I need to maintain a EndpointResolver factory to be able
> to get the appropriate resolver for each candidate binding and also to fluff
> up the EnpointResolverImpl that has been provided as an extension.
>
> Simon
>
>
I've gone ahead an renamed EndpointProvider to be EndpointResolver and I've
created a separate extension point for it. The endpoint resolver can apply
generally to an endpoint or to the candidate bindings within that endpoint.
So you can either do your endoint resolution in a general way or in a
binding specific way. Our main code path remains the same as it was before,
i.e. if the reference target can be resolved locally then the enpoint is
created but immediately used to select a candidate binding which is placed
in the reference binding list. Endpoint resolvers are only created if an
endpoint can't be resolved at build time.
I've created an itest (late-reference-resolution) to show how late
resolution could be done using endpoint resolvers.
I've updated all the code that used EndpointProviders. This includes
runtime-tomcat but I was unable to get this running following Ant's
instruction on this thread. It maybe that I did something wrong so I'll give
it another go a little later.
Regards
Simon
