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 <rwhee...@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)<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 > >
