You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Thomas Pischulski <ne...@googlemail.com> on 2012/04/03 15:04:40 UTC

Adding UsernameToken to WebService in DOSGi

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");
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.

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)

Re: Adding UsernameToken to WebService in DOSGi

Posted by Thomas Pischulski <ne...@gmail.com>.
I also have problems adding OutInterceptors on the Client-side (the client is
also an OSGi bundle). I basically used wsdl2java for generating the client
stub which works fine but when I try to add an WSS4JOutInterceptor for the
UsernameToken I get exceptions that say that some java.sun.xml
implementation is used instead of the CXF JAX-WS

--
View this message in context: http://cxf.547215.n5.nabble.com/Adding-UsernameToken-to-WebService-in-DOSGi-tp5615055p5616117.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Adding UsernameToken to WebService in DOSGi

Posted by Thomas Pischulski <ne...@googlemail.com>.
Hm ok sounds like I just have to wait. I would be very grateful though
for any hints for implementing WS-Policy in a java-based way in CXF
DOSGi (without the help of Spring or whatever). Ideally I'm looking
for something like this
http://www.jroller.com/gmazza/entry/cxf_x509_profile for DOSGi but I
doubt there's anything useful out there?

Cheers,

Thomas

On 4/4/2012 12:53 PM, Sergey Beryozkin wrote:
> 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)
>>> 
>>> 
> 

Re: Adding UsernameToken to WebService in DOSGi

Posted by Sergey Beryozkin <sb...@gmail.com>.
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)
>>
>>


Re: Adding UsernameToken to WebService in DOSGi

Posted by Thomas Pischulski <ne...@googlemail.com>.
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.

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)
> 
> 

Re: Adding UsernameToken to WebService in DOSGi

Posted by Sergey Beryozkin <sb...@gmail.com>.
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)


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: Adding UsernameToken to WebService in DOSGi

Posted by Thomas Pischulski <ne...@googlemail.com>.
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)

Re: Adding UsernameToken to WebService in DOSGi

Posted by Sergey Beryozkin <sb...@gmail.com>.
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)