Pete Nelson

Passed the Oracle Certified Professional, Java SE 6 Programmer exam on April 19th, 2012. I avoided posting for the past few months because I was disappointed in my low score (68%), but now as I'm looking over other scores, I think it's important to share. That friggin' test is tricky!!! My advice to others, "a pass is a pass!".

Now on to my OCE/WCD (The HeadFirst book arrived from Amazon just yesterday).

At work, we are looking at moving from Tomcat 6.0 to Glassfish 3. We are also trying to think more in terms of "Enterprise Architecture", and are looking for ways to implement an Enterprise Service Bus.

When I google for "glassfish esb", I am finding five-year-old documents that no longer point to a valid install file. Can anyone tell me, does Glassfish support ESB, or has that been removed?

When I look at Apache ServiceMix and the features it provides, it looks like it's covered in Glassfish ... but just don't know enough about ESB to know for sure.

Well, I feel sheepish!

Turned out my problem is that my 32-bit JVM wouldn't use my 64-bit native tomcat library. Go figure! Moving to 64-bit java solved my issue.

A HashSet is a specific implementation of java.util.Set that is backed by a HashMap. Note that it doesn't implement java.util.Map (it "has a" Map, not "is a" Map). Strait from the javadoc, a Set "makes no guarantees as to the iteration order of the set", which is why trying to retrieve an object at a particular index will not work.

Is a Set truly what you are looking for here? Sets do not allow duplicates, so you would only get the sum of UNIQUE integers if you are using a Set.

In the HTTP Cookie environment, you can set the the Domain so that the cookie is passed to any host within that domain. However, I do not know that you can do the same for the HttpSession object.

If you need to pass data between servers, you may need to look at other forms of persistence rather than HttpSession. If it is a small amount of non-sensitive data, you might consider rolling your own Cookie object to hold the data. If it's a lot of data, or it's data that must remain secure, I would look towards another form of persistence, such as a database.

Try breaking up the code to see exactly what's happening:
// String sShowLanguage = session.getAttribute("showlanguage").toString(); Object obj = session.getAttribute("showlanguage"); String sShowLanguage = obj.toString(); // here's your potential NullPointerException
Simply add a test for null before attempting to call "toString()", or any other method on that object.

As far as what to do for null, that's up to you. Sometimes a default value or empty string is appropriate, sometimes you need to raise an exception (maybe send the user back to the form?)

Program to an interface, not an implementation

Says it all.

One suggestion, when you have this many parameters you should consider encapsulating them in a class, rather than having 43 distinct String objects.
public class MyRequestData { // ... put your String objects here (although consider more descriptive names) ... // protected String one, two, ... ; public void populate(Map params) { this.one = (String)params.get("one"); this.two = (String)params.get("two"); // ... parse the remaining params, doing any error checking you may need ... // }

And then in your servlet's processRequest method:
// create an instance of MyRequestData MyRequestData myData = new MyRequestData(): // populate the data from the request's parameter map myData.populate(request.getParameterMap()); // ... note I do the query a bit different, using a PreparedStatement ... // String pquery ="INSERT INTO SOCFORMAT (SOCNO,SOCDATE,S1,S2,S3,S4,S5,S6,S7,S8,CAT,S9,S10,S11,S12,S13,S14,S15,S16,S17,S18) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)"; PreparedStatement pstmt = con.prepareStatement(pquery); // retrieve the data from the MyRequestData instance pstmt.setString(1, myData.one); pstmt.setString(2, myData.two); // ... set the remaining parameters here ... //

The biggest advantage is that you separate servlet logic from your data, which allows you to test the MyRequestData object independently of the servlet. It also gives you another chance to use more descriptive names for your data (so you might not be as likely to run into a problem with the "proper sequence".

If "cookies" is enabled in the browser, and yet it is NOT sending back a known cookie with the request, then you have a bug in the browser. The HTTP Cookie Wikipedia article speaks to how the browsers are supposed to implement cookies, with links to the actual specs that define the behavior.

If a browser doesn't implement this, it doesn't fully speak HTTP 1.1.

I think you are getting confused by the objects being returned from session.getAttribute(String). Every item returned by the getAttribute method is an instance of java.lang.Object. When you cast it, you need to cast it back to the same type it was before you added it to the session (with session.setAttribute(String, Object)).

In your case, you are adding an int primitive type, which gets automatically "upgraded" to an Integer (because we need a java.lang.Object, not a primitive type).
String cc_no = request.getParameter("ccno"); int ccno =Integer.parseInt(cc_no); HttpSession session=request.getSession(true); session.setAttribute("ccno",ccno);
At this point, you've added an Integer object to your session. Why bother casting or converting to a String, just to get it's primitive int value? Can't you cast to the Integer object, and then get the int value from that Integer Object?

Also, I notice that when people suggest you "cast" your Object to something else, you are instead calling a method like the Object's .toString(). I just have to ask - are you familiar with casting in Java?
MyBean bean = new MyBean(); session.setAttribute("bean", bean); ... // session returns an Object that is also a MyBean, so we can cast the reference (bean) to a MyBean bean = (MyBean)session.getAttribute("bean");

avneesh atri wrote:it is a good advice , but how to do this programaticaly in a single class.

That's a very strange goal for an object-oriented programming language - in most cases, you want to write multiple classes with each class being responsible for only what it absolutely needs to.

That being said, if you're looking to write a java program that needs to make HTTP requests, I would recommend looking at the Apache HTTP Client as a starting point.

Jk Robbins wrote:Most of the code I see uses the request method, so I'm guessing this is probably the older/original way of doing things and the context method was added later for some reason?

I suspect the biggest reason you see the ServletRequest version used is that you already have a reference to the ServletRequest object in your do* method, so it's just easier to do request.getRequestDispatcher(...) vs getServletContext().getRequestDispatcher(...).

I've personally never called the ServletContext method, nor have I ever used a relative path.

JSP is for outputting HTML or XML. Excel is neither. What you are creating is an HTML table, and then hoping that Excel will be smart enough to automatically import it.

If you want to generate Excel formatted files (like your content type suggests), look at Apache POI. I would also highly recommend implementing it as a Servlet rather than a JSP template, since JSP is not intended or designed for this type of content.

Rob Spoor wrote:HttpServletRequest has several methods to get the original URL the client requested. This includes getRequestURI(), getPathInfo() and getQueryString().

The first reply gave you your answer. Why dig through attribute values, when you can simply call request.getRequestURI() ?

While one application context cannot communicate internally with another, there are any number of ways two contexts could share information. A previous poster suggested a database for a persistence layer, which is a pretty common approach. Other options include reading / writing a local file both contexts would have access to, or even using HTTP to exchange data between the two contexts.