Giant Geek Blog

After updating the JDK on my development workstations, NetBeans started reporting the following at each start up.

Cannot locate java installation in specified jdkhome:
C:\Program Files\Java\jdk1.7.0_04
Do you want to try to use default version?
[ Yes | No ]

Thankfully, after a little searching, I found that the solution is very simple. You can change the value or comment it out with a # in:
C:\Program Files\NetBeans #.#.#\etc\netbeans.conf

netbeans_jdkhome="C:\Program Files\Java\jdk1.7.0_04”

REFERENCES:

Occasionally I’ve stumbled upon legacy javascript code that is used to determine javascript support by the visiting users. This often proves comical, because they are many times wasting time making checks for some “VERY OLD” browsers indeed! Here’s a rundown of the versions of javascript as well as their release dates and some common browser versions that implemented them.

• JavaScript 1.0 (March 1996) = Navigator 2.0 / MSIE 3.0
• JavaScript 1.1 (August 1996) = Navigator 3.0
• JavaScript 1.2 (June 1997) = Navigator 4.0-4.05
• JavaScript 1.3 (October 1998) = Navigator 4.06-4.7x / MSIE 4.0
• JavaScript 1.4 = Netscape Server
• JavaScript 1.5 (November 2000) = Navigator 6.0 / Firefox 1.0 / MSIE 5.5 – 8.0 / Safari 3.0-5 / Chrome 1.0-10.x / Opera 6.0
• JavaScript 1.6 (November 2005) = Firefox 1.5
• JavaScript 1.7 (October 2006) = Firefox 2.0
• JavaScript 1.8 (June 2008) = Firefox 3.0 / Opera 11.50
• JavaScript 1.8.1 = Firefox 3.5
• JavaScript 1.8.2 (June 2009) = Firefox 3.6
• JavaScript 1.8.5 (July 2010) = Firefox 4.0 / MSIE 9.0 / Opera 11.60

The language attribute has long been deprecated and should generally be avoided, it’s original purpose was to support other scripting languages, notably VBScript, or particular JavaScript versions. Modern conventions rely on specifying the MIME type instead via the ‘type’ attribute.

<SCRIPT LANGUAGE="JavaScript"> is now <script type="text/javascript">

<SCRIPT LANGUAGE="JavaScript1.1"> is now <script type="text/javascript1.1">

<SCRIPT LANGUAGE="VBScript"> is now <script type="text/vbscript">

<SCRIPT LANGUAGE="TCL"> is now <script type="text/tcl">

REFERENCES:

Ternary operators, if not abused, can make code easier to follow once you grasp the concept. While normally used for assignment, they can also be used to control program flow. The keys to this are the condition, question mark and colon that identify the condition and results.


var foo = (some_condition) ? then_code : else_code;


REFERENCES:

I’ve been a huge fan of the ‘final‘ modifier in Java for function arguments and variables. While there’s some debate on their usefulness for performance, they definitely add in readability and understanding of code as developers are instantly notified by modern IDE’s and when they try to reassign such values as the compiler will indicate the error.

NOTE: Use of final for classes or functions often contradicts the paradigm of Object Oriented programming as you’ll be restricted from extending or overriding those items!

Adding multi-language support to JSP based applications is very simple. In this post we will investigate the method that you can use to externalize your text based content.

NOTE: Additional work is required to establish the Locale, format Dates and Numbers or to support other differences such as text-direction.

JSP:

<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
<fmt:setLocale value="en_US" />
<fmt:setBundle basename="ResourceBundles.TestBundle" scope="request" var="rb" />
<fmt:message bundle="${rb}" key="label.test" />

/src/ResourceBundles/TestBundle.properties:

label.test=test(default)

/src/ResourceBundles/TestBundle_en.properties

label.test=test(en)

/src/ResourceBundles/TestBundle_en_US.properties

label.test=test(en_US)

You can also specify some default Locale information in web.xml if you do not wish to use the in your JSPs.

/WEB-INF/web.xml


<context-param>
<param-name>javax.servlet.jsp.jstl.fmt.locale</param-name>
<param-value>en</param-value>
</context-param>

<context-param>
<param-name>javax.servlet.jsp.jstl.fmt.fallbackLocale</param-name>
<param-value>en</param-value>
</context-param>


Some explanation… in this case we’ve told our JSP that the resources are in the TestBundle properties. As the Locale is set to ‘en_US’ it will first look in the TestBundle_en_US.properties file, if not found it will then look in TestBundle_en.properties and finally in TestBundle.properties. If not found there, the output will generally be in the form ‘???key???‘, in this example: ‘???label.test???‘, my understanding is that this can be suppressed by setting ‘allowNull=true‘ somewhere, but I have never found that setting to date.

REFERENCES:

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.

try{
// put your code here that may experience a runtime error/exception, i will show division by zero in this example
var x = 1;
alert(x/0);
}
catch(e){
if(e instanceof Error){
alert(’an error has occurred:name=’ + e.name + ‘|message=’ + e.message);
} else {
alert(’an unknown exception has occurred’);
}
}
finally{
alert(’now we are done’);
}

A little more on this… like in Java, there are types of Errors, and you can rely upon ‘instanceof’ to determine them appropriately, here are a few of the common types in JavaScript 1.5:

• EvalError
• RangeError
• ReferenceError
• SyntaxError
• TypeError
• URIError

REFERENCE:
http://www.devarticles.com/c/a/JavaScript/Exception-Handling-in-JavaScript-Using-Multiple-Exception-Handlers/

Cheers

If you have ever looked at the console or logs while starting a Tomcat instance on Windows you have probably seen the following line about APR.

INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path

As long as the “tcnative-1.dll”  is in the Windows PATH, generally you can place it in c:\windows\system32, but any other location in the PATH will work should you need it to be portable, or have different versions in use.

NOTE: Other Operating Systems use a similar approach as Windows to add an environmental variable, optionally you can also add the appropriate location to the “java.library.path” attribute used when calling the VM, if you are more technically inclined.

• http://www.coderanch.com/t/85960/Tomcat/Tomcat-Native-library-not-found
• http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Tomcat+Native+Library
• http://apr.apache.org/

Cheers

If you do any development or even production testing with Apache Tomcat, you may have seen the following message in your logs.

“The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path”

Here’s a quick solution that will leave you with greatly improved performance.

1. Go to the following URI’s:
   • For Tomcat 5.5.x – http://tomcat.apache.org/tomcat-5.5-doc/apr.html
   • For Tomcat 6.x – http://tomcat.apache.org/tomcat-6.0-doc/apr.html
2. Download the appropriate version of tcnative-1.dll
3. For Windows, place that file in c:\windows\system32\ 
4. Restart your Tomcat server
5. You are done!

Cheers

I’ve got my “Java Yellow Belt”

While this website does not give out official certifications, it’s a decent measure of individuals knowledge and provides a great way to test what you know (and may have forgotten over the years).

http://www.javablackbelt.com/

Cheers!

Often you want to use Apache HTTP for static content, yet use Tomcat for JSP and other Java type work.  This is a very common infrastructure for enterprise applications, particularly when using ‘pools’ of servers for performance, redundancy and security.  

In order to accomplish this, all connections need to be handled by the Apache webserver, which will delegate appropriate requests to Tomcat for it to process.

Here’s a simple setup to get you started:

• First you need to get the connector appropriate to your installation:
  

  http://tomcat.apache.org/connectors-doc/

• Next make sure the connector file is in the /conf folder of your Apache installation.
  

  NOTE: I prefer to use this path and leave the version name to make maintenance and backups easier.

• Add the following line to httpd.conf
  

  LoadModule jk_module conf/mod_jk-1.2.26-httpd-2.2.4.so

• Now, add the following to http.conf
  

  <IfModule jk_module>
  Include “c:/TOMCATPATH/conf/auto/mod_jk.conf”
  JkWorkersFile conf/workers.properties
  JkLogFile “c:/LOGSPATH/tomcat55_mod_jk.log”
  </IfModule>

• Add the c:/APACHEPATH/conf/workers.properties file with the following (minimal) contents:
  

  worker.list=ajp13
  worker.ajp13.port=8009
  worker.ajp13.host=localhost
  worker.ajp13.type=ajp13

• Finally, restart both Apache and Tomcat
• The following file should have been created in c:/TOMCATPATH/conf/auto/mod_jk.conf
  

  ########## Auto generated on …some datetime… ##########

  <IfModule !mod_jk.c>
    LoadModule jk_module “C:/APACHEPATH/conf/mod_jk-1.2.26-httpd-2.2.4.so”
  </IfModule>

  JkWorkersFile “C:/TOMCATPATH/conf/jk/workers.properties”
  JkLogFile “c:/LOGSPATH/mod_jk.log”

  JkLogLevel emerg

  <VirtualHost localhost>
      ServerName localhost

      JkMount /webdav ajp13
      JkMount /webdav/* ajp13

      JkMount /servlets-examples ajp13
      JkMount /servlets-examples/* ajp13

      JkMount /jsp-examples ajp13
      JkMount /jsp-examples/* ajp13

      JkMount /balancer ajp13
      JkMount /balancer/* ajp13

      JkMount /host-manager ajp13
      JkMount /host-manager/* ajp13

      JkMount /tomcat-docs ajp13
      JkMount /tomcat-docs/* ajp13

      JkMount /manager ajp13
      JkMount /manager/* ajp13
  </VirtualHost>

If all went well, you should be able to access  your Tomcat server webapps on the regular HTTP port used by your Apache installation.

Cheers!