You most elegantly explicated what I so badly explained about the
constructors for applets and servlets. Absolutely, every Java
class MUST have a constructor, but as I explained in a later
post, these non-parametered constructors are automatically
(magically) invoked by the containment context (JVM). You
articulated the solution much better than I.
(I hang my head in shame....)
I would suggest anybody having an interest in this subject to
save this email - Nic explained this phenomenally.
Cheers!
Mark
----- Original Message -----
From: "Nic Ferrier" <[EMAIL PROTECTED]>
Sent: Friday, April 20, 2001 8:09 PM
> >>> Saumont Pierre-Yves <[EMAIL PROTECTED]> 21-Apr-01 12:14:44 AM
>>>
> >Hey Mark, why do you need to use init() when you can do :
>
> public class CounterCons
> extends HttpServlet
> {
> int count = 1122;
>
> public void doGet(HttpServletRequest req...
> throws ...
> {
> PrintWriter out=res.getWriter();
> count++;
> out.println(count);
> }
> }
>
> >That's not exactly the same, but it's probably close
> >enough to what he want's !
>
> Mark was wrong in stating:
>
> servlets, like applets, do not take constructors.
>
> Both applets and servlets *must* have constructors because
*all*
> objects in Java have constructors (except the primordial cl).
>
> It's just that Servlets and Applets have constructors with no
> arguments and it's not possible to provide a constructor that
does
> have arguments.
>
>
> The original questionner asked why he couldn't have a cons like
> this:
>
> > CounterCons(int i)
> > {
> > count=i;
> > }
>
> He would have done well to ask himself:
>
> If I have a cons like this, how is the servlet to know what
> value should be passed to "i" when the servlet is
constructed?
> How is the servlet constructed? Do I have control over that
> process?
>
>
> If he'd thought about this he would have worked out that there
is no
> mechanism for him to specify an "i" to his servlet because his
code
> does not create it.
>
> So how does a servlet get created? It's by the magic of the
Java
> machine. The magic is fairly fundamental to Java so it's worth
> knowing.
>
> The servlet engine always knows the class name of the servlet
it's
> going to load. When the servlet needs to be loaded the servlet
engine
> will do something like this:
>
> Servlet
s=(Servlet)Class.forName(servletName).newInstance();
>
> This creates a Class object by the name of the class. That is
magic
> provided by the ClassLoader. You could for example do this:
>
> Class stringbufclaz=Class.forName("java.lang.StringBuffer");
>
> to get a Class object which represents the class of all
> StringBuffers. Once you have the Class object calling:
>
> Class.newInstance()
>
> returns an object of that class by calling the no-arg
constructor of
> the class. If the class doesn't have a no-arg constructor then
> newInstance() fails and the class can't be loaded.
>
> It could still be loaded because we could use the reflection
methods
> of the Class class to find a constructor that we could
invoke...
>
> But in a servlet engine that would take time and would be
> semantically confusing (how is the servlet engine to know what
the
> arguments are actually for?)
>
> Therefore the API is designed to insisit on a no-arg
constructor.
>
>
> That doesn't stop you using the no-arg constructor, for
example:
>
> class MyServ
> extends HttpServlet
> {
>
> int counter=-1;
>
> public MyServ
> {
> counter=0;
> }
>
> public void doGet(...
> throws ...
> {
> counter++;
> }
> }
>
> which is exactly equivalent to what Saumont suggested.
>
>
> The original questionner goes on to do this:
>
> > public void doGet(....
> > throws ...
> > {
> > new CounterCons(1122);
> > PrintWriter out=res.getWriter();
> > count++;
> > out.println(count);
> > }
>
> Which shows that he's really lost it in relation to this
problem.
>
> Why is this so dense? Because he's creating a new instance of
his
> servlet inside an instance of his servlet. He's simply
discarding the
> instance because he doesn't assign it so counter he's tried to
assign
> won't get used anyway.
>
> Of course, his code won't compile anyway, because he hasn't
supplied
> a no-arg constructor. If he gets it to compile (by calling
super() in
> his cons) then it won't load in the servlet engine because
there is no
> no-arg constructor.
>
> I suspect he's a bit confused about the difference between
instance
> methods and static methods and that's getting really off-topic
so I
> won't go there.
>
>
> In summation I would like to point out that Mark was absolutely
spot
> on when he said that the best way to deal with this is to use
the
> init(ServletConfig) method. So this post has been a bit of a
waste of
> time really /8->
>
>
> Nic Ferrier
>
>
_________________________________________________________________
__________
> 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
