scott p laplante

I would like to find out what the book has in terms of performance testing- specifically, to make sure that the configuration supports the highest throughput as possible, given a particular application. Thanks.

Joshua and Neal,

Without giving away precious information, are there any puzzlers you foudn which didn't quite make it into the book?

Do you two have a website with a forum so people can post their own, or discuss the answers/solutions?

And lastly, what was the most challenging aspect of the writing process, for each of you?

Thanks,
Scott
[ August 09, 2005: Message edited by: Mark Spritzler ]

To clarify by example:

class DoesntCompile {
void foo() {
Object x = new int[10][10];
boolean expectFalse = (x instanceof int[]);
}
}

DOES compile, correctly.
[ March 08, 2005: Message edited by: scott p laplante ]

For those who are certified, what do you think is the best way of presenting that information on a resume? Ideally you'd want it to stand out, but you don't want it to be too overbearing. Is the best thing to create a Certifications section entirely, or to mention it in the Objective and then again in the cover letter? What's the consensus on this one?

as for te claims that this is not thread safe, I have a question...

are both ++p and p++ atomic operations? if so, i don't see how this is not thread safe.

In answer to the multi-dimensioned generics question...

ArrayList<ArrayList<String> >

I would guess that that would work, as is, but if it wouldn't, you could always create a wrapper object...

ArrayList<ArrayListOfStrings> and define the class ArrayListOfStrings as a small wrapper around ArrayList<String>.

However, like I said, I would guess that this would just work. Can someone confirm?

I've found other examples of this, but cannot find any documentation as to why one would want to do this. any ideas?

I've seen many example tag classes that have pageContext.getOut().flush();, wrapped in a try/catch, as the first line of doEndTag().
1. What is the purpose of that?
2. From the docs at JspWriter.flush() it seems that this call would forward the flush onto the Response. Would this disallow a tag error from redirecting the user to the error page? (Response.flushBuffer() commits the status and headers, disallowing future redirects in the page, right?)
3. What bad things happen if you don't flush it?

If there is a good explanation of any of this, I'd love to be pointed to some good docs.
Thanks!
[ May 12, 2004: Message edited by: scott p laplante ]

We are not "generating the html code from the backend". The source of our HTML tags and content is still front end code. What we ARE trying to do is to pre/re-generate HTML blocks (from JSP) that take a long time or are resource-intensive.
Imagine a JSP file which requests an XML from a very slow server and returns the xmlString. If we did this based on a user-request, the user would wait a very long time to see the page. Instead, we are pre-fetching or pre-generating this XML block and caching it for a period of time.
When the cache expires, we still do not want this hit to be taken by a user. So we have, basically, a backend Thread that loops through and tries to re-generate the XML file, again caching it for a period of time.
The problem we are up against is that we cannot seem to invoke the JSP without already being within an HTTPServletRequest/Response cycle(see my comments above).
My example was fake, by the way, but appropriate to demonstrate the problem I am trying to tackle- i.e. not exposing long generation times to our end users. User-requests should be done very fast.
As an aside, when regenerating, we ARE running the regen request through the loopback device (for throttling purposes), but by the time we've figured out that it requires JSP to be generated (instead of, say XSL or XPath), we are well into the backend code and do not (nor should not) know what an HTTPServletRequest/Response is.

Thanks for the response. Unfortunate info, but expected.
What other options might i have? The basic requirements are:
-- inherently not end-user request-based (the point of generating the HTML chunks in the backend is to avoid end users taking the generation hit, which can be large at times)
-- mix of object-access code and HTML tags (similar to JSP, we'll have HTML tags interspersed with getters on the object(s) passed in)
-- as easily as possible to generate and maintain (would like to avoid writing individual classes with stringBuffer.append(...) to write characters to the resultString, as creation/updates will be done by front-end folk)

Some ideas I've entertained, to give you an idea of what I'm thinking:
-- write an HTML-parser using regexp and use reflection to run the object getters. (would be hard AND certainly re-inventing the wheel)
-- send an HTTP request through the loopback device, sending objects as request parameters (undesireable since it'll have to be throttled and/or would be unnecessarily clogging the request pool)
-- set up a mini-servlet engine on the side to handle these requests apart from tomcat (harder to maintain, memory hog, another possible bottleneck...)

any ideas or advice? the main problem is that some of these HTML chunks take non-neglible time to generate (which is why we're re-genning them without user-prompts), and they can be regenerated when loads are low, so as to tread as lightly as possible.
i appreciate any ideas or information or leads. thanks very much.

Is it possible to call a JSP outside of the confines of a Request/Response? How does one do that?
We have a backend system that is regenerating small HTML chunks/nuggets. These nuggets are mostly things like dropdowns or other page elements. I would like the front end people able to create these easily (i.e. without deep knowledge of JAVA), and JSP seems like an obvious choice.
The problem arises when my Thread is going through its regen loop, and it comes across one of these files that need to be updated. I would like the ability to "invoke" the JSP and get a return string, which I then write to a file, mark for future regeneration, etc.
The regeneration and that loop isn't the problem. I just simply don't know how to "invoke" a JSP from within backend code- i.e. I do not have an HTTPServletRequest or Response at that time and do not want to create one if possible. I simply want to say "invoke the JSP with these parameters, and give me back the HTML string".
I don't even know if "invoke" is the right terminology- hence the quotes.
If I'm stuck, I'll probably create a small pool of Request/Response Pairs that won't interfere with the request handling aspect that's going on in the Servlet side of the application.
Any ideas? Thanks in advance for yor input.

I think in general, security concerns come about when logging in, validating permissible actions (for a user), updating user information, etc. there's an inherent cost to security, though, so its use should be limited to only that which is necessary.

d1 through d4 would all have to be implemented over https as well, as other posters have said. any server-side includes when processing b.jsp would also (naturally, but mootly, as it's server-side) be secure.