Christopher Button

+ Follow
since Feb 19, 2013
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christopher Button

No problem, not quite worth the gray hairs, but progress is progress!

Thanks for the cow (at first I thought you were telling me to...have a cow)

One other point to note, which should be mentioned: I'm still not 100% clear as to why changing web.xml to XSD caused the JasperException with respect to JSTL, though I think it has something to do with JSTL being integrated with JSP at some point after Servlet 2.3.

For a more in-depth discussion around the JSTL integration with JSP:
4 years ago
Pardon the double post, but the gods have taken pity on me and provided me, at last, after several gray hairs, with the solution, posted here:
4 years ago

I finally came upon the solution. By default, for some reason (and I'd like to know why), Maven generates a Dynamic Web Module as version 2.3. DTD was of course the standard for Servlet 2.3 and was probably unable to parse or evaluate my XML-based deployment descriptor.


Right-click on your Maven project and select **Properties**

Navigate to Project Facets and untick **Dynamic Web Module**. Apply changes.

From the version drop-down box, select the latest version (as of writing, this is 3.1). Apply changes.

Right-click on your Maven project and select **Maven** -> **Update Project**.

Your project should now be able to correctly interpret a web.xml with an XSD declaration.
4 years ago
Unfortunately, it looks like I'm going to have to go back to the old DTD; it's the only way I can get my application to compile. After considerable time trying to get it to work with an XSD format, every time I change to XSD, I get the JasperException mentioned here:

Extensive reading throughout the internet has yielded no clear answer at all, despite the error being fairly common.
4 years ago
I realise now this is related to my web.xml; the web app only works if the web.xml contains a DOCTYPE declaration instead of an XML schema. I would love to know why.

My old web.xml:

However, once I change web.xml to the following, I get the JasperException:

Any idea why a current web.xml format, which is made with the latest versions of Eclipse and Maven, would cause the project to go haywire?
4 years ago
I dread somewhat having to open a thread for this, as both StockOverflow and Coderanch have had past discussions around this. Having scoured the net for answers and spent about five hours trying to troubleshoot, I'm still stumped. I am using Maven and trying to run a very simple web application containing three text boxes and a submit button which validates the parameters and redirects to a success page if valid.

When attempting to run the relevant JSP on the Tomcat 8 server (having done it successfully many times), I am confronted with this:

HTTP Status 500 - The absolute uri: cannot be resolved in either web.xml or the jar files deployed with this application

Almost all of the aforementioned discussion threads on this topic have advised adding jstl 1.2 as a dependency to pom.xml. Given the error, that seems to make sense, however I have already done this. Everything is also declared correctly and has compiled successfully in the past.



Maven project structure

The error

I suspect this will end up being another one of those things that "don't work until they do"; I've probably learned and retained most of what I know so far about JEE thanks to the hours spent debugging!
4 years ago
Thank you, Bear. I consulted the relevant FAQ article and did some further reading and indeed, it should be declared as an XML schema. The DOCTYPE declaration appears to have been the default for the pre-Tomcat 6 era, so I haven't the foggiest as to why Maven generated a much older web.xml, especially puzzling given that I'm using the latest version of Eclipse, which in turn contains the most recent version of Maven.

As to the choice of design pattern, I can certainly see why this approach is not ideal, however I am simply following the instructions and steps outlined in my beginner's manual. Improvement in this particular area will no doubt increase with my experience.
4 years ago
Thanks for your replies. However, I figured out the issue: My EL hadn't been activated; it had nothing to do with JSTL as such.

I added the following to the top of my JSP:

I'm a bit annoyed at having to do this. Is it common to have to add this specific declaration to get EL to work?

I've heard it has to do with the web.xml making use of Servlet 2.3 instead of 2.4, so I'll look into that as well. As it stands, my automatically generated web.xml looks like this:

4 years ago
I have a very simple JEE project that I am building in Eclipse using Maven. Three text boxes and a submit button which validates the entries and redirects to a second JSP page if successful.

This code checks the request parameters from the submit button:

The problem is that the c:if fails and I cannot figure out why. I am using source code taken straight from my textbook.

This is the code for the web form, located in the same JSP file:

All the required bean classes and variables and dependencies have been declared etc. as per the textbook instructions. I just need to figure out why it won't register the POST request from the submit button.

I set a breakpoint on the conditional statement in question and attempted to debug it. At the line, I select Step Over and get the message, "addCourse.jsp line: not available". This occurs three more times and then the test terminates at the end of the c:if statement, skipping the entire nested block.

Any ideas why this might be happening?
4 years ago
I can't believe I posted this in the wrong forum. Sorry about that. Could a moderator move this to the correct location?

Also, I rewrote my RMI code to fit the Adapter pattern, rather than the Factory pattern. It seems all is working well now.

Thanks for the help in any case!
7 years ago
Good day,

I was hoping with a quick glance over this code someone might be able to elucidate the problem I seem to be having in getting my client side to correctly invoke methods on the RMI stub.

I have set it up according to Andrew Monkhouse's design (Factory pattern) but am getting the below error whenever I try to run the client after running the server.

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\IT>java -jar c:\scjd\dist\scjd.jar

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:

java.rmi.server.ExportException: remote object implements illegal remote interface; nested exception is:

java.lang.IllegalArgumentException: illegal remote method encountered: public abstract long suncertify.db.DB.lock(int) throws suncertify.db.exceptions.RecordNotFoundException


Exception in thread "main" java.lang.NullPointerException
at suncertify.gui.Client.setTable(
at suncertify.gui.Client.<init>(
at suncertify.gui.AppLoader.<init>(
at suncertify.gui.AppLoader.main(

All the necessary methods throw RemoteExceptions.

More information may be needed from me to clarify things, but what I'm really after is an understanding of what the general issue is here, as far as "illegal remote method" and "illegal remote interface" are concerned. They are coded as per Monkhouse's design.

The issue with the Lock method is baffling above all, since I haven't yet invoked it at all, anywhere, and it is only one of the methods in the DB interface. I can't understand why it is being singled out.

I don't want to paste large swathes of code, so if any specific information is further needed, please let me know and I will try and explain in more detail what is required.

Any general conceptual help would be most appreciated.

Thank you,

7 years ago
Hi Roel,

Thank you for the warm welcome!

Clearly there was a bit of a misunderstanding going on. What you have written is of much help. I'm still not totally clear on the distinction, but I think it has something to do threading, which I haven't gotten around to implementing yet (I'm still working on the DB interface methods).

I'll be sure to have a closer look at the FAQ.

Thanks again!

Good day (or evening, as it is here).

I have a simple question regarding the difference between the customer ID field of the database and the lockCookie. It appears to me that both determine whether or not a record is available for booking/sale/editing/deleting, so my question is: why couldn't one just use the CSR ID as the cookie to determine whether a record can be updated or deleted? Why the need for an additional identifier?

I fear some deviously simple explanation is eluding me, based on a misunderstanding of their purposes. If anyone could be so kind as to clarify their individual uses, I would be most grateful.

Also, first time here. Hope to learn a lot, and maybe even contribute at some point.

Thanks kindly!