The two 5-minute screencasts focus on more clustering (ssh-based) features and websockets support (Grizzly-powered).

Please click here for more information about these screencasts.

Recently I already posted a bog about this subject, only it wasn’t sufficient enough. So below the exact steps you have to follow to change your admin password in an glasfish cluster environment.

Log in on the admin console, click on domain > Administrator Password, and put in a new password. Click on save. The password is immediatly changes. This does the same as “asadmin update-file-user –authrealmname admin-realm admin” commando, except the update-file-user expects that there is an other user. Default there is only the admin user. Both actions change the keyfile in $GLASSFISH_HOME/domains/domain1/config. I perfer the change password through the console, since I don’t have a second admin user.

next we have to change the .asadminpassword file in the user home. Start asadmin and enter the following commands:

[glassfish@YSGF01 ~]$ asadmin
Use "exit" to exit and "help" for online help.
asadmin> change-admin-password
Please enter the old admin password> [new password]
Please enter the new admin password> [new password]
Please enter the new admin password again> [new password]
Updated .asadminpass file with new password.
Command change-admin-password executed successfully.

Next we have to make sure the the node-agent are aware of the changed password.

asadmin> stop-node-agent nadev01-yenlo
Command stop-node-agent executed successfully.
asadmin> start-node-agent --startinstances=false nadev01-yenlo
Please enter the admin user name>admin
Please enter the admin password>
Redirecting output to /u00/oracle/product/2.2/glassfishesb/glassfish/nodeagents/nadev01-yenlo/agent/logs/server.log
Redirecting application output to /u00/oracle/product/2.2/glassfishesb/glassfish/nodeagents/nadev01-yenlo/agent/logs/server.log
Command start-node-agent executed successfully.
asadmin> list-instances
indev01-yenlo not running
indev02-yenlo running
Command list-instances executed successfully.
asadmin> start-instance indev01-yenlo
Command start-instance executed successfully.

Log in on every node of the cluster, stop the node agent, then start it again without starting the instance on it (–startinstances=false). Then start the instances on it. On this way you can change your password without any down time.

Assume we have a webservice. The first thing to do is to get a copy of the WSDL file of the service. Then inside Netbeans:

Select “File system” and click “Next >”. Locate the WSDL, and accept all default settings by clicking through the whole wizzard. The result:

Implementation

Next, create a new Collaboration Definition (JCD) inside the project. We want to initialize the JCD with a Queue message. So the input will be a JMS operation. For the output parameter look up the newly imported WSDL definition.

After creating the JCD, open it and look for the WSDL definition inside the mapping editor. Look for the PortType node. Rightclick the node :

Next an object browser window opens :

If the service needs input, we first have to fill all input objects, and after that call the invoke() like this (inside the code view):

Configuration

Create an environment inside the services tab of Netbeans with a logical host for catching message queue’s, and pointing to the right integration server. For calling the webservice we create an extra ‘SOAP / HTTP Webservice external system’.

Rightclick on the external system icon for the service, and click the ‘configuration’ menu:

It is also possible to store all above configuration data inside LDAP, and fill ldap://…. references inside the external engine configuration. After finishing the environment, create a connectivity map, drag and drop the JCD inside. Generate the mappings. Create a deployment profile and build the system.

Go to the Glassfish admin console. Look for the ESB node at the side menu

Now configure the connection settings.

Now ESB knows where to find LDAP.

JCAPS 6 uses the JBI runtime environment of OpenESB, which runs on Glassfish.
On the other side JCAPS 6 also uses design time tools inside Netbeans.
All JCaps projects are managed inside a JCaps repository. Netbeans gives support
regarding the JCaps repository and Service environments, where all the integration magic happens.

OpenESB is the umbrella project that takes the core runtime in Glassfish, the design time tooling in Netbeans, and many of the JBI components from OpenJBI and packages them into a single installer which you’re able to download.

First let’s map out the differences between OpenESB and CAPS 6

OpenESB	JCAPS 6
JBI runtime	JBI runtime and JCAPS 5.1 runtime
Glassfish v2 AS	Glassfish v2 Enterprise AS
Full collection of OpenESB components	Selection of OpenESB components
Netbeans 6 tooling	Netbeans 6.1 tooling and enterprise designer components

Glassfish v2 Enterprise AS has extra admin monitoring abilities plus user persistance storage capabilities for high availability.

In CAPS 5 applications were deployed to an integration server (IS). Connectivity information was embedded in repository-based EAR files. There was no connectivity information in the IS. Any change in configuration required a regeneration of the EAR file. A workaround was to use LDAP. However LDAP connectivity information is stored in the EAR file, which means that when the LDAP server is changed, the EAR file must be regenerated.

In CAPS 6 applications are deployed on Glassfish. CAPS 6 includes a new concept called Environment Objects, which represents connection information to an external system. This info is stored in the AS, where it is serialized in the domain.xml. When the EAR is deployed on the AS, environment configuration is overriden with the info stored inside the Environment Objects. You are able to use environment objects in combination with environment variables stored inside LDAP. (OpenDS for instance)

Every administrator will be facing the fact that he must change his passwords. Below a sort discripting how to do it on Glassfish Application Server

Admin password:

$ asadmin change-admin-password
Please enter the old admin password>
Please enter the new admin password>
Please enter the new admin password again>
Updated .asadminpass file with new password.
Command change-admin-password executed successfully.

Master Password:

First stop de Domain Administration Server

$ asadmin stop-domain domain1
$ asadmin change-master-password domain1
Please enter the new master password>
Please enter the new master password again>
Master password changed for domain domain1

If you are using a password file, don’t forget to change your passwords there as well.

Update:

Unfortunately  The above steps are not enough when you are running a mutli node or enterprise glassfish environment. When you change the admin password, all the nodes have to be aware of the new password.
For more information regarding the password change in a multi node or enterprise environment see: http://wiki.glassfish.java.net/attach/GlassFishAdministrationPages/admincreds.html#changing

Inside the IDE we have the menu Tools –> Java Platforms. Here we can assign more JDK locations. But we can’t assign a default JDK. There is no interface button for this.

The way to assign a default JDK is to go to the Netbeans install location {root}/netbeans/etc and edit the file netbeans.conf.

# (see http://wiki.netbeans.org/wiki/view/FaqGCPauses)

# Default location of JDK, can be overridden by using –jdkhome :
netbeans_jdkhome=”D:\jdk1.6.0_10″

# Additional module clusters, using ${path.separator} (‘;’ on Windows or ‘:’ on Unix):
#netbeans_extraclusters=”/absolute/path/to/cluster1:/absolute/path/to/cluster2″
netbeans_default_userdir=d:/JavaCAPS62/.netbeans/caps
#netbeans_jdkhome=D:/jdk1.6.0_20

I’ve commented out the first bold line and filled the reference to the new default location, and commented the old default location. Restarting Netbeans will run the new settings.

Say we have a web service using JAX-WS on Glassfish v2.1, and we have an operation using a XMLGregorianCalendar type. When this operation is called, an exception can be thrown:

java.lang.ClassNotFoundException: org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl

In the {glassfish install map}/lib location we have a launcher.xml and a launcher.properties file. Inside the XML there is a reference

assuming Xerces is already available inside the server shared libraries map. By installing Xerces the exception problem is solved.

Unfortunately Netbeans 6.8 lost the availability for the SOA plugin (and the UML plugin ).
To get these plug-ins back just follow these steps as they are still available in the update center of the 6.8M1version of Netbeans. 

1. Go to ”Plugins” dialog:  ”Tools” >”Plugins”
2. Go to “Settings” tab
3. Add a new update center:
- Name: NetBeans plugins 6.8M1
- URL: http://updates.netbeans.org/netbeans/updates/6.8/uc/m1/dev/catalog.xml.gz 
4. Go to “Available plugins” tab

These plugins are not certified for the final Netbeans 6.8 version and perhaps not the best option for production platform.

Because we needed the SOA – ‘database binding’ and because it still wasn’t available in the 6.8M1 plugin we choose to stick to Netbeans 6.7.1 instead.

In my current project I have set up a continuous integration environment consisting of Subversion, Maven, Nexus and Hudson and four servers (development, test, acceptance and production). The idea is to take away as much developer responsibilities concerning library and version management as possible, as well as facilitating an error prone mechanism to test and roll out your applications. One of the pitfalls I encountered was the lack of Maven support in NetBeans 6.7(.1) for JBI Modules and CASA projects. This article outlines the steps I took to be able to build and deploy Composite Applications to GlassFish/OpenESB v2 using Hudson. Read more