Re: [jbossws-dev] New configuration options proposal

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

>>> * Addition to the jboss-webservices.xml schema >>> ---------------------------------------------------------------------- >>> In jboss-webservices.xml we currently allow setting deployment level >>> properties. We should evaluate setting properties also at endpoint/port >>> level, basically within the port-component section. >> I totally agree with this. I remembered we talked about this before >> and we need to remove this configuration limitation. > With the same spirit of the comment above, we could actually also avoid > this change. Properties are already in the predefined configs. And if > none is specified for an endpoint, the endpoint class FQN could be used > to pick one in the container model. +1 for this proposal ... as we are on server 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 ?