qexo-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qexo-general] RE: useful servlet


From: Tom Reilly
Subject: [Qexo-general] RE: useful servlet
Date: Tue, 4 Feb 2003 13:27:03 -0500

> String.intern() is a good idea, however I am not sure that 
> there is not an
> oportunity for corrupting the cache. Say that two request for 
> different xql
> files hit the KawaPageServlet at the same time.
> Now what is the guarantee that one of them putting a new 
> entry will not
> change the internal array such that the other's get will 
> fetch the wrong
> value?

You're right, making the hash table un-synchronized was wrong.

> The saveClass should probably be a servlet init parameter, rather than
> request parameter.

Hmm, I kinda liked it as a request parameter.  The use case is:

1) run a kawa page
2) see an exception from the generated code
3) request the page again with ?saveClass
4) load the .class file in a decompiler/class file viewer and debug

This is how I used it anyways, its nice to have the feature w/o having to 
restart the application.  That said hardcoding saveClass is not very
nice, what if the query parameter that caused the .class file to be
written out was an init parameter?  That would at least give the application
control over its parameter namespace.
 
> Reportedly Servlet Printer and Writer are implemented very 
> inefficiently.
> Using plain OutputStream is preferable.

Hmm, I didn't realize this class was doing any buffering.  My preference
would be for ServletPrinter to write directly to response.getWriter relying on 
the
servlet engine's buffering.  Typically servlet engines will buffer chars 
and only do character conversion when flushing to the underlying stream.  
Batching the character conversion can make the PrintWriter more efficient
than an OutputStream.  Also if we write to an OutputStream we have to
worry about char->byte conversion.  Better to let the servlet engine handle
it based on the content type header.  

> If possible, add more descriptive JavaDoc to show explitly 
> that the class
> writing is just a debug option and will not affect performance.

Good idea.  Thanks for the feedback.

> -=Ivelin=-
> ----- Original Message -----
> From: "Tom Reilly" <address@hidden>
> To: "'Per Bothner'" <address@hidden>
> Cc: "Ivelin Ivanov" <address@hidden>
> Sent: Monday, February 03, 2003 10:40 AM
> Subject: RE: useful servlet
> 
> 
> >
> > Attached is Ivelin's servlet reworked.  Notables:
> >
> > - supports multiple languages (at the same time this time)
> > - supports writing out the class file for debugging purposes
> > - servlet functionality works
> > - I made it look like other kawa source files as much as possible
> > (couldn't get my IDE to match Per's brace style perfectly), 
> I also added
> > the copyright header from other files (I have no problem 
> assigning the
> > copyright to Per, assuming Ivelin feels the same)
> >
> > I had to make changes in other parts of Kawa to get this to work,
> > diff attached as well.  Comments/questions welcome.
> >
> > > -----Original Message-----
> > > From: Per Bothner [mailto:address@hidden
> > > Sent: Wednesday, January 29, 2003 2:50 PM
> > > To: Tom Reilly
> > > Cc: Ivelin Ivanov
> > > Subject: Re: useful servlet
> > >
> > >
> > > Tom Reilly wrote:
> > > > I've got another proposal that will greatly simplify things but
> > > > is a little more radical.
> > > >
> > > > If we have a servlet that can invoke a Kawa source language
> > > > compiled to a Procedure do we even need the ability to compile
> > > > a Kawa source language file to a servlet at all?
> > >
> > > Well, I think that *is* Ivelin's suggestion.
> > >
> > > > Ie, maybe Ivelin's servlet is the only servlet support Kawa
> > > > needs.  Real servlets have init parameters, an init/destroy
> > > > lifecycle, are configured in web.xml etc.  Kawa programs running
> > > > under a servlet don't need all that baggage IMHO.
> > >
> > > Not directly - and in any case Kawa servlets access the servlet
> > > context (by which I include request and request) via the
> > > ServletCallContext anyway.
> > >
> > > The real question is whether the forwarding/compilation is an
> > > instance of KawaServlet (and thus sets up the ServletCallContext)
> > > or whether the compiled XQuery is an instance of KawaServlet.
> > > Either works, it seems.
> > >
> > > If there is extra overhead for the compiled servlet then I
> > > agree we don't need it, since all we actually usen is its
> > > doGet method.
> > >
> > > If we're agreed on the basic approach, perhaps it would make
> > > sense it you went over Ivelin's implementation, tested it,
> > > and made any suggestions for improvements you can.  (To start
> > > with, I suspect his XqlServlet is doing a bit too much logging.
> > > Plus it should be generalized to other langauages.  It would be
> > > cool if you could try out BRL/KRL.)  Thnough perhaps wait to see
> > > if anyone else on the list has any comments first.
> > > --
> > > --Per Bothner
> > > address@hidden   http://www.bothner.com/per/
> > >
> >
> >
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]