cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@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 Wed, 13 Sep 2006 08:45:38 GMT

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).

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?

/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
> 

Mime
View raw message