This problem has now been fixed in SVN revision r657009
Thanks, Mark > -----Original Message----- > From: Mark Combellack [mailto:[EMAIL PROTECTED] > Sent: 16 May 2008 11:26 > To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] > Subject: RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed > operation and extension implementations - was: Re: Request to propogate > the value of a references target= attribute on its associated bindings > model object > > Hi, > > > > I've just tried building the latest trunk of Tuscany and I'm getting a > compile failure in the new endpoint module. The error I am getting is: > > > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Error for project: Apache Tuscany SCA Default Endpoint > Implementation > (during install) > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Compilation failure > > > > /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc > an > y/sca/binding/sca/EndpointTestCase.java:[109,32] package > org.apache.xml.serialize does not exist > > > > /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc > an > y/sca/binding/sca/EndpointTestCase.java:[110,32] package > org.apache.xml.serialize does not exist > > > > > > Is anyone else seeing this issue or is it just me? > > > > Thanks, > > > > Mark > > > > > -----Original Message----- > > > From: Simon Laws [mailto:[EMAIL PROTECTED] > > > Sent: 16 May 2008 09:26 > > > To: tuscany-dev@ws.apache.org > > > Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed > > > operation and extension implementations - was: Re: Request to propogate > > > the value of a references target= attribute on its associated bindings > > > model object > > > > > > ...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 > > _____
