This issue of dynamic bean initialization troubles me a bit. Having
processRequest() is certainly useful, but is it really appropriate to
initialize potentially sensitive dynamic information using HTTP requests?
This seems clunky.
Is there a standard way to access the bean namespace from HttpSession? If
there was, you could write a servlet that instantiated and connected the
beans to their respective back ends (RMI, CORBA, EJB, etc).
Perhaps the Infobus could be rolled into the JSP runtime engines to allow
these beans to discover each other...
Any thoughts...
Rob
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Costin Manolache
> Sent: Thursday, March 25, 1999 1:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: getting access to HttpServletResponse
>
>
> > .92 doesn't provide access to the HttpServletResponse from
> within a bean.
> > First, I'm wondering why it wasn't included. The reason I want
> it is so that
> > I can check the session to determine if a person has logged in. If they
> > haven't I need to redirect them to a log in page. I don't
> believe there is a
>
> > feasible way to do redirect that using JSP .92 beans.
>
> It's my understanding that processRequest() should init the Bean
> ( in addition
> or instead of just setting properties). That mean the "semantic"
> of processRequest()
> is more "initBean" ( you can do more - but I don't think it's a
> good ideea to
> take any action - since you want all the beans in the page to be
> initialized before
> starting any action, maybe other beans "processRequest" have
> something to do and
> you'ld brake it).
>
> The problem is that there is no second method called after all
> init is done and
> before getting the response stream.
>
> A similar problem - you might want your bean to have access to
> ServletContext,
> so you can use Log for example. We solved this problem by
> changing GNUJsp (
> the other one can be solved in the same way, we avoided it )
>
> I hope 1.0 will solve both problems.
>
> > On a similar note, why not have JSP beans look more like servlets and
> > include service, doGet, doPost, etc? Why make developers learn
> how to create
> > beans and servlets? Just make a servlet a bean.
>
> That may be a bad ideea.
> I use generic beans ( the same I use in a Swing application), and
> when I realy need
> processRequest I extend them with this method ( processRequest
> can be avoided
> in most cases ).
>
> The servlet is not a very good abstraction to design with ( i.e.
> it is less powerfull than
> a Bean - no introspection, etc). And also, it is hard to reuse it
> - that's why it's better
> to use it just as an adapter between your code and the web
> server, and to not put too
> much code in the adapter.
>
> Costin
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
