Mailing-List: contact cxf-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain iona.com designates
 63.65.132.112 as permitted sender)
From: Daniel Kulp <daniel.kulp@iona.com>
To: "Glynn, Eoghan" <eoghan.glynn@iona.com>
Subject: Re: svn commit: r442162 - in /incubator/cxf/trunk:
 api/src/main/java/org/apache/cxf/databinding/
 api/src/main/java/org/apache/cxf/endpoint/
 rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/
 rt/core/src/main/java/org/apache/cxf/endpoi
Date: Tue, 12 Sep 2006 15:20:44 -0400
User-Agent: KMail/1.9.4
Cc: cxf-dev@incubator.apache.org, cxf-commits@incubator.apache.org
References: 
 <FA1787F64A095C4090E76EBAF8B183E00300EC@emea-ems1.dublin.emea.iona.com>
In-Reply-To: 
 <FA1787F64A095C4090E76EBAF8B183E00300EC@emea-ems1.dublin.emea.iona.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200609121520.44760.daniel.kulp@iona.com>

On Tuesday September 12 2006 12:30 pm, Glynn, Eoghan wrote:
> > Actually, the BETTER way would be to make sure the needed
> > information is saved as specific properties on the
> > BindingOperationInfo (or OperationInfo) and not access the
> > method at all.
>
> Yep, makes sense.
>
> Where are these property sets currently built up?

Mostly in the WSDLServiceFactory for the "from wsdl" parts.   For the 
annotations, the JAX-WS frontend, when it looks up the operation, tends to 
fill in any missing details that it would require.    The request/response 
wrapper things mostly go in at that point.  

There is also the JaxWsServiceFactoryBean for the pure JAX-WS cases.

In both instances, we probably should create some sort of listener to allow 
plugged in subsystems to intercept and map "unknown" elements to something it 
would understand.    Right now, all "WSDL extensors" are added directly to 
the BindingOperationInfo.   That may be acceptable from a WSDL standpoint (if 
the extensors are our normal JAXB generated extensors).  For the "from java" 
case, we probably need a way to plugin to the frontend 
a "MethodMapperListener" or something to allow something to map the 
annotations to the same JAXB generated extensors.   (mapping to the extensors 
would allow the wsdl publish stuff to work correctly)    Otherwise, we'd need 
to keep hard coding new stuff into the JaxWsServiceFactoryBean.


> > How would a non-JAX-WS annotated endpoint configure the WS-A stuff?
> Fair point, we can't rely on the
> @WebService/WebMethod/{Request|Response}Wrapper annotations being set.
>
> But do you mean that we also may not be able to fall-back on the
> @javax.ws.addressing.Action annotation, or the <wsaw:Action> extension
> element in the WSDL?

Well, I would say falling back to the wsaw:Action wsdl extension may be fine 
as that's stored as is in the Service model.   The frontend would just need 
to map whatever it's "alternate source of information" is onto the service 
model.

> Are we likely to have a front-end that uses neither an SEI type approach
> nor WSDL?

The SEI type may be a DIFFERENT SEI.   Example, there are major differences 
between the JAX-WS SEI and the SCA SEI.   Thus, if we do a SCA style 
frontend, the annotation may be completely different.    That's the point of 
the Service model - to abstract everything out into a common format.

Also, there are other potential language frontends like JavaScript, Ruby , 
Jython, etc....  that may NOT be WSDL as they have alternative "reflection 
like" things, but definitely aren't java.lang.Method or Annotation based 
frontends.   Again, if the information can be represented in the Service 
model as a common format, the frontends just need to provide utilities to 
construct and/or modify the service model to provide the information.

> If so, we'll have to have some more generic way of controlling these
> free parameters (similarly for <wsaw:UsingAddressing> element).

One more note:  configuration should also be able to modify the Service model 
as needed.    Enabling WS-RM via configuration should just involve the config 
subsystem modifying the Service model to reflect the additions of the WS-RM 
stuff.   


Does all that make sense?


Enjoy!
Dan


> /Eoghan
>
> > On Tuesday September 12 2006 11:03 am, Glynn, Eoghan wrote:
> > > On a slightly related point, we actually already had at least three
> > > different ways of accessing the Method in an interceptor.
> > >
> > > On the requestor side, the ClientImpl caches the Method via
> > > Message.setContent(Method.class, ...) and the
> > > EndpointInvocationHandler also sticks the Method in its context map
> > > with key "java.lang.reflect.Method", and this is then
> >
> > copied into the
> >
> > > Exchange map (but not the message!) by the ClientImpl.
> > >
> > > On the responder side, its available via the BindingOperationInfo
> > > property "java.lang.reflect.Method", as you say.
> > >
> > > Currently in the WS-A (non-SOAP) interceptor, I'm looking up
> > > Message.getContent(Method.class), and falling back to the
> > > BindingOperationInfo property if the former is not set. BTW
> >
> > the Method
> >
> > > is used in this case to access certain annotations that
> >
> > determine the
> >
> > > wsa:Action header.
> > >
> > > Probably makes more sense though to just ensure the
> > > BindingOperationInfo property is set in ClientImpl, and
> >
> > then use this
> >
> > > as the single consistent way of accessing the Method,
> >
> > whether on the
> >
> > > requestor or responder sides. I make this change if there's
> >
> > no objection.
> >
> > > /Eoghan
> > >
> > > > The BindingOperationInfo name should correspond to the
> >
> > rpc element
> >
> > > > name and the JaxWsServiceFactory should have already instantiated
> > > > the operation with a Method. The invoker can then invoke
> >
> > the service
> >
> > > > by looking up the operation from the exchange. Also,
> >
> > there shouldn't
> >
> > > > be a need to look up the class as the Databinding is
> >
> > handling (see
> >
> > > > all the wrapped/bare interceptors for examples).
> > > >
> > > > Cheers,
> > > > - Dan
> > > >
> > > > --
> > > > Dan Diephouse
> > > > Envoi Solutions
> > > > http://envoisolutions.com
> > > > http://netzooid.com/blog
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> > daniel.kulp@iona.com

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com