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: [email protected]; [email protected]
> 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: [email protected]; [email protected]
> > > 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
> > > > > [EMAIL PROTECTED]
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> > > [EMAIL PROTECTED]
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> [EMAIL PROTECTED]
>
