Re: Status Report: "Sealing Violation" Problems With Xerces

[James Duncan Davidson]

on 2/7/01 6:05 PM, Craig R. McClanahan at [EMAIL PROTECTED]
wrote:
> For those interested in the gory details, the problem is in
> StandardClassLoader.findClass(), which delegates to the parent class
> loader prior to checking the local repositories (I'm not sure this is
> really correct behavior -- hence the need for some research).  Consider
> a class like org.xml.sax.EntityResolver, which correctly exists in both
> Xerces and Crimson.  If the Crimson version of this class is loaded
> first, any attempt to load other org.xml.sax.* classes from Xerces will
> fail with a package sealing exception, because crimson.jar is sealed.

By default, the behavior recommended by the docs -- and the one exhibited
here is correct for most cases as the classes that implement the same "name"
should be in totally different class loaders that are siblings and are not
in a parent-child relationship. The problem that you describe here is
symptomatic of some sort of parent-child relationship where differing
classloaders are resolving sometimes to the same classloader and sometimes
to different classloaders (often seen when there are subtle versioning
differences).

At least that's my two cents from having been around the class loader block
a few times.

.duncan
-- 
James Duncan Davidson
http://x180.net/ !try; do();


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

Re: [PROPOSAL] Tomcat 3.2.2 Release Plan

[James Duncan Davidson]

on 2/7/01 5:12 PM, Marc Saegesser at [EMAIL PROTECTED] wrote:

> Any bug introduced by a code change since Tomcat 3.2.1 was released MUST
> be fixed.  If it worked in 3.2.1 it will work in 3.2.2.

"no regressions" I think is the term that you are looking for.

-- 
James Duncan Davidson
http://x180.net/ !try; do();


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

Re: Bug?[Tomcat 3.2.1] Or am I missing something...

[Mel Martinez]

--- "Craig R. McClanahan"
<[EMAIL PROTECTED]> wrote:
> Mel Martinez wrote:
> > com.g1440.naf.reflect.SimpleDecorator: illegal
> access
> > ...
> > Method.invoke(cfg,"getServletName",null);
> >

Oops! That should have been something like
Method m = ...getServletName method..
m.invoke(cfg,null);

> This is exactly the cause of the problem.  When you
> use Java reflection
> to return a Method object from the implementation
> class, you'll get the
> access error exception if the class itself is not
> public (which is true
> in this case).
> 

Oh duh-uh!  I knew this.  I really did know this. 
Okay, so I completely forgot this.  Why do I not have
a perfect memory?  Sigh...

Thanks a ton, Craig.  I can batten this down easily
enough, I think.

> The workaround is to use reflection to identify the
> interfaces that this
> class implements, and get the Method object from the
> interface instead of
> the implementation class.  We just went through this
> rigamarole on the
> Struts utility module that calls property getters
> and setters via
> reflection -- check out the
> org.apache.struts.util.PropertyUtils class in
> Struts  for how we
> dealt with it.
> 

I have a good idea on what to do here, but I'll
definitely take a look at the above.  There is always
more to learn, after all!

Mel


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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

Status Report: "Sealing Violation" Problems With Xerces

[Craig R. McClanahan]

Several people have reported difficulties with Tomcat 4.0b1when trying
to put xerces.jar (or another XML parser) in the WEB-INF/lib directory.
In theory, this should work fine -- Tomcat 4.0 implements the new
servlet 2.3 recommendation that local classes override ones from the
shared library classpath (i.e. all the JAR files in $CATALINA_HOME/lib,
which includes the JAXP 1.1 reference implementation required by
Jasper).

The good news:  Thanks to the help of several folks in the Turbine and
Jetspeed communities, I was able to accumulate enough test cases to
isolate where the problem is occurring.  It's definitely a problem in
the Tomcat 4.0 web app class loader, which is implementing the "local
override" functionality inconsistently.

The bad news:  Several simple fix attempts have not succeeded in making
this work -- it's going to take some more digging, but I'm confident
that it can be solved within a few days.  At that time, I will be asking
people to try a nightly build with the proposed fix, to ensure (a) that
it fixes the problem for everyone encountering it; and (b) that it does
not introduce other wierd things related to class loaders.

For those interested in the gory details, the problem is in
StandardClassLoader.findClass(), which delegates to the parent class
loader prior to checking the local repositories (I'm not sure this is
really correct behavior -- hence the need for some research).  Consider
a class like org.xml.sax.EntityResolver, which correctly exists in both
Xerces and Crimson.  If the Crimson version of this class is loaded
first, any attempt to load other org.xml.sax.* classes from Xerces will
fail with a package sealing exception, because crimson.jar is sealed.

Knowing what's wrong is the biggest part of the debugging effort -- now,
it's just a matter of finding the right solution.

Craig McClanahan

(Jon, feel free to share this status report with the Turbine and
Jetspeed lists, and anyother list you know of that has reported this
issue).



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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardClassLoader.java

[craigmcc]

craigmcc01/02/07 17:58:07

  Modified:catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java
  Log:
  Add some additional debugging instrumentation to assist in locating the
  "package sealing violation" exception problem.
  
  Revision  ChangesPath
  1.10  +24 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
  
  Index: StandardClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- StandardClassLoader.java  2001/02/04 00:50:40 1.9
  +++ StandardClassLoader.java  2001/02/08 01:58:06 1.10
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.9 2001/02/04 00:50:40 glenn Exp $
  - * $Revision: 1.9 $
  - * $Date: 2001/02/04 00:50:40 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.10 2001/02/08 01:58:06 craigmcc Exp $
  + * $Revision: 1.10 $
  + * $Date: 2001/02/08 01:58:06 $
*
* 
*
  @@ -109,7 +109,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.9 $ $Date: 2001/02/04 00:50:40 $
  + * @version $Revision: 1.10 $ $Date: 2001/02/08 01:58:06 $
*/
   
   public class StandardClassLoader
  @@ -620,8 +620,12 @@
   int i = name.lastIndexOf('.');
   if (i >= 0) {
   try {
  + if (debug >= 4)
  + log("  securityManager.checkPackageDefinition");
   securityManager.checkPackageDefinition(name.substring(0,i));
   } catch (Exception se) {
  + if (debug >= 4)
  + log("  -->Exception-->ClassNotFoundException", se);
throw new ClassNotFoundException(name);
   }
   }
  @@ -631,7 +635,15 @@
   // (throws ClassNotFoundException if it is not found)
   Class clazz = null;
   try {
  -clazz = super.findClass(name);
  + if (debug >= 4)
  + log("  super.findClass(" + name + ")");
  + try {
  + clazz = super.findClass(name);
  + } catch (RuntimeException e) {
  + if (debug >= 4)
  + log("  -->RuntimeException Rethrown", e);
  + throw e;
  + }
   if (clazz == null) {
   if (debug >= 3)
   log("--> Returning ClassNotFoundException");
  @@ -639,7 +651,7 @@
   }
   } catch (ClassNotFoundException e) {
   if (debug >= 3)
  -log("--> Passing on ClassNotFoundException");
  +log("--> Passing on ClassNotFoundException", e);
   throw e;
   }
   
  @@ -649,6 +661,8 @@
   continue;
   String pathname =
   repositories[i].substring(0, repositories[i].length() - 1);
  + if (debug >= 4)
  + log("  Checking repository " + pathname);
   if (pathname.startsWith("file://"))
   pathname = pathname.substring(7);
   else if (pathname.startsWith("file:"))
  @@ -667,6 +681,10 @@
   }
   
   // Return the class we have located
  + if (debug >= 4)
  + log("  Returning class " + clazz);
  + if ((debug >= 4) && (clazz != null))
  + log("  Loaded by " + clazz.getClassLoader());
   return (clazz);
   
   }
  
  
  

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

RE: [PROPOSAL] Tomcat 3.2.2 Release Plan

[Marc Saegesser]

How about the following:

Any bug introduced by a code change since Tomcat 3.2.1 was released MUST
be fixed.  If it worked in 3.2.1 it will work in 3.2.2.

All Bugzilla items opened against "Tocmat 3" must be marked as RESOLVED.
Those items that are not going to be fixed in Tomcat 3.2.2 will be given
a resolution of LATER.  After Tomcat 3.2.2 is released items marked LATER
will be re-opened and may then be addressed in a future release.

I am currently reviewing all open Bugzilla items and I've found several
things have have been fixed but the BugRat/Bugzilla report has not been
updated.  I would greatly appreciate it if any committer who has made
changes to the tomcat_32 branch in the last several months would make sure
that the bugs they have fixed are marked appropriately.

> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 07, 2001 6:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Tomcat 3.2.2 Release Plan
>
>
> on 2/7/01 3:34 PM, "Marc Saegesser" <[EMAIL PROTECTED]> wrote:
>
> > Please review and comment on the proposed release plan.  I will
> call release
> > plan vote in the near future.
>
> +0 if and only if (ie: not -1) the following is modified to state:
>
> "Any bug introduced after Tomcat 3.2.1 MUST be fixed."
>
> changed to:
>
> Any bug introduced after Tomcat 3.2.1 MUST be marked with a
> status of CLOSED
> and a resolution of FIXED or LATER. After the release of Tomcat 3.2.2, all
> bugs marked LATER will be marked as OPEN again so that they can
> be fixed in
> future versions.
>
> thanks,
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
>  && 
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

Tomcat alias in tomcat standalone SSL

[Barbara Nelson]

I'm trying to integrate Tomcat 3.2.1 with my application, and have modified
the implementation of SSLSocketFactory to use my keystore and trust manager.
I have a certificate in my keystore, but it has a different alias (not
tomcat) and I cannot change the alias.

Where in the tomcat source code does it specify that it will use the
'tomcat' alias for its SSL certificate? Can I change it? (I am assuming that
it uses the alias tomcat because the instructions for generating the
certificate for tomcat specifies that you should give it the alias tomcat.)

Many thanks,

Barbara Nelson.


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

cvs commit: jakarta-tomcat RELEASE-PLAN-3.2.2

[marcsaeg]

marcsaeg01/02/07 17:05:35

  Modified:.Tag: tomcat_32 RELEASE-PLAN-3.2.2
  Log:
  Updated release criteria to include Bugzilla resolution requirements.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +8 -6  jakarta-tomcat/Attic/RELEASE-PLAN-3.2.2
  
  Index: RELEASE-PLAN-3.2.2
  ===
  RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-PLAN-3.2.2,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- RELEASE-PLAN-3.2.22001/02/07 23:24:53 1.1.2.1
  +++ RELEASE-PLAN-3.2.22001/02/08 01:05:27 1.1.2.2
  @@ -1,4 +1,4 @@
  -$Id: RELEASE-PLAN-3.2.2,v 1.1.2.1 2001/02/07 23:24:53 marcsaeg Exp $
  +$Id: RELEASE-PLAN-3.2.2,v 1.1.2.2 2001/02/08 01:05:27 marcsaeg Exp $
   
   NOTE:  This document is the first cut at a release plan for the next
  dot release of Tomcat.  Nothing in this document should be
  @@ -52,11 +52,13 @@
   
   Release Criteria:
   
  -Any bug introduced after Tomcat 3.2.1 MUST be fixed.  Bugs that existed 
  -prior to the release of Tomcat 3.2.1 that are not fixed before the 
  -code freeze/beta release will not be fixed in Tomcat 3.2.2.  Once 
  -Tomcat 3.2.2 is finalized the tomcat_32 branch will be unfrozen and 
  -developers may commit fixes for a future release.
  +Any bug introduced by a code change since Tomcat 3.2.1 was released MUST
  +be fixed.  If it worked in 3.2.1 it will work in 3.2.2.
  +
  +All Bugzilla items opened against "Tocmat 3" must be marked as RESOLVED.
  +Those items that are not going to be fixed in Tomcat 3.2.2 will be given
  +a resolution of LATER.  After Tomcat 3.2.2 is released items marked LATER
  +will be re-opened and may then be addressed in a future release.
   
   The Tomcat 3.2.2 release MUST run the jakarta-watchdog test suite with no 
   errors on the following platforms:  Linux, Solaris, Windows 9x, 
  
  
  

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

cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13.c

[keith]

keith   01/02/07 15:47:15

  Modified:src/native/mod_jk/common jk_ajp13.c
  Log:
  Add the ACL method to ajpv13
  
  (see http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-04.txt)
  
  Revision  ChangesPath
  1.5   +7 -3  jakarta-tomcat/src/native/mod_jk/common/jk_ajp13.c
  
  Index: jk_ajp13.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13.c,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jk_ajp13.c2001/01/30 05:38:34 1.4
  +++ jk_ajp13.c2001/02/07 23:47:12 1.5
  @@ -56,7 +56,7 @@
   /***
* Description: Experimental bi-directionl protocol handler.   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.4 $   *
  + * Version: $Revision: 1.5 $   *
***/
   
   
  @@ -82,8 +82,8 @@
   
   /*
* Request methods, coded as numbers instead of strings.
  - * The list of methods was taken from Section 5.1.1 of RFC 2616
  - * and RFC 2518
  + * The list of methods was taken from Section 5.1.1 of RFC 2616,
  + * RFC 2518, and the ACL IETF draft.
*  Method= "OPTIONS"
*| "GET"
*| "HEAD"   
  @@ -98,6 +98,7 @@
*| "MOVE"
*| "LOCK"
*| "UNLOCK"
  + *| "ACL"
* 
*/
   #define SC_M_OPTIONS(unsigned char)1
  @@ -114,6 +115,7 @@
   #define SC_M_MOVE   (unsigned char)12
   #define SC_M_LOCK   (unsigned char)13
   #define SC_M_UNLOCK (unsigned char)14
  +#define SC_M_ACL (unsigned char)15
   
   
   /*
  @@ -239,6 +241,8 @@
*sc = SC_M_LOCK;
   } else if(0 == strcmp(method, "UNLOCK")) {
*sc = SC_M_UNLOCK;
  +} else if(0 == strcmp(method, "ACL")) {
  + *sc = SC_M_ACL;
   } else {
   rc = JK_FALSE;
   }
  
  
  

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

Re: [PROPOSAL] Tomcat 3.2.2 Release Plan

[Jon Stevens]

on 2/7/01 3:34 PM, "Marc Saegesser" <[EMAIL PROTECTED]> wrote:

> Please review and comment on the proposed release plan.  I will call release
> plan vote in the near future.

+0 if and only if (ie: not -1) the following is modified to state:

"Any bug introduced after Tomcat 3.2.1 MUST be fixed."

changed to:

Any bug introduced after Tomcat 3.2.1 MUST be marked with a status of CLOSED
and a resolution of FIXED or LATER. After the release of Tomcat 3.2.2, all
bugs marked LATER will be marked as OPEN again so that they can be fixed in
future versions.

thanks,

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 && 


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

cvs commit: jakarta-tomcat/src/doc AJPv13.html

[keith]

keith   01/02/07 15:51:07

  Modified:src/doc  AJPv13.html
  Log:
  Document the added ACL method.
  
  Revision  ChangesPath
  1.3   +1 -0  jakarta-tomcat/src/doc/AJPv13.html
  
  Index: AJPv13.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/AJPv13.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- AJPv13.html   2001/01/28 20:51:45 1.2
  +++ AJPv13.html   2001/02/07 23:51:06 1.3
  @@ -356,6 +356,7 @@
   MOVE12
   LOCK13
   UNLOCK  14
  +ACL 15
 
 
 
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13.java

[keith]

keith   01/02/07 15:49:45

  Modified:src/share/org/apache/tomcat/modules/server Ajp13.java
  Log:
  Add the WebDAV ACL method.
  
  Revision  ChangesPath
  1.12  +2 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
  
  Index: Ajp13.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Ajp13.java2001/02/02 16:41:52 1.11
  +++ Ajp13.java2001/02/07 23:49:43 1.12
  @@ -152,7 +152,8 @@
   "COPY",
   "MOVE",
   "LOCK",
  -"UNLOCK"
  +"UNLOCK",
  +"ACL"
   };
   
   // Translates integer codes to request header names
  
  
  

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

[PROPOSAL] Tomcat 3.2.2 Release Plan

[Marc Saegesser]

We have collected quite a few good bug fixes on the tomcat_32 branch since
the release of Tomcat 3.2.1.  I propose that we make a public release of the
tomcat_32 branch as Tomcat 3.2.2.  A proposed release plan can be found at

http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/Attic/R
ELEASE-PLAN-3.2.2?rev=1.1.2.1

I am volunteering to be the release manager for Tomcat 3.2.2, unless someone
else really wants to do it.

The goal for this release is not to fix every known problem in Tomcat 3.2.1
but to make the current set of fixes publicly available.  It would be great
if everything could get fixed but in the interest of timely bug fixes for
users with production systems I think we need to get what we have out there.
Once 3.2.2 is finalized, development can continue to fix additional bugs and
subsequent 3.2.x release can be made as needed.

Please review and comment on the proposed release plan.  I will call release
plan vote in the near future.

I will be able to build and test the native code for the ISAPI redirector
but I will need others to build/test the other native components and supply
them to me for inclusion into the release.  I will be able to test on
WinNT/200 and probably Win9x platforms but I would appreciate test reports
from other developers about the status of the other supported platforms.


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

cvs commit: jakarta-tomcat RELEASE-PLAN-3.2.2

[marcsaeg]

marcsaeg01/02/07 15:24:57

  Added:   .Tag: tomcat_32 RELEASE-PLAN-3.2.2
  Log:
  First draft of the proposed release plan for Tomcat 3.2.2
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +67 -0 jakarta-tomcat/Attic/RELEASE-PLAN-3.2.2
  
  
  
  

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

Re: Bug?[Tomcat 3.2.1] Or am I missing something...

[Craig R. McClanahan]

Mel Martinez wrote:

> Hi,
>
> I'm not sure what I'm missing here, but I'm running
> into a strange bit of behavior in Tomcat 3.2.1.
>
> I've got a jsp that uses classes in a jar file that is
> placed in the WEB-INF/lib folder like so:
>
> webapps/demo/simple.jsp
> webapps/demo/WEB-INF/lib/mylib.jar
>
> Early on one of the classes inside mylib.jar gets
> handed a reference to the ServletConfig object (as
> returned from
> javax.servlet.Servlet.getServletConfig()).  At some
> point further on (through a sequence too complex to
> relate here just yet) this class invokes the
> 'getServletName()' method on the ServletConfig object
> using reflection (i.e. Method.invoke()).
>
> This results in an IllegalAccessException.  Details
> are like so:
>
> com.g1440.naf.util.NFRuntimeException:
> com.g1440.naf.reflect.SimpleDecorator: illegal access
> attempt on :
>  object =
>org.apache.tomcat.facade.ServletConfigImpl@5e83f9 :
>
>  object class =
> org.apache.tomcat.facade.ServletConfigImpl :
>  method = getServletContext :
>  modifiers = public abstract :
>  object class loader =
>sun.misc.Launcher$AppClassLoader@404536 :
>  handler class loader = AdaptiveClassLoader(  )
>
>  Nested Exception = java.lang.IllegalAccessException
>
> In the above diagnostics, 'handler' refers to the
> class that is simply calling (the equivalent of)
>
> ServletConfig cfg = getServletConfig();
> ...
> Method.invoke(cfg,"getServletName",null);
>
> The 'ServletConfig.getServletName()' method is
> declared public in the API.  Can anyone suggest to me
> why the above might be happening?  I note that the
> implementation class:
> org.apache.tomcat.facade.ServletConfigImpl is declared
> package-level, (why?) but I wouldn't think this should
> affect my access to a public method.  There seems to
> be some mumblings about access protection in the
> facade package but I'm not yet familiar with what is
> going on there yet.
>

This is exactly the cause of the problem.  When you use Java reflection
to return a Method object from the implementation class, you'll get the
access error exception if the class itself is not public (which is true
in this case).

The workaround is to use reflection to identify the interfaces that this
class implements, and get the Method object from the interface instead of
the implementation class.  We just went through this rigamarole on the
Struts utility module that calls property getters and setters via
reflection -- check out the org.apache.struts.util.PropertyUtils class in
Struts  for how we dealt with it.

>
> Any help is appreciated.  As usual, I'm sure this is
> something boneheaded that I am doing wrong...
>
> Mel
>

Craig



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

Bug?[Tomcat 3.2.1] Or am I missing something...

[Mel Martinez]

Hi,

I'm not sure what I'm missing here, but I'm running
into a strange bit of behavior in Tomcat 3.2.1.

I've got a jsp that uses classes in a jar file that is
placed in the WEB-INF/lib folder like so:

webapps/demo/simple.jsp
webapps/demo/WEB-INF/lib/mylib.jar

Early on one of the classes inside mylib.jar gets
handed a reference to the ServletConfig object (as
returned from
javax.servlet.Servlet.getServletConfig()).  At some
point further on (through a sequence too complex to
relate here just yet) this class invokes the
'getServletName()' method on the ServletConfig object
using reflection (i.e. Method.invoke()).

This results in an IllegalAccessException.  Details
are like so:

com.g1440.naf.util.NFRuntimeException:
com.g1440.naf.reflect.SimpleDecorator: illegal access
attempt on :
 object = 
   org.apache.tomcat.facade.ServletConfigImpl@5e83f9 :

 object class = 
org.apache.tomcat.facade.ServletConfigImpl : 
 method = getServletContext : 
 modifiers = public abstract : 
 object class loader = 
   sun.misc.Launcher$AppClassLoader@404536 : 
 handler class loader = AdaptiveClassLoader(  )

 Nested Exception = java.lang.IllegalAccessException

In the above diagnostics, 'handler' refers to the
class that is simply calling (the equivalent of)

ServletConfig cfg = getServletConfig();
...
Method.invoke(cfg,"getServletName",null);

The 'ServletConfig.getServletName()' method is
declared public in the API.  Can anyone suggest to me
why the above might be happening?  I note that the
implementation class:
org.apache.tomcat.facade.ServletConfigImpl is declared
package-level, (why?) but I wouldn't think this should
affect my access to a public method.  There seems to
be some mumblings about access protection in the
facade package but I'm not yet familiar with what is
going on there yet.

Any help is appreciated.  As usual, I'm sure this is
something boneheaded that I am doing wrong...

Mel


__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

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

Re: Is it legal to have multiple taglib setter methods for the same property

[Pierre Delisle]

Alex,

Until the expert group rules on this, one workaround (that will always work)
is to simply do the following (assuming a property of type Object):

instead of:

use:


Another way is to define a PropertyEditor associated with your
property of type Object.

As Craig mentioned, this problem has been the subject of numerous
discussions. Here are some pointers that may help you and others
understand the issue.

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg00732.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg01323.html
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg01328.html

-- Pierre

"Craig R. McClanahan" wrote:
> 
> Alex Tang wrote:
> 
> > Thanks for the quick reply Craig.
> >
> > A followup question.  In tomcat 3.1, I was able to do
> >
> >  public setIndex ( Object o )
> >
> > If this is legal, I can do my own internal checking to see if the object "o" is a 
>String or an
> > int.  However in Tomcat 4.0, I get an error when I try to do this.  I saw some 
>talk about this
> > on the tomcat archives, however it wasn't clear whether this is an error on my 
>side or an error
> > in tomcat.
> >
> 
> This has been the subject of no small discussion on the expert group for JSP 1.2.  A 
>final decision
> is still pending AFAIK, at which time Tomcat 4.0 will change if it needs to.
> 
> >
> > Thanks again.
> >
> > ...alex...
> >
> 
> Craig
> 
> >
> > "Craig R. McClanahan" wrote:
> >
> > > IIRC, having two setters with different argument types violates the JavaBeans
> > > specification.  In addition, it seems to cause the Java reflection APIs to think 
>that there
> > > is no setter method at all, so you will get complaints about a read-only 
>property from any
> > > JSP implementation that uses this technique.
> > >
> > > Craig McClanahan
> > >
> > > Alex Tang wrote:
> > >
> > > > Hi folks.  (My apologies for crossposting, I wasn't sure if this is a
> > > > taglib question or a tomcat question/problem)
> > > >
> > > > I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
> > > > having a problem with a property "set" method.
> > > >
> > > > I have a taglib tag which takes one parameter: "index".  This index can
> > > > be either the string "all" or a number representing which CLE object to
> > > > show.
> > > >
> > > > I have the following defined in my tld file:
> > > >
> > > > 
> > > > displayCLE
> > > > com.funkware.DisplayCLETag
> > > > com.funkware.DisplayCLEExtraInfo
> > > > Display a CLE
> > > > 
> > > > index
> > > > true
> > > > true
> > > > 
> > > > 
> > > >
> > > > In my "DisplayCLETag.java" file, I have the following:
> > > >
> > > > /**
> > > >  * 
> > > >  *
> > > >  *Called when the taglib encounters an int for the index field...
> > > >  *This form takes an int which happens when a jsp expression is
> > > >  *evaluated on the right side of the "index=".
> > > >  *
> > > >  * @param nIndex
> > > >  *The index
> > > >  */
> > > > public void setIndex ( int nIndex ) {
> > > > m_nIndex = nIndex;
> > > > }
> > > >
> > > > /**
> > > >  * 
> > > >  *
> > > >  *Called when the taglib encounters the "index" parameter.  This
> > > >  *form takes an object.  We try to convert and Integer and a
> > > >  *String.  Anything else we barf on.
> > > >  *
> > > >  * @param o
> > > >  *An object which we'll try to convert.
> > > >  */
> > > > public void setIndex ( String s ) {
> > > > if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
> > > > m_nIndex = SHOWELEMENT_ALL;
> > > > return;
> > > > }
> > > > try {
> > > > m_nIndex = Integer.parseInt ( s );
> > > > } catch ( NumberFormatException e ) {
> > > > Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
> > > > "The element: '" + s +
> > > > "' is invalid, it should be a number" );
> > > > m_nIndex = SHOWELEMENT_UNDEF;
> > > > }
> > > > }
> > > >
> > > > The reason I have two setter methods for Index is that doing:
> > > >
> > > > 
> > > >
> > > > is different than
> > > >
> > > >  
> > > >
> > > > Is this a legal way of doing this?
> > > >
> > > > I ask because when I run tomcat using the SunJDK1.3, it works fine,
> > > > however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
> > > >
> > > >  java.lang.NumberFormatException: all
> > > >  at java.lang.Integer.parseInt(Integer.java:405)
> > > >  at java.lang.Integer.(Integer.java:540)
> > > >  at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
> > > > (JspRuntimeLibrary.java:125)
> > > >  at org.apache.jasper.runtime.JspRuntimeLibrary.i

Re: Is it legal to have multiple taglib setter methods for the same property

[Alex Tang]

Maya Muchnik wrote:

> Why you cannot use only one setter "public setIndex (String index)" and then inside 
>check if the
> string is convertable to integer or not? This way your index can represent a number 
>or "all".

In Tocmat 3.x, your suggestion works if the tag looks like:

 
 OR
 

However, if the tag is used like so:

 <% int i = 1; %>
 

Tomcat tries to call "setIndex ( int i )", instead of trying to convert the int into a 
String.  This
results in an error in the JSP.

...alex...


>
>
> "Craig R. McClanahan" wrote:
>
> > Alex Tang wrote:
> >
> > > Thanks for the quick reply Craig.
> > >
> > > A followup question.  In tomcat 3.1, I was able to do
> > >
> > >  public setIndex ( Object o )
> > >
> > > If this is legal, I can do my own internal checking to see if the object "o" is 
>a String or an
> > > int.  However in Tomcat 4.0, I get an error when I try to do this.  I saw some 
>talk about this
> > > on the tomcat archives, however it wasn't clear whether this is an error on my 
>side or an error
> > > in tomcat.
> > >
> >
> > This has been the subject of no small discussion on the expert group for JSP 1.2.  
>A final decision
> > is still pending AFAIK, at which time Tomcat 4.0 will change if it needs to.
> >
> > >
> > > Thanks again.
> > >
> > > ...alex...
> > >
> >
> > Craig
> >
> > >
> > > "Craig R. McClanahan" wrote:
> > >
> > > > IIRC, having two setters with different argument types violates the JavaBeans
> > > > specification.  In addition, it seems to cause the Java reflection APIs to 
>think that there
> > > > is no setter method at all, so you will get complaints about a read-only 
>property from any
> > > > JSP implementation that uses this technique.
> > > >
> > > > Craig McClanahan
> > > >
> > > > Alex Tang wrote:
> > > >
> > > > > Hi folks.  (My apologies for crossposting, I wasn't sure if this is a
> > > > > taglib question or a tomcat question/problem)
> > > > >
> > > > > I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
> > > > > having a problem with a property "set" method.
> > > > >
> > > > > I have a taglib tag which takes one parameter: "index".  This index can
> > > > > be either the string "all" or a number representing which CLE object to
> > > > > show.
> > > > >
> > > > > I have the following defined in my tld file:
> > > > >
> > > > > 
> > > > > displayCLE
> > > > > com.funkware.DisplayCLETag
> > > > > com.funkware.DisplayCLEExtraInfo
> > > > > Display a CLE
> > > > > 
> > > > > index
> > > > > true
> > > > > true
> > > > > 
> > > > > 
> > > > >
> > > > > In my "DisplayCLETag.java" file, I have the following:
> > > > >
> > > > > /**
> > > > >  * 
> > > > >  *
> > > > >  *Called when the taglib encounters an int for the index field...
> > > > >  *This form takes an int which happens when a jsp expression is
> > > > >  *evaluated on the right side of the "index=".
> > > > >  *
> > > > >  * @param nIndex
> > > > >  *The index
> > > > >  */
> > > > > public void setIndex ( int nIndex ) {
> > > > > m_nIndex = nIndex;
> > > > > }
> > > > >
> > > > > /**
> > > > >  * 
> > > > >  *
> > > > >  *Called when the taglib encounters the "index" parameter.  This
> > > > >  *form takes an object.  We try to convert and Integer and a
> > > > >  *String.  Anything else we barf on.
> > > > >  *
> > > > >  * @param o
> > > > >  *An object which we'll try to convert.
> > > > >  */
> > > > > public void setIndex ( String s ) {
> > > > > if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
> > > > > m_nIndex = SHOWELEMENT_ALL;
> > > > > return;
> > > > > }
> > > > > try {
> > > > > m_nIndex = Integer.parseInt ( s );
> > > > > } catch ( NumberFormatException e ) {
> > > > > Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
> > > > > "The element: '" + s +
> > > > > "' is invalid, it should be a number" );
> > > > > m_nIndex = SHOWELEMENT_UNDEF;
> > > > > }
> > > > > }
> > > > >
> > > > > The reason I have two setter methods for Index is that doing:
> > > > >
> > > > > 
> > > > >
> > > > > is different than
> > > > >
> > > > >  
> > > > >
> > > > > Is this a legal way of doing this?
> > > > >
> > > > > I ask because when I run tomcat using the SunJDK1.3, it works fine,
> > > > > however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
> > > > >
> > > > >  java.lang.NumberFormatException: all
> > > > >  at java.lang.Integer.parseInt(Integer.java:405)
> > > > >  at java.lang.Integer.(Integer.java:540)
> > > > >  at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
> > > > > (JspRuntim

Re: Is it legal to have multiple taglib setter methods for the same property

[Maya Muchnik]

Why you cannot use only one setter "public setIndex (String index)" and then inside 
check if the
string is convertable to integer or not? This way your index can represent a number or 
"all".

"Craig R. McClanahan" wrote:

> Alex Tang wrote:
>
> > Thanks for the quick reply Craig.
> >
> > A followup question.  In tomcat 3.1, I was able to do
> >
> >  public setIndex ( Object o )
> >
> > If this is legal, I can do my own internal checking to see if the object "o" is a 
>String or an
> > int.  However in Tomcat 4.0, I get an error when I try to do this.  I saw some 
>talk about this
> > on the tomcat archives, however it wasn't clear whether this is an error on my 
>side or an error
> > in tomcat.
> >
>
> This has been the subject of no small discussion on the expert group for JSP 1.2.  A 
>final decision
> is still pending AFAIK, at which time Tomcat 4.0 will change if it needs to.
>
> >
> > Thanks again.
> >
> > ...alex...
> >
>
> Craig
>
> >
> > "Craig R. McClanahan" wrote:
> >
> > > IIRC, having two setters with different argument types violates the JavaBeans
> > > specification.  In addition, it seems to cause the Java reflection APIs to think 
>that there
> > > is no setter method at all, so you will get complaints about a read-only 
>property from any
> > > JSP implementation that uses this technique.
> > >
> > > Craig McClanahan
> > >
> > > Alex Tang wrote:
> > >
> > > > Hi folks.  (My apologies for crossposting, I wasn't sure if this is a
> > > > taglib question or a tomcat question/problem)
> > > >
> > > > I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
> > > > having a problem with a property "set" method.
> > > >
> > > > I have a taglib tag which takes one parameter: "index".  This index can
> > > > be either the string "all" or a number representing which CLE object to
> > > > show.
> > > >
> > > > I have the following defined in my tld file:
> > > >
> > > > 
> > > > displayCLE
> > > > com.funkware.DisplayCLETag
> > > > com.funkware.DisplayCLEExtraInfo
> > > > Display a CLE
> > > > 
> > > > index
> > > > true
> > > > true
> > > > 
> > > > 
> > > >
> > > > In my "DisplayCLETag.java" file, I have the following:
> > > >
> > > > /**
> > > >  * 
> > > >  *
> > > >  *Called when the taglib encounters an int for the index field...
> > > >  *This form takes an int which happens when a jsp expression is
> > > >  *evaluated on the right side of the "index=".
> > > >  *
> > > >  * @param nIndex
> > > >  *The index
> > > >  */
> > > > public void setIndex ( int nIndex ) {
> > > > m_nIndex = nIndex;
> > > > }
> > > >
> > > > /**
> > > >  * 
> > > >  *
> > > >  *Called when the taglib encounters the "index" parameter.  This
> > > >  *form takes an object.  We try to convert and Integer and a
> > > >  *String.  Anything else we barf on.
> > > >  *
> > > >  * @param o
> > > >  *An object which we'll try to convert.
> > > >  */
> > > > public void setIndex ( String s ) {
> > > > if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
> > > > m_nIndex = SHOWELEMENT_ALL;
> > > > return;
> > > > }
> > > > try {
> > > > m_nIndex = Integer.parseInt ( s );
> > > > } catch ( NumberFormatException e ) {
> > > > Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
> > > > "The element: '" + s +
> > > > "' is invalid, it should be a number" );
> > > > m_nIndex = SHOWELEMENT_UNDEF;
> > > > }
> > > > }
> > > >
> > > > The reason I have two setter methods for Index is that doing:
> > > >
> > > > 
> > > >
> > > > is different than
> > > >
> > > >  
> > > >
> > > > Is this a legal way of doing this?
> > > >
> > > > I ask because when I run tomcat using the SunJDK1.3, it works fine,
> > > > however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
> > > >
> > > >  java.lang.NumberFormatException: all
> > > >  at java.lang.Integer.parseInt(Integer.java:405)
> > > >  at java.lang.Integer.(Integer.java:540)
> > > >  at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
> > > > (JspRuntimeLibrary.java:125)
> > > >  at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
> > > > (JspRuntimeLibrary.java:201)
> > > >  at 
>ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
> > > > (_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
> > > >  ...
> > > >
> > > > I don't actually think that is hotspot related.  I think i'm doing
> > > > something wrong.  I've looked through the tomcat code, however not too
> > > > particularly closely.  I was hoping 

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Glenn Nielsen]

Steve Downey wrote:
> 
> Placing all generated servlet classes into the same package only works if
> the loader cooperates. If the container does not use a separate, special,
> classloader for each page, it will not be able to distinguish the different
> instances of MyJSP.class, or in my case of index.class.

JSP pages are portable between containers and JSP engines.  But there is no
requirement that a runtime servlet compiled by a specific JSP engine be
compatible
with other JSP engines.  The class loading for a compiled jsp page is done by
jasper for a page compiled by jasper.

> 
> That implies that the command line compiler must produce distinguishable
> class names for each jsp that is produced, as it is a requirement that the
> servlet class be portable among containers, as long as support classes the
> jsp implementation depends on are packaged in the WAR file (section 2.1.5
> Compiling JSP Pages). The interface contract is supposed to be the only
> dependency between the container and the servlet.
> 

It still can, just tell JspC what package to put the generated servlets in
on the command line.

> Following on to this, I would prefer that the classes that the command line
> compiler and the runtime compiler, differ as little as possible. It should
> be possible to make them identical. That way, the code that is developed and
> tested can be identical to the code that is shipped to QA and to production.
> 

It doesn't matter what package jasper puts compiled runtime servlets in, it is
all internal to jasper.

Regards,

Glenn

> -Original Message-
> From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 9:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit:
> jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
> CommandLineContext.java
> 
> Mel Martinez wrote:
> >
> > The package naming solution I've opt'ed for in my own
> > enhancement to Jasper (which I'll gladly share) is to
> > derive package names that are related to the location
> > of the jsp relative to the server context.  This is
> > simple, flexible and should avoid collisions.
> >
> 
> There is no need for all this complexity to generate a package name
> in the new Jasper.  The way jasper now loads jsp pages, each page is
> completely isolated from all other pages.  Every jsp page compiled
> could be a class named "org.apache.jsp.MyJSP" without
> any concern whatsoever about conflicts because each individual page
> has its own class loader.  I will modify the current jasper class loader
> to support putting the jsp pages in a package, but this is just to comply
> with the JSP 1.2 spec.
> 
> All of the previous code in jasper to do all the package and class name
> mangling was to overcome the limitations of how the Jasper class loader
> for jsp pages was designed.
> 
> The new jasper makes it very easy to find and view the java source for
> a translated jsp page, it is located in
> work/somehost/someapp/some/context/path/MyJSP.java.
> 
> Regards,
> 
> Glenn
> 
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> <><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
> may contain confidential information and is intended only for the person(s)
> named.  Any use, copying or disclosure by any other person is strictly
> prohibited.  If you have received this transmission in error, please notify
> the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: JDBC - Tomcat with JSDK Enterprise Edition

[Jon Stevens]

on 2/7/01 10:24 AM, "BOON PING LIM" <[EMAIL PROTECTED]> wrote:

> Tomcat-Apache is my choice to implement JSP.
> i wish to u JDBC-ODBC bridge to link database with JSP pages.
> i were told that JDK 1.3 standard edition does not support JDBC, therefore,
> i have installed "j2sdkee-1_2_1-win"  -- JSDK enterprise edition. However,
> the below problem occurs
> 
> ' "C:\j2sdkee1.2.1\bin\java"' is not recognized as an internal or external
> command, operable program or batch file.
> 
> 
> the above statment popup tomcat extracting my classpath and show it on DOS
> screen. after the above statement, tomcat stop by pop up from the prompt.
> 
> What has happened?? i need the answer urgently.. everything get stuck from
> here
> 
> best regards,
> Boon Ping

Please go back and read this page carefully:



You are asking a User question and this is a Developer list.

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 && 


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

JDBC - Tomcat with JSDK Enterprise Edition

[BOON PING LIM]

Tomcat-Apache is my choice to implement JSP.
i wish to u JDBC-ODBC bridge to link database with JSP pages.
i were told that JDK 1.3 standard edition does not support JDBC, therefore, 
i have installed "j2sdkee-1_2_1-win"  -- JSDK enterprise edition. However, 
the below problem occurs

' "C:\j2sdkee1.2.1\bin\java"' is not recognized as an internal or external 
command, operable program or batch file.


the above statment popup tomcat extracting my classpath and show it on DOS 
screen. after the above statement, tomcat stop by pop up from the prompt.

What has happened?? i need the answer urgently.. everything get stuck from 
here

best regards,
Boon Ping


_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


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

Re: Is it legal to have multiple taglib setter methods for the same property

[Craig R. McClanahan]

Alex Tang wrote:

> Thanks for the quick reply Craig.
>
> A followup question.  In tomcat 3.1, I was able to do
>
>  public setIndex ( Object o )
>
> If this is legal, I can do my own internal checking to see if the object "o" is a 
>String or an
> int.  However in Tomcat 4.0, I get an error when I try to do this.  I saw some talk 
>about this
> on the tomcat archives, however it wasn't clear whether this is an error on my side 
>or an error
> in tomcat.
>

This has been the subject of no small discussion on the expert group for JSP 1.2.  A 
final decision
is still pending AFAIK, at which time Tomcat 4.0 will change if it needs to.

>
> Thanks again.
>
> ...alex...
>

Craig


>
> "Craig R. McClanahan" wrote:
>
> > IIRC, having two setters with different argument types violates the JavaBeans
> > specification.  In addition, it seems to cause the Java reflection APIs to think 
>that there
> > is no setter method at all, so you will get complaints about a read-only property 
>from any
> > JSP implementation that uses this technique.
> >
> > Craig McClanahan
> >
> > Alex Tang wrote:
> >
> > > Hi folks.  (My apologies for crossposting, I wasn't sure if this is a
> > > taglib question or a tomcat question/problem)
> > >
> > > I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
> > > having a problem with a property "set" method.
> > >
> > > I have a taglib tag which takes one parameter: "index".  This index can
> > > be either the string "all" or a number representing which CLE object to
> > > show.
> > >
> > > I have the following defined in my tld file:
> > >
> > > 
> > > displayCLE
> > > com.funkware.DisplayCLETag
> > > com.funkware.DisplayCLEExtraInfo
> > > Display a CLE
> > > 
> > > index
> > > true
> > > true
> > > 
> > > 
> > >
> > > In my "DisplayCLETag.java" file, I have the following:
> > >
> > > /**
> > >  * 
> > >  *
> > >  *Called when the taglib encounters an int for the index field...
> > >  *This form takes an int which happens when a jsp expression is
> > >  *evaluated on the right side of the "index=".
> > >  *
> > >  * @param nIndex
> > >  *The index
> > >  */
> > > public void setIndex ( int nIndex ) {
> > > m_nIndex = nIndex;
> > > }
> > >
> > > /**
> > >  * 
> > >  *
> > >  *Called when the taglib encounters the "index" parameter.  This
> > >  *form takes an object.  We try to convert and Integer and a
> > >  *String.  Anything else we barf on.
> > >  *
> > >  * @param o
> > >  *An object which we'll try to convert.
> > >  */
> > > public void setIndex ( String s ) {
> > > if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
> > > m_nIndex = SHOWELEMENT_ALL;
> > > return;
> > > }
> > > try {
> > > m_nIndex = Integer.parseInt ( s );
> > > } catch ( NumberFormatException e ) {
> > > Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
> > > "The element: '" + s +
> > > "' is invalid, it should be a number" );
> > > m_nIndex = SHOWELEMENT_UNDEF;
> > > }
> > > }
> > >
> > > The reason I have two setter methods for Index is that doing:
> > >
> > > 
> > >
> > > is different than
> > >
> > >  
> > >
> > > Is this a legal way of doing this?
> > >
> > > I ask because when I run tomcat using the SunJDK1.3, it works fine,
> > > however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
> > >
> > >  java.lang.NumberFormatException: all
> > >  at java.lang.Integer.parseInt(Integer.java:405)
> > >  at java.lang.Integer.(Integer.java:540)
> > >  at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
> > > (JspRuntimeLibrary.java:125)
> > >  at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
> > > (JspRuntimeLibrary.java:201)
> > >  at 
>ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
> > > (_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
> > >  ...
> > >
> > > I don't actually think that is hotspot related.  I think i'm doing
> > > something wrong.  I've looked through the tomcat code, however not too
> > > particularly closely.  I was hoping someone would know what's wrong.
> > >
> > > In a somewhat unrelated question, I tried having my setIndex() method
> > > defined as:
> > >
> > >  public void setIndex ( Object o )
> > >
> > > and then doing internal "instanceof" calls and casting to proper
> > > objects.  This works in Tomcat 3.1, however it fails in Tomcat 4.0.
> > >
> > > Did something change in JSP/Taglib 1.2 that makes that type of
> > > declaration invalid?
> > >
> > > Thanks very much.
> > >
> > 

Re: ServletContext.getRealPath(string)

[Craig R. McClanahan]

Jason van Zyl wrote:

> Hi,
>
> In Turbine I wanted to provide an easy way to give
> all classes in a webapp easy access to the real
> path to the webapp: someone on the Turbine list
> mentioned that ServletContext.getRealPath(path)
> is not required to be implemented. If this is
> the case what is the best way to provide access
> to the webapp path.
>

Implementing getRealPath() is required, but it is allowed to return
null.  Consider that a container might run the web application directly
out of a WAR file (Tomcat 4.0 can do this), or by storing the static
resources as BLOB objects in a database.  In such a case, there is no
such thing as "the real path to the webapp" because it is not stored in
files.

>
> In my particular case I am uploading files into
> a directory in the webapp, so I need to create
> files.
>
> Craig, do you have some standard of providing
> access to the webapp in Struts? Maybe I can
> borrow your idea if you're implementing something
> like this.
>

For Struts, we use ServletContext.getResource() for read access to webapp
resources, so it does not matter whether or not getRealPath() returns
null.  For writeable things (like file uploads), the normal pattern is a
servlet initialization parameter that defines the upload directory.  You
could make this default intelligently by trying to call
getRealPath("/upload/dir") and using that value if it is non-null.

If you are uploading things that need to become part of the webapp (like
a new Velocity template installed on the fly), you will probably need to
add restrictions in your deployment instructions that it will only work
on a servlet container that unpacks the webapp to a directory structure.

Providing portable APIs for writeable resources was discussed by the
expert group for 2.3, but no consensus was gained in time to make the
spec :-(.  This will undoubtedly be a high priority issue for the next
round.

>
> Thanks.
>
> jvz.
>

Craig



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

RE: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Steve Downey]

Placing all generated servlet classes into the same package only works if
the loader cooperates. If the container does not use a separate, special,
classloader for each page, it will not be able to distinguish the different
instances of MyJSP.class, or in my case of index.class. 

That implies that the command line compiler must produce distinguishable
class names for each jsp that is produced, as it is a requirement that the
servlet class be portable among containers, as long as support classes the
jsp implementation depends on are packaged in the WAR file (section 2.1.5
Compiling JSP Pages). The interface contract is supposed to be the only
dependency between the container and the servlet.

Following on to this, I would prefer that the classes that the command line
compiler and the runtime compiler, differ as little as possible. It should
be possible to make them identical. That way, the code that is developed and
tested can be identical to the code that is shipped to QA and to production.


-Original Message-
From: Glenn Nielsen [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 9:48 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
CommandLineContext.java


Mel Martinez wrote:
> 
> The package naming solution I've opt'ed for in my own
> enhancement to Jasper (which I'll gladly share) is to
> derive package names that are related to the location
> of the jsp relative to the server context.  This is
> simple, flexible and should avoid collisions.
> 

There is no need for all this complexity to generate a package name
in the new Jasper.  The way jasper now loads jsp pages, each page is
completely isolated from all other pages.  Every jsp page compiled 
could be a class named "org.apache.jsp.MyJSP" without
any concern whatsoever about conflicts because each individual page
has its own class loader.  I will modify the current jasper class loader
to support putting the jsp pages in a package, but this is just to comply
with the JSP 1.2 spec.

All of the previous code in jasper to do all the package and class name
mangling was to overcome the limitations of how the Jasper class loader
for jsp pages was designed.

The new jasper makes it very easy to find and view the java source for
a translated jsp page, it is located in 
work/somehost/someapp/some/context/path/MyJSP.java.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

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

ServletContext.getRealPath(string)

[Jason van Zyl]

Hi,

In Turbine I wanted to provide an easy way to give
all classes in a webapp easy access to the real
path to the webapp: someone on the Turbine list
mentioned that ServletContext.getRealPath(path)
is not required to be implemented. If this is
the case what is the best way to provide access
to the webapp path.

In my particular case I am uploading files into
a directory in the webapp, so I need to create
files.

Craig, do you have some standard of providing
access to the webapp in Struts? Maybe I can
borrow your idea if you're implementing something
like this.

Thanks.

jvz.


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

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[cmanolache]

> > > The new jasper makes it very easy to find and view
> > > the java source for
> > > a translated jsp page, it is located in
> > > work/somehost/someapp/some/context/path/MyJSP.java.
> > >
> > 
> > Does it not seem logical to assign a package to the
> > MyJSP class based on all or part of the above path?
> > 
> > This may seem like esthetics, I suppose.  Not
> > something we should get stressed about.
> > 
> > What you've done is a great improvement over what was
> > there.  Does it work with tc 3.3?
> > 
> 
> It should work for tc 3.x, but I don't have the time to
> back port it.

Well, it works in tomcat 3.x for some time ( too long ago to remember,
it's part of the original JspInterceptor :-)

The scheme is slightly different, but the ideea is the 
same ( using simpler and predictible names for the 
generated classes ). 



-- 
Costin


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

Re: [PATCH] Makefile

[jean-frederic clere]

GOMEZ Henri wrote:
> 
> Did you succeed using the web_app connector ?

Not yet!

> I still have the same problem with cookies...
> 
> La prise de conscience de votre propre ignorance est un grand pas vers la
> connaissance.
> -- Benjamin Disraeli
> 
> 
> >-Original Message-
> >From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, February 07, 2001 2:06 PM
> >To: [EMAIL PROTECTED]
> >Cc: [EMAIL PROTECTED]
> >Subject: [PATCH] Makefile
> >
> >
> >Hi,
> >
> >The Makefile in jakarta-tomcat-4.0/connectors are broken. I have fixed
> >them. Find enclosed the patch.
> >
> >Cheers
> >
> >Jean-frederic
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

RE: [PATCH] Makefile

[GOMEZ Henri]

Did you succeed using the web_app connector ?
I still have the same problem with cookies...


La prise de conscience de votre propre ignorance est un grand pas vers la
connaissance.
-- Benjamin Disraeli
 

>-Original Message-
>From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 07, 2001 2:06 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: [PATCH] Makefile
>
>
>Hi,
>
>The Makefile in jakarta-tomcat-4.0/connectors are broken. I have fixed
>them. Find enclosed the patch.
>
>Cheers
>
>Jean-frederic
>

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

[PATCH] Makefile

[jean-frederic clere]

Hi,

The Makefile in jakarta-tomcat-4.0/connectors are broken. I have fixed
them. Find enclosed the patch.

Cheers

Jean-frederic

? Makedefs
? patch.txt
? apache-1.3/.libs
Index: Makefile
===
RCS file: /home/cvs/mirror/jakarta-tomcat-4.0/connectors/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile2001/01/23 18:43:08 1.4
+++ Makefile2001/02/07 13:35:10
@@ -1,123 +1,64 @@
 # = #
-
 #   #
-
 # The Apache Software License,  Version 1.1 #
-
 #   #
-
 # Copyright (c) 1999, 2000  The Apache Software Foundation. #
-
 #   All rights reserved.#
-
 #   #
-
 # = #
-
 #   #
-
 # Redistribution and use in source and binary forms,  with or without modi- #
-
 # fication, are permitted provided that the following conditions are met:   #
-
 #   #
-
 # 1. Redistributions of source code  must retain the above copyright notice #
-
 #notice, this list of conditions and the following disclaimer.  #
-
 #   #
-
 # 2. Redistributions  in binary  form  must  reproduce the  above copyright #
-
 #notice,  this list of conditions  and the following  disclaimer in the #
-
 #documentation and/or other materials provided with the distribution.   #
-
 #   #
-
 # 3. The end-user documentation  included with the redistribution,  if any, #
-
 #must include the following acknowlegement: #
-
 #   #
-
 #   "This product includes  software developed  by the Apache  Software #
-
 #Foundation ."  #
-
 #   #
-
 #Alternately, this acknowlegement may appear in the software itself, if #
-
 #and wherever such third-party acknowlegements normally appear. #
-
 #   #
-
 # 4. The names  "The  Jakarta  Project",  "Tomcat",  and  "Apache  Software #
-
 #Foundation"  must not be used  to endorse or promote  products derived #
-
 #from this  software without  prior  written  permission.  For  written #
-
 #permission, please contact <[EMAIL PROTECTED]>.#
-
 #   #
-
 # 5. Products derived from this software may not be called "Apache" nor may #
-
 #"Apache" appear in their names without prior written permission of the #
-
 #Apache Software Foundation.#
-
 #   #
-
 # THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES #
-
 # INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY #
-
 # AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL #
-
 # THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY #
-
 # DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL #
-
 # DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS #
-
 # OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) #
-
 # HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, #
-
 # STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN #
-
 # ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE #
-
 # POSSIBILITY OF SUCH DAMAGE.   #
-
 #   #
-
 # = #
-
 #   #
-
 # This software  consists of voluntary  contributions made  by many indivi- #
-
 # duals on behalf of the  Apache Software Foundation.  For more information #
-
 # on the Apache Software Foundation, please see .   #
-
 #   #
-
 # =

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java

[Glenn Nielsen]

Mel Martinez wrote:
> 
> --- Glenn Nielsen <[EMAIL PROTECTED]> wrote:
> 
> > There is no need for all this complexity to generate
> > a package name
> > in the new Jasper.
> 
> Hmmm... compared to the gobbledy-gook that was being
> done before, I'd hardly call what I did complex.
> Aside from options, all it does is very simply asign
> the JSP page a package name based on it's directory
> hierarchy and place the .java and .class files in same
> - this is consistant with strict java naming
> convention.
> 
>  The way jasper now loads jsp
> > pages, each page is
> > completely isolated from all other pages.  Every jsp
> > page compiled
> > could be a class named "org.apache.jsp.MyJSP"
> > without
> > any concern whatsoever about conflicts because each
> > individual page
> > has its own class loader.
> 
> Ah, I see, you avoid file-level conflicts by placing
> the generated code into separate directory paths, even
> though the package names (currently) do not reflect
> the directory locations.  Yup, that should work,
> although i wouldn't say it is any less complex and I
> don't think it is consistent with standard java
> package/directory naming conventions.
> 
> > The new jasper makes it very easy to find and view
> > the java source for
> > a translated jsp page, it is located in
> > work/somehost/someapp/some/context/path/MyJSP.java.
> >
> 
> Does it not seem logical to assign a package to the
> MyJSP class based on all or part of the above path?
> 
> This may seem like esthetics, I suppose.  Not
> something we should get stressed about.
> 
> What you've done is a great improvement over what was
> there.  Does it work with tc 3.3?
> 

It should work for tc 3.x, but I don't have the time to
back port it.

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)

[Kief Morris]

[EMAIL PROTECTED] typed the following on 02:07 PM 2/6/2001 -0800
>> >( +2 if he also ports them to tomcat 3.3 or makes them independent of
>> >the container architecture - i.e. general purpose utils for
>> >serialization/deserialization with a simple adapter for each server :-)
>> 
>> Sure, the 3.3 code could be modified to use the Store interfaces to 
>serialize 
>> its sessions, although that would require sharing the Session interface. 
>Maybe
>> a bit too much work for the current release cycle.
>
>This doesn't have to be part of tomcat3.3 release - it can be a standalone
>module. The only issue is that the code you write ( Store, impls, etc )
>need to be "standalone" - i.e. be usable in any container.
>
>( the session manager for tomcat3.2 is based on early catalina session
>managers, but it was a huge pain to extract the session management and use
>it, since it depended on a lot of internals - Request, Lifecycle, etc).

True, this may make it more work than than it's worth. It would be possible
to define interfaces for SessionManager, Session, and Store which can be
used by both (and other) containers. As long as each container can depend 
only on the defined interfaces, without compromising their existing architectures,
someone could develop an implementation that can be used on any container
using the interfaces. 

I'd be willing to work with someone on these interfaces, but for the time being
I'm going to continue developing Catalina's session management code integrated 
with its architecture, which isn't likely to be portable. If someone wants to port
the stuff to a 3.3 module I'm happy to help.

Kief


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