You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by matteo <ma...@abodata.com> on 2010/09/07 12:29:17 UTC
CXF Interceptors problem in OSGi
Dear all,
Let me briefly introduce my environment:
OSGi exec environment - equinox implementation, version
org.eclipse.osgi_3.5.2.R35x_v20100126
Apache CXF - version 2.2.10
I'm trying to enable CXF interceptors to address security issues in my web
services but I cannot get these in/out interceptors be called. Here are some
details of the problem:
I have a bundle called CXFBundle where I stashed all the modules and
libraries that come with the CXF 2.2.10 binary distribution and a bundle
called BundleCXFServer where I publish my endpoint with
IPersistence pers = PersistenceFactory.getPersist(); // returns the
IPersistence implementation
String addr = "http://myServerIP:8160/Persistence";
javax.xml.ws.Endpoint ep = org.apache.cxf.jaxws.EndpointImpl.publish(addr,
pers);
The IPersistence interface is declared inside a osgi service called
DataTypeService and the IPersistence implementation (the
dbproxyservice.PersistenceHandler class) is defined within a bundle called
DBProxyService:
@WebService(targetNamespace = "http://dbproxyservice/")
public interface IPersistence {
/**
* Clean the database.
* @param list
*/
public void CleanDb();
}
@WebService(serviceName=PersistenceService,
endpointInterface= "datatype.IPersistence",
portName=PersistencePort)
@InInterceptors (interceptors =
{"dbproxyservice.ws.security.interceptors.WSSecurityInterceptor"})
public class PersistenceHandler implements IPersistence {
public void CleanDb(){
// do actions...
}
}
and in the bundle DBProxyService I also put the WSSecurityInterceptor class:
public class WSSecurityInterceptor extends AbstractSoapInterceptor{
public WSSecurityInterceptor() {
super(Phase.PRE_PROTOCOL);
}
public WSSecurityInterceptor(String s) {
super(Phase.PRE_PROTOCOL);
}
public void handleMessage(SoapMessage message) throws Fault {
Map props = new HashMap();
props.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
props.put(WSHandlerConstants.PW_CALLBACK_REF, new PasswordHandler());
WSS4JInInterceptor wss4jInHandler = new WSS4JInInterceptor(props);
ValidateUserTokenInterceptor userTokenInterceptor = new
ValidateUserTokenInterceptor(Phase.POST_PROTOCOL);
message.getInterceptorChain().add(wss4jInHandler);
message.getInterceptorChain().add(new SAAJInInterceptor());
message.getInterceptorChain().add(userTokenInterceptor);
}
}
If I put a breakpoint in the first line of my handleMessage method it never
gets hit. And the interesting fact is that the CleanDb() service works
perfectly when the client invokes it even if I don't specify any client-side
interceptor and no exception is thrown (both client-side and server-side).
I cannot understand if this is a CXF-OSGi interoperability problem or just a
silly error of mine in the procedure that I reported above.
Thank you very much,
matteo
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Interceptors-problem-in-OSGi-tp2805910p2805910.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Interceptors problem in OSGi
Posted by matteo <ma...@abodata.com>.
Ok, I figured this out: the problem was due to a deprecated method of Apache
Cayenne I used in the CleanDb() method. Once I eliminated this deprecated
method the classloader context switch trick worked perfectly.
Thank you again Dan!
matteo
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Interceptors-problem-in-OSGi-tp2805910p2834644.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Interceptors problem in OSGi
Posted by matteo <ma...@abodata.com>.
Dear Dan,
thank you very much for your hints. I checked my imports (I imported the cxf
packages wherever they are directly or indirectly used) but the issue still
remains.
As another attempt, I did as you suggested about the classloader in the
BundleCXFServer:
Endpoint ep = null;
ClassLoader oldTCCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(WSSecurityInterceptor.class.getClassLoader());
ep = EndpointImpl.publish(addr, pers);
} finally {
Thread.currentThread().setContextClassLoader(oldTCCL);
}
but this apparently spoils the CleanDb web service functioning also when no
Interceptors are enabled (I get many ClassNotFoundEx probably due to the
class loader modification above).
Do you have any suggestions?
Thank you again,
matteo
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Interceptors-problem-in-OSGi-tp2805910p2827206.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Interceptors problem in OSGi
Posted by Daniel Kulp <dk...@apache.org>.
In OSGi, these types of things are usually a result of of improper (or
incomplete) imports on the application bundle or similar. In particular, for
your BundleCXFServer, you probably need to make sure you are importing the
InInterceptors class correctly to make sure it's resolved correctly.
That said, there may also be a classloader thing. Before calling the
Endpoint.publish, you might want to try setting the Thread context classloader
to the classloader that would be able to find the WSSecurityInterceptor.
Dan
On Tuesday 07 September 2010 6:29:17 am matteo wrote:
> Dear all,
> Let me briefly introduce my environment:
> OSGi exec environment - equinox implementation, version
> org.eclipse.osgi_3.5.2.R35x_v20100126
> Apache CXF - version 2.2.10
>
> I'm trying to enable CXF interceptors to address security issues in my web
> services but I cannot get these in/out interceptors be called. Here are
> some details of the problem:
>
> I have a bundle called CXFBundle where I stashed all the modules and
> libraries that come with the CXF 2.2.10 binary distribution and a bundle
> called BundleCXFServer where I publish my endpoint with
>
> IPersistence pers = PersistenceFactory.getPersist(); // returns the
> IPersistence implementation
> String addr = "http://myServerIP:8160/Persistence";
> javax.xml.ws.Endpoint ep = org.apache.cxf.jaxws.EndpointImpl.publish(addr,
> pers);
>
> The IPersistence interface is declared inside a osgi service called
> DataTypeService and the IPersistence implementation (the
> dbproxyservice.PersistenceHandler class) is defined within a bundle called
> DBProxyService:
>
> @WebService(targetNamespace = "http://dbproxyservice/")
> public interface IPersistence {
> /**
> * Clean the database.
> * @param list
> */
> public void CleanDb();
> }
>
> @WebService(serviceName=PersistenceService,
> endpointInterface= "datatype.IPersistence",
> portName=PersistencePort)
> @InInterceptors (interceptors =
> {"dbproxyservice.ws.security.interceptors.WSSecurityInterceptor"})
> public class PersistenceHandler implements IPersistence {
> public void CleanDb(){
> // do actions...
> }
> }
>
> and in the bundle DBProxyService I also put the WSSecurityInterceptor
> class:
>
> public class WSSecurityInterceptor extends AbstractSoapInterceptor{
> public WSSecurityInterceptor() {
> super(Phase.PRE_PROTOCOL);
> }
>
> public WSSecurityInterceptor(String s) {
> super(Phase.PRE_PROTOCOL);
> }
>
> public void handleMessage(SoapMessage message) throws Fault {
> Map props = new HashMap();
> props.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
> props.put(WSHandlerConstants.PW_CALLBACK_REF, new PasswordHandler());
> WSS4JInInterceptor wss4jInHandler = new WSS4JInInterceptor(props);
> ValidateUserTokenInterceptor userTokenInterceptor = new
> ValidateUserTokenInterceptor(Phase.POST_PROTOCOL);
> message.getInterceptorChain().add(wss4jInHandler);
> message.getInterceptorChain().add(new SAAJInInterceptor());
> message.getInterceptorChain().add(userTokenInterceptor);
> }
> }
>
> If I put a breakpoint in the first line of my handleMessage method it never
> gets hit. And the interesting fact is that the CleanDb() service works
> perfectly when the client invokes it even if I don't specify any
> client-side interceptor and no exception is thrown (both client-side and
> server-side). I cannot understand if this is a CXF-OSGi interoperability
> problem or just a silly error of mine in the procedure that I reported
> above.
>
> Thank you very much,
> matteo
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog