Grails - A RAD framework

During my quest to learn a new framework I stumbled upon Grails. I have heard about it very often but actually never dared to dive into it thinking that it might be yet another scripting framework like Ruby. But I was wrong and I must admit that I was mesmerized by what I saw (read it as "with What I achieved") in Grails. On the homepage of grails it says "the search is over", its a bold statement to make, but quite frankly it will make you feel like it when you start discovering its power. 


It is actually what Java should have been if it would have been written in 21st Century. The ease with which it helps you handle MVC architecture is great but what is amazing is the ease with which it handles CRUD operations and performs things with "convention over configuration" approach.


Long back I was wondering when a programming language be written which can understand plain simple English and performs the tasks. Grails does it and does it pretty good, no wonder it has developed so many followers. I mean who would not want to get away from reinventing the wheel all the time and just concentrate on building some lean mean applications.


The Grails community is also shaping up pretty well with so many plugins supported each day, I can only assume that this is the next generation framework. Do check back after some time as I will be publishing my first hand experience on Grails very soon.

Unit Test Helper

Working on JUnit is fun and great but always remember a golden rule "Never change a good design just to make it accessable/runnable by JUnit". Let me elaborate on this statement to tell you what exactly I meant. In our code we write data access layer, which creates connections and execute sql.

Specially in Web Application, connections are often managed inside container and are accessed by our code using JNDI. This is one of the industry best practices. Problem is how to test that code outside the Container. How to make that code JUnit accessible.

Normally we might make some changes in our code in order to make JUnit run outside container, DON'T. With the above statement I meant these kind of changes specially. But the question is what is the solution for this situation. Should you leave that code untested? No, you can still test that code. And I am not going to talk about any new testing methodology either. You can test the same code with simple JUnit.

This is made possible a small helper jar called JRUnitTestHelper from Java Ranch. This junit utility helps create JNDI based datasources and connections at the run time to assist junit test the code efficiently.

Using this jar is very very simple, put this jar in your classpath while running your junit test and call these two lines

if(JNDIUnitTestHelper.notInitialized()){

JNDIUnitTestHelper.init("jndi_unit_test_helper.properties");

}

And of course please mention your connection details like IP, port, username etc in this "jndi_unit_test_helper.properties" properties file. Please feel free to shoot me emails if you have any questions.

The jar for this program can be downloaded from JavaRanch.

JMX

UNDERSTANDING JMX TECHNOLOGY

Java Management Extensions (JMX) technology offers programmers the ability to add monitoring and management to their Java applications. In effect, these APIs allow you to locally or remotely manage anything Java-enabled, from web servers to network devices to web phones. JMX technology is defined by two closely related specifications developed through the Java Community Process (JCP): Java Specification Request (JSR) 3: Java Management Extensions (JMX) Specification and JSR 160: Java Management Extensions (JMX) Remote API 1.0. This tech tip introduces you to the JMX architecture, and shows you how to create a simple Managed Bean.

With JMX technology, an application, device, or service on one machine (called a resource), can be controlled remotely through the use of one or more custom JavaBean objects known as Managed Beans (MBeans). These MBeans are then registered in a core-managed object server (an MBean server). The MBean server acts as a management agent to any remote managers that want to access the resource.

The JMX Environment

The JMX specification defines an architecture in three distinct tiers. The first two levels shown are the instrumentation and agent tiers, which are defined by JSR 3:

Instrumentation Tier: Resources, such as applications, devices, or services, are instrumented using Java objects called Managed Beans (MBeans). MBeans expose their management interfaces, composed of attributes and operations, through a JMX agent for remote management and monitoring.

Agent Tier: The main component of a JMX agent is the MBean server. This is a core managed object server in which MBeans are registered. A JMX agent also includes a set of services for handling MBeans. JMX agents directly control resources and make them available for management. The remote management level, the third tier, is partly defined by JSR 160:

Remote Management Tier: This tier defines protocol adaptors and connectors that make a JMX agent accessible from remote management applications outside the agent's Java Virtual Machine (JVM)*. (Note that JSR 160 defines connectors only.) Connectors are used when the remote client is JMX-aware, and sees the same JMX API as a local client would. Adaptors are used when the remote client is using a generic management protocol such as Simple Network Management Protocol (SNMP) or Common Information Model and Web Based Enterprise Management (CIM/WBEM).

There are generally three types of developers who use JMX, although one person might exercise all three roles:A developer that writes MBeans to manage resources. Here, JMX technology defines the interfaces exposed for management.

The developer is responsible for the "glue" between the MBean and the resource itself.A developer that creates and deploys the agent. This person typically performs a number of tasks, including:Creating an MBean server, or using the one supplied by the platform.Registering the MBeans that represent the resources using MBean naming conventions.Configuring the connectors and protocol adaptors supplied by the platform (RMI and SNMP), or adding custom connectors or adaptors if the resources are to be accessed remotely.

A developer that writes the remote manager. This person chooses the connector or protocol adaptors to interact with the JMX agent, and builds views of the resources managed remotely through the exposed MBeans. There are four types of MBeans, as defined by the JMX specification:Standard MBeans: Standard MBeans are management interfaces that are described by their method names. The methods are then exposed through introspection of the interface. Standard MBeans are the most common type of MBean. Most developers do not need to create any other MBean types.

Dynamic MBeans: A dynamic MBean implements its management interface programmatically with the javax.management. DynamicMBean interface, instead of through introspection of method names. To do this, it relies on informational classes that represent the attributes and operations exposed for management. Dynamic MBeans are often used when the management interface of an MBean is not known at compile time -- for example, if it is determined by parsing an XML file.

Model MBeans: A model MBean is a generic, configurable MBean that applications can use to instrument any resource dynamically. Essentially, it is a dynamic MBean that has been implemented so that its management interface and its actual resource can be set programmatically. This enables any manager connected to a Java dynamic management agent to instantiate and configure a model MBean dynamically.

Open MBean: Open MBeans are dynamic MBeans, with specific constraints on their data types, that allow management applications and their human administrators to understand and use new managed objects as they are discovered at runtime. Open MBeans provide a flexible means of instrumenting resources that need to be open to a wide range of applications compliant with the Java Management Extensions (JMX) specification.

The typical process used in creating a JMX-compliant management interface involves at least two steps. The first step is to create an MBean interface, as well as an agent to register that MBean with the MBean server. The next step is to manage the MBean using a remote management application. The JMX specification defines a standard set of connectors that allow you to access JMX agents from remote management applications.

This is useful because JMX connectors using different protocols provide the same management interface. This enables a management application to manage resources transparently, regardless of the communication protocol used. JMX agents can also be used by systems or applications that are not compliant with the JMX specification, but which support JMX agents.