Jars in plugin's lib dir made visible to Tomcat's classloader

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Jars in plugin's lib dir made visible to Tomcat's classloader

Joris Kuipers
Hi,

I've been spending some time this month to add Groovy to an existing Java/Spring/Maven project using greclipse (incl. the maven plugin and the m2e integration in STS/GGTS). Even with the latest snapshot version I keep running into the problem that when I deploy my app to a local Tomcat from within the IDE, it seems like all jars from the plugin's lib dir are visible to the classloader, thus causing problems b/o the conflicting servlet jars. This is what I'm seeing:

Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/catalina/loader/WebappClassLoader) previously initiated loading for a different type with name "javax/servlet/RequestDispatcher"
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1177)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2836)
    at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1160)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
    at org.springframework.security.web.firewall.DefaultHttpFirewall.getFirewalledRequest(DefaultHttpFirewall.java:25)
    at org.springframework.security.web.FilterChainProxy.getFilters(FilterChainProxy.java:199)
    at org.springframework.security.config.http.DefaultFilterChainValidator.checkLoginPageIsntProtected(DefaultFilterChainValidator.java:127)
    at org.springframework.security.config.http.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:35)
    at org.springframework.security.web.FilterChainProxy.afterPropertiesSet(FilterChainProxy.java:148)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
    ... 22 more

When I delete the servlet-api-2.4.jar from the plugin's lib dir (actually, from all the plugin lib dirs, i.e. the 1.7, 1.8 and 2.0 versions) the problem goes away.
I've put a breakpoint on ClassLoader#defineClass and what I see is that the application first seems to start up OK, but then runs into this error when Spring Security goes on to check that its login page is not secured; the toString of the ProtectionDomain at that point is this:

ProtectionDomain  (file:/D:/java/ggts-3.1.0.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20121013-1100-e42/lib/servlet-api-2.4.jar <no signer certificates>)
 WebappClassLoader
  context:
  delegate: false
  repositories:
    /WEB-INF/classes/
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@4e4d6444

 <no principals>
 java.security.Permissions@25a076eb (
 ("java.io.FilePermission" "\D:\java\ggts-3.1.0.RELEASE\plugins\org.codehaus.groovy_1.7.10.xx-20121013-1100-e42\lib\servlet-api-2.4.jar" "read")
)


What I find even more confusing is that I"m not even using Groovy 1.7 but 2.0.
Any idea how this jar ends up being visible to Tomcat's classloader?

Thanks in advance,

Joris
Reply | Threaded
Open this post in threaded view
|

Re: Jars in plugin's lib dir made visible to Tomcat's classloader

Andrew Eisenberg
Hi Joris,

For the first problem (ie- the servlets-api jar being on the
classpath), it looks like you have the groovy classpath container in
your project.  If this is a maven project, the groovy classpath
container shouldn't be used.  All dependencies should be calculated by
m2e.  So, you should just be able to remove that classpath container
and things should work better.

The second problem might be related to the first.  Also, make sure
that your workspace compiler level is 2.0, and not 1.7.

On Fri, Oct 19, 2012 at 5:03 PM, Joris Kuipers <[hidden email]> wrote:

> Hi,
>
> I've been spending some time this month to add Groovy to an existing
> Java/Spring/Maven project using greclipse (incl. the maven plugin and the
> m2e integration in STS/GGTS). Even with the latest snapshot version I keep
> running into the problem that when I deploy my app to a local Tomcat from
> within the IDE, it seems like all jars from the plugin's lib dir are visible
> to the classloader, thus causing problems b/o the conflicting servlet jars.
> This is what I'm seeing:
>
> Caused by: java.lang.LinkageError: loader constraint violation: loader
> (instance of org/apache/catalina/loader/WebappClassLoader) previously
> initiated loading for a different type with name
> "javax/servlet/RequestDispatcher"
>     at java.lang.ClassLoader.defineClass1(Native Method)
>     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>     at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>     at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>     at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>     at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1177)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>     at java.lang.ClassLoader.defineClass1(Native Method)
>     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>     at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>     at
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2836)
>     at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1160)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>     at
> org.springframework.security.web.firewall.DefaultHttpFirewall.getFirewalledRequest(DefaultHttpFirewall.java:25)
>     at
> org.springframework.security.web.FilterChainProxy.getFilters(FilterChainProxy.java:199)
>     at
> org.springframework.security.config.http.DefaultFilterChainValidator.checkLoginPageIsntProtected(DefaultFilterChainValidator.java:127)
>     at
> org.springframework.security.config.http.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:35)
>     at
> org.springframework.security.web.FilterChainProxy.afterPropertiesSet(FilterChainProxy.java:148)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>     ... 22 more
>
> When I delete the servlet-api-2.4.jar from the plugin's lib dir (actually,
> from all the plugin lib dirs, i.e. the 1.7, 1.8 and 2.0 versions) the
> problem goes away.
> I've put a breakpoint on ClassLoader#defineClass and what I see is that the
> application first seems to start up OK, but then runs into this error when
> Spring Security goes on to check that its login page is not secured; the
> toString of the ProtectionDomain at that point is this:
>
> ProtectionDomain
> (file:/D:/java/ggts-3.1.0.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20121013-1100-e42/lib/servlet-api-2.4.jar
> <no signer certificates>)
>  WebappClassLoader
>   context:
>   delegate: false
>   repositories:
>     /WEB-INF/classes/
> ----------> Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader@4e4d6444
>
>  <no principals>
>  java.security.Permissions@25a076eb (
>  ("java.io.FilePermission"
> "\D:\java\ggts-3.1.0.RELEASE\plugins\org.codehaus.groovy_1.7.10.xx-20121013-1100-e42\lib\servlet-api-2.4.jar"
> "read")
> )
>
>
> What I find even more confusing is that I"m not even using Groovy 1.7 but
> 2.0.
> Any idea how this jar ends up being visible to Tomcat's classloader?
>
> Thanks in advance,
>
> Joris

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jars in plugin's lib dir made visible to Tomcat's classloader

Joris Kuipers
Unfortunately, neither of these things is the case: I don't have a Groovy classpath container and the workspace uses the 2.0.4 compiler.
I've attached my .classpath so you can verify the lack of extra classpath containers yourself.

Could this be a bug in the greclipse m2e integration? Should I file a JIRA issue perhaps?

Joris

2012/10/20 Andrew Eisenberg <[hidden email]>
Hi Joris,

For the first problem (ie- the servlets-api jar being on the
classpath), it looks like you have the groovy classpath container in
your project.  If this is a maven project, the groovy classpath
container shouldn't be used.  All dependencies should be calculated by
m2e.  So, you should just be able to remove that classpath container
and things should work better.

The second problem might be related to the first.  Also, make sure
that your workspace compiler level is 2.0, and not 1.7.

On Fri, Oct 19, 2012 at 5:03 PM, Joris Kuipers <[hidden email]> wrote:
> Hi,
>
> I've been spending some time this month to add Groovy to an existing
> Java/Spring/Maven project using greclipse (incl. the maven plugin and the
> m2e integration in STS/GGTS). Even with the latest snapshot version I keep
> running into the problem that when I deploy my app to a local Tomcat from
> within the IDE, it seems like all jars from the plugin's lib dir are visible
> to the classloader, thus causing problems b/o the conflicting servlet jars.
> This is what I'm seeing:
>
> Caused by: java.lang.LinkageError: loader constraint violation: loader
> (instance of org/apache/catalina/loader/WebappClassLoader) previously
> initiated loading for a different type with name
> "javax/servlet/RequestDispatcher"
>     at java.lang.ClassLoader.defineClass1(Native Method)
>     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>     at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>     at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>     at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>     at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1177)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>     at java.lang.ClassLoader.defineClass1(Native Method)
>     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>     at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>     at
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2836)
>     at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1160)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>     at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>     at
> org.springframework.security.web.firewall.DefaultHttpFirewall.getFirewalledRequest(DefaultHttpFirewall.java:25)
>     at
> org.springframework.security.web.FilterChainProxy.getFilters(FilterChainProxy.java:199)
>     at
> org.springframework.security.config.http.DefaultFilterChainValidator.checkLoginPageIsntProtected(DefaultFilterChainValidator.java:127)
>     at
> org.springframework.security.config.http.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:35)
>     at
> org.springframework.security.web.FilterChainProxy.afterPropertiesSet(FilterChainProxy.java:148)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>     ... 22 more
>
> When I delete the servlet-api-2.4.jar from the plugin's lib dir (actually,
> from all the plugin lib dirs, i.e. the 1.7, 1.8 and 2.0 versions) the
> problem goes away.
> I've put a breakpoint on ClassLoader#defineClass and what I see is that the
> application first seems to start up OK, but then runs into this error when
> Spring Security goes on to check that its login page is not secured; the
> toString of the ProtectionDomain at that point is this:
>
> ProtectionDomain
> (file:/D:/java/ggts-3.1.0.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20121013-1100-e42/lib/servlet-api-2.4.jar
> <no signer certificates>)
>  WebappClassLoader
>   context:
>   delegate: false
>   repositories:
>     /WEB-INF/classes/
> ----------> Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader@4e4d6444
>
>  <no principals>
>  java.security.Permissions@25a076eb (
>  ("java.io.FilePermission"
> "\D:\java\ggts-3.1.0.RELEASE\plugins\org.codehaus.groovy_1.7.10.xx-20121013-1100-e42\lib\servlet-api-2.4.jar"
> "read")
> )
>
>
> What I find even more confusing is that I"m not even using Groovy 1.7 but
> 2.0.
> Any idea how this jar ends up being visible to Tomcat's classloader?
>
> Thanks in advance,
>
> Joris

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

.classpath (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jars in plugin's lib dir made visible to Tomcat's classloader

Andrew Eisenberg
Interesting...groovy-m2e integration doesn't do anything with the
classpath (it only adds source folders and natures).  So, I wouldn't
think that this problem is related to groovy-m2e integration.  Any
chance that you could send me the project so I could try myself?

On Sat, Oct 20, 2012 at 3:49 AM, Joris Kuipers <[hidden email]> wrote:

> Unfortunately, neither of these things is the case: I don't have a Groovy
> classpath container and the workspace uses the 2.0.4 compiler.
> I've attached my .classpath so you can verify the lack of extra classpath
> containers yourself.
>
> Could this be a bug in the greclipse m2e integration? Should I file a JIRA
> issue perhaps?
>
> Joris
>
> 2012/10/20 Andrew Eisenberg <[hidden email]>
>>
>> Hi Joris,
>>
>> For the first problem (ie- the servlets-api jar being on the
>> classpath), it looks like you have the groovy classpath container in
>> your project.  If this is a maven project, the groovy classpath
>> container shouldn't be used.  All dependencies should be calculated by
>> m2e.  So, you should just be able to remove that classpath container
>> and things should work better.
>>
>> The second problem might be related to the first.  Also, make sure
>> that your workspace compiler level is 2.0, and not 1.7.
>>
>> On Fri, Oct 19, 2012 at 5:03 PM, Joris Kuipers <[hidden email]>
>> wrote:
>> > Hi,
>> >
>> > I've been spending some time this month to add Groovy to an existing
>> > Java/Spring/Maven project using greclipse (incl. the maven plugin and
>> > the
>> > m2e integration in STS/GGTS). Even with the latest snapshot version I
>> > keep
>> > running into the problem that when I deploy my app to a local Tomcat
>> > from
>> > within the IDE, it seems like all jars from the plugin's lib dir are
>> > visible
>> > to the classloader, thus causing problems b/o the conflicting servlet
>> > jars.
>> > This is what I'm seeing:
>> >
>> > Caused by: java.lang.LinkageError: loader constraint violation: loader
>> > (instance of org/apache/catalina/loader/WebappClassLoader) previously
>> > initiated loading for a different type with name
>> > "javax/servlet/RequestDispatcher"
>> >     at java.lang.ClassLoader.defineClass1(Native Method)
>> >     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> >     at
>> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >     at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>> >     at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>> >     at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>> >     at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>> >     at java.security.AccessController.doPrivileged(Native Method)
>> >     at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1177)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>> >     at java.lang.ClassLoader.defineClass1(Native Method)
>> >     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> >     at
>> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2836)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1160)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>> >     at
>> >
>> > org.springframework.security.web.firewall.DefaultHttpFirewall.getFirewalledRequest(DefaultHttpFirewall.java:25)
>> >     at
>> >
>> > org.springframework.security.web.FilterChainProxy.getFilters(FilterChainProxy.java:199)
>> >     at
>> >
>> > org.springframework.security.config.http.DefaultFilterChainValidator.checkLoginPageIsntProtected(DefaultFilterChainValidator.java:127)
>> >     at
>> >
>> > org.springframework.security.config.http.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:35)
>> >     at
>> >
>> > org.springframework.security.web.FilterChainProxy.afterPropertiesSet(FilterChainProxy.java:148)
>> >     at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
>> >     at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>> >     ... 22 more
>> >
>> > When I delete the servlet-api-2.4.jar from the plugin's lib dir
>> > (actually,
>> > from all the plugin lib dirs, i.e. the 1.7, 1.8 and 2.0 versions) the
>> > problem goes away.
>> > I've put a breakpoint on ClassLoader#defineClass and what I see is that
>> > the
>> > application first seems to start up OK, but then runs into this error
>> > when
>> > Spring Security goes on to check that its login page is not secured; the
>> > toString of the ProtectionDomain at that point is this:
>> >
>> > ProtectionDomain
>> >
>> > (file:/D:/java/ggts-3.1.0.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20121013-1100-e42/lib/servlet-api-2.4.jar
>> > <no signer certificates>)
>> >  WebappClassLoader
>> >   context:
>> >   delegate: false
>> >   repositories:
>> >     /WEB-INF/classes/
>> > ----------> Parent Classloader:
>> > org.apache.catalina.loader.StandardClassLoader@4e4d6444
>> >
>> >  <no principals>
>> >  java.security.Permissions@25a076eb (
>> >  ("java.io.FilePermission"
>> >
>> > "\D:\java\ggts-3.1.0.RELEASE\plugins\org.codehaus.groovy_1.7.10.xx-20121013-1100-e42\lib\servlet-api-2.4.jar"
>> > "read")
>> > )
>> >
>> >
>> > What I find even more confusing is that I"m not even using Groovy 1.7
>> > but
>> > 2.0.
>> > Any idea how this jar ends up being visible to Tomcat's classloader?
>> >
>> > Thanks in advance,
>> >
>> > Joris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jars in plugin's lib dir made visible to Tomcat's classloader

Joris Kuipers
I'll try to create a stipped-down version that I can send to you: starting on it right away.

Joris

2012/10/20 Andrew Eisenberg <[hidden email]>
Interesting...groovy-m2e integration doesn't do anything with the
classpath (it only adds source folders and natures).  So, I wouldn't
think that this problem is related to groovy-m2e integration.  Any
chance that you could send me the project so I could try myself?

On Sat, Oct 20, 2012 at 3:49 AM, Joris Kuipers <[hidden email]> wrote:
> Unfortunately, neither of these things is the case: I don't have a Groovy
> classpath container and the workspace uses the 2.0.4 compiler.
> I've attached my .classpath so you can verify the lack of extra classpath
> containers yourself.
>
> Could this be a bug in the greclipse m2e integration? Should I file a JIRA
> issue perhaps?
>
> Joris
>
> 2012/10/20 Andrew Eisenberg <[hidden email]>
>>
>> Hi Joris,
>>
>> For the first problem (ie- the servlets-api jar being on the
>> classpath), it looks like you have the groovy classpath container in
>> your project.  If this is a maven project, the groovy classpath
>> container shouldn't be used.  All dependencies should be calculated by
>> m2e.  So, you should just be able to remove that classpath container
>> and things should work better.
>>
>> The second problem might be related to the first.  Also, make sure
>> that your workspace compiler level is 2.0, and not 1.7.
>>
>> On Fri, Oct 19, 2012 at 5:03 PM, Joris Kuipers <[hidden email]>
>> wrote:
>> > Hi,
>> >
>> > I've been spending some time this month to add Groovy to an existing
>> > Java/Spring/Maven project using greclipse (incl. the maven plugin and
>> > the
>> > m2e integration in STS/GGTS). Even with the latest snapshot version I
>> > keep
>> > running into the problem that when I deploy my app to a local Tomcat
>> > from
>> > within the IDE, it seems like all jars from the plugin's lib dir are
>> > visible
>> > to the classloader, thus causing problems b/o the conflicting servlet
>> > jars.
>> > This is what I'm seeing:
>> >
>> > Caused by: java.lang.LinkageError: loader constraint violation: loader
>> > (instance of org/apache/catalina/loader/WebappClassLoader) previously
>> > initiated loading for a different type with name
>> > "javax/servlet/RequestDispatcher"
>> >     at java.lang.ClassLoader.defineClass1(Native Method)
>> >     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> >     at
>> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >     at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>> >     at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>> >     at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>> >     at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>> >     at java.security.AccessController.doPrivileged(Native Method)
>> >     at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1177)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>> >     at java.lang.ClassLoader.defineClass1(Native Method)
>> >     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> >     at
>> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2836)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1160)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>> >     at
>> >
>> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>> >     at
>> >
>> > org.springframework.security.web.firewall.DefaultHttpFirewall.getFirewalledRequest(DefaultHttpFirewall.java:25)
>> >     at
>> >
>> > org.springframework.security.web.FilterChainProxy.getFilters(FilterChainProxy.java:199)
>> >     at
>> >
>> > org.springframework.security.config.http.DefaultFilterChainValidator.checkLoginPageIsntProtected(DefaultFilterChainValidator.java:127)
>> >     at
>> >
>> > org.springframework.security.config.http.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:35)
>> >     at
>> >
>> > org.springframework.security.web.FilterChainProxy.afterPropertiesSet(FilterChainProxy.java:148)
>> >     at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
>> >     at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>> >     ... 22 more
>> >
>> > When I delete the servlet-api-2.4.jar from the plugin's lib dir
>> > (actually,
>> > from all the plugin lib dirs, i.e. the 1.7, 1.8 and 2.0 versions) the
>> > problem goes away.
>> > I've put a breakpoint on ClassLoader#defineClass and what I see is that
>> > the
>> > application first seems to start up OK, but then runs into this error
>> > when
>> > Spring Security goes on to check that its login page is not secured; the
>> > toString of the ProtectionDomain at that point is this:
>> >
>> > ProtectionDomain
>> >
>> > (file:/D:/java/ggts-3.1.0.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20121013-1100-e42/lib/servlet-api-2.4.jar
>> > <no signer certificates>)
>> >  WebappClassLoader
>> >   context:
>> >   delegate: false
>> >   repositories:
>> >     /WEB-INF/classes/
>> > ----------> Parent Classloader:
>> > org.apache.catalina.loader.StandardClassLoader@4e4d6444
>> >
>> >  <no principals>
>> >  java.security.Permissions@25a076eb (
>> >  ("java.io.FilePermission"
>> >
>> > "\D:\java\ggts-3.1.0.RELEASE\plugins\org.codehaus.groovy_1.7.10.xx-20121013-1100-e42\lib\servlet-api-2.4.jar"
>> > "read")
>> > )
>> >
>> >
>> > What I find even more confusing is that I"m not even using Groovy 1.7
>> > but
>> > 2.0.
>> > Any idea how this jar ends up being visible to Tomcat's classloader?
>> >
>> > Thanks in advance,
>> >
>> > Joris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Jars in plugin's lib dir made visible to Tomcat's classloader

Andrew Eisenberg
Thanks.  The reason why I had originally assumed you were using the
classpath container is that the servlet-api was removed from your
classpath when you deleted it from the plugin.  The plugin's jars are
only added to the classpath through the container.  So, I am currently
unsure as to what is going on.

On Sat, Oct 20, 2012 at 8:27 AM, Joris Kuipers <[hidden email]> wrote:

> I'll try to create a stipped-down version that I can send to you: starting
> on it right away.
>
>
> Joris
>
> 2012/10/20 Andrew Eisenberg <[hidden email]>
>>
>> Interesting...groovy-m2e integration doesn't do anything with the
>> classpath (it only adds source folders and natures).  So, I wouldn't
>> think that this problem is related to groovy-m2e integration.  Any
>> chance that you could send me the project so I could try myself?
>>
>> On Sat, Oct 20, 2012 at 3:49 AM, Joris Kuipers <[hidden email]>
>> wrote:
>> > Unfortunately, neither of these things is the case: I don't have a
>> > Groovy
>> > classpath container and the workspace uses the 2.0.4 compiler.
>> > I've attached my .classpath so you can verify the lack of extra
>> > classpath
>> > containers yourself.
>> >
>> > Could this be a bug in the greclipse m2e integration? Should I file a
>> > JIRA
>> > issue perhaps?
>> >
>> > Joris
>> >
>> > 2012/10/20 Andrew Eisenberg <[hidden email]>
>> >>
>> >> Hi Joris,
>> >>
>> >> For the first problem (ie- the servlets-api jar being on the
>> >> classpath), it looks like you have the groovy classpath container in
>> >> your project.  If this is a maven project, the groovy classpath
>> >> container shouldn't be used.  All dependencies should be calculated by
>> >> m2e.  So, you should just be able to remove that classpath container
>> >> and things should work better.
>> >>
>> >> The second problem might be related to the first.  Also, make sure
>> >> that your workspace compiler level is 2.0, and not 1.7.
>> >>
>> >> On Fri, Oct 19, 2012 at 5:03 PM, Joris Kuipers <[hidden email]>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I've been spending some time this month to add Groovy to an existing
>> >> > Java/Spring/Maven project using greclipse (incl. the maven plugin and
>> >> > the
>> >> > m2e integration in STS/GGTS). Even with the latest snapshot version I
>> >> > keep
>> >> > running into the problem that when I deploy my app to a local Tomcat
>> >> > from
>> >> > within the IDE, it seems like all jars from the plugin's lib dir are
>> >> > visible
>> >> > to the classloader, thus causing problems b/o the conflicting servlet
>> >> > jars.
>> >> > This is what I'm seeing:
>> >> >
>> >> > Caused by: java.lang.LinkageError: loader constraint violation:
>> >> > loader
>> >> > (instance of org/apache/catalina/loader/WebappClassLoader) previously
>> >> > initiated loading for a different type with name
>> >> > "javax/servlet/RequestDispatcher"
>> >> >     at java.lang.ClassLoader.defineClass1(Native Method)
>> >> >     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> >> >     at
>> >> >
>> >> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >> >     at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>> >> >     at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>> >> >     at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>> >> >     at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>> >> >     at java.security.AccessController.doPrivileged(Native Method)
>> >> >     at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1177)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>> >> >     at java.lang.ClassLoader.defineClass1(Native Method)
>> >> >     at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> >> >     at
>> >> >
>> >> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2836)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1160)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1668)
>> >> >     at
>> >> >
>> >> >
>> >> > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.security.web.firewall.DefaultHttpFirewall.getFirewalledRequest(DefaultHttpFirewall.java:25)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.security.web.FilterChainProxy.getFilters(FilterChainProxy.java:199)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.security.config.http.DefaultFilterChainValidator.checkLoginPageIsntProtected(DefaultFilterChainValidator.java:127)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.security.config.http.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:35)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.security.web.FilterChainProxy.afterPropertiesSet(FilterChainProxy.java:148)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
>> >> >     at
>> >> >
>> >> >
>> >> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>> >> >     ... 22 more
>> >> >
>> >> > When I delete the servlet-api-2.4.jar from the plugin's lib dir
>> >> > (actually,
>> >> > from all the plugin lib dirs, i.e. the 1.7, 1.8 and 2.0 versions) the
>> >> > problem goes away.
>> >> > I've put a breakpoint on ClassLoader#defineClass and what I see is
>> >> > that
>> >> > the
>> >> > application first seems to start up OK, but then runs into this error
>> >> > when
>> >> > Spring Security goes on to check that its login page is not secured;
>> >> > the
>> >> > toString of the ProtectionDomain at that point is this:
>> >> >
>> >> > ProtectionDomain
>> >> >
>> >> >
>> >> > (file:/D:/java/ggts-3.1.0.RELEASE/plugins/org.codehaus.groovy_1.7.10.xx-20121013-1100-e42/lib/servlet-api-2.4.jar
>> >> > <no signer certificates>)
>> >> >  WebappClassLoader
>> >> >   context:
>> >> >   delegate: false
>> >> >   repositories:
>> >> >     /WEB-INF/classes/
>> >> > ----------> Parent Classloader:
>> >> > org.apache.catalina.loader.StandardClassLoader@4e4d6444
>> >> >
>> >> >  <no principals>
>> >> >  java.security.Permissions@25a076eb (
>> >> >  ("java.io.FilePermission"
>> >> >
>> >> >
>> >> > "\D:\java\ggts-3.1.0.RELEASE\plugins\org.codehaus.groovy_1.7.10.xx-20121013-1100-e42\lib\servlet-api-2.4.jar"
>> >> > "read")
>> >> > )
>> >> >
>> >> >
>> >> > What I find even more confusing is that I"m not even using Groovy 1.7
>> >> > but
>> >> > 2.0.
>> >> > Any idea how this jar ends up being visible to Tomcat's classloader?
>> >> >
>> >> > Thanks in advance,
>> >> >
>> >> > Joris
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe from this list, please visit:
>> >>
>> >>     http://xircles.codehaus.org/manage_email
>> >>
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >     http://xircles.codehaus.org/manage_email
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Jars in plugin's lib dir made visible to Tomcat's classloader

domiko
This post has NOT been accepted by the mailing list yet.
... Don't know if your issue's been fixed but the problem is still appearing in GGTS 3.5.0

You can get a Linkage conflict when running a regular Eclipse Dynamic Web App on Tomcat inside GGTS.
It's caused by the fact that GGTS loads the content of the servlet-api.jar from the GGTS (groovy) plugin-dir.
i.e.
[Loaded javax.servlet.ServletInputStream from file:/C:/Data/j/springsource/ggts-3.4.0.RELEASE/plugins/org.codehaus.groovy_1.8.6.xx-20130828-1400-e43-RELEASE/lib/servlet-api-2.4.jar]
My solution is to explicitly add the Tomcat servlet-api.jar (from the Tomcat lib folder) to the 'Launch Configuration' classpath under 'User Entries'.

rgds,
Dominique.