cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject Extensor access (was RE: svn commit: r442162 ...)
Date Wed, 13 Sep 2006 13:51:03 GMT

Makes sense.

I'm using the generic form of extensor access [i.e. getExtensors() as
opposed to getWSDL{11|2}Extensors()] for the UsingAddressing element,
but still depend on the Method for the Action determination, so I'm
going to have to rework some of the stuff I just committed in the light
of this discussion.

First though I'll concentrate on getting a system test committed with
decoupled correlation in place.

Cheers,
Eoghan

> -----Original Message-----
> From: Kulp, John Daniel 
> Sent: 13 September 2006 13:39
> To: cxf-commits@incubator.apache.org; cxf-dev@incubator.apache.org
> 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/int
> erceptor/ rt/core/src/main/java/org/apache/cxf/endpoi
> 
> 
> Eoghan,
> 
> > One aspect that isn't clear to me is why we expose 
> WSDL-specific (in 
> > fact WSDL-version-specific) extensors on AbstractPropertiesHolder, 
> > when the whole motivation of the service model seems to be 
> to hide the 
> > fact that the source was WSDL or an annotated POJO (or 
> something else 
> > entirely for the more exotic frontends).
> 
> The "wish" is that there aren't version specific extensors.   
> For most of the 
> extensors we define (xml binding http-conf stuff, jms stuff, 
> etc....) the 
> extensors would be identical.     SOAP is the wacky case 
> where it completely 
> breaks down which is why the SOAP binding overrides the WSDL 
> processing methods to map them to more generic pieces of information.
> 
> > Given the current state of the service model, is there an existing 
> > alternative to an interceptor using 
> > AbstractPropertiesHolder.getWSDL11Extensors(), or the convenience 
> > accessor getExtensor(), in order to determine whether a particular 
> > extension element was present?
> 
> The expectation is that you would use getExtensor() to get 
> the "generic" form.   
> (Currently the same as the WSDL11 form)   The 
> getWSDL11Extensors() and future 
> getWSDL2Extensors() would be changed to make sure stuff is 
> mapped to the appropriate  form.
> 
> Basically, for the stuff we JAXB generate, all three versions 
> could be the 
> same object.   Keep it simple for the stuff we control.
> 
> That said, the extensors COULD also be registered as actual 
> properties based 
> on classname.   Thus, they would also look like regular properties. 
> 
> Dan
> 
> >
> > /Eoghan
> >
> > > -----Original Message-----
> > > From: Kulp, John Daniel
> > > Sent: 12 September 2006 20:21
> > > To: Glynn, Eoghan
> > > Cc: cxf-dev@incubator.apache.org; cxf-commits@incubator.apache.org
> > > 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/int
> > > erceptor/ rt/core/src/main/java/org/apache/cxf/endpoi
> > >
> > > 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
> 
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> daniel.kulp@iona.com
> 

Mime
View raw message