Hi
On 04/04/12 08:14, Thomas Pischulski wrote:
Hi Sergey,

TBH I don't know how to work with those WS-Policy Features. I'm still
trying to load my custom WSDL File from an included bundle resource path
but after registering my service, CXF also chooses to publish the auto
generated WSDL without any WS-Policy stuff.

Recently I just found out I have to add the location of the WSDL to the
bundles MANIFEST.FM

"Bundle-ClassPath: resources/wsdl/"

And it contains my resources/wsdl/hello.wsdl file.

Which type of path does CXF DOSGi now want from me? I tried both,
"resources/wsdl/hello.wsdl" and the bundle url
"bundleentry://123.fwk1395908581/resources/wsdl/hello.wsdl". In both
cases I always get the auto-generated wsdl. I really don't know how to
proceed from here.

The fastest way forward at this stage, as far as you experimenting with WSDL-first services is concerned is to build the trunk locally and see what needs to be fixed with respect to retrieving the bundle resources, it must be some minor fix that needs to be applied, otherwise it will be fixed in few months in time for the next release,

Cheers, Sergey

Cheers,

Thomas

On 4/3/2012 9:21 PM, Sergey Beryozkin wrote:
Actually, sorry, the 2nd approach you mentioned originally should work,
meaning the interceptor must've been added, according to
loadProviderClass, however adding a WSS4J interceptor definitely does
not cause the changes to auto-generated WADL afaik...

I wonder if registering a WS-Policy feature manually can help
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/WSPolicyFeature.java


Sergey

On 03/04/12 16:30, Thomas Pischulski wrote:
Hi,

thanks, I tried that earlier since it was recommended on the DOSGi
Reference site but I never made it to run without an Exception. I
changed it to:

List inInterceptors = new ArrayList();
inInterceptors.add(wssIn);
webServiceProps.put("org.apache.cxf.ws.in.interceptors", inInterceptors);

And during runtime I get the following CastClassExecption:

Exception in thread "pool-1-thread-2" java.lang.ClassCastException:
java.util.ArrayList cannot be cast to
org.apache.cxf.interceptor.Interceptor
     at
org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.addInterceptors(AbstractPojoConfigurationTypeHandler.java:211)

     at
org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.addWsInterceptorsFeaturesProps(AbstractPojoConfigurationTypeHandler.java:137)

     at
org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:121)

     at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:247)

     at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:72)

     at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:67)

     at java.security.AccessController.doPrivileged(Native Method)
     at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:66)

     at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:38)

     at
org.apache.cxf.dosgi.topologymanager.TopologyManager$2.run(TopologyManager.java:267)

     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)

Any ideas? Just for my understand, when using the Interceptor approach
the WS-Policy defintions will be automatically written into the WSDL
by CXF, correct?

Cheers,

Thomas

On 4/3/2012 3:13 PM, Sergey Beryozkin wrote:
Hi

On 03/04/12 16:04, Thomas Pischulski wrote:
Hi there,

I started to work with the DOSGi Subproject of Apache CXF and for
the most part everything worked fine until I began trying to add
security to my web service. AFAIK there're two possible methods
implementing WS-Security policies in CXF, right?

1) WSDL-first approach by specifying the *.wsdl location that
the server should publish a lá
props.put("org.apache.cxf.ws.wsdl.location", "/hello.wsdl");

It might be to do with the bug opened against 1.3:
https://issues.apache.org/jira/browse/DOSGI-111

2) Using WSS4J In/Out Interceptors

I tried both of them and the server always published no security
policies at all in my http://localhost:9090/hello?wsdl ([1] Link
to generated WSDL by CXF DOSGi) In the first approach I tested
that the *.wsdl-File is accessible by the bundle and configured
it with the org.apache.cxf.ws.wsdl.location property ([2] Link to
WSDL with manually added WS-Policy stuff) I also specified all
other properties necessary (org.apache.cxf.ws.wsdl.*) from DOSGi
References. The resulting wsdl shows no security bindings at all
and equaled to [1]

Then I tried the second approach with using WSS4JInInterceptors
and again, the resulting WSDL file has shown no difference to
[1]. Here's the Activator code that I used for that method:
Activator.java. I'm using
cxf-dosgi-ri-singlebundle-distribution-1.3 and my favorable
method would be the Interceptor Method. Also I'm trying to avoid
Spring or any other type of XML-based Server/Client
configuration. I was also searching through the mailing list with
moderate success.

I think at [3] you need to wrap wssIn in a List and that should do
it

HTH, Sergey


Up to this point I'm not sure where I'm wrong. Help appreciated.

Cheers,

Thomas

[1] Link to generated WSDL by CXF DOSGi
(http://pastebin.com/d20vNAQN) [2] Link to WSDL with manually
added WS-Policy stuff (http://pastebin.com/d20vNAQN) [3]
Activator.java (http://pastebin.com/YwvDZmvv)



Reply via email to