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)<jpsilva....@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<rwhee...@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<rwhee...@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<rwhee...@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
dk...@apache.org
http://dankulp.com/blog
