Meta

Pages

Tag: error

While I’ve run various builds of Linux for many years, I still have to routinely test my work in Windows. While I often attempt to keep my laptops able to dual-boot into Windows, that only (realistically) supports only a single version of Windows. For older versions, I generally rely upon VirtualBox and can then have different configurations available when needed, while keeping my Linux apps open too!

Occasionally, I’ve had a virtual machine running a licensed copy of Windows 7 start warning that it is not activated. This can prove to be annoying for several reasons, as such I did some research and found that others have encountered the same problem and shared the below solutions.

First method:

Open a command prompt in Administrator mode.

Execute “slmgr -rearm”

NOTE: some sites tell you to locate and remove “slui.exe” – DO NOT DO THIS!

SortSite is a popular desktop software for testing of web applications for broken links, browser compatibility, accessibility and common spelling errors. It is also available as a web application known as “OnDemand“.

After fixing the validation error in my Ant build.xml files, I got to wondering about the other common XML files in my projects. I’ve used Logback on many of my recent projects and it’s configuration has similar warnings that can be resolved in the same manner.

The simplest method to silence the warning is to add a DOCTYPE to the logback.xml files, between the XML declaration and the configuration. Official documentation seems to indicate that a DTD is not possible or likely.

I’ve seen this validation error in Eclipse for a few releases and finally got tired enough of seeing it that I did some research.

The simplest method to silence the warning is to add a DOCTYPE to the build.xml files, between the XML declaration and the project, there are a few more complicated methods, but this one works well for the cases I’ve experienced.

I’ve recently been doing some work with code that is still running in a Java5 environment, to make matters worse, no new libraries can be added to the application. With these restrictions, I’ve had to resort to using only functions available in the standard installed JVM. The code relies on HTTP Basic authentication, and thus needs to use Base64 encoding.

The following classes were to be used…
import sun.misc.BASE64Encoder;
import sun.misc.BASE64Decoder;

Unfortunately, Eclipse did not like this and gave an error…

Access restriction: The type BASE64Decoder is not accessible due to restriction on required library C:\jdk1.5.0_22\jre\lib\rt.jar

Thankfully, this class (while not recommended, is in every build of the JVM that I have seen), you can tell Eclipse to only ‘Warning’ on it’s usage…

IE overrides several HTTP error status pages but it has a size threshold. Only if the error page send by the server has a large enough body then IE decides it’s meaningful and displays it.

Usually to be safe you should make error pages that are larger then 512 bytes. The threshold varies per HTTP status code. You can look at what your thresholds are currently set to. In IE 5 and greater the settings are stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\ErrorThresholds]

This is a relatively common problem in JSP based apps as you need to understand the configuration. It’s further complicated if you use Apache HTTPD in front of the Apache Tomcat server to process requests as you need to know where each request is processed.

For this example, we will use the standard 404 error, but you can also intercept other errors for custom pages.

in WEB-INF/web.xml – add the following (NOTE: location within the file is important but outside the scope of this post)
<error-page>
<error-code>404</error-code>
<location>/404.jsp</location>
</error-page>

You might want to force the HTTP Header to give something other than a ‘404 status’ code, otherwise MSIE will show an unstyled ‘friendly error message’ if the user has not turned off the default setting. Unfortunately, this also means that search engines might index these pages that should not exist.

I’ve found that many developers (including myself) that have been coding javascript for some time don’t realize that javascript added the try/catch pattern from Java quite a while ago and that all modern browsers support it.

Here’s the standard pattern, the ‘finally’ of course is optional for when you require it.