From asoldano at redhat.com Thu Sep 4 12:35:35 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 04 Sep 2014 18:35:35 +0200 Subject: [jbossws-dev] JBossWS 5 migration notes Message-ID: <540894D7.9080303@redhat.com> I've started collecting migration notes on the JBossWS 5 upgrade at https://developer.jboss.org/wiki/JBossWS5MigrationNotes . Any feedback, just let me know (or directky add to the article above). Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From asoldano at redhat.com Fri Sep 5 03:29:04 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Fri, 05 Sep 2014 09:29:04 +0200 Subject: [jbossws-dev] JBossWS 5 Beta1 highlights Message-ID: <54096640.2080704@redhat.com> http://jbossws.blogspot.com/2014/09/wildfly-9-and-jbossws-5-future-is-coming.html -- Alessio Soldano Web Service Lead, JBoss From asoldano at redhat.com Fri Sep 5 10:16:20 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Fri, 05 Sep 2014 16:16:20 +0200 Subject: [jbossws-dev] JBossWS 4.3.1 release In-Reply-To: <53FE1653.5090704@redhat.com> References: <53FE1653.5090704@redhat.com> Message-ID: <5409C5B4.90208@redhat.com> JBossWS 4.3.1.Final has been released; get it at http://jbossws.jboss.org/downloads/latest and/or read more on the release at http://jbossws.blogspot.com/2014/09/jbossws-431final-is-available.html :-) Cheers Alessio On 27/08/14 19:33, Alessio Soldano wrote: > Folks, > it's been several months since we released JBossWS 4.3.0.Final. The > JBossWS 5 development is still the priority and we're pretty much on > target at the moment; in the mean time, however, I thought it would make > sense to backport the most relevant bug fixes of the last few months to > the 4.3.x branch, so that we can cut a 4.3.1 release. > The up to date list of 4.3.1 issues is at: > https://issues.jboss.org/issues/?jql=project%20%3D%20JBWS%20AND%20fixVersion%20%3D%20jbossws-cxf-4.3.1 > The plan would be to release at some time between now and the end of > next week. > Cheers > Alessio > -- Alessio Soldano Web Service Lead, JBoss From asoldano at redhat.com Mon Sep 29 11:02:19 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 29 Sep 2014 17:02:19 +0200 Subject: [jbossws-dev] New configuration options proposal Message-ID: <5429747B.4020705@redhat.com> 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. * 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. * 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. Please provide feedback, so that we can possibly create jiras and implement the relevant new features. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From ema at redhat.com Tue Sep 30 02:39:34 2014 From: ema at redhat.com (Jim Ma) Date: Tue, 30 Sep 2014 14:39:34 +0800 Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <5429747B.4020705@redhat.com> References: <5429747B.4020705@redhat.com> Message-ID: <542A5026.7050700@redhat.com> 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. > * 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. > > * 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 > > > Please provide feedback, so that we can possibly create jiras and > implement the relevant new features. > > Cheers > Alessio > From asoldano at redhat.com Tue Sep 30 06:58:12 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 30 Sep 2014 12:58:12 +0200 Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <542A5026.7050700@redhat.com> References: <5429747B.4020705@redhat.com> <542A5026.7050700@redhat.com> Message-ID: <542A8CC4.5080007@redhat.com> 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 From rsvoboda at redhat.com Tue Sep 30 07:51:09 2014 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 30 Sep 2014 07:51:09 -0400 (EDT) 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: <1061803543.1080595.1412077869207.JavaMail.zimbra@redhat.com> > 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 > From asoldano at redhat.com Tue Sep 30 08:09:17 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 30 Sep 2014 14:09:17 +0200 Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <1061803543.1080595.1412077869207.JavaMail.zimbra@redhat.com> References: <5429747B.4020705@redhat.com> <542A5026.7050700@redhat.com> <542A8CC4.5080007@redhat.com> <1061803543.1080595.1412077869207.JavaMail.zimbra@redhat.com> Message-ID: <542A9D6D.5060009@redhat.com> 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 From rsvoboda at redhat.com Tue Sep 30 08:49:11 2014 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 30 Sep 2014 08:49:11 -0400 (EDT) Subject: [jbossws-dev] New configuration options proposal In-Reply-To: <542A9D6D.5060009@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> Message-ID: <1696808751.1127246.1412081351168.JavaMail.zimbra@redhat.com> ----- 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 > >>>> * 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. Cheers. Rostislav