RE: ClassCastException while sharing objects accross applications

2005-10-04 Thread Seva Popov 
The type in Java is a combination of a fully qualified class name and its 
defining classloader. So the two objects with the same class name are 
considered different types in your two web applications because each web 
application is loaded by the dedicated webapp classloader.
 
To solve your problem you can use object serialization or if your objects are 
the java beans you can use the java.beans encoding.
 
The XMLEncoder class is a complementary alternative to the ObjectOutputStream 
and can used to generate a textual representation of a JavaBean in the same way 
that the ObjectOutputStream can be used to create binary representation of 
Serializable objects.   
 
--Seva



From: Surya Mishra [mailto:[EMAIL PROTECTED]
Sent: Mon 10/3/2005 4:12 PM
To: Tomcat Users List
Subject: ClassCastException while sharing objects accross applications



Hi,

I am trying to share an object between 2 applications deployed on the same
tomcat server. I have put the object in the ServletContext in my first
application. I access the object using
ServletContext.getContext(firstApp).getAttribute(object);.
The object comes in fine but it won't let me cast it to the actual Object
Type. I get a ClassCastException. I tried printing the name of the class.
That also came fine (same class name).

Thanks in advance.
-Surya

RE: ClassCastException while sharing objects accross applications

2005-10-04 Thread Seva Popov 
Yes, using the shared classloader seems like an obvious and easy option for 
sharing the objects between the web applications. However, like the previous 
author notes relying on the classloader can bring up some issues like 
introducing new dependencies and reducing the web application incapsulation. 

That is why the alternative way of sharing objects between the web applications 
is worth considering I guess. As I noted before one can achive this using the 
java object serialization or the java.beans xml encoding. This technique allows 
one to effectively eliminate the class loader information from the type and 
thus share the objects between the web applications without using the shared 
classloader.

BTW, one can not use the Tomcat JNDI tree as a place to share the objects 
between the web apps, because Tomcat does not allow one to put an arbitrary 
object into the JNDI tree. One possible way is to utilize the system 
MBeanServer.

--Seva

-Original Message-
From: Jon Wingfield [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 04, 2005 9:47 AM
To: Tomcat Users List
Subject: Re: ClassCastException while sharing objects accross applications

What Chuck says is right.
This approach has a few gotchas though, especially if ClassX is complex 
and references many other objects loaded from the same (WebApp) 
classloader. You can end up with a lot of classes up in the common 
repository. -o

Make ClassX an interface, if you can. That way only the interface (and 
any referenced types) need go in common. Refactoring here we go :)

HTH,

Jon

Caldarale, Charles R wrote:
From: Andrés Glez. [mailto:[EMAIL PROTECTED] 
Subject: Re: ClassCastException while sharing objects accross 
applications

What about using JNDI to share objects between webapps?
 
 
 Won't change anything, due to the previously noted classloader-specific 
 casting issue.  What should work (haven't tried it) is to put the defining 
 class for the object of interest in shared/classes or shared/lib (if packaged 
 in a jar), and remove it from each webapp.  This will create the class under 
 a classloader visible to both webapps.
 
 See:
 http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html
 for more info.
 
  - 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 5.5.9 and JSP 2.0 runtime expressions in the attribute values of JSTL 1.1

2005-09-13 Thread Seva Popov 
Hi,

I need to use the JSP 2.0 runtime expressions in the attribute values of
JSTL 1.1 tags but I am getting the exception when I try to use them.
 
My jsp page:

jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:c=http://java.sun.com/jsp/jstl/core;
  xmlns:fmt=http://java.sun.com/jsp/jstl/fmt;
  xmlns:fn=http://java.sun.com/jsp/jstl/functions;
  version=2.0

  jsp:directive.page contentType=text/html; charset=UTF-8/ 

  c:set var=aheader
value='%=System.getProperty(com.tv.common.assets.header)%'/
  
  ${aheader}
 
/jsp:root

org.apache.jasper.JasperException: /test10.jsp(9,31) The value of
attribute value associated with an element type c:set must not
contain the '' character.

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
ler.java:39)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java
:405)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java
:86)

org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.jav
a:211)

org.apache.jasper.compiler.ParserController.doParse(ParserController.jav
a:196)

org.apache.jasper.compiler.ParserController.parse(ParserController.java:
100)

org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja
va:556)

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

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

org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

Any advice?

Thanks,
Seva

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat 5.5.9 and JSP 2.0 runtime expressions in the attribute values of JSTL 1.1

2005-09-13 Thread Seva Popov 
BTW, I  understand that I can use a different syntax with the runtime
expressions. So, if I change my jsp (not use the xml syntax) it's
working fine:

%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
%@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %

  jsp:directive.page contentType=text/html; charset=UTF-8/ 

  c:set var=aheader
value='%=System.getProperty(com.tv.common.assets.header)%'/
  ${aheader}

However, I'd like to find out if it anyway somehow possible to use the
jsp xml syntax and JSP 2.0 runtime expressions in the attribute values
of JSTL 1.1

For example Resin does allow it.

Any ideas?


-Original Message-
From: Seva Popov [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 13, 2005 12:59 PM
To: Tomcat Users List
Subject: Tomcat 5.5.9 and JSP 2.0 runtime expressions in the attribute
values of JSTL 1.1

Hi,

I need to use the JSP 2.0 runtime expressions in the attribute values of
JSTL 1.1 tags but I am getting the exception when I try to use them.
 
My jsp page:

jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:c=http://java.sun.com/jsp/jstl/core;
  xmlns:fmt=http://java.sun.com/jsp/jstl/fmt;
  xmlns:fn=http://java.sun.com/jsp/jstl/functions;
  version=2.0

  jsp:directive.page contentType=text/html; charset=UTF-8/ 

  c:set var=aheader
value='%=System.getProperty(com.tv.common.assets.header)%'/
  
  ${aheader}
 
/jsp:root

org.apache.jasper.JasperException: /test10.jsp(9,31) The value of
attribute value associated with an element type c:set must not
contain the '' character.

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
ler.java:39)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java
:405)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java
:86)

org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.jav
a:211)

org.apache.jasper.compiler.ParserController.doParse(ParserController.jav
a:196)

org.apache.jasper.compiler.ParserController.parse(ParserController.java:
100)

org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja
va:556)

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

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

org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

Any advice?

Thanks,
Seva

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat 5.5.9 and JSP 2.0 runtime expressions in the attribute values of JSTL 1.1

2005-09-13 Thread Seva Popov 
It is funny. 
 
Once I talked with you a while ago I found in the spec that I indeed should use 
%= exp % in a JSP documents (i.e. with xml syntax)  instead of %= exp %  
in a JSP page. I tried it then and it did not work for me.
 
So I've decided that it's implemented differently in Tomcat.
I've just have tried it once more and it is working fine!
 
I guess last time my jsp was cached and that's why I did not see the result :)
 
Thanks again for your responce. It was helpful.
 
--Seva



From: Rahul Akolkar [mailto:[EMAIL PROTECTED]
Sent: Tue 9/13/2005 6:28 PM
To: Tomcat Users List
Subject: Re: Tomcat 5.5.9 and JSP 2.0 runtime expressions in the attribute 
values of JSTL 1.1



On 9/13/05, Seva Popov [EMAIL PROTECTED] wrote:
 BTW, I  understand that I can use a different syntax with the runtime
 expressions. So, if I change my jsp (not use the xml syntax) it's
 working fine:

 %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
 %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
 %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %

  jsp:directive.page contentType=text/html; charset=UTF-8/

  c:set var=aheader
 value='%=System.getProperty(com.tv.common.assets.header)%'/
  ${aheader}

 However, I'd like to find out if it anyway somehow possible to use the
 jsp xml syntax and JSP 2.0 runtime expressions in the attribute values
 of JSTL 1.1

 For example Resin does allow it.

 Any ideas?
snip/

Funny you should ask [
http://marc.theaimsgroup.com/?l=tomcat-userm=112493628101874w=2 ]

-Rahul



 -Original Message-
 From: Seva Popov [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, September 13, 2005 12:59 PM
 To: Tomcat Users List
 Subject: Tomcat 5.5.9 and JSP 2.0 runtime expressions in the attribute
 values of JSTL 1.1

 Hi,

 I need to use the JSP 2.0 runtime expressions in the attribute values of
 JSTL 1.1 tags but I am getting the exception when I try to use them.

 My jsp page:

 jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:c=http://java.sun.com/jsp/jstl/core;
  xmlns:fmt=http://java.sun.com/jsp/jstl/fmt;
  xmlns:fn=http://java.sun.com/jsp/jstl/functions;
  version=2.0

  jsp:directive.page contentType=text/html; charset=UTF-8/

  c:set var=aheader
 value='%=System.getProperty(com.tv.common.assets.header)%'/

  ${aheader}

 /jsp:root

 org.apache.jasper.JasperException: /test10.jsp(9,31) The value of
 attribute value associated with an element type c:set must not
 contain the '' character.

 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
 ler.java:39)

 org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java
 :405)

 org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java
 :86)

 org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.jav
 a:211)

 org.apache.jasper.compiler.ParserController.doParse(ParserController.jav
 a:196)

 org.apache.jasper.compiler.ParserController.parse(ParserController.java:
 100)

 org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)

 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja
 va:556)

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

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

 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

 Any advice?

 Thanks,
 Seva


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat 5.5 classloader log4j vs JCL issue

2005-09-06 Thread Seva Popov 
Yes it it possible to centralize the logging for the entire container
including all web apps. However, this seems to be a bad practice. The
better approach  is to separate the container internal logging and the
web apps logging. But I guess you know this for yourself.

-Original Message-
From: Woodchuck [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 06, 2005 11:10 AM
To: Tomcat Users List; Seva Popov
Subject: RE: Tomcat 5.5 classloader log4j vs JCL issue

hihi Seva,

yes, your suggestion also works.  i tried it to confirm, and it was my
backup plan to do in case i couldn't figure out how to *not* place
log4j.jar and commons-logging.jar into the ${Tomcat}/common/lib folder.

just fyi, it's also possible to centralize logging for the entire
servlet container by having the log4j.properties file in
${Tomcat}/common/classes (and the log4j.jar in ${Tomcat}/common/lib). 
this way, it is not necessary to put log4j.jar in each web app's
WEB-INF/lib folder, nor the log4j.properties file in each web app's
WEB-INF/classes folder.  centralize, as in one log4j.properties file
and one log4j.jar file.  yet, Tomcat and each web app can still
maintain their own separate log files!  i've tested this and it works
as well.


woodchuck


--- Seva Popov [EMAIL PROTECTED] wrote:

 Woodchuck,
  
 I guess, the alternative solution is to have all your web apps use
 log4j
 as well.
  
 So, you have commons-logging.jar and log4j.jar in the
 ${Tomcat}/common/lib folder
 and log4j.properties in ${Tomcat}/common/classes folder.
  
 Just add into your each web app's WEB-INF/classes folder
 log4j.properties file and
 into WEB-INF/lib folder log4j.jar.
  
 This way both Tomcat and your web apps will use separate log4j
 configurations.
  
 Thanks,
 Seva
  
 
 
 From: Paul Austin [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, August 31, 2005 1:30 PM
 To: Tomcat Users List
 Subject: Re: Tomcat 5.5 classloader log4j vs JCL issue
  
 Woodchuck,
 
 The following web page describes this situation and a solution to the
 problem.
 http://www.qos.ch/logging/sc.jsp
 
 I have attached the solution that I created this week based on the
 information above. To compile you will need servlet-api.jar and
 log4j.jar to compile.
 
 Include the jar you create from these files in your web application
 and
 then in your web.xml include the following sections.
 
 This section can be used if your log4j.xml is not under
 /WEB-INF/log4j.xml
   context-param
 param-namelog4jXmlLocation/param-name
 param-value/WEB-INF/log4j.xml/param-value
   /context-param
 
 The following calls invokes the listerner when the web app starts up
 to
 create a separate logging context for the web application.
 
   listener
  

listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/
 listener-class
   /listener
 
 Also make sure you have a listener that does the following when the
 context is destroyed otherwise you'll get a log of PermGen out of
 memory
 errors after a number of redeploys
 
 Introspector.flushCaches();
 LogFactory.getFactory().release();
 
 Good luck,
 Paul
 
 On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: 
  
 hihi all,
  
 on my TC 5.5.9 installation i deployed several web applications that
 uses the default JCL logging.  that is, i placed a simple
 logging.properties file into each web app's WEB-INF/classes folder
 and
 i have per web app logging.  everything works beautifully.
  
 then i installed a new web app that forced me to place
 commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib
 folder.
  as a result, all my previous per web app logging no longer works.
  
 i believe this is because log4j was discovered in the
 ${Tomcat}/common/lib first, and therefore it has superceeded any
 other
 logging system at the (lower) web app level.  this is due to Tomcat's
 classloading process.
  
 the reason this new web app required commons-logging.jar and
 log4j.jar
 to be placed specifically into the ${Tomcat}/commons/lib folder is
 because it instantiates a log4j logger object in it's start-up
 servlet
 which extends HttpServlet which is found in the servlet-api.jar which
 is also in the ${Tomcat}/commons/lib folder.  this is because
 Tomcat's
 classloading hierarchy dictates that classes in the common/lib cannot
 see web app classes 'downstream'.
  
 does anyone have any suggestions on how i can have per web app
 logging
 again?  i would like to keep my deployment process as web app
 isolated
 as possible (ie. each web app deployed by WAR, drop it in and that's
 it, no further steps necessary).
  
 thanks in advance,
 woodchuck
  
  

 
 Start your day with Yahoo! - make it your home page 
 http://www.yahoo.com/r/hs 
  
  
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED

RE: Tomcat 5.5 classloader log4j vs JCL issue

2005-08-31 Thread Seva Popov 
Woodchuck,
 
I guess, the alternative solution is to have all your web apps use log4j
as well.
 
So, you have commons-logging.jar and log4j.jar in the
${Tomcat}/common/lib folder
and log4j.properties in ${Tomcat}/common/classes folder.
 
Just add into your each web app's WEB-INF/classes folder
log4j.properties file and
into WEB-INF/lib folder log4j.jar.
 
This way both Tomcat and your web apps will use separate log4j
configurations.
 
Thanks,
Seva
 


From: Paul Austin [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 31, 2005 1:30 PM
To: Tomcat Users List
Subject: Re: Tomcat 5.5 classloader log4j vs JCL issue
 
Woodchuck,

The following web page describes this situation and a solution to the
problem.
http://www.qos.ch/logging/sc.jsp

I have attached the solution that I created this week based on the
information above. To compile you will need servlet-api.jar and
log4j.jar to compile.

Include the jar you create from these files in your web application and
then in your web.xml include the following sections.

This section can be used if your log4j.xml is not under
/WEB-INF/log4j.xml
  context-param
param-namelog4jXmlLocation/param-name
param-value/WEB-INF/log4j.xml/param-value
  /context-param

The following calls invokes the listerner when the web app starts up to
create a separate logging context for the web application.

  listener
 
listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/
listener-class
  /listener

Also make sure you have a listener that does the following when the
context is destroyed otherwise you'll get a log of PermGen out of memory
errors after a number of redeploys

Introspector.flushCaches();
LogFactory.getFactory().release();

Good luck,
Paul

On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: 
 
hihi all,
 
on my TC 5.5.9 installation i deployed several web applications that
uses the default JCL logging.  that is, i placed a simple
logging.properties file into each web app's WEB-INF/classes folder and
i have per web app logging.  everything works beautifully.
 
then i installed a new web app that forced me to place
commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder.
 as a result, all my previous per web app logging no longer works.
 
i believe this is because log4j was discovered in the
${Tomcat}/common/lib first, and therefore it has superceeded any other
logging system at the (lower) web app level.  this is due to Tomcat's
classloading process.
 
the reason this new web app required commons-logging.jar and log4j.jar
to be placed specifically into the ${Tomcat}/commons/lib folder is
because it instantiates a log4j logger object in it's start-up servlet
which extends HttpServlet which is found in the servlet-api.jar which
is also in the ${Tomcat}/commons/lib folder.  this is because Tomcat's
classloading hierarchy dictates that classes in the common/lib cannot
see web app classes 'downstream'.
 
does anyone have any suggestions on how i can have per web app logging
again?  i would like to keep my deployment process as web app isolated
as possible (ie. each web app deployed by WAR, drop it in and that's
it, no further steps necessary).
 
thanks in advance,
woodchuck
 
 
   

Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Custom tag library packaged within a jar and Tomcat 5.5.9

2005-08-25 Thread Seva Popov 
Hi,

I have the JAR file with the custom tag library in META-INF/tlds
directory.

My test.jsp page:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:ui=http://www.metatv.com/common/ui/tags-test;
  version=2.0
  test:print/
/jsp:root

The following exception is raised when I am trying to use the custom tag
library that packaged withing the JAR file in the web application: 
(happens both with Tomcat 5.5.9 or 5.5.11) :

org.apache.jasper.JasperException: /test.jsp(3,25) Could not add one or
more tag libraries
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
ler.java:39)...


So, is this a bug in Tomcat or am I missing something? 

Can anybody confirm that he/she was successful when using custom tag
libraries packaged withing the JAR file with the Tomcat 5.5.9?

I've searched the archives and the bug database without a luck.

P.S. Note, that the tag library and the jar file that I am using works
fine for me with the latest Resin container.
 
Thanks,
Seva

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JAASRealm's useContextClassLoader flag is misleading

2005-08-25 Thread Seva Popov 
Hi,

I believe the name of the JAASRealm's useContextClassLoader flag (and
the relevant Tomcat 5.5.* documentation) is misleading. Let's look at
the source code:

org.apache.catalina.realm.JAASRealm:
... 
// What if the LoginModule is in the container class loader ?
ClassLoader ocl = null;

if (isUseContextClassLoader()) {
  ocl=Thread.currentThread().getContextClassLoader();
 
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoa
der());
}
...

From the above code it is obvious that if useContextClassLoader flag is
set to true (the user intends to use the web app class loader) the
opposite happens: the context ClassLoader (that is web app's class
loader) will not be used but the container ClassLoader will be used
instead.

(When things were not working as I've expected, first I thought that the
useContextClassLoader flag is not used in the source code at all. Then,
I had to look into the source code to understand that the
seContextClassLoader flag is misleading).

Hope this saves somebody some time. 

I believe that either the name of the flag should be changed from
useContextClassLoader to useContainerClassLoader or the logic of the
source code should be changed.

Thanks,
Seva

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

org.apache.jasper.JasperException using jsp expression inside the c:set /

2005-08-24 Thread Seva Popov 
Hi,


The following line: 

 c:set var=admin value=%=request.getParameter(admin)%/

gives me the below exception under Tomcat 5.5.9:

org.apache.jasper.JasperException: /test.jsp(11,29) The value of
attribute value associated with an element type c:set must not
contain the '' character.

Is this a bug in Tomcat or am I missing something?
(I did not have any problems using the above syntax in Resin.)


Thanks,
Seva 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: org.apache.jasper.JasperException using jsp expression inside the c:set /

2005-08-24 Thread Seva Popov 
Hi Rahul,

Thanks for pointing me to the implicit JSP 2.0 param object. This worked
for me perfectly with the JSP 2.0 JSTL URIs:

jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:c=http://java.sun.com/jsp/jstl/core;
  version=2.0
c:set var=admin value=${param.admin} /


Anyway, I'd be interested to hear from somebody (with the pointers to
the JSP or JSTL specs if possible) why 

   c:set var=admin value=%=request.getParameter(admin)%/

worked for me with the latest Resin and doesn't with the latest Tomcat.

Is it against the specs?
 
Thanks again,
Seva

-Original Message-
From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 24, 2005 2:10 PM
To: Tomcat Users List
Subject: Re: org.apache.jasper.JasperException using jsp expression
inside the c:set /

On 8/24/05, Seva Popov [EMAIL PROTECTED] wrote:
 Hi,
 
 
 The following line:
 
 c:set var=admin value=%=request.getParameter(admin)%/
 
 gives me the below exception under Tomcat 5.5.9:
 
 org.apache.jasper.JasperException: /test.jsp(11,29) The value of
 attribute value associated with an element type c:set must not
 contain the '' character.
 
 Is this a bug in Tomcat or am I missing something?
 (I did not have any problems using the above syntax in Resin.)

Not sure what the prefix c is bound to, but I'd use JSTL 1.1 with TC
5.5.x and use EL and the implicit JSP 2.0 param object like so:

c:set var=admin value=${param.admin} /

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: org.apache.jasper.JasperException using jsp expression inside the c:set /

2005-08-24 Thread Seva Popov 
Well, 

JSTL l.0 spec
Supporting the EL in a JSP 1.2 environment

There were quite a few issues involved with the support of an expression
language
within JSTL given the constraint that it had to work with JSP 1.2
containers. In order
to be able to support both the scripting (rtexprvalues) and the EL
(elexprvalues)
worlds, we came up with the concept of twin tag libraries: one that
supports the
expression language, and one that supports request time expression
values. The
assumption is that people will mostly use the EL-based tag libraries,
while it is still
possible for page authors that prefer scripting to use JSTL with
rtexprvalues
(provides benefits for type safety and performance) via the RT-based tag
libraries.
The URIs of the RT-based tag libraries simply have the _rt suffix
appended. It is
allowed to mix both EL- and RT- based actions as shown in the following
example:
fmt:message key=attendanceAgeAverage
fmt:param value=${totalParticipants}
fmt_rt:param value=%=Stats.ageAverage(participants)%/
/fmt:message
/JSTL l.0 spec

As you see runtime expressions were quite valid in jstl 1.0 tags.

I couldn't find information in jstl 1.1 / jsp 2.0 regarding this issue. 
That is why I would appreciated the pointers to the specs.

--Seva

-Original Message-
From: Rahul Akolkar [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 24, 2005 4:23 PM
To: Tomcat Users List
Subject: Re: org.apache.jasper.JasperException using jsp expression
inside the c:set /

On 8/24/05, Seva Popov [EMAIL PROTECTED] wrote:
 Hi Rahul,
 
 Thanks for pointing me to the implicit JSP 2.0 param object. This
worked
 for me perfectly with the JSP 2.0 JSTL URIs:
 
 jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:c=http://java.sun.com/jsp/jstl/core;
  version=2.0
 c:set var=admin value=${param.admin} /
 
 
 Anyway, I'd be interested to hear from somebody (with the pointers to
 the JSP or JSTL specs if possible) why
 
   c:set var=admin value=%=request.getParameter(admin)%/
 
 worked for me with the latest Resin and doesn't with the latest
Tomcat.
 
 Is it against the specs?
snip/

You mean, apart from the fact that it is invalid XML and hence cannot
be part of a jspx document (such as the one you are using)? ;-)

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Exception when using TLD files in JAR files included with web application

2005-08-23 Thread Seva Popov 
Hi,

I am evaluating the migration to Tomcat from Resin and encounted the
following problem.

The following exception is raised when I am trying to use tag libraries
packaged as JAR files in the web application with both Tomcat 5.5.9 or
5.5.11 (I have the JAR file with the tld in META-INF/tlds directory):

My JSP page:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page;
  xmlns:ui=http://www.metatv.com/common/ui/tags-test;
  version=2.0
  test:dosomething/
/jsp:root

Exception:
org.apache.jasper.JasperException: /test.jsp(7,25) Could not add one or
more tag libraries.

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
ler.java:39)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java
:405)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java
:86)

org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.jav
a:211)

org.apache.jasper.compiler.ParserController.doParse(ParserController.jav
a:196)

org.apache.jasper.compiler.ParserController.parse(ParserController.java:
100)

org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja
va:556)

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

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

org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)


I've configured Tomcat for multiple instances and besides the above
problem the rest looks okay.

I did not have this problem with Resin. 
So, is this a bug in Tomcat or am I missing something?
 
Thanks,
Seva

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]