[jbossws-dev] New configuration options proposal

[Alessio Soldano]

OK, I've complete the work on JBWS-3836, JBWS-3837, JBWS-3840.
Rostislav, please also see comments below:

On 30/09/14 14:49, Rostislav Svoboda wrote:
> ----- 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
Done; we'll have to double check this (the jaxws-client-config.xml file 
lookup) does not affect performances too much on client 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.
>>
> 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.

Thanks again for the feedback.
Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss