[jbossws-dev] New configuration options proposal

[Alessio Soldano]

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.

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

Thanks for the feedback

Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss