[jbossws-dev] New configuration options proposal

[Kyle Lape]

+1 to all the ideas, really.

I really like the alternative idea described below since it allows the
configuration to be updated via the CLI (as well as all the other
benefits of config via mgmt interface).  

I'm okay with keeping only jboss-webservices.xml and adding client
config in there if possible.  

--Kyle

On Tue, Sep 30, 2014 at 12:58:12PM +0200, Alessio Soldano wrote:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev