You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Steve Downey <st...@netfolio.com> on 2001/02/07 17:38:20 UTC
RE: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/ja
sper CommandLineContext.java
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:glenn@voyager.apg.more.net]
Sent: Tuesday, February 06, 2001 9:48 PM
To: tomcat-dev@jakarta.apache.org
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 glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
<><><><><><><><><><><><><><><><><><><><><>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. <><><><><><><><><><><><><><><><><><><><><>
Re: Bug?[Tomcat 3.2.1] Or am I missing something...
Posted by Mel Martinez <me...@yahoo.com>.
--- "Craig R. McClanahan"
<Cr...@eng.sun.com> 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 <http://jakarta.apache.org/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/
Re: Bug?[Tomcat 3.2.1] Or am I missing something...
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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 <http://jakarta.apache.org/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
Bug?[Tomcat 3.2.1] Or am I missing something...
Posted by Mel Martinez <me...@yahoo.com>.
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/
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
CommandLineContext.java
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
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:glenn@voyager.apg.more.net]
> Sent: Tuesday, February 06, 2001 9:48 PM
> To: tomcat-dev@jakarta.apache.org
> 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 glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
> <><><><><><><><><><><><><><><><><><><><><>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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------