[jbossws-dev] New configuration options proposal

[Rostislav Svoboda]

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

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

Cheers.
Rostislav

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