[jbossws-dev] New configuration options proposal

[Rostislav Svoboda]

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

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

Cheers.
Rostislav