We don't need to override service method when we build a servlet: I imagine that an implementation not abstract of this method is already available in the class HttpServlet as we could check in API documentation. Why HttpServlet is abstract if it not contain abstracts methods? What about all I wrote?
Thanks.
> We don't need to override service method when we
> build a servlet: I imagine that an implementation not
> abstract of this method is already available in the
> class HttpServlet as we could check in API
> documentation.
> Why HttpServlet is abstract if it not
> contain abstracts methods?
If it had abstract methods it of course needs to be abstract. But why should not having abstract methods mean it isn't allowed to be abstract in return?
Servlets have to override doGet or doPost or whetever to do something useful. So no point in having a non-abstract HttpServlet. Design decision - it's abstract to "enforce" overriding of the do... methods, and they're not abstract so you don't have to implement them all if you don't need them.
If I have understood you say that I can define abstract a class even if it hasn't abstract methods. Ok?
An other question: can I imagine that methods in class ServletInputstream are native as, for example, they strongly depend on operating system? I would have checked but is not so easy to find source code for a real server implementation of JEE.
Thanks.
> If I have understood you say that I can define
> abstract a class even if it hasn't abstract methods.
> Ok?
Yes. Think OO: does it make sense to have a classes "Intern", "Contractor", "Employee", "Client", "Manager"? Yepp.
Does it make sense to make them extend "Person"? Yepp, why not? With address and such.
Does it make sense to have an object that's "just" a person? Not really - whatever this person does, he always has some kind of special semantics and abilities, which means that it might make sense to leave Person abstract - and there aren't even a methods defined yet that would enforce this decision anyway.
> An other question: can I imagine that methods in
> class ServletInputstream are native as, for example,
> they strongly depend on operating system?
You wouldn't know if they're not public - at least the API doesn't mention any. I doubt it has native methods itself, but it will probably rely on native methods it inherits from InputStream.
> I would
> have checked but is not so easy to find source code
> for a real server implementation of JEE.
> Thanks.
Tomcat, JBoss..
I just want to understand the logic behind the system...the real implementation is may be not so important but if possible I will take a look.
Anyway thanks for your good answers...I am the same who asked for the second volume of JEE. In that case your answer was very nice...
The last question for today.
Does it make sense to handle IOExceptions throws in the body of DoGet method? In the JEE first book this method always throws IOException: who handles these exception in the system? I was interested about source code because I wanted to check exactly which type of exception was thrown by the different IO methods but now I am not so sure that it is really important.
Thanks.
try VB-java code translator by looking at google.That would be
a better option than placing this here ;-)
> Does it make sense to handle IOExceptions throws in
> the body of DoGet method?
Depends on whether the servlet is actually capable of handling it at that point, like redirecting to another page (not the error page) or getting an alternate source for your input or whatever. If you can, do it, if you can't, leave it.
> In the JEE first book this
> method always throws IOException: who handles these
> exception in the system?
The servlet container.
But is it important to see the source code of the different methods in the servlet container? Anyway, I took a look but I hadn't find the source code in apache in the site...when you have time would you like to send me the exact link if it exists? I absolutly want almost an example of source code in order to better understand what I am doing!
Thanks more.
> But is it important to see the source code of the
> different methods in the servlet container?
What for? There's a specification and API that define what it's supposed to do, I couldn't care less *how* it actually does it.
> Anyway, I
> took a look but I hadn't find the source code in
> apache in the site...when you have time would you
> like to send me the exact link if it exists?
http://tomcat.apache.org/download-60.cgi
> I absolutly want almost an example of source code in
> order to better understand what I am doing!
I'm not convinced that this helps.
You have reason but try to answer to this question...If I wanted to handle the exceptions thrown by doGet method without catching all exceptions of the type IOException I have may be to look for source code in order to handle only thosethat are really thrown...Ok I know that if some methods are native methods then I thing it is a mission impossible (Do you know how throw java exception from native code or may be it not make sense?)...Ok I know that writing catch(IOException e) I handle all exception of this type...I would like to write a very minimal code for only the situations that really could happen.
Thanks for your patience.
> If I wanted to handle the exceptions
> thrown by doGet method without catching all
> exceptions of the type IOException I have may be to
> look for source code in order to handle only those
> that are really thrown.
Well, that isn't exactly a question. But since you are the one writing the doGet() method, it should not be too difficult for you to find the source code. And it's up to you to decide whether to handle an IOException that your code throws or whether to rethrow it and let the servlet framework deal with it.
I was speaking about the exceptions thrown by IO methods of the classes ServletinputStream and ServletOutputStream which let me to read and write the socket: I have not written the code for those methods because they are availabled from the JEE platform. I would like to see that code in order to catch only the exceptions really thrown but may be those methods are written in native code: in that case I don't know if it is possible. This was the meaning of my message DrClap.
