Re: [jbossws-dev] New configuration options proposal

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