IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

Hi, I've been trying to wire my WSS4J interceptors into Spring security,
which I was able to do following Freeman's suggestions.
However, I'm facing the (whats looks to be a) common problem with
WebServiceContext when trying to enable method security.

Before adding the global-method-security line everything works well.
When I add it, I get an IllegalArgumentException which complaints that it
cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm not able
to copy the stack trace from here).

I found some posts on the subject, mostly answered by Sergei and jax-RS
related. I learned thatthe issue is related to spring AOP and to CGLIB
proxies and suggesting to add a setter in the service interface to solve te
issue. However, I added a setWebServiceContext(WebServiceContext wsc) to the
service interface, and still have no luck, it fails with identical exception
and message.

I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
2.0.5.RELEASE.
Which steps should I take to be able to use method security?
Thanks again for all the help.

Fwd: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

Daniel, thank you very much for your answer.
I'll give your suggestion a try first thing tomorrow.
Tying this application to CXF wouldn't be an issue, so I'm open to use
anything that might work.

I'm getting the feeling that this might come from Tomcat mixing
different versions of Spring or CXF dependencies. I don't have
different versions in my POM, but it wouldn't be the first time that
copying the exact same code to a new tomcat/eclipse workspace fixes
the problem.

Regards,
              Juan Pedro

2011/1/3 Daniel Kulp <dk...@apache.org>
>
> On Monday 03 January 2011 1:25:26 pm Juan Pedro Silva Gallino (UPM) wrote:
> > I was only able to trace it up to
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with the
> > a reference to the proper method (the init() method in the service)
> > and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
> > on which to invoke it. Afterwards, it goes into the native
> > invoke0() method and throws the exception.
>
> Honestly, I have no idea.   Is there a way you can create a simple test case
> with a modified hello world or similar?
>
> You could probably work around it by just not injecting it and doing:
>
> WebServiceContext context = new
> org.apache.cxf.jaxws.context.WebServiceContextImpl();
>
> (note: no @Resource or anything)
>
> That would tie the implementation to CXF, but that may not be a huge issue for
> you.
>
>
> Dan
>
>
> >
> > Any ideas?.
> > Thanks again.
> >
> >
> >
> > 2011/1/3 Ron Wheeler <rw...@artifact-software.com>
> >
> > > On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
> > >> Ron, I really appreciate your answer.
> > >> With my comment I only meant to ask if you were aware that newer
> > >> versions solved the issue, and by it being rhetorical I meant that I
> > >> should try things before asking that much. I hope you took no offense
> > >> on my comments
> > >>
> > >> :-) .
> > >
> > > Not at all.
> > >
> > >  Again, any perspective from outside helps seeing things more clearly,
> > >  and
> > >
> > >> thanks to you I updated to a newer version of the CXF  framework
> > >> (2.2.12) while keeping the rest untouch. Besides having to enforce the
> > >> use of some saaj version, I ran into no other complications, so I thank
> > >> you for this, as
> > >> your suggestion might have avoided a lot of bugs.
> > >>
> > >>  Sorry that it didn't fix the problem.
> > >
> > >  Regarding the error, it is still there. Again, it only happens when
> > >  adding
> > >
> > >> "global-method-security" to the equation.
> > >> I get an "IllegalArgumentException: Object is not an instance of
> > >> declaring class" after the invocation of
> > >> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
> > >> both
> > >> with and without the setter method for the @Resource WebServiceContext.
> > >>
> > >> Any ideas, anybody?, I can't seem to find any related info on the Web.
> > >> Thanks everybody for your help.
> > >> Regards,
> > >>
> > >>              Juan Pedro
> > >>
> > >> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
> > >>
> > >>  On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
> > >>>  Hi Ron, thanks for your answer.
> > >>>
> > >>>> Regarding the version in use, well, this is sort of a legacy code into
> > >>>> which
> > >>>> I'm adding new authorization functionality, so I was trying to get
> > >>>> away without changing versions just to avoid adding another grade of
> > >>>> uncertainty
> > >>>> from where new errors might come from. Just that.
> > >>>>
> > >>>> Even more, I've never found in the different posts on the topic any
> > >>>> reference to a bug or a functionality that was to be added in future
> > >>>> versions, so I assumed that there was a particular way in which to do
> > >>>> things
> > >>>> to make it work that I was not aware of, not that this was a problem
> > >>>> that
> > >>>> had been addressed in newer versions.
> > >>>>
> > >>>> With that said, I may upgrade to newer versions of the CXF framework.
> > >>>> However, will just doing this solve the WebServiceContext injection
> > >>>> issue?,
> > >>>> I don't get that clearly from your answer and I didn't find anything
> > >>>> online
> > >>>> that would lead me to have such an impression. Anyhow, it is sort of a
> > >>>> rhetorical question, I'll try this first thing in the morning.
> > >>>>
> > >>>>  It was only a general comment that should be easy to test and if it
> > >>>>
> > >>>> works
> > >>>
> > >>> might lead to a more complete explanation and a workaround for the old
> > >>> version.
> > >>> It also keeps the discussion active which is sometimes helpful on
> > >>> weekends
> > >>> and holidays when the real experts may be otherwise occupied and not
> > >>> see your question.
> > >>>
> > >>>
> > >>> Ron
> > >>>
> > >>>  Thanks again,
> > >>>
> > >>>>                      Juan Pedro
> > >>>>
> > >>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
> > >>>>
> > >>>>  On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
> > >>>>>  Hi, I've been trying to wire my WSS4J interceptors into Spring
> > >>>>>
> > >>>>> security,
> > >>>>>
> > >>>>>> which I was able to do following Freeman's suggestions.
> > >>>>>> However, I'm facing the (whats looks to be a) common problem with
> > >>>>>> WebServiceContext when trying to enable method security.
> > >>>>>>
> > >>>>>> Before adding the global-method-security line everything works well.
> > >>>>>> When I add it, I get an IllegalArgumentException which complaints
> > >>>>>> that it
> > >>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm
> > >>>>>> not
> > >>>>>> able
> > >>>>>> to copy the stack trace from here).
> > >>>>>>
> > >>>>>> I found some posts on the subject, mostly answered by Sergei and
> > >>>>>> jax-RS
> > >>>>>> related. I learned thatthe issue is related to spring AOP and to
> > >>>>>> CGLIB proxies and suggesting to add a setter in the service
> > >>>>>> interface to solve
> > >>>>>> te
> > >>>>>> issue. However, I added a setWebServiceContext(WebServiceContext
> > >>>>>> wsc) to
> > >>>>>> the
> > >>>>>> service interface, and still have no luck, it fails with identical
> > >>>>>> exception
> > >>>>>> and message.
> > >>>>>>
> > >>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
> > >>>>>> 2.0.5.RELEASE.
> > >>>>>>
> > >>>>>>  Any reason why you are using such old versions?
> > >>>>>
> > >>>>> I would try to upgrade to newer versions before chasing bugs
> > >>>>>
> > >>>>> Ron
> > >>>>>
> > >>>>>  Which steps should I take to be able to use method security?
> > >>>>>
> > >>>>>  Thanks again for all the help.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog

Re: Fwd: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

[Ron Wheeler <rw...@artifact-software.com>]

On 05/01/2011 7:04 AM, Juan Pedro Silva Gallino (UPM) wrote:
> Thank you very much, Ron, for your suggestion.
> I may have to adopt a similar policy.
> I agree with you on the transitive dependencies.
> I'm using maven inside wclipse (Spring tool suite, to be more
> precise), and the dependencies graph showed nothing that called my
> attention, but since this is not the only project on the tc server,
> you never know.
> Thanks again.
>
We use Eclipse STS as well and I used the dependency graph and list 
extensively to track down each library that I had to exclude.
It took me a few days to clean up and build the 10 or so POMs that handle:
CXF
Spring, Hibernate, MySQL, Tomcat
3rd party utilities - mostly Apache commons
JSF
JasperReports
Velocity
Jetspeed
Our own libraries and utilities

Once I did that, we had no more run-time issues caused by random 
selection of library versions
It also make builds faster and makes the setting up of new modules 
trivial - copy an existing POM, set the GAV, adjust the 4 or 5 
dependencies and start writing code.
Most modules have the same set of dependencies except for JSF, 
JasperReports and Jetspeed so the developer can usually get a good set 
of dependencies by selecting the right POM to copy.

When we set up a new run-time, we simply copy our libraries to Tomcat's 
../lib and we are ready to deploy the webapps.

> 2011/1/4 Ron Wheeler<rw...@artifact-software.com>:
>> On 04/01/2011 6:18 AM, Juan Pedro Silva Gallino (UPM) wrote:
>>> Hi Daniel.
>>> I tried your suggestion with no luck. The same exception kept coming up.
>>> The issue seems to be when calling the "init()" method on the proxy.
>>>
>>> On the other hand, I was able to make it work by adding
>>> <aop:aspectj-autoproxy proxy-target-class="true"/>    to the
>>> configuration (a suggestion I found after hours of googling around,
>>> and which I hadn't seen much). I leave interpretations to you as I'm
>>> not very confident on what goes on inside spring/cxf guts.
>> You can look at the dependency tree for the details but we made sure that we
>> excluded the spring dependency from CXF since it was a lot older than what
>> we wanted to run.
>>
>>> Do you still want me to upload a test code for this?, I may try to
>>> find some time out to create a mock project if you consider it useful.
>>> Best regards and thanks for your and Ron's help .
>>>
>>>
>>> 2011/1/3 Juan Pedro Silva Gallino (UPM)<jp...@gmail.com>
>>>> Daniel, thank you very much for your answer.
>>>> I'll give your suggestion a try first thing tomorrow.
>>>> Tying this application to CXF wouldn't be an issue, so I'm open to use
>>>> anything that might work.
>>>>
>>>> I'm getting the feeling that this might come from Tomcat mixing different
>>>> versions of Spring or CXF dependencies. I don't have different versions in
>>>> my POM, but it wouldn't be the first time that copying the exact same code
>>>> to a new tomcat/eclipse workspace fixes the problem.
>> We have found that it is a good idea to carefully look at what transitive
>> dependencies are dragged in by your primary dependencies.
>> Our applications do not depend on CXF directly but depend on our own library
>> (POM below) that includes CXF with most of the transitive dependencies
>> excluded.
>> This ensures that Tomcat actually loads what we want. Classloaders are not
>> mindreaders and they just load the first version of a library that they come
>> across.
>>
>> We do this with all the 3rd party libraries since without this, it is hard
>> to know what Tomcat is actually using and you get odd problems caused by
>> code written for new versions of libraries being executed with older ones -
>> not good!
>>
>> In the POM below, we build the CXF library that is installed in Tomcat's
>> ../lib folder and used by all web services and clients.
>> It is "provided" in each of the applications that uses or provides web
>> services.
>> The excluded libraries are provided in other shareable library projects.
>> We use a higher version of Velocity than CXF specifies so we excluded it
>> from CXF-bundle and added a dependency on our Velocity library.
>>
>> A big side benefit is that our individual war files are a lot smaller and
>> builds are much faster since they have no CXF code (or Velocity) in them.
>>
>> We do not use dependency management in the parent POM but that is also a
>> good way to move the<cxf-bundle.version>2.2.5</cxf-bundle.version>
>> to a central place. I like to have the version control centralized in the
>> individual POMs so that the parent POM is stable and only the library
>> changes but either approach would be a "Best Practice" in my book.
>> The individual projects just depend on the "right" version of the master pom
>> which includes a property that defines the "right" version of all of our
>> libraries.
>>
>> We have about 12 of these master libraries now. They handle JSF,
>> JasperReports, Spring, Hibernate, My-SQL, the Apache commons libraries as
>> well as our own utilities.
>>
>>
>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>> <description>Includes all of the dependencies required to use CXF that
>>         are not included in lms-pom-shared.
>> Note: Velocity excluded from the bundle but our version added</description>
>> <modelVersion>4.0.0</modelVersion>
>> <parent>
>> <artifactId>lms-pom-master</artifactId>
>> <groupId>com.x</groupId>
>> <version>1.9.1</version>
>> </parent>
>> <groupId>com.x</groupId>
>> <artifactId>lms-pom-cxf</artifactId>
>> <packaging>pom</packaging>
>> <name>Shared CXF</name>
>> <version>1.9.1</version>
>> <properties>
>> <cxf-bundle.version>2.2.5</cxf-bundle.version>
>> <velocity-pom.version>${lms-project.version}</velocity-pom.version>
>> </properties>
>>
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.cxf</groupId>
>> <artifactId>cxf-bundle</artifactId>
>> <version>${cxf-bundle.version}</version>
>> <exclusions>
>> <exclusion>
>> <artifactId>spring-beans</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>spring-context</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>aopalliance</artifactId>
>> <groupId>aopalliance</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>commons-logging</artifactId>
>> <groupId>commons-logging</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>spring-core</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>spring-jms</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>spring-context-support</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>spring-web</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>commons-lang</artifactId>
>> <groupId>commons-lang</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>oro</artifactId>
>> <groupId>oro</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>commons-collections</artifactId>
>> <groupId>commons-collections</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>spring-tx</artifactId>
>> <groupId>org.springframework</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>dom4j</artifactId>
>> <groupId>dom4j</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>commons-codec</artifactId>
>> <groupId>commons-codec</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>antlr</artifactId>
>> <groupId>antlr</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>velocity</artifactId>
>> <groupId>org.apache.velocity</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>xercesImpl</artifactId>
>> <groupId>xerces</groupId>
>> </exclusion>
>> <exclusion>
>> <artifactId>xml-apis</artifactId>
>> <groupId>xml-apis</groupId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>> <dependency>
>> <groupId>com.x</groupId>
>> <artifactId>lms-pom-velocity</artifactId>
>> <version>${velocity-pom.version}</version>
>> <type>pom</type>
>> </dependency>
>> </dependencies>
>> </project>
>>>> Regards,
>>>>                Juan Pedro
>>>>
>>>> 2011/1/3 Daniel Kulp<dk...@apache.org>
>>>>> On Monday 03 January 2011 1:25:26 pm Juan Pedro Silva Gallino (UPM)
>>>>> wrote:
>>>>>> I was only able to trace it up to
>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with
>>>>>> the
>>>>>> a reference to the proper method (the init() method in the service)
>>>>>> and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
>>>>>> on which to invoke it. Afterwards, it goes into the native
>>>>>> invoke0() method and throws the exception.
>>>>> Honestly, I have no idea.   Is there a way you can create a simple test
>>>>> case
>>>>> with a modified hello world or similar?
>>>>>
>>>>> You could probably work around it by just not injecting it and doing:
>>>>>
>>>>> WebServiceContext context = new
>>>>> org.apache.cxf.jaxws.context.WebServiceContextImpl();
>>>>>
>>>>> (note: no @Resource or anything)
>>>>>
>>>>> That would tie the implementation to CXF, but that may not be a huge
>>>>> issue for
>>>>> you.
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>> Any ideas?.
>>>>>> Thanks again.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>>>>>
>>>>>>> On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>> Ron, I really appreciate your answer.
>>>>>>>> With my comment I only meant to ask if you were aware that newer
>>>>>>>> versions solved the issue, and by it being rhetorical I meant that I
>>>>>>>> should try things before asking that much. I hope you took no offense
>>>>>>>> on my comments
>>>>>>>>
>>>>>>>> :-) .
>>>>>>> Not at all.
>>>>>>>
>>>>>>>   Again, any perspective from outside helps seeing things more clearly,
>>>>>>>   and
>>>>>>>
>>>>>>>> thanks to you I updated to a newer version of the CXF  framework
>>>>>>>> (2.2.12) while keeping the rest untouch. Besides having to enforce
>>>>>>>> the
>>>>>>>> use of some saaj version, I ran into no other complications, so I
>>>>>>>> thank
>>>>>>>> you for this, as
>>>>>>>> your suggestion might have avoided a lot of bugs.
>>>>>>>>
>>>>>>>>   Sorry that it didn't fix the problem.
>>>>>>>   Regarding the error, it is still there. Again, it only happens when
>>>>>>>   adding
>>>>>>>
>>>>>>>> "global-method-security" to the equation.
>>>>>>>> I get an "IllegalArgumentException: Object is not an instance of
>>>>>>>> declaring class" after the invocation of
>>>>>>>>
>>>>>>>> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
>>>>>>>> both
>>>>>>>> with and without the setter method for the @Resource
>>>>>>>> WebServiceContext.
>>>>>>>>
>>>>>>>> Any ideas, anybody?, I can't seem to find any related info on the
>>>>>>>> Web.
>>>>>>>> Thanks everybody for your help.
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>>               Juan Pedro
>>>>>>>>
>>>>>>>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>>>>>>>
>>>>>>>>   On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>>>   Hi Ron, thanks for your answer.
>>>>>>>>>
>>>>>>>>>> Regarding the version in use, well, this is sort of a legacy code
>>>>>>>>>> into
>>>>>>>>>> which
>>>>>>>>>> I'm adding new authorization functionality, so I was trying to get
>>>>>>>>>> away without changing versions just to avoid adding another grade
>>>>>>>>>> of
>>>>>>>>>> uncertainty
>>>>>>>>>> from where new errors might come from. Just that.
>>>>>>>>>>
>>>>>>>>>> Even more, I've never found in the different posts on the topic any
>>>>>>>>>> reference to a bug or a functionality that was to be added in
>>>>>>>>>> future
>>>>>>>>>> versions, so I assumed that there was a particular way in which to
>>>>>>>>>> do
>>>>>>>>>> things
>>>>>>>>>> to make it work that I was not aware of, not that this was a
>>>>>>>>>> problem
>>>>>>>>>> that
>>>>>>>>>> had been addressed in newer versions.
>>>>>>>>>>
>>>>>>>>>> With that said, I may upgrade to newer versions of the CXF
>>>>>>>>>> framework.
>>>>>>>>>> However, will just doing this solve the WebServiceContext injection
>>>>>>>>>> issue?,
>>>>>>>>>> I don't get that clearly from your answer and I didn't find
>>>>>>>>>> anything
>>>>>>>>>> online
>>>>>>>>>> that would lead me to have such an impression. Anyhow, it is sort
>>>>>>>>>> of a
>>>>>>>>>> rhetorical question, I'll try this first thing in the morning.
>>>>>>>>>>
>>>>>>>>>>   It was only a general comment that should be easy to test and if
>>>>>>>>>> it
>>>>>>>>>>
>>>>>>>>>> works
>>>>>>>>> might lead to a more complete explanation and a workaround for the
>>>>>>>>> old
>>>>>>>>> version.
>>>>>>>>> It also keeps the discussion active which is sometimes helpful on
>>>>>>>>> weekends
>>>>>>>>> and holidays when the real experts may be otherwise occupied and not
>>>>>>>>> see your question.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ron
>>>>>>>>>
>>>>>>>>>   Thanks again,
>>>>>>>>>
>>>>>>>>>>                       Juan Pedro
>>>>>>>>>>
>>>>>>>>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>>>>>>>>>>
>>>>>>>>>>   On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>>>>>   Hi, I've been trying to wire my WSS4J interceptors into Spring
>>>>>>>>>>>
>>>>>>>>>>> security,
>>>>>>>>>>>
>>>>>>>>>>>> which I was able to do following Freeman's suggestions.
>>>>>>>>>>>> However, I'm facing the (whats looks to be a) common problem with
>>>>>>>>>>>> WebServiceContext when trying to enable method security.
>>>>>>>>>>>>
>>>>>>>>>>>> Before adding the global-method-security line everything works
>>>>>>>>>>>> well.
>>>>>>>>>>>> When I add it, I get an IllegalArgumentException which complaints
>>>>>>>>>>>> that it
>>>>>>>>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry,
>>>>>>>>>>>> I'm
>>>>>>>>>>>> not
>>>>>>>>>>>> able
>>>>>>>>>>>> to copy the stack trace from here).
>>>>>>>>>>>>
>>>>>>>>>>>> I found some posts on the subject, mostly answered by Sergei and
>>>>>>>>>>>> jax-RS
>>>>>>>>>>>> related. I learned thatthe issue is related to spring AOP and to
>>>>>>>>>>>> CGLIB proxies and suggesting to add a setter in the service
>>>>>>>>>>>> interface to solve
>>>>>>>>>>>> te
>>>>>>>>>>>> issue. However, I added a setWebServiceContext(WebServiceContext
>>>>>>>>>>>> wsc) to
>>>>>>>>>>>> the
>>>>>>>>>>>> service interface, and still have no luck, it fails with
>>>>>>>>>>>> identical
>>>>>>>>>>>> exception
>>>>>>>>>>>> and message.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and
>>>>>>>>>>>> Spring-security
>>>>>>>>>>>> 2.0.5.RELEASE.
>>>>>>>>>>>>
>>>>>>>>>>>>   Any reason why you are using such old versions?
>>>>>>>>>>> I would try to upgrade to newer versions before chasing bugs
>>>>>>>>>>>
>>>>>>>>>>> Ron
>>>>>>>>>>>
>>>>>>>>>>>   Which steps should I take to be able to use method security?
>>>>>>>>>>>
>>>>>>>>>>>   Thanks again for all the help.
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org
>>>>> http://dankulp.com/blog
>>

Re: Fwd: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

Thank you very much, Ron, for your suggestion.
I may have to adopt a similar policy.
I agree with you on the transitive dependencies.
I'm using maven inside wclipse (Spring tool suite, to be more
precise), and the dependencies graph showed nothing that called my
attention, but since this is not the only project on the tc server,
you never know.
Thanks again.

2011/1/4 Ron Wheeler <rw...@artifact-software.com>:
> On 04/01/2011 6:18 AM, Juan Pedro Silva Gallino (UPM) wrote:
>>
>> Hi Daniel.
>> I tried your suggestion with no luck. The same exception kept coming up.
>> The issue seems to be when calling the "init()" method on the proxy.
>>
>> On the other hand, I was able to make it work by adding
>> <aop:aspectj-autoproxy proxy-target-class="true"/>  to the
>> configuration (a suggestion I found after hours of googling around,
>> and which I hadn't seen much). I leave interpretations to you as I'm
>> not very confident on what goes on inside spring/cxf guts.
>
> You can look at the dependency tree for the details but we made sure that we
> excluded the spring dependency from CXF since it was a lot older than what
> we wanted to run.
>
>> Do you still want me to upload a test code for this?, I may try to
>> find some time out to create a mock project if you consider it useful.
>> Best regards and thanks for your and Ron's help .
>>
>>
>> 2011/1/3 Juan Pedro Silva Gallino (UPM)<jp...@gmail.com>
>>>
>>> Daniel, thank you very much for your answer.
>>> I'll give your suggestion a try first thing tomorrow.
>>> Tying this application to CXF wouldn't be an issue, so I'm open to use
>>> anything that might work.
>>>
>>> I'm getting the feeling that this might come from Tomcat mixing different
>>> versions of Spring or CXF dependencies. I don't have different versions in
>>> my POM, but it wouldn't be the first time that copying the exact same code
>>> to a new tomcat/eclipse workspace fixes the problem.
>
> We have found that it is a good idea to carefully look at what transitive
> dependencies are dragged in by your primary dependencies.
> Our applications do not depend on CXF directly but depend on our own library
> (POM below) that includes CXF with most of the transitive dependencies
> excluded.
> This ensures that Tomcat actually loads what we want. Classloaders are not
> mindreaders and they just load the first version of a library that they come
> across.
>
> We do this with all the 3rd party libraries since without this, it is hard
> to know what Tomcat is actually using and you get odd problems caused by
> code written for new versions of libraries being executed with older ones -
> not good!
>
> In the POM below, we build the CXF library that is installed in Tomcat's
> ../lib folder and used by all web services and clients.
> It is "provided" in each of the applications that uses or provides web
> services.
> The excluded libraries are provided in other shareable library projects.
> We use a higher version of Velocity than CXF specifies so we excluded it
> from CXF-bundle and added a dependency on our Velocity library.
>
> A big side benefit is that our individual war files are a lot smaller and
> builds are much faster since they have no CXF code (or Velocity) in them.
>
> We do not use dependency management in the parent POM but that is also a
> good way to move the <cxf-bundle.version>2.2.5</cxf-bundle.version>
> to a central place. I like to have the version control centralized in the
> individual POMs so that the parent POM is stable and only the library
> changes but either approach would be a "Best Practice" in my book.
> The individual projects just depend on the "right" version of the master pom
> which includes a property that defines the "right" version of all of our
> libraries.
>
> We have about 12 of these master libraries now. They handle JSF,
> JasperReports, Spring, Hibernate, My-SQL, the Apache commons libraries as
> well as our own utilities.
>
>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd">
> <description>Includes all of the dependencies required to use CXF that
>        are not included in lms-pom-shared.
> Note: Velocity excluded from the bundle but our version added</description>
> <modelVersion>4.0.0</modelVersion>
> <parent>
> <artifactId>lms-pom-master</artifactId>
> <groupId>com.x</groupId>
> <version>1.9.1</version>
> </parent>
> <groupId>com.x</groupId>
> <artifactId>lms-pom-cxf</artifactId>
> <packaging>pom</packaging>
> <name>Shared CXF </name>
> <version>1.9.1</version>
> <properties>
> <cxf-bundle.version>2.2.5</cxf-bundle.version>
> <velocity-pom.version>${lms-project.version}</velocity-pom.version>
> </properties>
>
> <dependencies>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-bundle</artifactId>
> <version>${cxf-bundle.version}</version>
> <exclusions>
> <exclusion>
> <artifactId>spring-beans</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>spring-context</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>aopalliance</artifactId>
> <groupId>aopalliance</groupId>
> </exclusion>
> <exclusion>
> <artifactId>commons-logging</artifactId>
> <groupId>commons-logging</groupId>
> </exclusion>
> <exclusion>
> <artifactId>spring-core</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>spring-jms</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>spring-context-support</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>spring-web</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>commons-lang</artifactId>
> <groupId>commons-lang</groupId>
> </exclusion>
> <exclusion>
> <artifactId>oro</artifactId>
> <groupId>oro</groupId>
> </exclusion>
> <exclusion>
> <artifactId>commons-collections</artifactId>
> <groupId>commons-collections</groupId>
> </exclusion>
> <exclusion>
> <artifactId>spring-tx</artifactId>
> <groupId>org.springframework</groupId>
> </exclusion>
> <exclusion>
> <artifactId>dom4j</artifactId>
> <groupId>dom4j</groupId>
> </exclusion>
> <exclusion>
> <artifactId>commons-codec</artifactId>
> <groupId>commons-codec</groupId>
> </exclusion>
> <exclusion>
> <artifactId>antlr</artifactId>
> <groupId>antlr</groupId>
> </exclusion>
> <exclusion>
> <artifactId>velocity</artifactId>
> <groupId>org.apache.velocity</groupId>
> </exclusion>
> <exclusion>
> <artifactId>xercesImpl</artifactId>
> <groupId>xerces</groupId>
> </exclusion>
> <exclusion>
> <artifactId>xml-apis</artifactId>
> <groupId>xml-apis</groupId>
> </exclusion>
> </exclusions>
> </dependency>
> <dependency>
> <groupId>com.x</groupId>
> <artifactId>lms-pom-velocity</artifactId>
> <version>${velocity-pom.version}</version>
> <type>pom</type>
> </dependency>
> </dependencies>
> </project>
>>>
>>> Regards,
>>>               Juan Pedro
>>>
>>> 2011/1/3 Daniel Kulp<dk...@apache.org>
>>>>
>>>> On Monday 03 January 2011 1:25:26 pm Juan Pedro Silva Gallino (UPM)
>>>> wrote:
>>>>>
>>>>> I was only able to trace it up to
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with
>>>>> the
>>>>> a reference to the proper method (the init() method in the service)
>>>>> and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
>>>>> on which to invoke it. Afterwards, it goes into the native
>>>>> invoke0() method and throws the exception.
>>>>
>>>> Honestly, I have no idea.   Is there a way you can create a simple test
>>>> case
>>>> with a modified hello world or similar?
>>>>
>>>> You could probably work around it by just not injecting it and doing:
>>>>
>>>> WebServiceContext context = new
>>>> org.apache.cxf.jaxws.context.WebServiceContextImpl();
>>>>
>>>> (note: no @Resource or anything)
>>>>
>>>> That would tie the implementation to CXF, but that may not be a huge
>>>> issue for
>>>> you.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>> Any ideas?.
>>>>> Thanks again.
>>>>>
>>>>>
>>>>>
>>>>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>>>>
>>>>>> On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>
>>>>>>> Ron, I really appreciate your answer.
>>>>>>> With my comment I only meant to ask if you were aware that newer
>>>>>>> versions solved the issue, and by it being rhetorical I meant that I
>>>>>>> should try things before asking that much. I hope you took no offense
>>>>>>> on my comments
>>>>>>>
>>>>>>> :-) .
>>>>>>
>>>>>> Not at all.
>>>>>>
>>>>>>  Again, any perspective from outside helps seeing things more clearly,
>>>>>>  and
>>>>>>
>>>>>>> thanks to you I updated to a newer version of the CXF  framework
>>>>>>> (2.2.12) while keeping the rest untouch. Besides having to enforce
>>>>>>> the
>>>>>>> use of some saaj version, I ran into no other complications, so I
>>>>>>> thank
>>>>>>> you for this, as
>>>>>>> your suggestion might have avoided a lot of bugs.
>>>>>>>
>>>>>>>  Sorry that it didn't fix the problem.
>>>>>>
>>>>>>  Regarding the error, it is still there. Again, it only happens when
>>>>>>  adding
>>>>>>
>>>>>>> "global-method-security" to the equation.
>>>>>>> I get an "IllegalArgumentException: Object is not an instance of
>>>>>>> declaring class" after the invocation of
>>>>>>>
>>>>>>> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
>>>>>>> both
>>>>>>> with and without the setter method for the @Resource
>>>>>>> WebServiceContext.
>>>>>>>
>>>>>>> Any ideas, anybody?, I can't seem to find any related info on the
>>>>>>> Web.
>>>>>>> Thanks everybody for your help.
>>>>>>> Regards,
>>>>>>>
>>>>>>>              Juan Pedro
>>>>>>>
>>>>>>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>>>>>>
>>>>>>>  On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>>
>>>>>>>>  Hi Ron, thanks for your answer.
>>>>>>>>
>>>>>>>>> Regarding the version in use, well, this is sort of a legacy code
>>>>>>>>> into
>>>>>>>>> which
>>>>>>>>> I'm adding new authorization functionality, so I was trying to get
>>>>>>>>> away without changing versions just to avoid adding another grade
>>>>>>>>> of
>>>>>>>>> uncertainty
>>>>>>>>> from where new errors might come from. Just that.
>>>>>>>>>
>>>>>>>>> Even more, I've never found in the different posts on the topic any
>>>>>>>>> reference to a bug or a functionality that was to be added in
>>>>>>>>> future
>>>>>>>>> versions, so I assumed that there was a particular way in which to
>>>>>>>>> do
>>>>>>>>> things
>>>>>>>>> to make it work that I was not aware of, not that this was a
>>>>>>>>> problem
>>>>>>>>> that
>>>>>>>>> had been addressed in newer versions.
>>>>>>>>>
>>>>>>>>> With that said, I may upgrade to newer versions of the CXF
>>>>>>>>> framework.
>>>>>>>>> However, will just doing this solve the WebServiceContext injection
>>>>>>>>> issue?,
>>>>>>>>> I don't get that clearly from your answer and I didn't find
>>>>>>>>> anything
>>>>>>>>> online
>>>>>>>>> that would lead me to have such an impression. Anyhow, it is sort
>>>>>>>>> of a
>>>>>>>>> rhetorical question, I'll try this first thing in the morning.
>>>>>>>>>
>>>>>>>>>  It was only a general comment that should be easy to test and if
>>>>>>>>> it
>>>>>>>>>
>>>>>>>>> works
>>>>>>>>
>>>>>>>> might lead to a more complete explanation and a workaround for the
>>>>>>>> old
>>>>>>>> version.
>>>>>>>> It also keeps the discussion active which is sometimes helpful on
>>>>>>>> weekends
>>>>>>>> and holidays when the real experts may be otherwise occupied and not
>>>>>>>> see your question.
>>>>>>>>
>>>>>>>>
>>>>>>>> Ron
>>>>>>>>
>>>>>>>>  Thanks again,
>>>>>>>>
>>>>>>>>>                      Juan Pedro
>>>>>>>>>
>>>>>>>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>>>>>>>>>
>>>>>>>>>  On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>>>>
>>>>>>>>>>  Hi, I've been trying to wire my WSS4J interceptors into Spring
>>>>>>>>>>
>>>>>>>>>> security,
>>>>>>>>>>
>>>>>>>>>>> which I was able to do following Freeman's suggestions.
>>>>>>>>>>> However, I'm facing the (whats looks to be a) common problem with
>>>>>>>>>>> WebServiceContext when trying to enable method security.
>>>>>>>>>>>
>>>>>>>>>>> Before adding the global-method-security line everything works
>>>>>>>>>>> well.
>>>>>>>>>>> When I add it, I get an IllegalArgumentException which complaints
>>>>>>>>>>> that it
>>>>>>>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry,
>>>>>>>>>>> I'm
>>>>>>>>>>> not
>>>>>>>>>>> able
>>>>>>>>>>> to copy the stack trace from here).
>>>>>>>>>>>
>>>>>>>>>>> I found some posts on the subject, mostly answered by Sergei and
>>>>>>>>>>> jax-RS
>>>>>>>>>>> related. I learned thatthe issue is related to spring AOP and to
>>>>>>>>>>> CGLIB proxies and suggesting to add a setter in the service
>>>>>>>>>>> interface to solve
>>>>>>>>>>> te
>>>>>>>>>>> issue. However, I added a setWebServiceContext(WebServiceContext
>>>>>>>>>>> wsc) to
>>>>>>>>>>> the
>>>>>>>>>>> service interface, and still have no luck, it fails with
>>>>>>>>>>> identical
>>>>>>>>>>> exception
>>>>>>>>>>> and message.
>>>>>>>>>>>
>>>>>>>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and
>>>>>>>>>>> Spring-security
>>>>>>>>>>> 2.0.5.RELEASE.
>>>>>>>>>>>
>>>>>>>>>>>  Any reason why you are using such old versions?
>>>>>>>>>>
>>>>>>>>>> I would try to upgrade to newer versions before chasing bugs
>>>>>>>>>>
>>>>>>>>>> Ron
>>>>>>>>>>
>>>>>>>>>>  Which steps should I take to be able to use method security?
>>>>>>>>>>
>>>>>>>>>>  Thanks again for all the help.
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>
>

Re: Fwd: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

[Ron Wheeler <rw...@artifact-software.com>]

On 04/01/2011 6:18 AM, Juan Pedro Silva Gallino (UPM) wrote:
> Hi Daniel.
> I tried your suggestion with no luck. The same exception kept coming up.
> The issue seems to be when calling the "init()" method on the proxy.
>
> On the other hand, I was able to make it work by adding
> <aop:aspectj-autoproxy proxy-target-class="true"/>  to the
> configuration (a suggestion I found after hours of googling around,
> and which I hadn't seen much). I leave interpretations to you as I'm
> not very confident on what goes on inside spring/cxf guts.

You can look at the dependency tree for the details but we made sure 
that we excluded the spring dependency from CXF since it was a lot older 
than what we wanted to run.

> Do you still want me to upload a test code for this?, I may try to
> find some time out to create a mock project if you consider it useful.
> Best regards and thanks for your and Ron's help .
>
>
> 2011/1/3 Juan Pedro Silva Gallino (UPM)<jp...@gmail.com>
>> Daniel, thank you very much for your answer.
>> I'll give your suggestion a try first thing tomorrow.
>> Tying this application to CXF wouldn't be an issue, so I'm open to use anything that might work.
>>
>> I'm getting the feeling that this might come from Tomcat mixing different versions of Spring or CXF dependencies. I don't have different versions in my POM, but it wouldn't be the first time that copying the exact same code to a new tomcat/eclipse workspace fixes the problem.

We have found that it is a good idea to carefully look at what 
transitive dependencies are dragged in by your primary dependencies.
Our applications do not depend on CXF directly but depend on our own 
library (POM below) that includes CXF with most of the transitive 
dependencies excluded.
This ensures that Tomcat actually loads what we want. Classloaders are 
not mindreaders and they just load the first version of a library that 
they come across.

We do this with all the 3rd party libraries since without this, it is 
hard to know what Tomcat is actually using and you get odd problems 
caused by code written for new versions of libraries being executed with 
older ones - not good!

In the POM below, we build the CXF library that is installed in Tomcat's 
../lib folder and used by all web services and clients.
It is "provided" in each of the applications that uses or provides web 
services.
The excluded libraries are provided in other shareable library projects.
We use a higher version of Velocity than CXF specifies so we excluded it 
from CXF-bundle and added a dependency on our Velocity library.

A big side benefit is that our individual war files are a lot smaller 
and builds are much faster since they have no CXF code (or Velocity) in 
them.

We do not use dependency management in the parent POM but that is also a 
good way to move the <cxf-bundle.version>2.2.5</cxf-bundle.version>
to a central place. I like to have the version control centralized in 
the individual POMs so that the parent POM is stable and only the 
library changes but either approach would be a "Best Practice" in my book.
The individual projects just depend on the "right" version of the master 
pom which includes a property that defines the "right" version of all of 
our libraries.

We have about 12 of these master libraries now. They handle JSF, 
JasperReports, Spring, Hibernate, My-SQL, the Apache commons libraries 
as well as our own utilities.


<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd">
<description>Includes all of the dependencies required to use CXF that
         are not included in lms-pom-shared.
Note: Velocity excluded from the bundle but our version added</description>
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>lms-pom-master</artifactId>
<groupId>com.x</groupId>
<version>1.9.1</version>
</parent>
<groupId>com.x</groupId>
<artifactId>lms-pom-cxf</artifactId>
<packaging>pom</packaging>
<name>Shared CXF </name>
<version>1.9.1</version>
<properties>
<cxf-bundle.version>2.2.5</cxf-bundle.version>
<velocity-pom.version>${lms-project.version}</velocity-pom.version>
</properties>

<dependencies>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>${cxf-bundle.version}</version>
<exclusions>
<exclusion>
<artifactId>spring-beans</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-context</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>aopalliance</artifactId>
<groupId>aopalliance</groupId>
</exclusion>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
<exclusion>
<artifactId>spring-core</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-jms</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-context-support</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-web</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>commons-lang</artifactId>
<groupId>commons-lang</groupId>
</exclusion>
<exclusion>
<artifactId>oro</artifactId>
<groupId>oro</groupId>
</exclusion>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
<exclusion>
<artifactId>spring-tx</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>dom4j</artifactId>
<groupId>dom4j</groupId>
</exclusion>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
<exclusion>
<artifactId>antlr</artifactId>
<groupId>antlr</groupId>
</exclusion>
<exclusion>
<artifactId>velocity</artifactId>
<groupId>org.apache.velocity</groupId>
</exclusion>
<exclusion>
<artifactId>xercesImpl</artifactId>
<groupId>xerces</groupId>
</exclusion>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.x</groupId>
<artifactId>lms-pom-velocity</artifactId>
<version>${velocity-pom.version}</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
>> Regards,
>>                Juan Pedro
>>
>> 2011/1/3 Daniel Kulp<dk...@apache.org>
>>> On Monday 03 January 2011 1:25:26 pm Juan Pedro Silva Gallino (UPM) wrote:
>>>> I was only able to trace it up to
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with the
>>>> a reference to the proper method (the init() method in the service)
>>>> and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
>>>> on which to invoke it. Afterwards, it goes into the native
>>>> invoke0() method and throws the exception.
>>> Honestly, I have no idea.   Is there a way you can create a simple test case
>>> with a modified hello world or similar?
>>>
>>> You could probably work around it by just not injecting it and doing:
>>>
>>> WebServiceContext context = new
>>> org.apache.cxf.jaxws.context.WebServiceContextImpl();
>>>
>>> (note: no @Resource or anything)
>>>
>>> That would tie the implementation to CXF, but that may not be a huge issue for
>>> you.
>>>
>>>
>>> Dan
>>>
>>>
>>>> Any ideas?.
>>>> Thanks again.
>>>>
>>>>
>>>>
>>>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>>>
>>>>> On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>> Ron, I really appreciate your answer.
>>>>>> With my comment I only meant to ask if you were aware that newer
>>>>>> versions solved the issue, and by it being rhetorical I meant that I
>>>>>> should try things before asking that much. I hope you took no offense
>>>>>> on my comments
>>>>>>
>>>>>> :-) .
>>>>> Not at all.
>>>>>
>>>>>   Again, any perspective from outside helps seeing things more clearly,
>>>>>   and
>>>>>
>>>>>> thanks to you I updated to a newer version of the CXF  framework
>>>>>> (2.2.12) while keeping the rest untouch. Besides having to enforce the
>>>>>> use of some saaj version, I ran into no other complications, so I thank
>>>>>> you for this, as
>>>>>> your suggestion might have avoided a lot of bugs.
>>>>>>
>>>>>>   Sorry that it didn't fix the problem.
>>>>>   Regarding the error, it is still there. Again, it only happens when
>>>>>   adding
>>>>>
>>>>>> "global-method-security" to the equation.
>>>>>> I get an "IllegalArgumentException: Object is not an instance of
>>>>>> declaring class" after the invocation of
>>>>>> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
>>>>>> both
>>>>>> with and without the setter method for the @Resource WebServiceContext.
>>>>>>
>>>>>> Any ideas, anybody?, I can't seem to find any related info on the Web.
>>>>>> Thanks everybody for your help.
>>>>>> Regards,
>>>>>>
>>>>>>               Juan Pedro
>>>>>>
>>>>>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>>>>>
>>>>>>   On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>   Hi Ron, thanks for your answer.
>>>>>>>
>>>>>>>> Regarding the version in use, well, this is sort of a legacy code into
>>>>>>>> which
>>>>>>>> I'm adding new authorization functionality, so I was trying to get
>>>>>>>> away without changing versions just to avoid adding another grade of
>>>>>>>> uncertainty
>>>>>>>> from where new errors might come from. Just that.
>>>>>>>>
>>>>>>>> Even more, I've never found in the different posts on the topic any
>>>>>>>> reference to a bug or a functionality that was to be added in future
>>>>>>>> versions, so I assumed that there was a particular way in which to do
>>>>>>>> things
>>>>>>>> to make it work that I was not aware of, not that this was a problem
>>>>>>>> that
>>>>>>>> had been addressed in newer versions.
>>>>>>>>
>>>>>>>> With that said, I may upgrade to newer versions of the CXF framework.
>>>>>>>> However, will just doing this solve the WebServiceContext injection
>>>>>>>> issue?,
>>>>>>>> I don't get that clearly from your answer and I didn't find anything
>>>>>>>> online
>>>>>>>> that would lead me to have such an impression. Anyhow, it is sort of a
>>>>>>>> rhetorical question, I'll try this first thing in the morning.
>>>>>>>>
>>>>>>>>   It was only a general comment that should be easy to test and if it
>>>>>>>>
>>>>>>>> works
>>>>>>> might lead to a more complete explanation and a workaround for the old
>>>>>>> version.
>>>>>>> It also keeps the discussion active which is sometimes helpful on
>>>>>>> weekends
>>>>>>> and holidays when the real experts may be otherwise occupied and not
>>>>>>> see your question.
>>>>>>>
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>>   Thanks again,
>>>>>>>
>>>>>>>>                       Juan Pedro
>>>>>>>>
>>>>>>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>>>>>>>>
>>>>>>>>   On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>>>>>>   Hi, I've been trying to wire my WSS4J interceptors into Spring
>>>>>>>>>
>>>>>>>>> security,
>>>>>>>>>
>>>>>>>>>> which I was able to do following Freeman's suggestions.
>>>>>>>>>> However, I'm facing the (whats looks to be a) common problem with
>>>>>>>>>> WebServiceContext when trying to enable method security.
>>>>>>>>>>
>>>>>>>>>> Before adding the global-method-security line everything works well.
>>>>>>>>>> When I add it, I get an IllegalArgumentException which complaints
>>>>>>>>>> that it
>>>>>>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm
>>>>>>>>>> not
>>>>>>>>>> able
>>>>>>>>>> to copy the stack trace from here).
>>>>>>>>>>
>>>>>>>>>> I found some posts on the subject, mostly answered by Sergei and
>>>>>>>>>> jax-RS
>>>>>>>>>> related. I learned thatthe issue is related to spring AOP and to
>>>>>>>>>> CGLIB proxies and suggesting to add a setter in the service
>>>>>>>>>> interface to solve
>>>>>>>>>> te
>>>>>>>>>> issue. However, I added a setWebServiceContext(WebServiceContext
>>>>>>>>>> wsc) to
>>>>>>>>>> the
>>>>>>>>>> service interface, and still have no luck, it fails with identical
>>>>>>>>>> exception
>>>>>>>>>> and message.
>>>>>>>>>>
>>>>>>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>>>>>>>>>> 2.0.5.RELEASE.
>>>>>>>>>>
>>>>>>>>>>   Any reason why you are using such old versions?
>>>>>>>>> I would try to upgrade to newer versions before chasing bugs
>>>>>>>>>
>>>>>>>>> Ron
>>>>>>>>>
>>>>>>>>>   Which steps should I take to be able to use method security?
>>>>>>>>>
>>>>>>>>>   Thanks again for all the help.
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog

Fwd: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

Hi Daniel.
I tried your suggestion with no luck. The same exception kept coming up.
The issue seems to be when calling the "init()" method on the proxy.

On the other hand, I was able to make it work by adding
<aop:aspectj-autoproxy proxy-target-class="true"/> to the
configuration (a suggestion I found after hours of googling around,
and which I hadn't seen much). I leave interpretations to you as I'm
not very confident on what goes on inside spring/cxf guts.

Do you still want me to upload a test code for this?, I may try to
find some time out to create a mock project if you consider it useful.
Best regards and thanks for your and Ron's help .


2011/1/3 Juan Pedro Silva Gallino (UPM) <jp...@gmail.com>
>
> Daniel, thank you very much for your answer.
> I'll give your suggestion a try first thing tomorrow.
> Tying this application to CXF wouldn't be an issue, so I'm open to use anything that might work.
>
> I'm getting the feeling that this might come from Tomcat mixing different versions of Spring or CXF dependencies. I don't have different versions in my POM, but it wouldn't be the first time that copying the exact same code to a new tomcat/eclipse workspace fixes the problem.
>
> Regards,
>               Juan Pedro
>
> 2011/1/3 Daniel Kulp <dk...@apache.org>
>>
>> On Monday 03 January 2011 1:25:26 pm Juan Pedro Silva Gallino (UPM) wrote:
>> > I was only able to trace it up to
>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with the
>> > a reference to the proper method (the init() method in the service)
>> > and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
>> > on which to invoke it. Afterwards, it goes into the native
>> > invoke0() method and throws the exception.
>>
>> Honestly, I have no idea.   Is there a way you can create a simple test case
>> with a modified hello world or similar?
>>
>> You could probably work around it by just not injecting it and doing:
>>
>> WebServiceContext context = new
>> org.apache.cxf.jaxws.context.WebServiceContextImpl();
>>
>> (note: no @Resource or anything)
>>
>> That would tie the implementation to CXF, but that may not be a huge issue for
>> you.
>>
>>
>> Dan
>>
>>
>> >
>> > Any ideas?.
>> > Thanks again.
>> >
>> >
>> >
>> > 2011/1/3 Ron Wheeler <rw...@artifact-software.com>
>> >
>> > > On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
>> > >> Ron, I really appreciate your answer.
>> > >> With my comment I only meant to ask if you were aware that newer
>> > >> versions solved the issue, and by it being rhetorical I meant that I
>> > >> should try things before asking that much. I hope you took no offense
>> > >> on my comments
>> > >>
>> > >> :-) .
>> > >
>> > > Not at all.
>> > >
>> > >  Again, any perspective from outside helps seeing things more clearly,
>> > >  and
>> > >
>> > >> thanks to you I updated to a newer version of the CXF  framework
>> > >> (2.2.12) while keeping the rest untouch. Besides having to enforce the
>> > >> use of some saaj version, I ran into no other complications, so I thank
>> > >> you for this, as
>> > >> your suggestion might have avoided a lot of bugs.
>> > >>
>> > >>  Sorry that it didn't fix the problem.
>> > >
>> > >  Regarding the error, it is still there. Again, it only happens when
>> > >  adding
>> > >
>> > >> "global-method-security" to the equation.
>> > >> I get an "IllegalArgumentException: Object is not an instance of
>> > >> declaring class" after the invocation of
>> > >> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
>> > >> both
>> > >> with and without the setter method for the @Resource WebServiceContext.
>> > >>
>> > >> Any ideas, anybody?, I can't seem to find any related info on the Web.
>> > >> Thanks everybody for your help.
>> > >> Regards,
>> > >>
>> > >>              Juan Pedro
>> > >>
>> > >> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>> > >>
>> > >>  On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>> > >>>  Hi Ron, thanks for your answer.
>> > >>>
>> > >>>> Regarding the version in use, well, this is sort of a legacy code into
>> > >>>> which
>> > >>>> I'm adding new authorization functionality, so I was trying to get
>> > >>>> away without changing versions just to avoid adding another grade of
>> > >>>> uncertainty
>> > >>>> from where new errors might come from. Just that.
>> > >>>>
>> > >>>> Even more, I've never found in the different posts on the topic any
>> > >>>> reference to a bug or a functionality that was to be added in future
>> > >>>> versions, so I assumed that there was a particular way in which to do
>> > >>>> things
>> > >>>> to make it work that I was not aware of, not that this was a problem
>> > >>>> that
>> > >>>> had been addressed in newer versions.
>> > >>>>
>> > >>>> With that said, I may upgrade to newer versions of the CXF framework.
>> > >>>> However, will just doing this solve the WebServiceContext injection
>> > >>>> issue?,
>> > >>>> I don't get that clearly from your answer and I didn't find anything
>> > >>>> online
>> > >>>> that would lead me to have such an impression. Anyhow, it is sort of a
>> > >>>> rhetorical question, I'll try this first thing in the morning.
>> > >>>>
>> > >>>>  It was only a general comment that should be easy to test and if it
>> > >>>>
>> > >>>> works
>> > >>>
>> > >>> might lead to a more complete explanation and a workaround for the old
>> > >>> version.
>> > >>> It also keeps the discussion active which is sometimes helpful on
>> > >>> weekends
>> > >>> and holidays when the real experts may be otherwise occupied and not
>> > >>> see your question.
>> > >>>
>> > >>>
>> > >>> Ron
>> > >>>
>> > >>>  Thanks again,
>> > >>>
>> > >>>>                      Juan Pedro
>> > >>>>
>> > >>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>> > >>>>
>> > >>>>  On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>> > >>>>>  Hi, I've been trying to wire my WSS4J interceptors into Spring
>> > >>>>>
>> > >>>>> security,
>> > >>>>>
>> > >>>>>> which I was able to do following Freeman's suggestions.
>> > >>>>>> However, I'm facing the (whats looks to be a) common problem with
>> > >>>>>> WebServiceContext when trying to enable method security.
>> > >>>>>>
>> > >>>>>> Before adding the global-method-security line everything works well.
>> > >>>>>> When I add it, I get an IllegalArgumentException which complaints
>> > >>>>>> that it
>> > >>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm
>> > >>>>>> not
>> > >>>>>> able
>> > >>>>>> to copy the stack trace from here).
>> > >>>>>>
>> > >>>>>> I found some posts on the subject, mostly answered by Sergei and
>> > >>>>>> jax-RS
>> > >>>>>> related. I learned thatthe issue is related to spring AOP and to
>> > >>>>>> CGLIB proxies and suggesting to add a setter in the service
>> > >>>>>> interface to solve
>> > >>>>>> te
>> > >>>>>> issue. However, I added a setWebServiceContext(WebServiceContext
>> > >>>>>> wsc) to
>> > >>>>>> the
>> > >>>>>> service interface, and still have no luck, it fails with identical
>> > >>>>>> exception
>> > >>>>>> and message.
>> > >>>>>>
>> > >>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>> > >>>>>> 2.0.5.RELEASE.
>> > >>>>>>
>> > >>>>>>  Any reason why you are using such old versions?
>> > >>>>>
>> > >>>>> I would try to upgrade to newer versions before chasing bugs
>> > >>>>>
>> > >>>>> Ron
>> > >>>>>
>> > >>>>>  Which steps should I take to be able to use method security?
>> > >>>>>
>> > >>>>>  Thanks again for all the help.
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

[Daniel Kulp <dk...@apache.org>]

On Monday 03 January 2011 1:25:26 pm Juan Pedro Silva Gallino (UPM) wrote:
> I was only able to trace it up to
> sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with the
> a reference to the proper method (the init() method in the service)
> and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
> on which to invoke it. Afterwards, it goes into the native
> invoke0() method and throws the exception.

Honestly, I have no idea.   Is there a way you can create a simple test case 
with a modified hello world or similar?

You could probably work around it by just not injecting it and doing:

WebServiceContext context = new 
org.apache.cxf.jaxws.context.WebServiceContextImpl();

(note: no @Resource or anything)

That would tie the implementation to CXF, but that may not be a huge issue for 
you.   


Dan


> 
> Any ideas?.
> Thanks again.
> 
> 
> 
> 2011/1/3 Ron Wheeler <rw...@artifact-software.com>
> 
> > On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
> >> Ron, I really appreciate your answer.
> >> With my comment I only meant to ask if you were aware that newer
> >> versions solved the issue, and by it being rhetorical I meant that I
> >> should try things before asking that much. I hope you took no offense
> >> on my comments
> >> 
> >> :-) .
> > 
> > Not at all.
> > 
> >  Again, any perspective from outside helps seeing things more clearly,
> >  and
> >  
> >> thanks to you I updated to a newer version of the CXF  framework
> >> (2.2.12) while keeping the rest untouch. Besides having to enforce the
> >> use of some saaj version, I ran into no other complications, so I thank
> >> you for this, as
> >> your suggestion might have avoided a lot of bugs.
> >> 
> >>  Sorry that it didn't fix the problem.
> >  
> >  Regarding the error, it is still there. Again, it only happens when
> >  adding
> >  
> >> "global-method-security" to the equation.
> >> I get an "IllegalArgumentException: Object is not an instance of
> >> declaring class" after the invocation of
> >> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
> >> both
> >> with and without the setter method for the @Resource WebServiceContext.
> >> 
> >> Any ideas, anybody?, I can't seem to find any related info on the Web.
> >> Thanks everybody for your help.
> >> Regards,
> >> 
> >>              Juan Pedro
> >> 
> >> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
> >> 
> >>  On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
> >>>  Hi Ron, thanks for your answer.
> >>>  
> >>>> Regarding the version in use, well, this is sort of a legacy code into
> >>>> which
> >>>> I'm adding new authorization functionality, so I was trying to get
> >>>> away without changing versions just to avoid adding another grade of
> >>>> uncertainty
> >>>> from where new errors might come from. Just that.
> >>>> 
> >>>> Even more, I've never found in the different posts on the topic any
> >>>> reference to a bug or a functionality that was to be added in future
> >>>> versions, so I assumed that there was a particular way in which to do
> >>>> things
> >>>> to make it work that I was not aware of, not that this was a problem
> >>>> that
> >>>> had been addressed in newer versions.
> >>>> 
> >>>> With that said, I may upgrade to newer versions of the CXF framework.
> >>>> However, will just doing this solve the WebServiceContext injection
> >>>> issue?,
> >>>> I don't get that clearly from your answer and I didn't find anything
> >>>> online
> >>>> that would lead me to have such an impression. Anyhow, it is sort of a
> >>>> rhetorical question, I'll try this first thing in the morning.
> >>>> 
> >>>>  It was only a general comment that should be easy to test and if it
> >>>> 
> >>>> works
> >>> 
> >>> might lead to a more complete explanation and a workaround for the old
> >>> version.
> >>> It also keeps the discussion active which is sometimes helpful on
> >>> weekends
> >>> and holidays when the real experts may be otherwise occupied and not
> >>> see your question.
> >>> 
> >>> 
> >>> Ron
> >>> 
> >>>  Thanks again,
> >>>  
> >>>>                      Juan Pedro
> >>>> 
> >>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
> >>>> 
> >>>>  On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
> >>>>>  Hi, I've been trying to wire my WSS4J interceptors into Spring
> >>>>> 
> >>>>> security,
> >>>>> 
> >>>>>> which I was able to do following Freeman's suggestions.
> >>>>>> However, I'm facing the (whats looks to be a) common problem with
> >>>>>> WebServiceContext when trying to enable method security.
> >>>>>> 
> >>>>>> Before adding the global-method-security line everything works well.
> >>>>>> When I add it, I get an IllegalArgumentException which complaints
> >>>>>> that it
> >>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm
> >>>>>> not
> >>>>>> able
> >>>>>> to copy the stack trace from here).
> >>>>>> 
> >>>>>> I found some posts on the subject, mostly answered by Sergei and
> >>>>>> jax-RS
> >>>>>> related. I learned thatthe issue is related to spring AOP and to
> >>>>>> CGLIB proxies and suggesting to add a setter in the service
> >>>>>> interface to solve
> >>>>>> te
> >>>>>> issue. However, I added a setWebServiceContext(WebServiceContext
> >>>>>> wsc) to
> >>>>>> the
> >>>>>> service interface, and still have no luck, it fails with identical
> >>>>>> exception
> >>>>>> and message.
> >>>>>> 
> >>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
> >>>>>> 2.0.5.RELEASE.
> >>>>>> 
> >>>>>>  Any reason why you are using such old versions?
> >>>>> 
> >>>>> I would try to upgrade to newer versions before chasing bugs
> >>>>> 
> >>>>> Ron
> >>>>> 
> >>>>>  Which steps should I take to be able to use method security?
> >>>>>  
> >>>>>  Thanks again for all the help.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

I was only able to trace it up to
sun.reflect.DelegatingMethodAccessorImpl.invoke(), which is called with the
a reference to the proper method (the init() method in the service)
and aorg.springframework.aop.framework.JdkDynamicAopProxyas the object
on which to invoke it. Afterwards, it goes into the native
invoke0() method and throws the exception.

Any ideas?.
Thanks again.



2011/1/3 Ron Wheeler <rw...@artifact-software.com>

> On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
>
>> Ron, I really appreciate your answer.
>> With my comment I only meant to ask if you were aware that newer versions
>> solved the issue, and by it being rhetorical I meant that I should try
>> things before asking that much. I hope you took no offense on my comments
>> :-) .
>>
> Not at all.
>
>  Again, any perspective from outside helps seeing things more clearly, and
>> thanks to you I updated to a newer version of the CXF  framework (2.2.12)
>> while keeping the rest untouch. Besides having to enforce the use of some
>> saaj version, I ran into no other complications, so I thank you for this,
>> as
>> your suggestion might have avoided a lot of bugs.
>>
>>  Sorry that it didn't fix the problem.
>
>  Regarding the error, it is still there. Again, it only happens when adding
>> "global-method-security" to the equation.
>> I get an "IllegalArgumentException: Object is not an instance of declaring
>> class" after the invocation of
>> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(),
>> both
>> with and without the setter method for the @Resource WebServiceContext.
>>
>> Any ideas, anybody?, I can't seem to find any related info on the Web.
>> Thanks everybody for your help.
>> Regards,
>>              Juan Pedro
>>
>> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>>
>>  On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>
>>>  Hi Ron, thanks for your answer.
>>>>
>>>> Regarding the version in use, well, this is sort of a legacy code into
>>>> which
>>>> I'm adding new authorization functionality, so I was trying to get away
>>>> without changing versions just to avoid adding another grade of
>>>> uncertainty
>>>> from where new errors might come from. Just that.
>>>>
>>>> Even more, I've never found in the different posts on the topic any
>>>> reference to a bug or a functionality that was to be added in future
>>>> versions, so I assumed that there was a particular way in which to do
>>>> things
>>>> to make it work that I was not aware of, not that this was a problem
>>>> that
>>>> had been addressed in newer versions.
>>>>
>>>> With that said, I may upgrade to newer versions of the CXF framework.
>>>> However, will just doing this solve the WebServiceContext injection
>>>> issue?,
>>>> I don't get that clearly from your answer and I didn't find anything
>>>> online
>>>> that would lead me to have such an impression. Anyhow, it is sort of a
>>>> rhetorical question, I'll try this first thing in the morning.
>>>>
>>>>  It was only a general comment that should be easy to test and if it
>>>> works
>>>>
>>> might lead to a more complete explanation and a workaround for the old
>>> version.
>>> It also keeps the discussion active which is sometimes helpful on
>>> weekends
>>> and holidays when the real experts may be otherwise occupied and not see
>>> your question.
>>>
>>>
>>> Ron
>>>
>>>  Thanks again,
>>>
>>>>                      Juan Pedro
>>>>
>>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>>>>
>>>>  On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>
>>>>>  Hi, I've been trying to wire my WSS4J interceptors into Spring
>>>>> security,
>>>>>
>>>>>> which I was able to do following Freeman's suggestions.
>>>>>> However, I'm facing the (whats looks to be a) common problem with
>>>>>> WebServiceContext when trying to enable method security.
>>>>>>
>>>>>> Before adding the global-method-security line everything works well.
>>>>>> When I add it, I get an IllegalArgumentException which complaints that
>>>>>> it
>>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm
>>>>>> not
>>>>>> able
>>>>>> to copy the stack trace from here).
>>>>>>
>>>>>> I found some posts on the subject, mostly answered by Sergei and
>>>>>> jax-RS
>>>>>> related. I learned thatthe issue is related to spring AOP and to CGLIB
>>>>>> proxies and suggesting to add a setter in the service interface to
>>>>>> solve
>>>>>> te
>>>>>> issue. However, I added a setWebServiceContext(WebServiceContext wsc)
>>>>>> to
>>>>>> the
>>>>>> service interface, and still have no luck, it fails with identical
>>>>>> exception
>>>>>> and message.
>>>>>>
>>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>>>>>> 2.0.5.RELEASE.
>>>>>>
>>>>>>  Any reason why you are using such old versions?
>>>>>>
>>>>> I would try to upgrade to newer versions before chasing bugs
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>>  Which steps should I take to be able to use method security?
>>>>>
>>>>>  Thanks again for all the help.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

[Ron Wheeler <rw...@artifact-software.com>]

On 03/01/2011 7:10 AM, Juan Pedro Silva Gallino (UPM) wrote:
> Ron, I really appreciate your answer.
> With my comment I only meant to ask if you were aware that newer versions
> solved the issue, and by it being rhetorical I meant that I should try
> things before asking that much. I hope you took no offense on my comments
> :-) .
Not at all.
> Again, any perspective from outside helps seeing things more clearly, and
> thanks to you I updated to a newer version of the CXF  framework (2.2.12)
> while keeping the rest untouch. Besides having to enforce the use of some
> saaj version, I ran into no other complications, so I thank you for this, as
> your suggestion might have avoided a lot of bugs.
>
Sorry that it didn't fix the problem.
> Regarding the error, it is still there. Again, it only happens when adding
> "global-method-security" to the equation.
> I get an "IllegalArgumentException: Object is not an instance of declaring
> class" after the invocation of
> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(), both
> with and without the setter method for the @Resource WebServiceContext.
>
> Any ideas, anybody?, I can't seem to find any related info on the Web.
> Thanks everybody for your help.
> Regards,
>               Juan Pedro
>
> 2011/1/3 Ron Wheeler<rw...@artifact-software.com>
>
>> On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>
>>> Hi Ron, thanks for your answer.
>>>
>>> Regarding the version in use, well, this is sort of a legacy code into
>>> which
>>> I'm adding new authorization functionality, so I was trying to get away
>>> without changing versions just to avoid adding another grade of
>>> uncertainty
>>> from where new errors might come from. Just that.
>>>
>>> Even more, I've never found in the different posts on the topic any
>>> reference to a bug or a functionality that was to be added in future
>>> versions, so I assumed that there was a particular way in which to do
>>> things
>>> to make it work that I was not aware of, not that this was a problem that
>>> had been addressed in newer versions.
>>>
>>> With that said, I may upgrade to newer versions of the CXF framework.
>>> However, will just doing this solve the WebServiceContext injection
>>> issue?,
>>> I don't get that clearly from your answer and I didn't find anything
>>> online
>>> that would lead me to have such an impression. Anyhow, it is sort of a
>>> rhetorical question, I'll try this first thing in the morning.
>>>
>>>   It was only a general comment that should be easy to test and if it works
>> might lead to a more complete explanation and a workaround for the old
>> version.
>> It also keeps the discussion active which is sometimes helpful on weekends
>> and holidays when the real experts may be otherwise occupied and not see
>> your question.
>>
>>
>> Ron
>>
>>   Thanks again,
>>>                       Juan Pedro
>>>
>>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>>>
>>>   On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>>   Hi, I've been trying to wire my WSS4J interceptors into Spring security,
>>>>> which I was able to do following Freeman's suggestions.
>>>>> However, I'm facing the (whats looks to be a) common problem with
>>>>> WebServiceContext when trying to enable method security.
>>>>>
>>>>> Before adding the global-method-security line everything works well.
>>>>> When I add it, I get an IllegalArgumentException which complaints that
>>>>> it
>>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm not
>>>>> able
>>>>> to copy the stack trace from here).
>>>>>
>>>>> I found some posts on the subject, mostly answered by Sergei and jax-RS
>>>>> related. I learned thatthe issue is related to spring AOP and to CGLIB
>>>>> proxies and suggesting to add a setter in the service interface to solve
>>>>> te
>>>>> issue. However, I added a setWebServiceContext(WebServiceContext wsc) to
>>>>> the
>>>>> service interface, and still have no luck, it fails with identical
>>>>> exception
>>>>> and message.
>>>>>
>>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>>>>> 2.0.5.RELEASE.
>>>>>
>>>>>   Any reason why you are using such old versions?
>>>> I would try to upgrade to newer versions before chasing bugs
>>>>
>>>> Ron
>>>>
>>>>
>>>>   Which steps should I take to be able to use method security?
>>>>
>>>>> Thanks again for all the help.
>>>>>
>>>>>
>>>>>

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

Ron, I really appreciate your answer.
With my comment I only meant to ask if you were aware that newer versions
solved the issue, and by it being rhetorical I meant that I should try
things before asking that much. I hope you took no offense on my comments
:-) .

Again, any perspective from outside helps seeing things more clearly, and
thanks to you I updated to a newer version of the CXF  framework (2.2.12)
while keeping the rest untouch. Besides having to enforce the use of some
saaj version, I ran into no other complications, so I thank you for this, as
your suggestion might have avoided a lot of bugs.

Regarding the error, it is still there. Again, it only happens when adding
"global-method-security" to the equation.
I get an "IllegalArgumentException: Object is not an instance of declaring
class" after the invocation of
org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(), both
with and without the setter method for the @Resource WebServiceContext.

Any ideas, anybody?, I can't seem to find any related info on the Web.
Thanks everybody for your help.
Regards,
             Juan Pedro

2011/1/3 Ron Wheeler <rw...@artifact-software.com>

> On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
>
>> Hi Ron, thanks for your answer.
>>
>> Regarding the version in use, well, this is sort of a legacy code into
>> which
>> I'm adding new authorization functionality, so I was trying to get away
>> without changing versions just to avoid adding another grade of
>> uncertainty
>> from where new errors might come from. Just that.
>>
>> Even more, I've never found in the different posts on the topic any
>> reference to a bug or a functionality that was to be added in future
>> versions, so I assumed that there was a particular way in which to do
>> things
>> to make it work that I was not aware of, not that this was a problem that
>> had been addressed in newer versions.
>>
>> With that said, I may upgrade to newer versions of the CXF framework.
>> However, will just doing this solve the WebServiceContext injection
>> issue?,
>> I don't get that clearly from your answer and I didn't find anything
>> online
>> that would lead me to have such an impression. Anyhow, it is sort of a
>> rhetorical question, I'll try this first thing in the morning.
>>
>>  It was only a general comment that should be easy to test and if it works
> might lead to a more complete explanation and a workaround for the old
> version.
> It also keeps the discussion active which is sometimes helpful on weekends
> and holidays when the real experts may be otherwise occupied and not see
> your question.
>
>
> Ron
>
>  Thanks again,
>>                      Juan Pedro
>>
>> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>>
>>  On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>>
>>>  Hi, I've been trying to wire my WSS4J interceptors into Spring security,
>>>> which I was able to do following Freeman's suggestions.
>>>> However, I'm facing the (whats looks to be a) common problem with
>>>> WebServiceContext when trying to enable method security.
>>>>
>>>> Before adding the global-method-security line everything works well.
>>>> When I add it, I get an IllegalArgumentException which complaints that
>>>> it
>>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm not
>>>> able
>>>> to copy the stack trace from here).
>>>>
>>>> I found some posts on the subject, mostly answered by Sergei and jax-RS
>>>> related. I learned thatthe issue is related to spring AOP and to CGLIB
>>>> proxies and suggesting to add a setter in the service interface to solve
>>>> te
>>>> issue. However, I added a setWebServiceContext(WebServiceContext wsc) to
>>>> the
>>>> service interface, and still have no luck, it fails with identical
>>>> exception
>>>> and message.
>>>>
>>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>>>> 2.0.5.RELEASE.
>>>>
>>>>  Any reason why you are using such old versions?
>>> I would try to upgrade to newer versions before chasing bugs
>>>
>>> Ron
>>>
>>>
>>>  Which steps should I take to be able to use method security?
>>>
>>>> Thanks again for all the help.
>>>>
>>>>
>>>>
>>>
>

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

[Ron Wheeler <rw...@artifact-software.com>]

On 02/01/2011 2:18 PM, Juan Pedro Silva Gallino (UPM) wrote:
> Hi Ron, thanks for your answer.
>
> Regarding the version in use, well, this is sort of a legacy code into which
> I'm adding new authorization functionality, so I was trying to get away
> without changing versions just to avoid adding another grade of uncertainty
> from where new errors might come from. Just that.
>
> Even more, I've never found in the different posts on the topic any
> reference to a bug or a functionality that was to be added in future
> versions, so I assumed that there was a particular way in which to do things
> to make it work that I was not aware of, not that this was a problem that
> had been addressed in newer versions.
>
> With that said, I may upgrade to newer versions of the CXF framework.
> However, will just doing this solve the WebServiceContext injection issue?,
> I don't get that clearly from your answer and I didn't find anything online
> that would lead me to have such an impression. Anyhow, it is sort of a
> rhetorical question, I'll try this first thing in the morning.
>
It was only a general comment that should be easy to test and if it 
works might lead to a more complete explanation and a workaround for the 
old version.
It also keeps the discussion active which is sometimes helpful on 
weekends and holidays when the real experts may be otherwise occupied 
and not see your question.


Ron
> Thanks again,
>                       Juan Pedro
>
> 2011/1/1 Ron Wheeler<rw...@artifact-software.com>
>
>> On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>>
>>> Hi, I've been trying to wire my WSS4J interceptors into Spring security,
>>> which I was able to do following Freeman's suggestions.
>>> However, I'm facing the (whats looks to be a) common problem with
>>> WebServiceContext when trying to enable method security.
>>>
>>> Before adding the global-method-security line everything works well.
>>> When I add it, I get an IllegalArgumentException which complaints that it
>>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm not
>>> able
>>> to copy the stack trace from here).
>>>
>>> I found some posts on the subject, mostly answered by Sergei and jax-RS
>>> related. I learned thatthe issue is related to spring AOP and to CGLIB
>>> proxies and suggesting to add a setter in the service interface to solve
>>> te
>>> issue. However, I added a setWebServiceContext(WebServiceContext wsc) to
>>> the
>>> service interface, and still have no luck, it fails with identical
>>> exception
>>> and message.
>>>
>>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>>> 2.0.5.RELEASE.
>>>
>> Any reason why you are using such old versions?
>> I would try to upgrade to newer versions before chasing bugs
>>
>> Ron
>>
>>
>>   Which steps should I take to be able to use method security?
>>> Thanks again for all the help.
>>>
>>>
>>

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

["Juan Pedro Silva Gallino (UPM)" <jp...@gmail.com>]

Hi Ron, thanks for your answer.

Regarding the version in use, well, this is sort of a legacy code into which
I'm adding new authorization functionality, so I was trying to get away
without changing versions just to avoid adding another grade of uncertainty
from where new errors might come from. Just that.

Even more, I've never found in the different posts on the topic any
reference to a bug or a functionality that was to be added in future
versions, so I assumed that there was a particular way in which to do things
to make it work that I was not aware of, not that this was a problem that
had been addressed in newer versions.

With that said, I may upgrade to newer versions of the CXF framework.
However, will just doing this solve the WebServiceContext injection issue?,
I don't get that clearly from your answer and I didn't find anything online
that would lead me to have such an impression. Anyhow, it is sort of a
rhetorical question, I'll try this first thing in the morning.

Thanks again,
                     Juan Pedro

2011/1/1 Ron Wheeler <rw...@artifact-software.com>

> On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
>
>> Hi, I've been trying to wire my WSS4J interceptors into Spring security,
>> which I was able to do following Freeman's suggestions.
>> However, I'm facing the (whats looks to be a) common problem with
>> WebServiceContext when trying to enable method security.
>>
>> Before adding the global-method-security line everything works well.
>> When I add it, I get an IllegalArgumentException which complaints that it
>> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm not
>> able
>> to copy the stack trace from here).
>>
>> I found some posts on the subject, mostly answered by Sergei and jax-RS
>> related. I learned thatthe issue is related to spring AOP and to CGLIB
>> proxies and suggesting to add a setter in the service interface to solve
>> te
>> issue. However, I added a setWebServiceContext(WebServiceContext wsc) to
>> the
>> service interface, and still have no luck, it fails with identical
>> exception
>> and message.
>>
>> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
>> 2.0.5.RELEASE.
>>
> Any reason why you are using such old versions?
> I would try to upgrade to newer versions before chasing bugs
>
> Ron
>
>
>  Which steps should I take to be able to use method security?
>> Thanks again for all the help.
>>
>>
>
>

Re: IllegalArgumentException setting WebServiceContext in jax:ws endpoint.

[Ron Wheeler <rw...@artifact-software.com>]

On 28/12/2010 5:37 PM, Juan Pedro Silva Gallino (UPM) wrote:
> Hi, I've been trying to wire my WSS4J interceptors into Spring security,
> which I was able to do following Freeman's suggestions.
> However, I'm facing the (whats looks to be a) common problem with
> WebServiceContext when trying to enable method security.
>
> Before adding the global-method-security line everything works well.
> When I add it, I get an IllegalArgumentException which complaints that it
> cannot set the WebServiceContext field to a "$Proxy131" (sorry, I'm not able
> to copy the stack trace from here).
>
> I found some posts on the subject, mostly answered by Sergei and jax-RS
> related. I learned thatthe issue is related to spring AOP and to CGLIB
> proxies and suggesting to add a setter in the service interface to solve te
> issue. However, I added a setWebServiceContext(WebServiceContext wsc) to the
> service interface, and still have no luck, it fails with identical exception
> and message.
>
> I'm using CXF 2.1.1, Spring 2.5, Spring-ws 1.5.9 and Spring-security
> 2.0.5.RELEASE.
Any reason why you are using such old versions?
I would try to upgrade to newer versions before chasing bugs

Ron

> Which steps should I take to be able to use method security?
> Thanks again for all the help.
>