Timothy Stone

We shut it down at my employer. Hard stop. Not allowed and we have full lifecycle development in the IDE too. It really is simple; of course we couple a number technologies and processes to do it, Maven being the biggest piece to deliver full lifecycle DEV in the IDE.

We started with the following directive in the web.xml

<jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <scripting-invalid>true</scripting-invalid> </jsp-property-group> </jsp-config>

Anyone trying to remove it is labeled (yes, we are quite the bully team and feeling often get hurt). In enforces better design in the Controller and Model layer as well.

Darren, I think you had an epiphany. NetBeans really does just "do it better." Most of the Tomcat plugins for Eclipse tack support on to existing plugins. From Maven to Tomcat integration NetBeans is still your best choice.

I can't speak for JDeveloper, but isn't it just Eclipse in an Oracle wrapper?

Marco, have you seen this article by Brandon Carlson, http://www.bcarlso.net/2007/10/19/tomcat-weak-etags-and-javascript-css-caching.html

Definitely worth a look!

Tomcat 7 is also at the core of Mulesoft's TCAT Server product. TCAT Server is a suite of administration controls, mostly all available in DIY configurations but neatly packaged by Mulesoft (along with significant value add), for clustering and deploying Tomcat 7 in enterprise, production environments.

While Tomcat is widely known as the "reference implementation" of the JSP and Servlet specifications, it has long been used in production, mission critical, environments. IMHO you can scale as noted by Tanuj both ways and very reliably. However, how much you want to build versus buy in this regard may lead you to products like TCAT Server.

Regarding HFS&JSP 2nd Ed. page 426, question 12.

I have looked at some of the answers from c. 2007, but nothing directly asking the question, Why is Answer C more correct than Answer A.

Sure the comments on the answer provide some context to the author's thinking, but I have used "SSI" in Apache and Tomcat, and the include standard action and the directive provide SSI-like functionality as I have used SSI in the past. Is it the "dynamic content" phrasing that makes C more correct than A?

The question is provided below for context.

Thanks!
Tim

How would you include dynamic content in a JSP, similar to a server-side include (SSI)? (Choose all that apply.)
A. <%@ include file=”/segments/footer.jspf” %>
B. <jsp:forward page=”/segments/footer.jspf” />
C. <jsp:include page=”/segments/footer.jspf” />
D. RequestDispatcher dispatcher = request.getRequestDispatcher(“/segments/footer.jspf”); dispatcher.include(request,response);

You win for "rules lawyering."

IOOBE, not a real word, is easier than writing IndexOutOfBoundsException. Though, I could have cited first, then used the "acronym."

I know that an ArrayList is zero-indexed. I did pass the SCJP exam...allow me to bask in my self congratulatory sun...now...

What I was trying to say, though I was unclear, is better demo'd in code...

// Some object array that has 1 or more items of a type with a name property // An object name might be "PRIMARY_CHOICE_1", "PRIMARY_CHOICE_2", n-names // The order of the object array is not guaranteed by the provider. // Any given request might return 2, 1, 3, n, or 1, 3, 2, n or even natural, 1, 2, 3, n // We want to provide a list of only "PRIMARY_CHOICE"s so we extract to a new ArrayList public List<Product> getPrimaryProducts() { ArrayList<Product> prdts = new ArrayList<Product>(); if (catalog!=null && catalog.getProductArray()!=null) { for (Product prdct:catalog.getProductArray()) { if (prdct.getPrdctRole()==ProductRole.PRIMARY_PRODUCT) { prdts.add(0, prdct); } else if (prdct.getPrdctRole()==ProductRole.PRIMARY_CHOICE_1) { prdts.add(0, prdct); } else if (prdct.getPrdctRole()==ProductRole.PRIMARY_CHOICE_2) { prdts.add(1, prdct); } else if (prdct.getPrdctRole()==ProductRole.PRIMARY_CHOICE_3) { prdts.add(2, prdct); } } prdts.trimToSize(); } return prdts; }

What I have found is that if the order of the products provided in the original list is not naturally ordered, and arrives at line 16 above, the ArrayList throws an IOOBE on the add method.

What is not clear in the ArrayList documentation is that the first item added to an ArrayList must be at index 0.

Or is that documented somewhere; everywhere I looked it seemed assumed (and is a safe assumption I suppose), but the developer writing the above code, of which I'm reviewing, seems to insist this is possible. I couldn't refute, so I came here.

Regards,
Tim

... so this is an odd question, but the documentation is a bit muddy on the actual execution of adding to an ArrayList (I should know this...)

... ArrayList<Product> products = new ArrayList<Products>(3); products.ensureCapacity(3); ... // loop through an array of products, comparing properties then maybe... products.add(1,product); ...

So, now I have a nice IOOBE. The reason, apparently, is that in the loop a comparison is performed that assumes incoming objects are "ordered," e.g., 1, 2, 3..., but may come as: 2, 1, 3...

Hence, Object 2 belongs in the second index of the ArrayList (index 1).

The IOOBE seems to stem from this as the ArrayList size is initially zero (0) and there is no position 1. Initial capacity and ensuring of the capacity does not help.

Are these observations correct?

I see the logic... but cite this example from actual production code in a JSP:

<a href="<%=MyStaticMethod.getURL("formaction.jsp", request, ACONSTANT.type)%>">My Accounts</a>

Note the nested double quotes the JSP. Some template code uses the response/return of the static method. This hasn't "boof'd" on parsing. Is it a scriptlet v. EL/JSTL question then?

Thanks!
Tim

There appears to be a subtlety to the `test' attribute that could use some clarification.

What is known:

single quotes or double quotes may be used in most tags and the EL.

However, the following fails with `equal symbol expected':

<c:if test="${userType eq "member"}">

The following will compile and behave as expected:

<c:if test="${userType eq 'member'}">

Where is this noted in the spec? Or is it noted in the JSTL spec?

Sidebar... HF:S&JSP could be less ambiguous about this subtlety on pg 441 me thinks. The scribble implies that both forms should work, by its presence, not by example.

Can anyone elaborate?

Thanks!
Tim

SCWCD has a pre-req of SCJP. I'm SCJP 2 (v1.4, 10/2001).

If I want to take the SCWCD this year, or 1Q 2008, do I need to "re-certify" as SCJP?

Thanks!

Consider the Yahoo! User Interface (YUI).

Okay, I admit it, this is the second post I have made with this recommendation, and I'm a bit of an evangelist.

The YUI might not be as popular as Prototype + Scriptaculous or Dojo, but it is far more intutitive. The latter two frameworks seem to "hate" JavaScript and HTML (rewriting it in their respective ways), whereas the YUI is JavaScript and CSS, just plain and simple. No reinventing. Additionally, it is far better documented than Dojo, and short of a guarantee or promise, provides some reassurance that it will work across multiple platforms.

DWR is interesting and complements YUI nicely with JSON boxing of server side objects. And the YUI, like the others is further complemented by ext.js.

You can look up all of these in your favorite search engine.

Arundhati,

Two tips to be taken very seriously:

Develop in Firefox first, FIX for IE

Consider the Yahoo! User Interface (YUI)

The first tip is something that drives me crazy about most Java engineers, they develop in IE as if they are building a .NET app! HTML, CSS, and JavaScript are not technologies owned or invented by Micros~1. In fact, most of the time, Micros~1 gets it wrong. When you develop in Firefox (or Opera and Safari) you are at least getting Core support of DOM 0 and 1, CSS 1, 2, and 2.1, and better HTML validation. With IE, you get mostly broken implementations of these features. Additionally, most resources will address fixing IE, not fixing Firefox. Think about that, you'll get more resources for fixing IE!

The second tip will provide you some sanity. The YUI is an open-source JavaScript and CSS library that follows a "Graded Browser Support" model that Yahoo! tests in all current browsers and, short of a guarantee or promise, makes every effort to be sure that layouts and code using the YUI library wil behave identically across most popular platforms.

HTH, a little.
Tim
[ October 09, 2007: Message edited by: Timothy Stone ]

There is no question that this topic excites me as a SCJP web developer. Especially in this forum, a venerated one such as the "JR BMS".

If you want to know what DIVs vs TABLEs really means, a concrete example is always the best way to learn: using Firefox, turn off styles (View > Page Style > No Style), and surf the web. If the page remains ridgedly in form, it's TABLEs at work. If the page collapses to a still readable and functional form of pure, semantic HTML, conveying information like a good outline or book, that's CSS at work, likely on DIVs.

Try it at csszengarden.com for a real treat. To sweeten it further, and see just how different a real browser like Firefox works vs. IE, try viewing this CZG design in IE v. FF.

http://www.csszengarden.com/?cssfile=062/062.css

Thank you. I read this in [Manning, JSFIA] and it just didn't pop when I went back looking for an answer to my "expectations."

I have not seen an answer that stands out in [Manning, JSFIA] so I thought I would ask it here:

I have a Login.jsp page. On a "success" outcome it takes me to another resource. Straight forward enough. However, I expected the new resource to be reflected in the URL in the location field of the browser, e.g.

Login.jsp > "success" > MyPage.jsp
Login.jsp > "failure" > Login.jsp

(All faces-config.xml navigation rule and cases apply)

My URL seems to always display "Login.jsp", or, depending on the browser, "Login.jsp#". I expected, possibly incorrectly because of the postback nature of JSF, "MyPage.jsp" ... the correct resource is returned as expected though.

Did I configure something wrong, or am I using the commandbutton component incorrectly, in its action attribute?

Oh, I'm using the Sun Java Visual Web Pack components part of NetBeans 5.5, not the RI components, if that matters.

Regards,
Tim