June 2009 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: JBossWS Deployers Integration

by anil.saldhana＠jboss.com

Because of WS deployer framework, I had to create the JACC web permissions for the WS deployments in the WS deployers rather than the security deployers. I am referring to the transient tomcat deployment WS uses to deal with WS invocations. When JBossWS starts using AS deployers, I guess we can clean up the JACC permissions creation. If metadata is used by WS, then I think we just have to remove the jacc perm creation from the as/webservice project. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238006#4238006 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238006

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: EJBContext as an attachment in WebServiceContext

by alessio.soldano＠jboss.com

JBossWS still uses that to retrieve the caller principal and for the isCallerInRole check. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237996#4237996 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237996

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - EJBContext as an attachment in WebServiceContext

by jaikiran

Currently in our EJB3 StatelessContainer http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/... we have WSCallbackImpl which is a callback for BeanContext creation and removal: static class WSCallbackImpl implements BeanContextLifecycleCallback | { | private ExtensibleWebServiceContext jaxwsContext; | private javax.xml.rpc.handler.MessageContext jaxrpcMessageContext; | | public WSCallbackImpl(javax.xml.rpc.handler.MessageContext jaxrpc, ExtensibleWebServiceContext jaxws) | { | jaxrpcMessageContext = jaxrpc; | jaxwsContext = jaxws; | } | | public void attached(BeanContext beanCtx) | { | // JAX-RPC MessageContext | StatelessBeanContext sbc = (StatelessBeanContext)beanCtx; | sbc.setMessageContextJAXRPC(jaxrpcMessageContext); | | // JAX-WS MessageContext | BeanProperty beanProp = sbc.getWebServiceContextProperty(); | if (beanProp != null) | { | EJBContext ejbCtx = beanCtx.getEJBContext(); | jaxwsContext.addAttachment(EJBContext.class, ejbCtx); | beanProp.set(beanCtx.getInstance(), jaxwsContext); | } | } | | public void released(BeanContext beanCtx) | { | StatelessBeanContext sbc = (StatelessBeanContext)beanCtx; | sbc.setMessageContextJAXRPC(null); | | BeanProperty beanProp = sbc.getWebServiceContextProperty(); | if (beanProp != null) | beanProp.set(beanCtx.getInstance(), null); | } | } As seen in the code, on the BeanContext callback, we attach the EJBContext as an attachment to the WebServiceContext. Does JBossWS still require this EJBContext within the WebServiceContext or can we stop attaching this? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237949#4237949 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237949

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS Deployers Integration - Fixing Strategy

by richard.opalka＠jboss.com

Current JBossWS + AS5 integration isn't implemented properly. There are two main issues with it: ad1) We're not reusing provided AS deployers architecture/concept. Instead of reusing it we're reimplementing the same architecture pattern on our own. It made sence to do it in the past when we were supporting AS 40, AS 42 and AS 50 but now when AS 5x is supported only it doesn't make sence anymore. Correcting JBossWS integration with AS deployers architecture will also allow other AS projects to better integrate with JBossWS seamlessly (see JBAS-5935). ad2) Second problem is we're doing not just metadata processing stuff in deployers processing layer. Many of the current deployment aspects have to be executed in Servlet lifecycle methods to prevent "chicken and egg" problem we're facing at the present (see JBWS-2370). These deployment aspects that will be moved to servlet lifecycle methods will also be executed per endpoint not per deployment like is it now. The following JBossWS deployment aspects will be removed from deployers chain (will be moved to servlet lifecycle methods): * EndpointLifecycleDeploymentAspect * EndpointHandlerDeploymentAspect * EndpointRecordProcessorDeploymentAspect * EventingDeploymentAspect * ServiceEndpointInvokerDeploymentAspect * RMDeploymentAspect * EagerInitializeDeploymentAspect * EndpointMetricsDeploymentAspect * EndpointAddressDeploymentAspect The following JBossWS deployment aspects will stay in deployers processing chain (but will be reimplemented to use AS deployers approach instead): * RuntimeLoaderDeploymentAspect * PublishContractDeploymentAspect * JAXBIntroDeploymentAspect * UnifiedMetaDataDeploymentAspect * ContextPropertiesDeploymentAspect * ModifyWebMetaDataDeploymentAspect * BackwardCompatibleContextRootDeploymentAspect * BackwardCompatibleURLPatternDeploymentAspect * EndpointRegistryDeploymentAspect * EndpointNameDeploymentAspect * InjectionMetaDataDeploymentAspect * ContainerMetaDataDeploymentAspect * WebAppGeneratorDeploymentAspect * WebAppDeploymentAspect * VirtualHostDeploymentAspect WS deployer hooks will be reimplemented too (will become AS deployers) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237925#4237925 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237925

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS Deployers Integration

by richard.opalka＠jboss.com

First our current deployers architecture: We have three deployers in place, namely: * WebServiceDeployerEJB * WebServiceDeployerPreJSE * WebServiceDeployerPostJSE These are ordered in the following way: ordering1) EJBDeployer < WebServiceDeployerEJB < WarDeployer ordering2) WebServiceDeployerPreJSE < WarDeployer < WebServiceDeployerPostJSE ordering1) is followed when EJB as WS is deployed (only one WS deployer does all the WS magic) ordering2) is followed in case POJO as WS is deployed (two WS deployers do all the WS magic) Each WS deployer has two deployer hooks registered (JAX-RPC and JAX-WS): +--- WebServiceDeployerEJB ( holds WSDeploymentAspectManagerEJB ) | | | +--- JAXRPCDeployerHookEJB21 | | | +--- JAXWSDeployerHookEJB3 | +--- WebServiceDeployerPreJSE ( holds WSDeploymentAspectManagerPreJSE ) | | | +--- JAXRPCDeployerHookPreJSE | | | +--- JAXWSDeployerHookPreJSE | +--- WebServiceDeployerPostJSE ( holds WSDeploymentAspectManagerPostJSE ) | +--- JAXRPCDeployerHookPostJSE | +--- JAXWSDeployerHookPostJSE Deployer hook represents JBossAS 4 style deployer that does almost all the WS processing stuff. It usually does the following things: * determines the WS deployment type (JAX-WS or JAX-RPC) * constructs initial JBossWS Metadata model that is later used by JBossWS deployment aspects * calls WS deployment aspect manager to build/process WS Metadata model using registered WS deployment aspects The following deployment aspects are registered with particular deployment aspect managers: (AS guys can imagine them like AS deployers, they are following the same chain-of-responsibility pattern and are also kind of ordered set of processors like AS deployers are). WSDeploymentAspectManagerEJB | +--- AS | |- WSContainerMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.ContainerMetaDataDeploymentAspect | |- WSInjectionMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.InjectionMetaDataDeploymentAspect | |- WSContextRootDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleContextRootDeploymentAspect | |- WSVirtualHostDeploymentAspect = org.jboss.wsf.framework.deployment.VirtualHostDeploymentAspect | |- WSEndpointAddressDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointAddressDeploymentAspect | |- WSEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect | |- WSEndpointLifecycleDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointLifecycleDeploymentAspect | |- WSEndpointMetricsDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointMetricsDeploymentAspect | |- WSEndpointNameDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointNameDeploymentAspect | |- WSEndpointRegistryDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect | |- WSURLPatternDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleURLPatternDeploymentAspect | |- WSRuntimeLoaderDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.RuntimeLoaderDeploymentAspect | |- WSWebAppDeploymentAspect = org.jboss.wsf.container.jboss50.transport.WebAppDeploymentAspect | +- WSWebAppGeneratorDeploymentAspect = org.jboss.wsf.container.jboss50.transport.WebAppGeneratorDeploymentAspect | +--- Native |- WSNativeContextPropertiesDeploymentAspect = org.jboss.wsf.framework.deployment.ContextPropertiesDeploymentAspect |- WSNativeEagerInitializeDeploymentAspect = org.jboss.wsf.stack.jbws.EagerInitializeDeploymentAspect |- WSNativeEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect |- WSNativeEndpointRecordProcessorDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect |- WSNativeEventingDeploymentAspect = org.jboss.wsf.stack.jbws.EventingDeploymentAspect |- WSNativePublishContractDeploymentAspect = org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect |- WSNativeServiceEndpointInvokerDeploymentAspect = org.jboss.wsf.stack.jbws.ServiceEndpointInvokerDeploymentAspect |- WSNativeRMDeploymentAspect = org.jboss.ws.extensions.wsrm.server.RMDeploymentAspect |- WSNativeUnifiedMetaDataDeploymentAspect = org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect +- WSJAXBIntroDeploymentAspect = org.jboss.wsf.stack.jbws.JAXBIntroDeploymentAspect WSDeploymentAspectManagerPreJSE | +--- AS | |- WSContainerMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.ContainerMetaDataDeploymentAspect | |- WSInjectionMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.metadata.InjectionMetaDataDeploymentAspect | |- WSContextRootDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleContextRootDeploymentAspect | |- WSEndpointAddressDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointAddressDeploymentAspect | |- WSEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect | |- WSEndpointMetricsDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointMetricsDeploymentAspect | |- WSEndpointNameDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointNameDeploymentAspect | |- WSEndpointRegistryDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect | |- WSModifyWebMetaDataDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.tomcat.ModifyWebMetaDataDeploymentAspect | +- WSURLPatternDeploymentAspect = org.jboss.wsf.framework.deployment.BackwardCompatibleURLPatternDeploymentAspect | +--- Native +- WSNativeContextPropertiesDeploymentAspect = org.jboss.wsf.framework.deployment.ContextPropertiesDeploymentAspect WSDeploymentAspectManagerPostJSE | +--- AS | |- WSEndpointLifecycleDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointLifecycleDeploymentAspect | +- WSRuntimeLoaderDeploymentAspect = org.jboss.wsf.container.jboss50.deployment.RuntimeLoaderDeploymentAspect | +--- Native |- WSNativeEndpointHandlerDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect |- WSNativeEndpointRecordProcessorDeploymentAspect = org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect |- WSNativeEventingDeploymentAspect = org.jboss.wsf.stack.jbws.EventingDeploymentAspect |- WSNativePublishContractDeploymentAspect = org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect |- WSNativeServiceEndpointInvokerDeploymentAspect = org.jboss.wsf.stack.jbws.ServiceEndpointInvokerDeploymentAspect |- WSNativeRMDeploymentAspect = org.jboss.ws.extensions.wsrm.server.RMDeploymentAspect |- WSNativeUnifiedMetaDataDeploymentAspect = org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect |- WSNativeEagerInitializeDeploymentAspect = org.jboss.wsf.stack.jbws.EagerInitializeDeploymentAspect +- WSJAXBIntroDeploymentAspect = org.jboss.wsf.stack.jbws.JAXBIntroDeploymentAspect View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237911#4237911 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237911

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - JBossWS Deployers Integration

by richard.opalka＠jboss.com

This is a first brain dump regarding the following issues (feel free to comment/discuss): JBWS-2332 JBWS-2333 JBWS-2338 JBWS-2370 JBWS-2382 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237910#4237910 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237910

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by richard.opalka＠jboss.com

"trustin" wrote : | As an alternative, I'd like to suggest you to try Netty HTTP codec - http://www.jboss.org/netty/ | Hi Trustin, I just spent few hours with studying your Netty project/samples/code base. I think Netty is the best thing we could use for our next generation webservices client transport ;) Richard View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237016#4237016 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237016

14 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by richard.opalka＠jboss.com

JBWS-2674 depends on this issue as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236953#4236953 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236953

14 years, 10 months

1
0
0 / 0

Re: Improving JBossWS-CXF Client Side Integration

by Richard Opalka

Hi Daniel, all the options mentioned below sound reasonable to me. Richard Daniel Kulp wrote: > Richard, > > Modifying the generated code is not a doable solution. That would tie them > to CXF which would then violate the JAX-WS spec and TCK and such. Thus, > that's not an option. > > However, you could be on the right track. In our ServiceImpl, all the > "getPort" calls forward into the protected "createPort" method (line 384 of > ServiceImpl). We COULD put your call to the listener in there. > > The better option would be to push it even furthur into CXF and put it into > the JaxWsProxyFactoryBean/ClientProxyFactoryBean.create() call. That way, > if they end up using the spring "jaxws:client" call or use the factories > directly themselves, the listeners would be invoked as well. > > Dan > > > > On Wed June 3 2009 2:11:22 am Richard Opalka wrote: > >> Hi Daniel, >> >> Yes, I know about solution 1) you suggested. However I don't like it. >> It's hacky and could cause a lot of troubles to our customers. >> Thus I'd like to go the way to modify CXF code base. >> >> Before I'll write my suggestion let me clarify that we don't need to >> wrap your ServiceDelegate. We just need to register properties >> on the proxy and that can be achieved using listener approach. >> So here are my thoughts how it could be achieved in another way (no >> delegation): >> >> --- >> ad1) >> --- >> // CXF provides listener interface >> package org.apache.cxf.jaxws; >> >> public interface ServiceListener >> { >> void onPortCreated(T proxy, Class<T> sei); >> } >> --- >> ad2) >> --- >> // JBossWS provides listener implementation >> package org.jboss.wsf.stack.cxf.client; >> >> public class ServiceListenerImpl implements ServiceListener >> { >> public void onPortCreated(T proxy, Class<T> sei) >> { >> // ... our integration code >> } >> } >> --- >> ad3) >> --- >> // JBossWS somehow registers the listener >> --- >> ad4) >> --- >> // finally replace the following code in >> org.apache.cxf.jaxws.ServiceImpl.createPort(...) >> protected <T> T createPort(QName portName, EndpointReferenceType epr, >> Class<T> serviceEndpointInterface, WebServiceFeature... features) >> { >> // ... >> return serviceEndpointInterface.cast(obj); >> } >> // with the following code: >> protected <T> T createPort(QName portName, EndpointReferenceType epr, >> Class<T> serviceEndpointInterface, WebServiceFeature... features) >> { >> // ... >> T proxy = serviceEndpointInterface.cast(obj); >> for (ServiceListener listener : listeners) >> { >> listener.onPortCreated(proxy, serviceEndpointInterface); >> } >> return proxy; >> } >> >> If you like this approach then let's disscuss how ad3) could be >> achieved, i.e. how to register the listener on the service. >> >> Cheers, >> >> Richard >> >> Daniel Kulp wrote: >> >>> Well, couple things spring to mind: >>> >>> Option 1: requires no changes to CXF, but requires some classloader magic >>> on your side >>> Write your own javax.xml.ws.spi.Provider that probably subclasses ours >>> and overrides the method: >>> @Override >>> public ServiceDelegate createServiceDelegate(URL url, QName qname, >>> Class cls) { >>> Bus bus = BusFactory.getThreadDefaultBus(); >>> return new ServiceImpl(bus, url, qname, cls); >>> } >>> >>> In your case, return a subclass of our ServiceImpl the does your >>> additional stuff. That way, any cast we may do to ServiceImpl would >>> still work (not sure if we do it anywhere, but just in case). That way, >>> you won't really have an extra delegation layer. Just overrides. >>> The TRICK is getting your provider to be used instead of ours. Thus, >>> you may need to make sure your >>> META-INF/services/javax.xml.ws.spi.Provider file is picked up before our >>> (or use the system property to force yours). >>> >>> >>> Option 2: make changes to CXF. Couple of ideas here. One could be in >>> our createServiceDelegate method above, we do something like: >>> >>> >>> Provider p = bus.getExtension(Provider.class); >>> if (p != null) { >>> return p.createServiceDelegate(....); >>> } >>> return new ServiceImpl(....); >>> >>> or similar. Thus, if a custom Provider is found on the Bus, we'll >>> delegate to it. Heck, we could also put a static "Provider delegate;" >>> field on our ProviderImpl that you could set to your provider prior to >>> any calls. >>> >>> Or, we could look for a property someplace for the name of the >>> "ServiceImpl" class to instantiate. If set, use reflection to create >>> the ServiceImpl thing if set. >>> >>> Anyway, those are my immediate thoughts. >>> >>> Dan >>> >>> On Mon May 25 2009 9:21:35 am Richard Opalka wrote: >>> >>>> Hi CXF Team, >>>> >>>> >>>> We've spent some time with CXF source code analysis but without >>>> success. Related issue is: https://jira.jboss.org/jira/browse/JBWS-2521 >>>> We would like to remove one very ugly JBossWS CXF JAX-WS client proxy >>>> integration hack related to service references (method >>>> hackServiceDelegate()), >>>> see: >>>> >>>> http://fpaste.org/paste/12892 >>>> >>>> We're registering our custom ServiceDelegate handler (via reflection) >>>> in original proxy >>>> and we delegate each call to CXF original service delegate there, with >>>> one exception. >>>> We're propagating service ref properties for every port creation before >>>> returning >>>> from our custom service delegate (method propagateProps(T proxy, >>>> Class<T> serviceEndpointInterface)), >>>> see: >>>> >>>> http://fpaste.org/paste/12893 >>>> >>>> Could you guys, with excellent CXF architecture knowledge, give us >>>> some hints how >>>> to improve our JBossWS CXF JAX-WS client integration and remove >>>> aforementioned ugly hack? >>>> >>>> JBossWS Team >>>> >>>> PS: We're looking forward for your suggestions ;) >>>> > > -- Richard Opalka JBoss Software Engineer Mail: ropalka(a)redhat.com Mobile: +420 731 186 942

14 years, 11 months

1
0
0 / 0

Re: Improving JBossWS-CXF Client Side Integration

by Richard Opalka

Hi Daniel, Yes, I know about solution 1) you suggested. However I don't like it. It's hacky and could cause a lot of troubles to our customers. Thus I'd like to go the way to modify CXF code base. Before I'll write my suggestion let me clarify that we don't need to wrap your ServiceDelegate. We just need to register properties on the proxy and that can be achieved using listener approach. So here are my thoughts how it could be achieved in another way (no delegation): --- ad1) --- // CXF provides listener interface package org.apache.cxf.jaxws; public interface ServiceListener { void onPortCreated(T proxy, Class<T> sei); } --- ad2) --- // JBossWS provides listener implementation package org.jboss.wsf.stack.cxf.client; public class ServiceListenerImpl implements ServiceListener { public void onPortCreated(T proxy, Class<T> sei) { // ... our integration code } } --- ad3) --- // JBossWS somehow registers the listener --- ad4) --- // finally replace the following code in org.apache.cxf.jaxws.ServiceImpl.createPort(...) protected <T> T createPort(QName portName, EndpointReferenceType epr, Class<T> serviceEndpointInterface, WebServiceFeature... features) { // ... return serviceEndpointInterface.cast(obj); } // with the following code: protected <T> T createPort(QName portName, EndpointReferenceType epr, Class<T> serviceEndpointInterface, WebServiceFeature... features) { // ... T proxy = serviceEndpointInterface.cast(obj); for (ServiceListener listener : listeners) { listener.onPortCreated(proxy, serviceEndpointInterface); } return proxy; } If you like this approach then let's disscuss how ad3) could be achieved, i.e. how to register the listener on the service. Cheers, Richard Daniel Kulp wrote: > Well, couple things spring to mind: > > Option 1: requires no changes to CXF, but requires some classloader magic on > your side > Write your own javax.xml.ws.spi.Provider that probably subclasses ours and > overrides the method: > @Override > public ServiceDelegate createServiceDelegate(URL url, QName qname, > Class cls) { > Bus bus = BusFactory.getThreadDefaultBus(); > return new ServiceImpl(bus, url, qname, cls); > } > > In your case, return a subclass of our ServiceImpl the does your additional > stuff. That way, any cast we may do to ServiceImpl would still work (not > sure if we do it anywhere, but just in case). That way, you won't really have > an extra delegation layer. Just overrides. The TRICK is getting your > provider to be used instead of ours. Thus, you may need to make sure your > META-INF/services/javax.xml.ws.spi.Provider file is picked up before our (or > use the system property to force yours). > > > Option 2: make changes to CXF. Couple of ideas here. One could be in our > createServiceDelegate method above, we do something like: > > > Provider p = bus.getExtension(Provider.class); > if (p != null) { > return p.createServiceDelegate(....); > } > return new ServiceImpl(....); > > or similar. Thus, if a custom Provider is found on the Bus, we'll delegate > to it. Heck, we could also put a static "Provider delegate;" field on our > ProviderImpl that you could set to your provider prior to any calls. > > Or, we could look for a property someplace for the name of the "ServiceImpl" > class to instantiate. If set, use reflection to create the ServiceImpl thing > if set. > > Anyway, those are my immediate thoughts. > > Dan > > > > On Mon May 25 2009 9:21:35 am Richard Opalka wrote: > >> Hi CXF Team, >> >> >> We've spent some time with CXF source code analysis but without success. >> Related issue is: https://jira.jboss.org/jira/browse/JBWS-2521 >> We would like to remove one very ugly JBossWS CXF JAX-WS client proxy >> integration hack related to service references (method >> hackServiceDelegate()), >> see: >> >> http://fpaste.org/paste/12892 >> >> We're registering our custom ServiceDelegate handler (via reflection) >> in original proxy >> and we delegate each call to CXF original service delegate there, with >> one exception. >> We're propagating service ref properties for every port creation before >> returning >> from our custom service delegate (method propagateProps(T proxy, >> Class<T> serviceEndpointInterface)), >> see: >> >> http://fpaste.org/paste/12893 >> >> Could you guys, with excellent CXF architecture knowledge, give us >> some hints how >> to improve our JBossWS CXF JAX-WS client integration and remove >> aforementioned ugly hack? >> >> JBossWS Team >> >> PS: We're looking forward for your suggestions ;) >> > > -- Richard Opalka JBoss Software Engineer Mail: ropalka(a)redhat.com Mobile: +420 731 186 942

14 years, 11 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev June 2009