Eduardo Dela Rosa

Greenhorn
+ Follow
since Apr 15, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Eduardo Dela Rosa

Since you're using Hibernate, you may want to inspect your models to see if
they're set to use proxy or make them lazy (appropriately, if not all of them).

This would prevent hitting the database outright and loading the object graphs
that you don't not actually needed and could be exhausting your JVM's memory.

HTH.
17 years ago

Originally posted by ranga shreya:
doPost and doGet methods differences



Well, basically doPost is invoked by the Servlet's service method if it
finds that the method used in the form to submit the request is "POST".
The doGet is invoked if the request is submitted using the "GET" method.

Although both method in your servlet (doPost and doGet) can invoke common
private method to process your request and response object, one basic
difference is how the parameters are transmitted to the server (discrete or
not, etc).

Instance where doPost would be invoked in the service method:



Likewise, when you use POST, form parameters are contained in the "body"
of the HTTP message request, and not in the HTTP message header. This
makes the values you submit a bit more secure that using GET method because
they are not shown as part of the URL.

Cheers!
17 years ago
Hi,

In the first place, you should not blame the book. Head First Servlets & JSP is one of the best books out there. If you'd read the "how to use this book" section (page xx), the topics "who is this book for?" and "Who should probably back away from this book?" should tell yourself where you stand.

On the other hand, if you're really up to something more interesting guide to developing shopping carts, try checking the following links:

xPetStore @ http://xpetstore.sourceforge.net
Duke's Bookstore @ http://java.sun.com/javaee/5/docs/tutorial/doc

Regards,

Eduardo
[ May 06, 2006: Message edited by: Eduardo Dela Rosa ]
17 years ago
Hi,

WEB-INF/classes folder would be the appropriate place to put it. After all,
that would serve as the root directory for your classpath.

HTH.
17 years ago
Hi,

Will this work for you?



Take note of the BACK SLASH before the word "The Link".

HTH.
[ May 01, 2006: Message edited by: Eduardo Dela Rosa ]
17 years ago
JSP
Hi,

This example should show you the difference between using and not using JSTL:



[ May 01, 2006: Message edited by: Eduardo Dela Rosa ]
[ May 01, 2006: Message edited by: Eduardo Dela Rosa ]
17 years ago
JSP
Hi,

I don't actually see problem with your taglib directives, nor taglibs in web
descriptor file, but if you're getting the same problem, i.e., invalid Customer object, try looking back at your 17th post.

Is it right that you moved your Customer class to "storePackage"?... then why did you declare a "com.storePackage.Customer" class in your <jsp:useBean>
action tag when it should only be "storePackage.Customer" (whithout the com)?

But please ignore this if you already have restructured your codes then. It's
just a thought of the past.
17 years ago
JSP
Hi,

To easily isolate the problem, you may want to create a package
for the Customer class (i.e., do not use default package) and
you may want to include it in the list of imports in your JSP
page directive.

hth.
17 years ago
JSP
Hi,

Although both PrintWriter and JspWriter extends java.io.Writer, they're designed to be used for specific purpose.

If your working on Servlets, use PrintWriter (from response.getWriter()).

If your working on JSP's, then use JspWriter (implicit object called *out* from pageContext.getOut() which returns javax.servlet.jsp.JspWriter).

JspWriter (out) is much preferrable to use because it uses buffering techniques designed for JSP.

Therefore, it *could be*, but not provenly, that your display has been affected by buffering. It's just a guess.

HTH.
17 years ago
JSP
Hi,

How did you define your page directive and attributes?

Should be:

<%@page pageEncoding="{CharSet}" %>

If that is giving you a problem, try to remove the *pageEnconding*
attribute first(and its corresponding value, if any), then run the
web app again. It might be that the value you've set is not in the
valid list of CharSets.

Better yet post your page directive to have a much clearer view of
what's causing your problem.

HTH.
17 years ago
JSP
Apparently, you've got problem with your classpath.

Can you echo and display the value of your %classpath% variable?
17 years ago
I would suggest reinstalling your Tomcat, as you might have messed it up because of your Beer?

Otherwise, check that the <tomcat-dir>\webapps\ROOT\WEB-INF\web.xml is
intact and its content is still in order.

Take note of the following "NOTE" when you first install and run TOMCAT for the first time:


NOTE: This page is precompiled. If you change it, this page will not change since it was compiled into a servlet at build time. (See $CATALINA_HOME/webapps/ROOT/WEB-INF/web.xml as to how it was mapped.)



So whatever you do, don't blow it up, else the only option you've got is
really - a reinstall.

HTH.
17 years ago

3) Compiled BeerSelect.java and placed BeerSelect.class to:
<tomcat-path>\webapps\ROOT\Beer-v1\WEB-INF\classes\com\example\web\BeerSelect.class



Don't put your Beer-v1 app inside ROOT folder.

You should have structured it as follows:

<tomcat-path>\webapps\Beer-v1
[ April 09, 2006: Message edited by: Eduardo Dela Rosa ]
17 years ago
Hi,

Sometimes it's hard to guess the cause of problem. Can you possibly include
the stack trace of the exception you've got? That way, we'll easily pin point
where the problem is coming from, hence possible solution can be provided.

But initially, you might not be getting any results at all in your ResultSet
object. Besides, you can simply use Statement, rather than PreparedStatement
because you're not using or setting any parameters to your query anyway.

Cheers!
Hi,

It's not a good practice to store *value in non-final variable* in Servlet,
be it member or class variable.

If you're thinking of a *final* or *constant* value, that should be no
problem. BUT that's not your case.

Since you mention about session, better yet store your values as attributes
in the HttpSession object to maintain integrity, i.e., the value it holds
is local to the session that created it.

If you should really need a value to be shared by all Servlets, you still
have the option of using ServletConfig (per servlet) OR ServletContext (per
web app). They are read only once during web app initialisation, though.


Regards,
17 years ago