[jbossws-dev] New configuration options proposal

[Alessio Soldano]

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