tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MANDAR RAJE <man...@pathfinder.eng.sun.com>
Subject Re: Jasper Name Mangling Question - repost
Date Mon, 12 Jun 2000 22:06:50 GMT
Fedor Karpelevitch wrote:
> 
> is there really a need for class names to be calculated off jsp name. If
> this is not required then I would suggest that class files are named  with
> sequential numbers. for exaample jsp1.java; jsp2.java;... ;jsp10.java;
> jsp11.java etc... . And then have a hash table with jsp name as the key and
> the class name as the value. This way file names will stay short enough. I
> hope overhead of searching the hashtable is not too bad. Does this make
> sense?
> 


 While it is not required that the class name be based upon the 
name of the JSP, it is better to do that. I can't see all 
situations where it is useful but it's definitely useful for 
debugging as I know exactly which source corresponds to which
JSP. I think even the tool vendors will want some resemblance in 
the names (or alternately a way of predicting class name from the 
JSP name which is something we don't have in your "counter" scheme).

Mandar.




> WBR, Fedor.
> 
> Today: If builders built buildings the way programmers wrote programs, the
> first woodpecker that came along would destroy civilization. (Weinberg's
> Second Law)
> 
> > -----Original Message-----
> > From: MANDAR RAJE [mailto:mandar@pathfinder.eng.sun.com]
> > Sent: Monday, June 12, 2000 1:40 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: Jasper Name Mangling Question - repost
> >
> >
> > Steve Appling wrote:
> > >
> > > Jasper's JSP name mangling is causing me some problems, but
> > I don't know if it
> > > is operating in this fashion by design or because of a bug.
> >  I'm using the 3.1
> > > release.
> > >
> > > When compiling a JSP, jasper creates a directory structure
> > under my scratchdir
> > > that mimics the path to my jsp (as expected).  It then
> > creates the java source
> > > file (and resulting class) in the root of the scratchdir in
> > a mangled form
> > > (including substituting the "/" in the path with "_0002f").
> >  Between mangling
> > > the "/" and "_" characters, the resulting file names are
> > often too long to
> > > create
> > > under Win98 (>256 chars).
> >
> >  I have seen this particular problem mentioned before. What we need
> > (maybe) is a simple fix -- one that (for example) ignores '/' and
> > '-' characters. This will not gurantee a unique class name, but
> > probability of having name collisions will still be very low, also
> > making the file name relatively smaller.
> >
> >
> > >
> > > Why does jasper create a directory structure under the
> > scratchdir and not use
> > > it?  It would seem to be better to put an unmangled file
> > name in the appropriate
> > > directory.
> >
> >  The main reason is that Jasper needs to compare the time-stamps
> > and constructing a proper path name to the class file to find out
> > "last-modified time" at runtime is somewhat expensive. Ofcourse
> > things can be cached -- maybe one of the to-do things.
> >
> > >
> > > It is also not clear to me why the generated classes have
> > the appended version
> > > numbers.  Is it necessary to keep multiple versions of the
> > same jsp loaded
> > > simultaneously for some reason?  If the generated java file
> > name / class file
> > > name / class name were the same, then the
> > ClassFileData.findClassName call
> > > wouldn't be so expensive - it wouldn't have to parse the
> > class file data to
> > > determine the class name.
> > >
> > > This all seems overly complicated - I must be missing
> > something.  I would
> > > appreciate any clarifications.
> >
> >  This is to support JSP reloading. If you modify a JSP, you use
> > a different version number and generate a different
> > class which can then be loaded (A class with the same name can't
> > be loaded if its been loaded before).
> >
> > Thanks,
> > Mandar.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message