Folks, I've been chatting with users and thinking a bit about the client/endpoint descriptor-based configuration options we currently offer in JBossWS. Looks like there's room for improvement, mainly to allow setting stuff that is currently controlled through JBossWS / Apache CXF APIs only. Hence, here is a proposal for few additions, please have a look and let me know any comment. * New client descriptor ---------------------------------------------------------------------- Currently we do have the jboss-webservices.xml descriptor on server side; it allows setting options for endpoints included in the deployment. For example, we can have properties specified in there, which can affect the pre-defined endpoint config selection, some Apache CXF features (policy alernative selection, just to say one), etc. We don't have a corresponding client descriptor though. We could have a default descriptor (say, jboss-webservices-client.xml) to be looked up through TCCL when building JAX-WS client services. That would allow setting properties for the specific client instead of at system/jvm level; we already have properties for getting a specific pre-defined client configuration, for controlling cxf bus selection, etc.

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

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

Please provide feedback, so that we can possibly create jiras and implement the relevant new features. Cheers Alessio

On 30/09/14 08:39, Jim Ma wrote: > On 09/29/2014 11:02 PM, Alessio Soldano wrote: >> Folks, >> I've been chatting with users and thinking a bit about the >> client/endpoint descriptor-based configuration options we currently >> offer in JBossWS. Looks like there's room for improvement, mainly to >> allow setting stuff that is currently controlled through JBossWS / >> Apache CXF APIs only. Hence, here is a proposal for few additions, >> please have a look and let me know any comment. >> >> * New client descriptor >> ---------------------------------------------------------------------- >> Currently we do have the jboss-webservices.xml descriptor on server >> side; it allows setting options for endpoints included in the >> deployment. For example, we can have properties specified in there, >> which can affect the pre-defined endpoint config selection, some Apache >> CXF features (policy alernative selection, just to say one), etc. >> We don't have a corresponding client descriptor though. We could have a >> default descriptor (say, jboss-webservices-client.xml) to be looked up >> through TCCL when building JAX-WS client services. That would allow >> setting properties for the specific client instead of at system/jvm >> level; we already have properties for getting a specific pre-defined >> client configuration, for controlling cxf bus selection, etc. > Can we add the new elements in the old named jboss-webservices.xml > instead of introducing another new descriptor ? Configure all things > in one file will be better and easy to maintain in the future. well, what made me think about an additional descriptor is the fact that jboss-webservices.xml is a descriptor for WS deployments, but given we're talking about clients, you could actually have no WS deployment (a JAX-WS client living within a plain EJB3 deployment, for instance). 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.

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

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

Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss _______________________________________________ jbossws-dev mailing list jbossws-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbossws-dev

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.

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

On 30/09/14 08:39, Jim Ma wrote: > On 09/29/2014 11:02 PM, Alessio Soldano wrote: >> Folks, >> I've been chatting with users and thinking a bit about the >> client/endpoint descriptor-based configuration options we currently >> offer in JBossWS. Looks like there's room for improvement, mainly to >> allow setting stuff that is currently controlled through JBossWS / >> Apache CXF APIs only. Hence, here is a proposal for few additions, >> please have a look and let me know any comment. >> >> * New client descriptor >> ---------------------------------------------------------------------- >> Currently we do have the jboss-webservices.xml descriptor on server >> side; it allows setting options for endpoints included in the >> deployment. For example, we can have properties specified in there, >> which can affect the pre-defined endpoint config selection, some Apache >> CXF features (policy alernative selection, just to say one), etc. >> We don't have a corresponding client descriptor though. We could have a >> default descriptor (say, jboss-webservices-client.xml) to be looked up >> through TCCL when building JAX-WS client services. That would allow >> setting properties for the specific client instead of at system/jvm >> level; we already have properties for getting a specific pre-defined >> client configuration, for controlling cxf bus selection, etc. > Can we add the new elements in the old named jboss-webservices.xml > instead of introducing another new descriptor ? Configure all things > in one file will be better and easy to maintain in the future. well, what made me think about an additional descriptor is the fact that jboss-webservices.xml is a descriptor for WS deployments, but given we're talking about clients, you could actually have no WS deployment (a JAX-WS client living within a plain EJB3 deployment, for instance). 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. >> * 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. >> >> * 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 Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss _______________________________________________ jbossws-dev mailing list jbossws-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbossws-dev