Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Konstantin,

On 8/28/12 5:28 PM, Konstantin Kolinko wrote:
 2012/8/29 Dale Ogilvie dale_ogil...@trimble.com:
 -Original Message- From: Mark Thomas
 [mailto:ma...@apache.org]
 
 Not quite. My point was the loading of the EL implementation is
 likely to be triggered by user code. If the webapp class loader
 is the TCCL loader than classes from the web app will be loaded
 before those from the container. If the web app contains
 container classes then it is possible that they get loaded from
 the webapp rather than from Tomcat. (Enabling the security
 manager enables additional class loading checks that would stop
 this). Those classes from the webapp then have references held
 to them. They will work right up unto the point Tomcat tries to
 access the class outside of the webapp they were loaded from.
 
 Mark
 
 I'm still not quite sure what you are saying matches exactly what
 I'm seeing Mark.
 
 
 Have you ever tried to run with SecurityManager being enabled?
 
 
 So, it appears to me that the class *loading* is occurring from
 app1 in step 4. I'm only pushing this because it kind looks
 buggy to me.
 
 Class loading does not always use TCCL.  Sometimes it uses 
 otherclass.getClassLoader(). See e.g. javadoc of 
 java.lang.Class#forName(String).
 
 
 So it is quite valid for it to load a class from app1 even if
 current TCCL belongs to app2.

...and it's worth pointing out that Tomcat cannot protect against this
kind of ClassLoading, since Tomcat can't wrap every ClassLoader that
ever gets created in the JVM. The container can control lots of
things, but this isn't one of them. The same is true for example with
Threads: Tomcat can't prevent a webapp from spewing threads even
though the container is ostensibly in control.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA+E94ACgkQ9CaO5/Lv0PDsbgCfRrQb0C7StOuGg/PTqYlMro2t
uWwAoLRlLkSJY1ODrpmxte2GJiAbGnN0
=Dkxq
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 

Not quite. My point was the loading of the EL implementation is likely to be 
triggered by user code. If the webapp class loader is the TCCL loader than 
classes from the web app will be loaded before those from the container. If 
the web app contains container classes then it is possible that they get 
loaded from the webapp rather than from Tomcat.
(Enabling the security manager enables additional class loading checks that 
would stop this). Those classes from the webapp then have references held to 
them. They will work right up unto the point Tomcat tries to access the class 
outside of the webapp they were loaded from.

Mark

I'm still not quite sure what you are saying matches exactly what I'm seeing 
Mark. The webapp classloader IS the TCCL loader. No problem at all that the app 
containing the  container classes will load those in preference to the actual 
Tomcat ones. Ok.

However, what I see is this, in time order:

1. App2 (containing container classes) is deployed by TC at TC startup

2. App1 (not containing container classes) is deployed by TC at TC startup

3. A web request is made of App1 to load a JSP that uses EL

4. The vm (-verbose:class) reports class LOAD from app2:

[Loaded javax.el.ExpressionFactory from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]

5. Class cast exception occurs somewhat later

So, it appears to me that the class *loading* is occurring from app1 in step 
4. I'm only pushing this because it kind looks buggy to me.

Dale

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Konstantin Kolinko]

2012/8/29 Dale Ogilvie dale_ogil...@trimble.com:
 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]

Not quite. My point was the loading of the EL implementation is likely to be 
triggered by user code. If the webapp class loader is the TCCL loader than 
classes from the web app will be loaded before those from the container. If 
the web app contains container classes then it is possible that they get 
loaded from the webapp rather than from Tomcat.
(Enabling the security manager enables additional class loading checks that 
would stop this). Those classes from the webapp then have references held to 
them. They will work right up unto the point Tomcat tries to access the 
class outside of the webapp they were loaded from.

Mark

 I'm still not quite sure what you are saying matches exactly what I'm seeing 
 Mark.


Have you ever tried to run with SecurityManager being enabled?


 So, it appears to me that the class *loading* is occurring from app1 in 
 step 4. I'm only pushing this because it kind looks buggy to me.

Class loading does not always use TCCL.  Sometimes it uses
otherclass.getClassLoader(). See e.g. javadoc of
java.lang.Class#forName(String).


So it is quite valid for it to load a class from app1 even if current
TCCL belongs to app2.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

On 21/08/2012 23:35, Dale Ogilvie wrote:
 -Original Message- From: Pid * [mailto:p...@pidster.com]
 
 Where is that dependency JSP jar from? It should not be in
 WEB-INF/lib if it's providing JSP functionality.
 
 
 p
 
 The manifest for the jar says JSP 2.1 Jasper implementation from
 Glassfish, and yeah it was bad practice for maven to include that in
 our app2 for us.
 
 Regardless of where the jar is coming from, it still seems bad to me
 that Tomcat will respond to my request of app1 by loading a class
 from app2/WEB-INF/lib/jsp-2.1-6.1.14.jar.
 
 I think Mark Thomas was saying that Tomcat was preventing loading of
 classes outside of Tomcat and app1, the vm classloading output seems
 to suggest otherwise.

Not quite. My point was the loading of the EL implementation is likely
to be triggered by user code. If the webapp class loader is the TCCL
loader than classes from the web app will be loaded before those from
the container. If the web app contains container classes then it is
possible that they get loaded from the webapp rather than from Tomcat.
(Enabling the security manager enables additional class loading checks
that would stop this). Those classes from the webapp then have
references held to them. They will work right up unto the point Tomcat
tries to access the class outside of the webapp they were loaded from.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Pid *]

On 20 Aug 2012, at 23:28, Dale Ogilvie dale_ogil...@trimble.com wrote:

 So, I ran with JVM option -verbose:class
 Then I requested a jsp from app1 and the console printed:

 ...
 [Loaded javax.el.ExpressionFactory from 
 file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
 [Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
 file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
 [Loaded javax.el.ELContext from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
 [Loaded org.apache.jasper.runtime.ELContextImpl from 
 file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
 ...

 This seems to indicate that the class is being loaded by app1 from 
 app2/WEB-INF/lib/jsp-2.1-6.1.14.jar. No?

Where is that dependency JSP jar from?
It should not be in WEB-INF/lib if it's providing JSP functionality.


p




 Dale

 Т�ХF�V�7V'67�R�R���âW6W'2�V�7V'67�TF��6B�6�R��pФf�FF�F����6����G2�R���âW6W'2ֆV�F��6B�6�R��pР

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Pid * [mailto:p...@pidster.com] 

Where is that dependency JSP jar from?
It should not be in WEB-INF/lib if it's providing JSP functionality.


p

The manifest for the jar says JSP 2.1 Jasper implementation from Glassfish, 
and yeah it was bad practice for maven to include that in our app2 for us.

Regardless of where the jar is coming from, it still seems bad to me that 
Tomcat will respond to my request of app1 by loading a class from 
app2/WEB-INF/lib/jsp-2.1-6.1.14.jar.

I think Mark Thomas was saying that Tomcat was preventing loading of classes 
outside of Tomcat and app1, the vm classloading output seems to suggest 
otherwise.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Martin Gainty]

If you implement a VM Profiler such as 
http://visualvm.java.net/eclipse-launcher.html#installation

and send the profiler output to app1.output 
then stop app1 and stop tomcat
restart tomcat then reference app2 and send the profiler output to app2.output

then diff the 2..

can you confirm from the output that app1 is pulling classes from 
app2/WEB-INF/classes
can you confirm from the output that app2 is pulling classes from 
app1/WEB-INF/classes
?
Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.


 Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl 
 cannot be cast to org.apache.jasper.el.ELContextImpl
 Date: Wed, 22 Aug 2012 10:35:10 +1200
 From: dale_ogil...@trimble.com
 To: users@tomcat.apache.org
 
 -Original Message-
 From: Pid * [mailto:p...@pidster.com] 
 
 Where is that dependency JSP jar from?
 It should not be in WEB-INF/lib if it's providing JSP functionality.
 
 
 p
 
 The manifest for the jar says JSP 2.1 Jasper implementation from Glassfish, 
 and yeah it was bad practice for maven to include that in our app2 for us.
 
 Regardless of where the jar is coming from, it still seems bad to me that 
 Tomcat will respond to my request of app1 by loading a class from 
 app2/WEB-INF/lib/jsp-2.1-6.1.14.jar.
 
 I think Mark Thomas was saying that Tomcat was preventing loading of classes 
 outside of Tomcat and app1, the vm classloading output seems to suggest 
 otherwise.
 
 Dale
 B�CB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[�\�\��Z[�X�]�\X�K�ܙ�B�
  

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

So, I ran with JVM option -verbose:class 
Then I requested a jsp from app1 and the console printed:

...
[Loaded javax.el.ExpressionFactory from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELContext from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.ELContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
...

This seems to indicate that the class is being loaded by app1 from 
app2/WEB-INF/lib/jsp-2.1-6.1.14.jar. No?

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com] 
Sent: Monday, 13 August 2012 5:46 p.m.
To: users@tomcat.apache.org

Dale,

Are you running this under Eclipse (looks like it)? If so, what happens
when you run the same test outside of Eclipse?

/mde/

Well, the ClassCastException first showed itself on our standalone
tomcat instance on test. For debugging I moved to my workstation and
eclipse.

The test system has many apps deployed, my workstation just the two
apps. *Behavior* is the same in both environments, class loading output
comes from the eclipse environment.

Dale

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 

The above shows the problem (along with several other classes loaded
from that location).  
Looks like you have some hard-coded links to the local file system
buried inside the webapp's META-INF entries - making the .war file
decidedly non-portable. 
This doesn't explain why Tomcat isn't protecting itself from
ill-mannered webapps, but it does indicate that your process for
constructing webapps needs looking into.

 - Chuck

The app containing jsp-2.1xxx.jar is assembled by eclipse's maven
integration. There is nothing untoward I can see in MANIFEST.MF or
META-INF in general. No hard coded links I can detect (where should they
be?) and the app deploys and runs the same from windows workstation to
linux test server. Possibly what you are seeing as a problem is just the
way eclipse does things...

Dale

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Daniel Mikusa [mailto:dmik...@vmware.com] 

Maybe try adding the JVM option -verbose:class to bin/setenv.sh.  This 
option will cause the JVM to log when a class is loaded and from where it was 
loaded.
Dan

The following class load output excerpt results when I request a jsp from app1 
(wtpwebapps/PromotionCodes/) after both app2 (wtpwebapps/OsirisTest) and app1 
have been loaded in Tomcat startup. 

After the load of javax.el.ExpressionFactory, various loads from app2 
(wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar) occur.

snip preceding context

[Loaded javax.el.ExpressionFactory from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELContext from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.ELContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELException from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ExpressionFactory$CacheValue from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ExpressionFactory$CacheKey from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.el.ExpressionFactoryImpl from 
file:/C:/apache-tomcat-7.0.27/lib/jasper-el.jar]
[Loaded javax.el.ValueExpression from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.el.ValueExpressionLiteral from 
file:/C:/apache-tomcat-7.0.27/lib/jasper-el.jar]
[Loaded org.apache.jasper.runtime.ProtectedFunctionMapper from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELResolver from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.servlet.jsp.el.ImplicitObjectELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.el.MapELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ResourceBundleELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ListELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ArrayELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.BeanELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.servlet.jsp.el.ScopedAttributeELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.el.CompositeELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.servlet.jsp.JspWriter from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.apache.jasper.runtime.JspWriterImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.tagext.BodyContent from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.apache.jasper.runtime.BodyContentImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.el.VariableResolver from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.el.VariableMapper from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.VariableMapperImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.el.ExpressionEvaluator from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.apache.jasper.runtime.ExpressionEvaluatorImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded org.apache.jasper.security.SecurityUtil from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.tagext.TryCatchFinally from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.servlet.jsp.tagext.IterationTag from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.servlet.jsp.tagext.TagSupport from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.springframework.web.servlet.tags.RequestContextAwareTag from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/PromotionCodes/WEB-INF/lib/org.springframework.web.servlet-3.0.5.RELEASE.jar]
[Loaded org.springframework.web.servlet.tags.HtmlEscapingAwareTag from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/PromotionCodes/WEB-INF/lib/org.springframework.web.servlet-3.0.5.RELEASE.jar]
[Loaded org.springframework.web.servlet.tags.MessageTag from 

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Caldarale, Charles R]

 From: Dale Ogilvie [mailto:dale_ogil...@trimble.com] 
 Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl 
 cannot be cast to org.apache.jasper.el.ELContextImpl

 The following class load output excerpt results when I request 
 a jsp from app1 (wtpwebapps/PromotionCodes/) after both app2 
 (wtpwebapps/OsirisTest) and app1 have been loaded in Tomcat startup. 

 [Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
 file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/
 tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
 [Loaded org.apache.jasper.runtime.ELContextImpl from 
 file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/
 tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]

The above shows the problem (along with several other classes loaded from that 
location).  Looks like you have some hard-coded links to the local file system 
buried inside the webapp's META-INF entries - making the .war file decidedly 
non-portable.  This doesn't explain why Tomcat isn't protecting itself from 
ill-mannered webapps, but it does indicate that your process for constructing 
webapps needs looking into.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Eggers]

On 8/12/2012 9:28 PM, Caldarale, Charles R wrote:

From: Dale Ogilvie [mailto:dale_ogil...@trimble.com]
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl
cannot be cast to org.apache.jasper.el.ELContextImpl



The following class load output excerpt results when I request
a jsp from app1 (wtpwebapps/PromotionCodes/) after both app2
(wtpwebapps/OsirisTest) and app1 have been loaded in Tomcat startup.



[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/
tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded org.apache.jasper.runtime.ELContextImpl from
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/
tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]


The above shows the problem (along with several other classes loaded from that 
location).  Looks like you have some hard-coded links to the local file system 
buried inside the webapp's META-INF entries - making the .war file decidedly 
non-portable.  This doesn't explain why Tomcat isn't protecting itself from 
ill-mannered webapps, but it does indicate that your process for constructing 
webapps needs looking into.

  - Chuck


Dale,

Are you running this under Eclipse (looks like it)? If so, what happens 
when you run the same test outside of Eclipse?


/mde/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

On 10/08/2012 05:13, Dale Ogilvie wrote:

 It does concern me that there was a known issue that was fixed, and here
 I am seeing this EL impl instance sharing between apps in the fixed
 version.

It is certainly worth looking at to see what is going on. It might be
that there is another reference being retained somewhere or it could be
something the Jetty code is interfering with.

 Mark's Don't do that in terms of loading container jars in apps
 generally is a solution, but the trick is we didn't create the problem
 intentionally. We got scuppered by a maven dependency and Tomcat didn't
 protect us. Ideally bad behaviour of an app should not break the other
 apps in the container.

There are always ways for one app to impact another. CPU, I/O, network
traffic etc. Ways to separate apps in order of increasing separation:
- use a security manager (likely to have expensive side-effects)
- separate JVMs
- separate VMs
- separate physical machines
- separate networks

In most cases separate JVMs will suffice.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

On 10/08/2012 04:57, Dale Ogilvie wrote:
 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org] 
 Sent: Thursday, 9 August 2012 8:22 p.m.
 To: Tomcat Users List
 Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl 
 cannot be cast to org.apache.jasper.el.ELContextImpl
 
 Dale Ogilvie dale_ogil...@trimble.com wrote:

 ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast 
 to org.apache.jasper.el.ELContextImpl

 That says to me that app1 already has an instance of 
 org.apache.jasper.runtime.ELContextImpl which it is trying to cast to 
 the tomcat version.  So your statement that Tomcat prevents a class 
 loaded in app2 from being visible in app1 seems to be false.
 
 Does that cast succeed? No. Why? Because the class isn't visible to app1. 
 
 Thanks again for your explanations here Mark. Apologies if you thought I was 
 calling your credentials into question. Nothing of any sort entered into my 
 mind. 
 
 Trying not to be annoying, just to gain clarity. I'll rephrase your comment 
 above for clarity of what I believe you are saying.
 
 Does that cast of the org.apache.jasper.runtime.ELContextImpl  instance 
 succeed? No. Why? Because the org.apache.jasper.runtime.ELContextImpl class 
 isn't visible to app1.
 
 If app1 has an instance of org.apache.jasper.runtime.ELContextImpl (provided 
 by app2) whose class it knows nothing about, shouldn't the exception be:
 
 ClassNotFoundException org.apache.jasper.runtime.ELContextImpl
 
 NOT
 
 ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
 org.apache.jasper.el.ELContextImpl
 
 The latter error does not tell me that the class 
 org.apache.jasper.runtime.ELContextImpl isn't visible to app1.

It will depend exactly what is going on but since it is a cast that
fails, ClassCastException doesn't seem to be unreasonable. There may be
a root cause that provides more detail. The full exception should be in
the logs.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

On 10/08/2012 10:04, Mark Thomas wrote:
 On 10/08/2012 05:13, Dale Ogilvie wrote:
 
 It does concern me that there was a known issue that was fixed, and here
 I am seeing this EL impl instance sharing between apps in the fixed
 version.
 
 It is certainly worth looking at to see what is going on. It might be
 that there is another reference being retained somewhere or it could be
 something the Jetty code is interfering with.

When I try re-creating this I get all sorts of errors. I have worked
around a few but I am not inclined to continue. It is clear that adding
in the Jetty JAR is overriding parts of Tomcat's JSP support - not just
the EL implementation.

As previously suggested, running under a security manager will prevent this.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Martin Gainty]

a bug report needs to be filed for the maven-dependency 
apache-tomcat-maven-plugin that caused the error
the problem is since the plugin was rolled out to its new home..the latest 
plugin version 2.1 has no content which displays what the new version is 
supposed to accomplish
https://issues.apache.org/jira/browse/MTOMCAT#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

If the apache-tomcat-maven-plugin fix is in version 2.1
deprecate previous versions and pull that version from the dependency list of 
each affectect parent pom and rebuild all affected distros
In other words pull the contanimated version from all distros
 
If the apache-tomcat-maven-plugin fix is NOT in 2.1
Lets

1)file a report 

2)grab the source

3)implement a fix

4)notify interested parties

5)commit the fix to source control ..tag it uniquely (e.g. 2.1.1)

Martin
-


 Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl 
 cannot be cast to org.apache.jasper.el.ELContextImpl
 Date: Fri, 10 Aug 2012 16:13:32 +1200
 From: dale_ogil...@trimble.com
 To: users@tomcat.apache.org
 
 -Original Message-
 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
 
 1. Tomcat 7.0.26 and earlier has static field
 JspApplicationContextImpl.ExpressionFactory, so the EL implementation is
 effectively shared between web applications.
 
 Thanks for that info about the earlier bug in 7.0.26 Konstantin.
 
 2. I do not know why you are observing the issue with 7.0.27.
 Either the fix was incomplete,
 or maybe the JSPs were compiled with an earlier version of Tomcat. Try
 clearing the work folder so that they are recompiled.
 or it is caused specifically by other vendor using jasper package
 names in their classes. E.g. when some jasper classes were loaded by
 Tomcat by the first time, it might be loaded from 3rd party JAR instead
 of Tomcat.
 
 The work directory would have been empty when the apps started up with
 7.0.27, it wasn't an in place upgrade from the earlier 7.x version. I
 also specifically cleaned the app1 work directory while I was trying to
 figure out what was happening.
 
 It does concern me that there was a known issue that was fixed, and here
 I am seeing this EL impl instance sharing between apps in the fixed
 version.
 
 Mark's Don't do that in terms of loading container jars in apps
 generally is a solution, but the trick is we didn't create the problem
 intentionally. We got scuppered by a maven dependency and Tomcat didn't
 protect us. Ideally bad behaviour of an app should not break the other
 apps in the container. 
 
 Dale
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
  

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

Dale Ogilvie dale_ogil...@trimble.com wrote:


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, 8 August 2012 7:44 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl
cannot be cast to org.apache.jasper.el.ELContextImpl

Dale Ogilvie dale_ogil...@trimble.com wrote:
So you are saying that Tomcat should not be responsible for
preventing
app1 from unintentionally loading a class from
app2/WEB-INF/lib/[jetty-jsp-el].jar?

No I am not saying that. The reason you see the exception is because
Tomcat (well, with the help of the JVM) prevents a class loaded from
one application being visible to another application.

Thanks for your help Mark. I think your understanding doesn't match
what is being reported.

Thanks, but I'm quite happy with my understanding of the situation.

snip content=repeat of info already provided /

That says to me that app1 already has an instance of
org.apache.jasper.runtime.ELContextImpl which it is trying to cast to
the tomcat version.  So your statement that Tomcat prevents a class
loaded in app2 from being visible in app1 seems to be false.

Does that cast succeed? No. Why? Because the class isn't visible to app1. 

 Or am I reading this error message incorrectly?

You seem to be mixing up the object (can be passed from app2 to any app) with 
the class (only visible to app2).

snip /

As a aside, if someone with an @apache.org e-mail address (or a long term 
contributor to this list such as Chuck, Andre or Pid) answers your question 
then it is wise to assume that they know what they are talking about. If you 
want to avoid annoying them (which reduces your chances of being helped in the 
future) it is a good idea not to blatantly question the accuracy of their 
answer or their knowledge of Tomcat. On the odd occasion they do get it wrong 
there are tactful ways to point that out. For example, I get that the class 
from app2 is not visible to app1. Given that, the bit I don't get is that app1 
appears to be working with an instance of the class that is only visible to 
app2. What am I missing? would have achieved the same ends as your e-mail 
without any of the associated annoyance.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[chris derham]

| I am 95% certain of what is happenning but haven't tested this. It will
help your understanding if you read the EL specification, specifically the
section in the Javadoc regarding how implementations are discovered.
| Tomcat implements these rules. It is possible for an EL implementation to
be loaded from an application. Everything will be fine EL-wise for the
application that shipped with the EL implementation but things will
| fall apart for any other application that tries to use EL since the
implementation classes will not be visible.

Mark,

I don't understand one key component of your response. I don't pretend to
understand the internals of tomcat, but I thought that I had a good grasp
on how things were supposed to work. Please forgive me if I ask something
stupid.

You seem to say that the EL implementation will be loaded from the app2, as
it has an implementation present in its lib. You then say that this won't
be visible to app 1, presumably because this class is loaded into the
app2's class loader. That bit matches up with my understanding on app class
loaders in web containers - each app has its own, and they are separate
preventing leakage from one app to another. The bit I don't really
understand is when app 1 tries to run some EL code, surely the same
mechanism should kick in and load an EL implementation. I get that app 1
doesn't have an impl in its lib folder, but I would expect the call to be
passed to the tomcat shared class loader, whereby tomcat's EL impl is
loaded from CATALINA_BASE/lib. You seem to imply that once tomcat has
loaded a EL impl into the app2's classloader, that this some how breaks or
dirties the tomcat shared classloader so that it can no longer work the way
I describe above. Could you spare a minute to explain where my
understanding falters?

Thanks

Chris

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Konstantin Kolinko]

2012/8/3 Dale Ogilvie dale_ogil...@trimble.com:
 Hi,

 I'm seeing this problem below appearing now with one of our web-apps, google 
 has not helped me so far... There have been no changes with the web app in 
 question, which was working, so I'm picking something is going on with either 
 the tomcat or OS (virtualized) environment, but what? Any tips as to how to 
 figure out what is going on?

 root cause

 java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot 
 be cast to org.apache.jasper.el.ELContextImpl
 
 org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:982)
 
 org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspx_meth_c_005fout_005f0(promoCodeWelcome_jsp.java:301)
 
 org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspService(promoCodeWelcome_jsp.java:171)
 org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 
 org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)
 
 org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
 
 org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)
 
 org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)
 
 org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
 
 org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
 
 org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)

 The app is deployed on Tomcat 7.0.27, java 1.6_026, erroring jsp line:

 c:out value=${fn:length(promoCodeSpecCommand.user)} /


(...)
 I found the problem, but I am confused as to WHY it is a problem.
 *Another webapp* on the same tomcat instance includes the following jar
 in its WEB-INF/lib:

 jsp-2.1-6.1.14.jar

 This jar contains the offending class
 org.apache.jasper.runtime.ELContextImpl.

 If I remove this *other* application  (app2) from the server, the
 ClassCastException in app1 goes away.

 I thought the WEB-INF/lib directories for different applications were
 isolated from each other, but in this case it appears app1 is using a
 class from app2. This seems rather bad to me.


1. Tomcat 7.0.26 and earlier has static field
JspApplicationContextImpl.ExpressionFactory, so the EL implementation
is effectively shared between web applications.

This was a bug, noted and fixed in 7.0.27 (see BZ 52998),
http://svn.apache.org/viewvc?view=revisionrevision=1307581


2. I do not know why you are observing the issue with 7.0.27.

Either the fix was incomplete,

or maybe the JSPs were compiled with an earlier version of Tomcat. Try
clearing the work folder so that they are recompiled.

or it is caused specifically by other vendor using jasper package
names in their classes. E.g. when some jasper classes were loaded by
Tomcat by the first time, it might be loaded from 3rd party JAR
instead of Tomcat.

It is possible to set delegate=true on a Loader element to change
Tomcat classloading behaviour.


3. Regarding protection against other vendor using Jasper package classes,

The package.access setting in catalina.properties does include the
org.apache.jasper. package,  so a protection is already in place.
Note though that this setting is only effective when you run with
SecurityManager enabled.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

On 09/08/2012 11:41, chris derham wrote:
 | I am 95% certain of what is happenning but haven't tested this. It will
 help your understanding if you read the EL specification, specifically the
 section in the Javadoc regarding how implementations are discovered.
 | Tomcat implements these rules. It is possible for an EL implementation to
 be loaded from an application. Everything will be fine EL-wise for the
 application that shipped with the EL implementation but things will
 | fall apart for any other application that tries to use EL since the
 implementation classes will not be visible.
 
 Mark,
 
 I don't understand one key component of your response. I don't pretend to
 understand the internals of tomcat, but I thought that I had a good grasp
 on how things were supposed to work. Please forgive me if I ask something
 stupid.
 
 You seem to say that the EL implementation will be loaded from the app2, as
 it has an implementation present in its lib. You then say that this won't
 be visible to app 1, presumably because this class is loaded into the
 app2's class loader. That bit matches up with my understanding on app class
 loaders in web containers - each app has its own, and they are separate
 preventing leakage from one app to another. The bit I don't really
 understand is when app 1 tries to run some EL code, surely the same
 mechanism should kick in and load an EL implementation.

I strongly suspect - but haven't run a test to confirm - that the
implementation obtained from app2 is cached by the EL discovery
mechanism so that app1 is given the same instance.

It is pretty much a given that app1 will then break. The only question
is how long it will take before app1 hits a point where it realises it
is working with an instance of a class it can't load.

I'd need to do some testing to confirm exactly what is going on but the
reported behaviour is - so far - consistent with what I think is happening.

HTH,

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Thursday, 9 August 2012 8:22 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot 
be cast to org.apache.jasper.el.ELContextImpl

 Dale Ogilvie dale_ogil...@trimble.com wrote:

 ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
 org.apache.jasper.el.ELContextImpl

That says to me that app1 already has an instance of 
org.apache.jasper.runtime.ELContextImpl which it is trying to cast to 
the tomcat version.  So your statement that Tomcat prevents a class 
loaded in app2 from being visible in app1 seems to be false.

Does that cast succeed? No. Why? Because the class isn't visible to app1. 

Thanks again for your explanations here Mark. Apologies if you thought I was 
calling your credentials into question. Nothing of any sort entered into my 
mind. 

Trying not to be annoying, just to gain clarity. I'll rephrase your comment 
above for clarity of what I believe you are saying.

Does that cast of the org.apache.jasper.runtime.ELContextImpl  instance 
succeed? No. Why? Because the org.apache.jasper.runtime.ELContextImpl class 
isn't visible to app1.

If app1 has an instance of org.apache.jasper.runtime.ELContextImpl (provided by 
app2) whose class it knows nothing about, shouldn't the exception be:

ClassNotFoundException org.apache.jasper.runtime.ELContextImpl

NOT

ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
org.apache.jasper.el.ELContextImpl

The latter error does not tell me that the class 
org.apache.jasper.runtime.ELContextImpl isn't visible to app1.

Dale


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 

1. Tomcat 7.0.26 and earlier has static field
JspApplicationContextImpl.ExpressionFactory, so the EL implementation is
effectively shared between web applications.

Thanks for that info about the earlier bug in 7.0.26 Konstantin.

2. I do not know why you are observing the issue with 7.0.27.
Either the fix was incomplete,
or maybe the JSPs were compiled with an earlier version of Tomcat. Try
clearing the work folder so that they are recompiled.
or it is caused specifically by other vendor using jasper package
names in their classes. E.g. when some jasper classes were loaded by
Tomcat by the first time, it might be loaded from 3rd party JAR instead
of Tomcat.

The work directory would have been empty when the apps started up with
7.0.27, it wasn't an in place upgrade from the earlier 7.x version. I
also specifically cleaned the app1 work directory while I was trying to
figure out what was happening.

It does concern me that there was a known issue that was fixed, and here
I am seeing this EL impl instance sharing between apps in the fixed
version.

Mark's Don't do that in terms of loading container jars in apps
generally is a solution, but the trick is we didn't create the problem
intentionally. We got scuppered by a maven dependency and Tomcat didn't
protect us. Ideally bad behaviour of an app should not break the other
apps in the container. 

Dale




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

Dale Ogilvie dale_ogil...@trimble.com wrote:

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 

Again, that class is not a Tomcat class. As far as I can tell, that is
party of Jetty's JSP/EL implementation. 
snip
Anyway, if you start adding JARs from one container into another then
all sorts of things can and will go wrong. I see no way to protect
Tomcat against this.

Mark

So you are saying that Tomcat should not be responsible for preventing
app1 from unintentionally loading a class from
app2/WEB-INF/lib/[jetty-jsp-el].jar?

No I am not saying that. The reason you see the exception is because Tomcat 
(well, with the help of the JVM) prevents a class loaded from one application 
being visible to another application.

I thought that this was a contravention of Tomcat classloading rules.
Is your point that the jetty jar is doing some magic to force its
class into another apps classloader tree, and this sort of thing is
actually allowable for an app using container jars?

No.

If you could provide some more details on how one can intentionally
inject your own classes into other apps for their use, that would be
interesting, but it does sound like a bit of a security hole.

You can't do that.

Note, I don't know very much about the technical details of
classloaders, I am just trying to understand how something occurred
which seems to be against how things are supposed to work.

I am 95% certain of what is happenning but haven't tested this. It will help 
your understanding if you read the EL specification, specifically the section 
in the Javadoc regarding how implementations are discovered. Tomcat implements 
these rules. It is possible for an EL implementation to be loaded from an 
application. Everything will be fine EL-wise for the application that shipped 
with the EL implementation but things will fall apart for any other application 
that tries to use EL since the implementation classes will not be visible.

It might be possible to protect against this particular problem - I'd need to 
do some testing to confirm that - but in the general case, adding Servlet, JSP 
or EL implementation classes into a web application is going to cause problems 
(or a buunch of errors/warnings for the cases that Tomcat does detect).

P.S. The jetty jar actually appeared in app2 due to maven dependencies,
it was not added as a direct dependency for app2.

Why am I not surprised.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, 8 August 2012 7:44 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot 
be cast to org.apache.jasper.el.ELContextImpl

Dale Ogilvie dale_ogil...@trimble.com wrote:
So you are saying that Tomcat should not be responsible for preventing
app1 from unintentionally loading a class from 
app2/WEB-INF/lib/[jetty-jsp-el].jar?

No I am not saying that. The reason you see the exception is because Tomcat 
(well, with the help of the JVM) prevents a class loaded from one application 
being visible to another application.

Thanks for your help Mark. I think your understanding doesn't match what is 
being reported. I'll lay it out as I see it, for your consideration:

App1 *does not have* the jetty EL implementation class 
org.apache.jasper.runtime.ELContextImpl anywhere in its classloader tree
App2 *has* the jetty EL implementation EL class 
org.apache.jasper.runtime.ELContextImpl in WEB-INF/lib

When app1 is accessed and an EL expression is encountered in a jsp this error 
results:

ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
org.apache.jasper.el.ELContextImpl

That says to me that app1 already has an instance of 
org.apache.jasper.runtime.ELContextImpl which it is trying to cast to the 
tomcat version.  So your statement that Tomcat prevents a class loaded in app2 
from being visible in app1 seems to be false. App1 according to the error 
message has an instance of org.apache.jasper.runtime.ELContextImpl from app2, 
and it can't be cast to the expected class.

Or am I reading this error message incorrectly?

1. org.apache.jasper.runtime.ELContextImpl is from app2
2. org.apache.jasper.el.ELContextImpl is the normal tomcat class expected in 
app1
3. The error message from app1 is ClassCastException 
org.apache.jasper.runtime.ELContextImpl cannot be cast to 
org.apache.jasper.el.ELContextImpl

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Caldarale, Charles R]

 From: Dale Ogilvie [mailto:dale_ogil...@trimble.com] 
 Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl 
 cannot be cast to org.apache.jasper.el.ELContextImpl

 That says to me that app1 already has an instance of 
 org.apache.jasper.runtime.ELContextImpl which it is 
 trying to cast to the tomcat version.

No, that's not what's going on.  A class extending the abstract class ELContext 
is typically supplied *only* by the servlet container, not by any webapp.  
Since you have included it in app2 (inadvertently or not), it has superseded 
the one included with Tomcat, which would normally be loaded with a shared 
classloader, as part of the Jasper environment.  When app1 is referenced later, 
Jasper encounters an error because its expected ELContextImpl can't be accessed.

 So your statement that Tomcat prevents a class loaded in app2 from being 
 visible in app1 seems to be false.

Nope, that's exactly what's going on.  Your ELContextImpl class in app2 has 
disrupted Jasper being able to process expression language constructs in app1, 
as Mark stated.

What Tomcat might be able to do is prevent use of any webapp classes extending 
ELContext, but I haven't looked to see how hard that would be, or if the spec 
allows such a restriction.  The proper thing to do is not build a webapp that 
doesn't play well with others.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Pid]

On 07/08/2012 00:24, Dale Ogilvie wrote:
 Daniel Mikusa [mailto:dmik...@vmware.com] wrote:
 
 You would be using a shared class loader if you are placing JAR files used 
 by multiple deployed web applications into the
 $CATALINA_BASE/lib or $CATALINA_HOME/lib directory.  Are you placing any JAR 
 files into those folders?  
 
 We have placed three JDBC driver jars in $CATALINA_HOME/lib. I presume this 
 is irrelevant to this issue. The class in question 
 org.apache.jasper.runtime.ELContextImpl only appears to be in a jar located 
 in app2/WEB-INF/lib, yet it is being loaded for app1. I have verified that 
 the class is NOT in $CATALINA_HOME/lib. If we remove app2 from tomcat, the 
 ClassCastException disappears from app1. Further, removing the jar containing 
 org.apache.jasper.runtime.ELContextImpl  from app2 also resolves the issue.
 
 There does seem to be a problem that app2 is sharing classes with app1 from 
 app2/WEB-INF/lib. How can this happen?

Tomcat blocks some JARs from being loaded from a webapp lib - the
Servlet APIs - maybe the Tomcat JARs should go on the list.
This might be construed as a bug, or at least an enhancement request.


p

 Maybe try adding the JVM option -verbose:class to bin/setenv.sh.  This 
 option will cause the JVM to log when a class is loaded and from where it 
 was loaded.
 
 I'll look into that. 
 
 Dan
 
 Thanks.
 
 Dale
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Mark Thomas]

On 07/08/2012 00:24, Dale Ogilvie wrote:
 Daniel Mikusa [mailto:dmik...@vmware.com] wrote:
 
 You would be using a shared class loader if you are placing JAR
 files used by multiple deployed web applications into the 
 $CATALINA_BASE/lib or $CATALINA_HOME/lib directory.  Are you
 placing any JAR files into those folders?
 
 We have placed three JDBC driver jars in $CATALINA_HOME/lib. I
 presume this is irrelevant to this issue. The class in question
 org.apache.jasper.runtime.ELContextImpl only appears to be in a jar
 located in app2/WEB-INF/lib, yet it is being loaded for app1. I have
 verified that the class is NOT in $CATALINA_HOME/lib. If we remove
 app2 from tomcat, the ClassCastException disappears from app1.
 Further, removing the jar containing
 org.apache.jasper.runtime.ELContextImpl  from app2 also resolves the
 issue.
 
 There does seem to be a problem that app2 is sharing classes with
 app1 from app2/WEB-INF/lib. How can this happen?

Again, that class is not a Tomcat class. As far as I can tell, that is
party of Jetty's JSP/EL implementation. What on earth Jetty is doing
using an ASF namespace I have no idea. It looks to be a Jetty 6 issue
(i.e. 2 major versions ago) so not one we need to worry about too much
at this point.

Anyway, if you start adding JARs from one container into another then
all sorts of things can and will go wrong. I see no way to protect
Tomcat against this.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 

Again, that class is not a Tomcat class. As far as I can tell, that is party 
of Jetty's JSP/EL implementation. 
snip
Anyway, if you start adding JARs from one container into another then all 
sorts of things can and will go wrong. I see no way to protect Tomcat against 
this.

Mark

So you are saying that Tomcat should not be responsible for preventing app1 
from unintentionally loading a class from app2/WEB-INF/lib/[jetty-jsp-el].jar?

I thought that this was a contravention of Tomcat classloading rules. Is your 
point that the jetty jar is doing some magic to force its class into another 
apps classloader tree, and this sort of thing is actually allowable for an app 
using container jars?

If you could provide some more details on how one can intentionally inject your 
own classes into other apps for their use, that would be interesting, but it 
does sound like a bit of a security hole.

Note, I don't know very much about the technical details of classloaders, I am 
just trying to understand how something occurred which seems to be against how 
things are supposed to work.

P.S. The jetty jar actually appeared in app2 due to maven dependencies, it was 
not added as a direct dependency for app2.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

They are.  However, if you have classes in a shared classloader used by
both webapps, and such a class is coded badly, references can leak from
one webapp to another.

BTW, jcifs.http.NtlmHttpFilter hasn't been viable for some years (no
possibility of supporting NTLMv2), so you might want to use something
that actually works, such as waffle or Jespa.

 - Chuck

We don't intentionally use any shared classloader magic... Both of these
apps use the Spring framework 3.x. I *guess* that linking to a shared
classloader would have to be something designed into both of these apps,
or could it happen accidentally?

So either tomcat has a bug leaking class references between apps, or our
two separate apps (from a developer and design standpoint) somehow elect
to use the same classloader by default. Any thoughts on how to determine
which of these it is?

I admit to be surprized to see jcifs in there myself, I didn't write
this app, just have to support it.

Dale

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Daniel Mikusa]

- Original Message -
 They are.  However, if you have classes in a shared classloader used
 by
 both webapps, and such a class is coded badly, references can leak
 from
 one webapp to another.
 
 BTW, jcifs.http.NtlmHttpFilter hasn't been viable for some years (no
 possibility of supporting NTLMv2), so you might want to use something
 that actually works, such as waffle or Jespa.
 
  - Chuck
 
 We don't intentionally use any shared classloader magic... Both of
 these
 apps use the Spring framework 3.x. I *guess* that linking to a shared
 classloader would have to be something designed into both of these
 apps,
 or could it happen accidentally?

You would be using a shared class loader if you are placing JAR files used by 
multiple deployed web applications into the $CATALINA_BASE/lib or 
$CATALINA_HOME/lib directory.  Are you placing any JAR files into those 
folders?  

 
 So either tomcat has a bug leaking class references between apps, or
 our
 two separate apps (from a developer and design standpoint) somehow
 elect
 to use the same classloader by default. Any thoughts on how to
 determine
 which of these it is?

Maybe try adding the JVM option -verbose:class to bin/setenv.sh.  This 
option will cause the JVM to log when a class is loaded and from where it was 
loaded.

Dan


 
 I admit to be surprized to see jcifs in there myself, I didn't write
 this app, just have to support it.
 
 Dale
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

Daniel Mikusa [mailto:dmik...@vmware.com] wrote:

You would be using a shared class loader if you are placing JAR files used by 
multiple deployed web applications into the
$CATALINA_BASE/lib or $CATALINA_HOME/lib directory.  Are you placing any JAR 
files into those folders?  

We have placed three JDBC driver jars in $CATALINA_HOME/lib. I presume this is 
irrelevant to this issue. The class in question 
org.apache.jasper.runtime.ELContextImpl only appears to be in a jar located in 
app2/WEB-INF/lib, yet it is being loaded for app1. I have verified that the 
class is NOT in $CATALINA_HOME/lib. If we remove app2 from tomcat, the 
ClassCastException disappears from app1. Further, removing the jar containing 
org.apache.jasper.runtime.ELContextImpl  from app2 also resolves the issue.

There does seem to be a problem that app2 is sharing classes with app1 from 
app2/WEB-INF/lib. How can this happen?

Maybe try adding the JVM option -verbose:class to bin/setenv.sh.  This 
option will cause the JVM to log when a class is loaded and from where it was 
loaded.

I'll look into that. 

Dan

Thanks.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

2012/8/3 Dale Ogilvie dale_ogil...@trimble.com:
 Hi,

 I'm seeing this problem below appearing now with one of our web-apps,
google has not helped me so far... There have been no changes with the
web app in question, which was working, so I'm picking something is
going on with either the tomcat or OS (virtualized) environment, but
what? Any tips as to how to figure out what is going on?

 root cause

 java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl
cannot be cast to org.apache.jasper.el.ELContextImpl

org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContex
tImpl.java:982)

org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspx_meth_c_005fo
ut_005f0(promoCodeWelcome_jsp.java:301)

org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspService(promoC
odeWelcome_jsp.java:171)

org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:432)

org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)

org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

org.springframework.web.servlet.view.InternalResourceView.renderMergedOu
tputModel(InternalResourceView.java:238)

org.springframework.web.servlet.view.AbstractView.render(AbstractView.ja
va:250)

org.springframework.web.servlet.DispatcherServlet.render(DispatcherServl
et.java:1047)

org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherS
ervlet.java:817)

org.springframework.web.servlet.DispatcherServlet.doService(DispatcherSe
rvlet.java:719)

org.springframework.web.servlet.FrameworkServlet.processRequest(Framewor
kServlet.java:644)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.
java:549)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)

 The app is deployed on Tomcat 7.0.27, java 1.6_026, erroring jsp line:

 c:out value=${fn:length(promoCodeSpecCommand.user)} /


I found the problem, but I am confused as to WHY it is a problem.
*Another webapp* on the same tomcat instance includes the following jar
in its WEB-INF/lib:

jsp-2.1-6.1.14.jar

This jar contains the offending class
org.apache.jasper.runtime.ELContextImpl.

If I remove this *other* application  (app2) from the server, the
ClassCastException in app1 goes away.

I thought the WEB-INF/lib directories for different applications were
isolated from each other, but in this case it appears app1 is using a
class from app2. This seems rather bad to me.

Thoughts?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Caldarale, Charles R]

 From: Dale Ogilvie [mailto:dale_ogil...@trimble.com] 
 Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl 
 cannot be cast to org.apache.jasper.el.ELContextImpl

 I thought the WEB-INF/lib directories for different applications were
 isolated from each other, but in this case it appears app1 is using a
 class from app2. This seems rather bad to me.

They are.  However, if you have classes in a shared classloader used by both 
webapps, and such a class is coded badly, references can leak from one webapp 
to another.

BTW, jcifs.http.NtlmHttpFilter hasn't been viable for some years (no 
possibility of supporting NTLMv2), so you might want to use something that 
actually works, such as waffle or Jespa.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Konstantin Kolinko]

2012/8/3 Dale Ogilvie dale_ogil...@trimble.com:
 Hi,

 I'm seeing this problem below appearing now with one of our web-apps, google 
 has not helped me so far... There have been no changes with the web app in 
 question, which was working, so I'm picking something is going on with either 
 the tomcat or OS (virtualized) environment, but what? Any tips as to how to 
 figure out what is going on?

 root cause

 java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot 
 be cast to org.apache.jasper.el.ELContextImpl
 
 org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:982)
 
 org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspx_meth_c_005fout_005f0(promoCodeWelcome_jsp.java:301)
 
 org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspService(promoCodeWelcome_jsp.java:171)
 org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 
 org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)
 
 org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
 
 org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)
 
 org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)
 
 org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
 
 org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
 
 org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)

 The app is deployed on Tomcat 7.0.27, java 1.6_026, erroring jsp line:

 c:out value=${fn:length(promoCodeSpecCommand.user)} /


1. Stop the application,
 clear its work folder (${catalina.base}/work/${engine}/${host}/${webapp})
 - so that JSPs are recompiled,
 then start it again?

(That is if JSPs were occasionally compiled against different version
of Tomcat).

If you are precompiling your JSPs at build time - check that they are
compiled against the same version of Tomcat (7.0.27).

2. What libraries do you use in your application?
Check you have in WEB-INF/lib of the deployed application.

(That is if some libraries there conflict with same libraries provided
by Tomcat).

There is no such class as org.apache.jasper.runtime.ELContextImpl,
so whereever it comes from is the source of the problem.

You may search your jar files for the filename
org/apache/jasper/runtime/ELContextImpl.class


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[THIND Mansukhdeep]

May be this particular line in JSP is attempting to perform an action which the 
container is unable to process as a Servlet class. Just cross check the JSP 
code once. What does the c:out value=${fn:length(promoCodeSpecCommand.user)} 
/ do? Is it a directive? Or a call to some function?

Regards
Mansukhdeep

-Original Message-
From: Dale Ogilvie [mailto:dale_ogil...@trimble.com]
Sent: Friday, August 03, 2012 11:10 AM
To: Tomcat Users List
Subject: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be 
cast to org.apache.jasper.el.ELContextImpl

Hi,

I'm seeing this problem below appearing now with one of our web-apps, google 
has not helped me so far... There have been no changes with the web app in 
question, which was working, so I'm picking something is going on with either 
the tomcat or OS (virtualized) environment, but what? Any tips as to how to 
figure out what is going on?

root cause

java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot be 
cast to org.apache.jasper.el.ELContextImpl

org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:982)

org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspx_meth_c_005fout_005f0(promoCodeWelcome_jsp.java:301)

org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspService(promoCodeWelcome_jsp.java:171)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)

org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)

org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)

org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)

org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)

org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)

The app is deployed on Tomcat 7.0.27, java 1.6_026, erroring jsp line:

c:out value=${fn:length(promoCodeSpecCommand.user)} /

Thanks

Dale


B�CB��[��X��ܚX�KK[XZ[
�\�\��][��X��ܚX�P�X�]
�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�\�\��Z[�X�]
�\X�K�ܙ�B�
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systemes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.

For other languages, go to http://www.3ds.com/terms/email-disclaimer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org