Steve Dietrich wrote:
>
> does anyone know when apache/jserv will be fully Servlet 2.1 API compliant? Is
> it OK to run servlets based on 2.1 currently without many problems?
>
> Steve Dietrich
>
The standard answer to the "when" question is "Apache JServ is an all-volunteer
project, so the speed with which changes are completed is dependent upon the number of
volunteer developers that are actively involved. Volunteers are welcome; see the
http://java.apache.org web site for more information."
In practice, the new code is a complete reorganization of the existing architecture,
making it component-based for easier future changes. The basic execution of servlets
seems to work OK, and we're just starting to test out the rest of the functionality
(sessions, request dispatchers, and so on). The communications protocol handler to
connect to Apache has yet to be written -- changes are planned
to improve performance. (For testing, we're currently using a simple HTTP adapter
that accepts requests directly.) No significant performance tuning has even been
started yet. Because there is so much new code, a much higher level of alpha and beta
testing will be required before I'd feel comfortable calling this stuff releasable
(the code is pretty good IMHO, but there's nothing like the real
world to wring out problems! :-) -- to say nothing of the fact that a bunch of new
documentation needs to be written, yadda yadda.
Apache JServ 1.0b3 (the current version) is compliant with the 2.0 servlet API, so it
will run servlets that do not depend on any of the new changes -- for instance, the
getServlet() call in the current version really does return you an initialized
instance of the servlet you asked for, in compliance with the 2.0 API spec. But
there's none of the new 2.1 things (RequestDispatcher, storing attributes
in requests or the servlet context, and so on).
Craig McClanahan
>
> > Hi all,
> >
> > I have written a service servlet that other servlets can invoke to perform
> > special functionality. I chose to write it as a GenericServlet and not just
> as
> > a regular class so that I can use the log() feature to examine my jserv.log
> file
> > in Apache (we all know how painful it is to debug run-time problems with
> > servlets).... anyway, I use (from Hunter)
> >
> > MyServlet servlet = (MyServlet)getServletContext().getServlet("MyServlet");
> >
> > in the calling servlet to grab a handle to the service servlet, it compiles
> > fine, but I get a run-time error ClassNotFoundException in Jserv.log.
> > So, obviously I need to force the webserver to instantiate the service object
> > prior to using getServlet.... HOW do I do this?
> >
>
> The issue is not instantiating the servlet before the call .. the getServlet()
> method does that for you. A ClassNotFoundException indicates that the servlet
> engine could not find your class file, which indicates a configuration error.
> Make
> sure that the "MyServlet" class is available in the repositories you have
> configured for your zone (in Apache JServ).
>
> >
> > I am still a novice with servlets... If there is a more appropriate way
> entirely
> > different that this, please let me know!
> >
> > PS I am working under the assumption that once I get the handle to the
> service
> > object that I can invoke it's methods and pass and return objects between the
> > two.
> >
>
> This approach will work, but not for long. In the 2.1 servlet API, the
> getServlet() call is deprecated and required to return NULL, which eliminates
> its
> usefulness for providing access to shared services. This was done for many,
> many,
> very good reasons -- despite the fact that it will break a *lot* of current
> servlets when you upgrade to a 2.1-compliant servlet engine.
>
> The assumption in your PS is correct, and that's the basis of the problem. For
> example, nothing stops you from calling the destroy() method of the servlet you
> got
> a reference to, after which your servlet thinks it has been shut down but the
> servlet engine does not know that. Also, nothing stops you from calling the
> service() method of a SingleThreadModel servlet from several threads yourself,
> even
> though the servlet engine promises not to do that. This kind of thing is a
> recipie
> for disaster.
>
> In a 2.1 world, the ability to store arbitrary objects in your servlet context
> (getServletContext.setAttribute()) is the best way to share service objects.
> Alternatively, you can use the Singleton pattern and provide classes with static
> factory methods that can be utilized even if you don't have a reference to a
> particular instance.
>
> >
> > Steve Dietrich
> > PG&E Energy Trading
> >
>
> Craig McClanahan
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
