> > 1. I want to be able to do some general bookkeeping/logging for
> > each request before any other processing is done.
>
> Like what?
>
> The reason why I say this is that you can accomplish this in your Page
Module.
Yes, I think that will work for my application.
> If you did have this functionality, what would you want passed in?
Request/Response? What
> exactly would you be logging that the servlet engine can't already log for
you (JServ's debug
> logging shows quite a bit of information)?
That could work too, but I wouldn't want to marry myself to a specific
servlet engine, and yes, Request/Response would get passed in.
> > 2. I need to do some generic initialization on each HttpSession
> > object after it is created.
>
> Again, like what? The reason why I ask is because this probably isn't a
very good design and
> I want to prevent you from doing a bad design before you go down that
road. :-)
>
> HttpSession is just a hashtable. You stuff objects into that Hashtable.
Those objects may need
> to have initialization on them before you stuff them into the hashtable.
So, your methodology
> of stuffing those objects into the hashtable should execute the
initialization.
True, but it would still be convenient to perform the object initialization
and hashtable stuffing in one place for the objects that are required for
each session.
The main thing I'm trying to accomplish is to attach a "workspace" object to
my session as soon as it is created. This is both a data staging area and
an interface layer to other middle-tier and back-end services, such as our
EJB server. The reason I'm localizing this stuff in a workspace object is
because it will also be used for non-web (i.e. Java) clients.
If you're still opposed to the idea of adding the initializeSession method
then I think I can accomplish what I need by writing a simple service for
accessing my workspace that will retrieve the object from the session,
creating it first if it doesn't already exist, but see below for additional
comments.
> > Of course I could extend Turbine, override doGet, copy the
> > doGet code into my subclass and modify it as necessary,
> > but then I wouldn't pick up changes to doGet in Turbine.
>
> Actually, a better way would be to write a "pre-servlet" that simply wraps
around the Turbine
> servlet and simply calls it by passing in the Req/Response. That way you
don't have to worry
> about calling super().
>
Yes, that's a nice generic way to take care of any pre-processing
requirements.
> > Here's what I'd like to propose:
> >
> > 1. Add a method called something like preHandleRequest to
> > Turbine that would get called like this (code modified from
> > Turbine.java):
> >
> > // check to make sure that we started up properly
> > if (initFailureMessage != null)
> > {
> > throw new Exception ( initFailureMessage );
> > }
> >
> > preHandleRequest(req, res);
> >
> > // get general RunData here...
> >
> > The default implementation of preHandleRequest wouldn't do
> > anything, but a Turbine subclass could override it as desired.
>
> -1. Next people will ask for a postHandleRequest()...
Well, that doesn't seem like a bad idea to me, although I don't have a need
for it myself.
> > Now I could override initializeSession in my subclass, call the default
> > implementation, and then perform my own custom initialization.
> > What does everyone think about this?
>
> Again, I don't think this is a good idea. Prove me wrong. ;-)
>
So, it appears that I can do what I need to do without touching the Turbine
class. However I'm not quite ready to give up on the idea in principle yet.
As I've been learning Turbine, I've found that the mechanisms for extending
it are fairly obvious and convenient, which is a primary characteristic of a
quality framework. I brought up these two cases because the mechanism for
extending Turbine the way that I wanted wasn't obvious to me, and I'm not
sure that the solutions we're batting around would work well in all cases.
I would think that others besides myself would run into the same questions
I've brought up here, so shy not create an obvious (i.e. self documenting)
solution in the framework?
If you want to disourage people from subclassing Turbine, another option
would be to create default objects like RequestPreProcessor,
SessionInitializer, etc. that get called from Turbine in the appropriate
places. A user could then tell Turbine to use alternate implementations
(subclasses) of these objects in the Turbine properties file. Actually I
guess they would simply be new types of Actions. This would make the
implementation of these features more consistent with the rest of the
framework (SessionValidatior, AccessController, etc.)
Comments?
-Jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
