From klape at redhat.com Wed Oct 1 01:46:09 2014 From: klape at redhat.com (Kyle Lape) Date: Tue, 30 Sep 2014 22:46:09 -0700 Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <542A8CC4.5080007@redhat.com> References: <5429747B.4020705@redhat.com> <542A5026.7050700@redhat.com> <542A8CC4.5080007@redhat.com> Message-ID: <20141001054609.GA25325@kjl.me> +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 From asoldano at redhat.com Mon Oct 13 09:33:43 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 13 Oct 2014 15:33:43 +0200 Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <1696808751.1127246.1412081351168.JavaMail.zimbra@redhat.com> References: <5429747B.4020705@redhat.com> <542A5026.7050700@redhat.com> <542A8CC4.5080007@redhat.com> <1061803543.1080595.1412077869207.JavaMail.zimbra@redhat.com> <542A9D6D.5060009@redhat.com> <1696808751.1127246.1412081351168.JavaMail.zimbra@redhat.com> Message-ID: <543BD4B7.5010408@redhat.com> 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 From ema at redhat.com Mon Oct 13 23:29:49 2014 From: ema at redhat.com (Jim Ma) Date: Tue, 14 Oct 2014 11:29:49 +0800 Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <543BD4B7.5010408@redhat.com> References: <5429747B.4020705@redhat.com> <542A5026.7050700@redhat.com> <542A8CC4.5080007@redhat.com> <1061803543.1080595.1412077869207.JavaMail.zimbra@redhat.com> <542A9D6D.5060009@redhat.com> <1696808751.1127246.1412081351168.JavaMail.zimbra@redhat.com> <543BD4B7.5010408@redhat.com> Message-ID: <543C98AD.1070802@redhat.com> On 10/13/2014 09:33 PM, Alessio Soldano wrote: >>>>>>> * 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. We should make it same behaviour like in cxf. There is no replacement in cxf. Interceptors configured with different places (from annotation like @Interceptors, @Feature or cxf.xml) will be all added to cxf's interceptor chain. If there is the same interceptor is added twice , the later added will override the previous one. From rsvoboda at redhat.com Tue Oct 14 05:46:05 2014 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 14 Oct 2014 05:46:05 -0400 (EDT) Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <543BD4B7.5010408@redhat.com> References: <5429747B.4020705@redhat.com> <542A5026.7050700@redhat.com> <542A8CC4.5080007@redhat.com> <1061803543.1080595.1412077869207.JavaMail.zimbra@redhat.com> <542A9D6D.5060009@redhat.com> <1696808751.1127246.1412081351168.JavaMail.zimbra@redhat.com> <543BD4B7.5010408@redhat.com> Message-ID: <1095206640.8543943.1413279965914.JavaMail.zimbra@redhat.com> Thanks for letting me know, agree that *adding* interceptors is fine for now. We can discuss *replacing* interceptors if there is push on it. Cheers. Rostislav ----- Original Message ----- > 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 > >