On Thu, 27 Jun 2002, Heligon Sandra wrote:
> Date: Thu, 27 Jun 2002 18:33:48 +0200
> From: Heligon Sandra <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: ServletContextListener vs ActionServlet/RequestProcessor
> subc lassing
>
> I need to trace when the "application" and new client-browsers start-up or
> stop.
> I think so that the ServletContextListener and SessionListener are really
> the best solution.
> Do you know if a lot of servlet engines don't support servlet2.3?
> I look for summary on the web but I don't find.
> We have chose to work with Tomcat and Tomcat 4.0.4 supports
> servlet 2.3 specifications but we don't know how the future will be?
>
FYI, any J2EE 1.3 application server, by definition, supports Servlet 2.3
and JSP 1.2. A list of J2EE licensees is available at:
http://java.sun.com/j2ee/licensees.html
You'd have to check with each vendor on their plans, but I imagine that
all of these companies either already have, or will have, J2EE 1.3
products.
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 27 June 2002 18:19
> To: Struts Users Mailing List
> Subject: RE: ServletContextListener vs ActionServlet/RequestProcessor
> subc lassing
>
>
>
>
> On Thu, 27 Jun 2002, Heligon Sandra wrote:
>
> > Date: Thu, 27 Jun 2002 18:10:43 +0200
> > From: Heligon Sandra <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> > Subject: RE: ServletContextListener vs ActionServlet/RequestProcessor
> > subc lassing
> >
> > Thanks for your help, if I understand your explanation,
> > the ServletContextListener is the best solution.
> > But this case needs to have a servlet 2.3 engine, like Tomcat 4.0.4
> > for instance. I read the Struts 1.1 "used" JSP1.1 and Servlet2.2
> > but it works with container2.3. Are they downsides to mixing
> > servlet specifications? It is dangerous if we have to change servlet
> > engine and that the new engine doesn't support servlet2.3, isn't ?
> >
>
> Struts will work fine with either Servlet 2.2 / JSP 1.1 containers, or
> with Servlet 2.3 / JSP 1.2 containers, so you can choose whichever kind
> meets your other needs.
>
> Obviously, if you use a Servlet 2.3 feature, you will make it impossible
> to use a container that only supports Servlet 2.2, so you have to make a
> tradeoff decision. However, things like ServletContextListener (added in
> Servlet 2.3) will work on any other Servlet 2.3 container as well.
>
> If you cannot (or do not want to) use a Servlet 2.3 container, then you
> cannot use ServletContextListener and need to use the previous approach.
>
> Craig
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: 27 June 2002 17:43
> > To: Struts Users Mailing List
> > Subject: Re: ServletContextListener vs ActionServlet/RequestProcessor
> > sub clas sing
> >
> >
> >
> >
> > On Thu, 27 Jun 2002, Heligon Sandra wrote:
> >
> > > Date: Thu, 27 Jun 2002 11:09:47 +0200
> > > From: Heligon Sandra <[EMAIL PROTECTED]>
> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > > Subject: ServletContextListener vs ActionServlet/RequestProcessor sub
> > > clas sing
> > >
> > >
> > > I would like to add comments on my previous message about
> > > ServletContextListener and
> > > ActionServlet sub classing. I read that with Struts1.1 it is bad to
> > > create ActionServlet subclass ,
> > > because a new class RequestProcessor has been added.
> > > So my new question is, single initialisations (as database
> > > connection or ORB initialisation)
> > > must be done in ServletContextListener class
> > > or RequestProcessor sub classing (in this case which method use ?, I
> > > don't look any init() method).
> > >
> >
> > See previous response.
> >
> > Note that the Struts PlugIn API in 1.1 is designed to replace the need to
> > subclass ActionServlet if the *only* thing you need to do is add some
> > extra initialization stuff. It has the same advantages (runs under
> > Servlet 2.2 environments) and disadvantages (lifecycle is not guaranteed)
> > as overriding init() and destroy() on ActionServlet itself.
> >
> > > I don't understand why the RequestProcessor has been created ? Do
> > > this class implement new
> > > features/methods in comparison with ActionServlet ?
> > > Or do these two classes not work in the same context ? For example a
> > > RequestProcessor is
> > > associated to a single application whereas an ActionServlet instance
> > > can be shared between several
> > > applications ?
> > > In this case we can yet need to subclass the ActionServlet class.
> > > Has somebody an example ? I work on a little web application and I
> > > don't understand well the
> > > notion of sub-application or multiple applications and the
> > > difference with multiple Action
> > > instances.
> > >
> >
> > It was created so that advanced users could have different request
> > processing lifecycles for different sub-applications if they need them.
> > For the vast majority of Struts developers, you can just forget that this
> > thing even exists.
> >
> > Sub-applications are not well documented yet (that is being worked on),
> > but the basic idea is that you can have multiple independent
> > struts-config.xml files in the same webapp, sharing the same controller
> > servlet underneath. Sub-applications are distinguished by a prefix, so
> > you might have context-relative requests like "/catalog/showCategory.do"
> > and "/checkout/acceptCreditCard.do" served by different subapps.
> >
> > This will be explained better (with examples) in the final docs.
> >
> > > Thanks in advance.
> > > Sandra
> > >
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
