Installing NetBeans 6.9 Fails when XCode is Running

I've been trying to install the NetBeans 6.9 official release (netbeans-6.9-ml-java-macosx.dmg) but it kept on failing during the "Preparing Installation" phase.  No detailed errors were shown other than a generic statement to contact my software vendor.

Turned out, at least on my MacBook  Pro, that the cause seemed to be that XCode was running at the same time.  As soon as I quit from XCode and ran the NetBeans installer from the same installation package, it worked without any problems and installed NetBeans successfully.

Don't know if this is isolated to NetBeans or more generally to the installer technology used on the Mac, but it seems that there was some contention with Xcode, which resulted in the installer not working.

 

Dynamically Setting JAVA_HOME on Mac OS X

This was a new discovery to me today, so please ignore if this is widely used and known.

On Mac OS X, there is a very specific, managed directory structure for the various Java versions that are installed.  The general directory is "/System/Library/Frameworks/JavaVM.framework/".  For those of us new to Mac OS X, the sub-directories under there look a little foreign.

To run WLS, you need to set JAVA_HOME to the appropriate directory before you can start a domain.  Hardcoding the directory into either .bashrc or the startWebLogic.sh scripts does the trick.

But today I stumbled on another little utility that can be used to dynamically determine the current  JAVA_HOME, as set in the user preferences:

NAME
       java_home - return a value for $JAVA_HOME

SYNOPSIS
       /usr/libexec/java_home [options]

DESCRIPTION
       The  java_home  command  returns  a path suitable for setting the JAVA_HOME environment variable.  It
       determines this path from the user's preferred Java in the Java Preferences application.   Additional
       constraints may be provided to filter the list of JVMs available.  By default, if no constrants match
       the available list of JVMs, the default order is used.  The path is printed to standard output.

Thus setting JAVA_HOME dynamically in scripts, shell profiles can be done simply like this:

export JAVA_HOME=`/usr/libexec/java_home`

NetBeans 6.9 Released

I've been using NetBeans 6.8 quite a bit lately to explore new functionality in Java EE 6.

Just noticed on the weekend (somewhat belatedly) that their latest 6.9 version has been finalized and released.  At a measly 178mb for the core IDE with Java EE 6 support and an embedded GlassFish v3.0.1 server for the dev/test runtime, it sounds like a download well worth making.

Running WLS on Mac OS X with Correct Memory Settings

The shell scripts that launch WLS on Mac OS X don't seem to set the JAVA_VENDOR to Apple, which means that the relevant USER_MEM_ARGS are not specified when the server is started.

To remedy this I've been setting JAVA_VENDOR="Apple" before starting my domain.

But occasionally I forget.  So to automate the setting, I udpated $DOMAIN_DIR/bin/setDomainEnv.sh as follows:

if [ "${JAVA_VENDOR}" = "Oracle" ] ; then
    JAVA_HOME="${BEA_JAVA_HOME}"
    export JAVA_HOME
else
    if [ "${JAVA_VENDOR}" = "Sun" ] ; then
        JAVA_HOME="${SUN_JAVA_HOME}"
        export JAVA_HOME
    else
        if [ "`uname`" = "Darwin" ] ; then
            JAVA_VENDOR="Apple"
            export JAVA_VENDOR

            JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home"
            export JAVA_HOME

    fi

    fi
fi

This then results in the relevant MEM_ARGS for Apple being set later in the script:

if [ "${JAVA_VENDOR}" = "Apple" ] ; then
    MEM_ARGS="${MEM_ARGS} ${MEM_MAX_PERM_SIZE}"
    export MEM_ARGS
fi

Now starting the domain on Mac OS X, the necessary memory arguments are set on the JVM and the server runs as expected.

$ startWebLogic.sh

          ....

java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
Starting WLS with line:
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java -client   -Xms512m -Xmx512m -XX:MaxPermSize=128m -Dweblogic.Name=myserver ...

WLS 1033 Class Caching for Faster Startup in Development Mode

Another incremental development feature that was added to WLS 10.3.3 is a Class Caching option, designed to reduce startup time of a development server.

See the documentation for more details:

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13706/classloading.htm#WLPRG493

Configuring Class Caching

WebLogic Server now allows you to enable class caching for faster start ups. Once you enable caching, the server records all the classes loaded until a specific criterion is reached and persists the class definitions in an invisible file. When the server restarts, the cache is checked for validity with the existing code sources and the server uses the cache file to bulk load the same sequence of classes recorded in the previous run. If any change is made to the system classpath or its contents, the cache will be invalidated and re-built on server restart.
The advantages of using class caching are:

• Reduces server startup time.
  
• The package level index reduces search time for all classes and resources.
  

The cache uses optimization techniques to minimize the initial cache recording time. Cache recording continues until a specific class has been recorded.

Moving up to Mac

It would be somewhat remiss of me to not mention that I've recently become a convert to the world of Mac, purchasing myself a 15" MacBook Pro. 

I was a little hesitant about moving over to it, but I have to say, it's been fairly painless so far (thanks to VMware Fusion for the few remaining Windows apps I have no control over) and the rewards of using Mac OS X instead of Windows XP are plentiful. 

As I sit here writing this, with a Terminal window open with WLS running happily in the background, I just noticed that Time Machine has kicked in and started an incremental backup. 

And don't even get me started on the wonders of using Trackpad, Expose and Spaces ... my only question is why did I wait so long?!

More on the WLS Zip Distribution

My colleague Prash has recently added a post to the official WebLogicServer blog discussing the new WLS zip file distribution.

http://blogs.oracle.com/WebLogicServer/2010/05/the_new_wls_zip_distribution_w.html

He has helpfully included the contents of the readme.txt that ships within the zip file, just click on the link towards the bottom of the page to see it.

Moving WLS 1033 Developer Zip Location

I just ran into a usage issue with the WLS 10.3.3 Developer Zip file distribution that I thought I'd share.

What I did was to move the unzipped WLS Developer Zip from one directory location to another.

>mv /Users/sbutton/Java/wls-1033-dev /Users/Shared/Java

Upon doing that, I found I could no longer create new domains when the server was started, despite it working previously.

<May 20, 2010 12:18:13 PM CST> <Info> <Management> <BEA-141254> <Generating new domain directory in /Users/sbutton/Domains/dev>
<May 20, 2010 12:18:14 PM CST> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:

There are 1 nested errors:

weblogic.management.ManagementException: Failure during domain creation
    at weblogic.management.internal.DomainDirectoryService.generateDomain(DomainDirectoryService.java:235)
    at weblogic.management.internal.DomainDirectoryService.ensureDomainExists(DomainDirectoryService.java:153)
    at weblogic.management.internal.DomainDirectoryService.start(DomainDirectoryService.java:73)
    at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:461)
    at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:166)
    at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:802)
    at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:489)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:446)
    at weblogic.Server.main(Server.java:67)
Caused by: com.oracle.cie.domain.DomainConfigException: Unable to locate default template
    at com.oracle.cie.domain.DomainInfoHelper.createDefaultDomain(DomainInfoHelper.java:1759)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at weblogic.management.internal.DomainDirectoryService.generateDomain(DomainDirectoryService.java:230)
    ... 8 more

>
<May 20, 2010 12:18:14 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
<May 20, 2010 12:18:14 PM CST> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down>
<May 20, 2010 12:18:14 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN> 

After some head scratching, I finally realized it was probably to do with the security settings that are applied by the "configure.sh" script that needs to be executed when the zip file is first extracted.

After re-running configure.sh from the new directory location, the domain was then able to be created as normal.

So if you do move the directory holding the extracted WLS 10.3.3 Developer Zip distribution around, remember to run the configure.sh script again.

Changing Default JPA Provider in WebLogic Server 10.3.3

WebLogic Server has been providing both OpenJPA/Kodo and EclipseLink as JPA providers since WLS 10.3.1.

Unless an explicit <provider>...</provider> is specifed in the persistence.xml file of a deployed application, WLS will use OpenJPA/Kodo by default.

With the release of WLS 10.3.3, we have now provided a way to change the default JPA provider at the domain level, allowing you to switch between OpenJPA/Kodo or EclipseLink as the default that WLS will use.

The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.

To easiest way to change the default JPA provider it to use the console and select the desired provider value.

JSF 2.0 Support in WebLogic Server 10.3.3

With the release of WebLogic Server 10.3.3 (now available on OTN) we have added support for JSF 2.0 by providing a JSF 2.0 shared-library that can be deployed and used with WebLogic Server.

The new JSF 2.0 shared-library is located here in a WLS 10.3.3 installation:

>$WL_HOME/common/deployable-libraries/jsf-2.0.war.

The shared-library name and spec/implementation version details are listed in the documentation here:

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13712/configurejsfandjtsl.htm#sthref43

The JSF 2.0 shared-library follows the same model as the previous JSF libraries shipped with WLS, where it needs to be deployed and referenced using a &gt;library-ref&lt; in a WLS deployment descriptor by applications that wish to use it.

The JSF 2.0 library supports Dependency Iinjection of Java EE resources and the use of the Java EE 5 lifecycle annotations in Managed Beans as described in the specification.  This is done through the inclusion of a WLS specific class that implements the com.sun.faces.spi.InjectionProvider interface provided in the WEB-INF/lib/wls.jsf.di.jar library within the jsf-2.0.war shared-library.

We also continue to provide support for earlier JSF 1.2 releases.

Weblogic Server 10.3.3 available on OTN

News at hand! We've just released WebLogic Server 10.3.3 and it's now available for download on OTN:

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

You may also note the addition of a new zip file download for WLS itself:

http://download.oracle.com/otn/nt/middleware/11g/wls1033_dev.zip

This is a new smaller distribution of WLS that we are making available as a zip file, which can be simply extracted to a local directory, one script executed to specify some access control settings, and then launch WLS directly from the command line. A new domain will automatically created if none is found.

This is a really good step forward for WLS, making it more easily installed and incorporated into development and testing environments. Please read the README.txt embedded within the zip file for more details on how to start and use the server. Note that this is only supported for development use, not for use in production deployment environments.

By the way, this new WLS zip file distribution has been tested, and is supported on Mac OS X for development use. Enjoy!

Note: an issue was identified by a reader below showing that the upgrade utility was not launching successfully.  We have identified a workaround for this which involves adding two additional libraries to the PRE_CLASPATH environment variable before running the upgrade utility.

$ export PRE_CLASSPATH="${MW_HOME}/modules/features/com.bea.cie.common-plugin.launch_2.5.0.0.jar:${MW_HOME}/utils/config/10.3/config-launch.jar"
 

Then run upgrade command as usual.

$ ${MW_HOME}/wlserver/common/bin/upgrade.sh

The Obligatory Calculator in JSF 2.0

Checked out some of the high level JSF 2.0 new features recently using NetBeans 6.8 and GlassFish v3.  For what it's worth, I think they are very usable, feature rich and effcient pairing for conducting Java EE 6 development.

As with all old habits, some won't die.  And my habit for taking a quick look at any new programming language/framework is to build a very simple calculator with one screen and some simple calculation logic.

With NetBeans, creating a new Web project is trivial.  To add JSF support select it as a framework to use.

After a bit of navel gazing, I realized a significant part of the unholy dislike I had for JSF 1.2 and its earlier versions predominantly stemmed from the need to live in the configuration red zone -- faces-config.xml. Every damned thing that you wanted to use or access pretty much needed to be defined in the configuration file: managed beans definitions with packages/classes and names and scopes, even the most simples of page navigation paths, etc.

But as of JSF 2.0, that has mostly changed! Accomodating a convention over configuration model for page navigation and making use of annotations for declaring managed bean components (and associated runtime attributes and property values) in my simple example, I didn't have to even look at the faces-config.xml file.  Happy Days.

Here's my simple CalculatorManagedBean, which is responsible for performing the arduous task of calculating a result from a given two values and an operand. It also supplies the operand values for the screen to display.

To declare this as a ManagedBean, all I had to do was to add the @ManagedBean annotation. I also decided to bind this ManagedBean into each clients HttpSession so it was created once, and was able to store property values set from eacg clients page.

 1 package sab.demo.calc.beans;
 2 
 3 import java.io.Serializable;
 4 import javax.annotation.PostConstruct;
 5 import javax.faces.bean.ManagedBean;
 6 import javax.faces.bean.SessionScoped;
 7 
 8 @ManagedBean(eager=true)
 9 @SessionScoped
10 public class CalculatorManagedBean implements Serializable {
11 
12     public static char[] operands = { '+', '-', '*', '/' };
13 
14     int value1;
15     int value2;
16     char operand;
17     String result;
18 
19     public CalculatorManagedBean() {
20     }
21 
22     public char[] getOperands() {
23         return operands;
24     }
25     
26     public char getOperand() {
27         return operand;
28     }
29 
30     public void setOperand(char operand) {
31         System.out.printf("setOperand: %s", operand);
32         this.operand = operand;
33     }
34 
35     public String getResult() {
36         return result;
37     }
38 
39     public void setResult(String result) {
40         this.result = result;
41     }
42 
43     public int getValue1() {
44         return value1;
45     }
46 
47     public void setValue1(int value1) {
48         System.out.printf("setValue1: %s\n", value1);
49         this.value1 = value1;
50     }
51 
52     public int getValue2() {
53         return value2;
54     }
55 
56     public void setValue2(int value2) {
57         System.out.printf("setValue2: %s\n", value2);
58         this.value2 = value2;
59     }
60 
61     public void calculate() {
62         switch(getOperand()) {
63             case '+' :
64                 result = String.valueOf(value1 + value2);
65                 break;
66             case '-' :
67                 result = String.valueOf(value1 - value2);
68                 break;
69             case '*' :
70                 result = String.valueOf(value1 * value2);
71                 break;
72             case '/' :
73                 double v1 = value1;
74                 double v2 = value2;
75                 result = String.valueOf(v1 / v2);
76                 break;
77         }
78         System.out.printf("Calculate: %s %s %s = %s\n",
79                 getValue1(),
80                 getOperand(),
81                 getValue2(),
82                 getResult());
83 
84     }
85 
86     @PostConstruct
87     public void postConstruct() {
88         System.out.println("postConstruct");
89         operand = '+';
90         value1 = 0;
91         value2 = 0;
92         result = "n/a";
93     }
94 }
95 
96 

With the ManagedBean taken care of, the next step was to create the JSF page. With JSF 2.0, it now uses Facelets as the default view technology instead of JSP. This means there are lots of things that are able to be expressed more naturally in the view layer, which were previously difficult or cumbersome in the older JSP model.

A really useful thing I found in facelets was the ability to render a ManagedBean property directly in the page, without needing to surround it with other tag library calls.

So to create my calculator screen, I simply added a couple of fields, and wired them into the CalculatorManagedBean that I'd developed. Again, following convention over configuration, the default name for a ManagedBean is a lower case version of the classname, which makes them easy to remember/lookup from a project hierachy (as opposed to hunting through XML). Of course NetBeans makes this easy since it has code-insight which presents the names of known ManagedBeans and their available properties for insertion via a few keystrokes.

The list of operands values shown in the select list are populated from a property on the ManagedBean which returns an array of char.

The "=" button is wired into the calculate operation, which takes its current property values, performs the desired operation and sets the result property, which is then displayed in the result field on the page.

 1 <?xml version='1.0' encoding='UTF-8' ?>
 2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 3 <html xmlns="http://www.w3.org/1999/xhtml"
 4       xmlns:f="http://java.sun.com/jsf/core"
 5       xmlns:h="http://java.sun.com/jsf/html">
 6     <h:head>
 7         <title>Calculator Facelet</title>
 8     </h:head>
 9     <h:body>
10         <h:column><h3 style="font-family: arial; font-variant: small-caps; color: #336699">Calculator</h3></h:column>
11         <h:form>
12             <h:panelGrid columns="1" style="text-align: center; border: 1px solid #336699; padding: 5px; ">
13             <h:column>
14                 <h:inputText id="value1" value="#{calculatorManagedBean.value1}" 
15                              size="5" maxlength="5" style="text-align: right;"/>
16             </h:column>
17             <h:column>
18                 <h:inputText id="value2" value="#{calculatorManagedBean.value2}" 
19                              size="5" maxlength="5" style="text-align: right"/>
20             </h:column>
21             <h:panelGrid columns="2">
22                 <h:column >
23                     <h:selectOneMenu id="operand" value="#{calculatorManagedBean.operand}" 
24                                      style="text-align: center;">
25                         <f:selectItems value="#{calculatorManagedBean.operands}"/>
26                     </h:selectOneMenu>
27                 </h:column>
28                 <h:column><h:commandButton value="=" action="#{calculatorManagedBean.calculate}"/></h:column>
29             </h:panelGrid>
30             <h:column>
31                 <h:inputText id="result" value="#{calculatorManagedBean.result}" 
32                              readonly="true" size="5" style="font-weight: bold; text-align: right"/>
33             </h:column>
34         </h:panelGrid>
35         </h:form>
36     </h:body>
37 </html>
38 
39 
40 

Put it all together and run using the local GlassFish instance, the page works and looks like this.

So there it is, a JSF 2.0 version of my old habit up and running in a few minutes. I like what I've seen with JSF 2.0 so far.

Of course, the use of @ManagedBean annotation in JSF 2.0 may be dead already with the arrival of CDI in Java EE 6 and its @Named annotation, but that's not an issue I'm going to explore here.