1:11 a.m.
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
3:14 a.m.
New subject: Improving JBossWS-CXF Client Side Integration
Hi Dan and Richard,
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.
I would not say it's
hacky, as providing a custom
javax.xml.ws.spi.Provider impl is something quite common.
However, just to clarify, should another solution be found and put in
place without much trouble, I'd prefer that. The reason being we've
doing something similar (leveraging the META-INF/service load system) in
other area in the past and that taught us this can lead to a lot of
misunderstandings with users building up the classpath the wrong way and
thus not getting things working.
Thanks for the collaboration Dan.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead
JBoss, a division of Red Hat
5699
days inactive
5699
days old
1 comments
2 participants
participants (2)
-
Alessio Soldano -
Richard Opalka