[jbossws-dev] New configuration options proposal

[Rostislav Svoboda]

Thanks for letting me know, agree that *adding* interceptors is fine for now.
We can discuss *replacing* interceptors if there is push on it.

Cheers.
Rostislav

----- Original Message -----
> OK, I've complete the work on JBWS-3836, JBWS-3837, JBWS-3840.
> Rostislav, please also see comments below:
> 
> On 30/09/14 14:49, Rostislav Svoboda wrote:
> > ----- Original Message -----
> >> Hi Rostislav,
> >>
> >> On 30/09/14 13:51, Rostislav Svoboda wrote:
> >>>> On 30/09/14 08:39, Jim Ma wrote:
> >>>>> On 09/29/2014 11:02 PM, Alessio Soldano wrote:
> >>>>> This said, I see your point on trying avoiding introducing further
> >>>>> descriptors, and carefully thinking about this we should also
> >>>>> consider that you can already set properties within the pre-defined
> >>>>> client configurations (and setting properties is the main reason why
> >>>>> we'd add the descriptor). An alternative idea would be to provide a
> >>>>> convention for automatically reading a pre-defined client
> >>>>> configuration, for instance based on the SEI class FQN. So for
> >>>>> instance, we could say that for a port retrieved as follows import
> >>>>> org.foo.ServiceIface; ... Service service = Service.create(new
> >>>>> URL("...?wsdl"), serviceQName); ServiceIface port =
> >>>>> (ServiceIface)service.getPort(portQName, ServiceIface.class);
> >>>>> instead of directly going and fetching the
> >>>>> "Standard-Client-Configuration" from the container webservices
> >>>>> management model we'd first try getting a configuration named
> >>>>> "org.foo.ServiceIface" (still in the webservices model) and only
> >>>>> fallback to the "Standard-Client-Configuration" if that's not found.
> >>>>> That would allow for different configurations to clients without
> >>>>> touching their code; the only requirement is the clients run
> >>>>> in-container.
> >>> 'clients run in-container' is quite strict requirement. How would you
> >>> "customize" standalone clients ?
> >> Well, AFAIK most of users relying on JBossWS actually run clients
> >> in-container (that is on JBoss AS / WildFly / EAP). In any case,
> >> similarly, we could also make our client always try resolving a
> >> "jaxws-client-config.xml" and look for a configuration named as the SEI
> >> class. Skipping this saves us a classloader resource lookup.
> > +1 for solution acceptable for standalo client too,
> > "jaxws-client-config.xml" ++ lookup for a configuration named as the SEI
> > class
> Done; we'll have to double check this (the jaxws-client-config.xml file
> lookup) does not affect performances too much on client side.
> 
> >>>>>> * Apache CXF interceptors setup through properties
> >>>>>> ----------------------------------------------------------------------
> >>>>>> Speaking of properties, currently specified in jboss-webservices.xml
> >>>>>> and
> >>>>>> possibly in jboss-webservices-client.xml, we could start supporting
> >>>>>> two
> >>>>>> additional props:
> >>>>>> * org.apache.cxf.interceptor.InInterceptors, with the value string to
> >>>>>> be
> >>>>>> parsed for getting a list of in-interceptor classnames; basically to
> >>>>>> achieve the same we get with @InInterceptor
> >>>>>> * org.apache.cxf.interceptor.OutInterceptors, with the value string to
> >>>>>> be parsed for getting a list of out-interceptor classnames; basically
> >>>>>> to
> >>>>>> achieve the same we get with @OutInterceptor
> >>>>>> The interceptors would be attached either to the bus or to the
> >>>>>> client/endpoint depending on where the property is declared.
> >>>>>     +1
> >>>> ok
> >>> Would org.apache.cxf.interceptor.In/OutInterceptors props override
> >>> @In/OutInterceptor defined in class file ? Or it would be just addition
> >>> to
> >>> already defined ones ?
> >> Good question... I'd say it would be an addition; we can decide to warn
> >> the user if he's trying adding an interceptor that is already there.
> >>
> > Option for either *adding* or *replacing* interceptors would be great.
> I've thought a bit about this while implementing and figured out it's
> quite complex to allow replacing. We'll go with the addition only for
> now, and try also supporting replacement if there's actual user interest
> in this.
> 
> Thanks again for the feedback.
> Cheers
> Alessio
> 
> --
> Alessio Soldano
> Web Service Lead, JBoss
> 
>