Re: [jbossws-dev] New configuration options proposal

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.

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