Re: [jbossws-dev] New configuration options proposal

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