organic thoughts

Google Buys On2. JavaFX Gains?

2009-08-05T16:42:00.000-04:00

When Google purchased YouTube back in 2006, the Flash video (FLV) format got an astronomical boots almost overnight. The media format became even more popular, the Flash/Flex pair gained notoriety as a viable platform, Adobe fortified its arsenals in the battle for media dominance. This single act shadowed other players such as Real, Microsoft, and to a certain extent Apple's QuickTime (when was the last time you embedded a Microsoft Media Player on your website).

Today (in TechChruch), it was announced that Google is purchasing On2, the media compression technology company behind many of the most popular media codecs including FLV. This has the potential to change the course of online video technologies once again. One can only imagine some of the implications this purchase will have

It moves Google higher in the media compression food chain and gives it complete control of the most popular codecs used on the web.
Google may open source the current proprietary VP6 (on which Flash video is based) & VP7 codec formats that On2 licenses to companies. They may decide to provide needed support for the Ogg Theora format and make it first class citizen in the compression stack.
With Google's push of HTML5 which includes the notion of built-in video/audio support, one can rightly guess that we will see On2 technologies in Chrome Browser, Chrome OS, and Android and anywhere else Google control (which is wide and far).
As Ogg (Vorbis and Theora) becomes the open source format of choice for media delivery, Google will wield its influence on the format and direction of media deliver on the web.

Why am I rambling about On2, Ogg, and video codec formats? Well, it all has to do with JavaFX. One of the selling point of JavaFX is portable playback of Video/Audio basedon VP6 (consequently FLV). With the purchase of On2, Google will have a direct control of the destiny of media codec supported by JavaFX. Depending on how Google proceeds, we, in the Java community, may see positive developments for JavaFX and this is how:

Google open sources the On2 codec stack: big win for JavaFX (to a certain extent Adobe). This will imply that JavaFX applications can take part in the online media revolution with lowered entry points.We probably will see Java bindings to the codec's API's which means building both encoders and players in Java/JavaFX.
If the stack is open source, this may also mean eventual support on JavaFX mobile platforms.
Google may make On2 encoding tools available for free: another win for JavaFX! More videos being created with the supported On2 formats means more opportunities for JavaFX developers to create players.

Or, Google may decide to just sit on the technologies use them to further their ambitions in Mobile, desktop OS, and web markets. Only time will tell.

NetBeans 6.7.1 + Mac OS = Sweetness

2009-07-30T13:18:00.002-04:00

I just updated my netbeans to 6.7.x on the Mac and the difference is vivid.
Even faster start time
Snappier GUI
On the Mac, the new look makes it look native
Plus all the other goodies (Groovy, JavaFX, etc)

Introducing JmxLogger - Real-time Application Log Monitoring with JMX

2009-04-12T04:21:00.005-04:00

For past month, I have been working (on/off) on JmxLogger, a logging API which lets you monitor your Java Logging or Log4J application log events in real-time using JMX. I have had the idea for a while, but decided to finally capture it as project. So, here it is.

http://code.google.com/p/jmx-logger/

JmxLogger
JmxLogger makes it easy to broadcast your Java Logging or your Log4J log events as JMX notifications. As such, you can easily monitor your application's activity logs in real-time. Using familiar logging API and configuration mechanism (i.e. log4j.xml or Java Logging properties file), developers can quickly integrate realtime application log monitoring into their existing deployed code. All it takes is a logging configuration change.

The JmxLogger API provides a Java Logging Handler and a Log4J Appender which can be used to integrate between your favorite logging framework and JMX. JmxLogger hides the complexity of dealing with JMX. You simply configure your logging framework as you normally do, and that's it. You are ready to broadcast your logging events as JMX notification events.

Features

Support for Java Util Logging API
Support for the Log4J logging API
Easy integration with your favorite logging framework
No coding required, simply configure your logging framework to get started.
Specify and control the level of event to broadcast
Monitor event through a console or listener scripts
Realtime monitoring of your application activity logging via JMX.

Getting Started

Download the jar (generic or with log4j support)
Add jar to your classpath (in case of Log4J, you will need log4j.jar on your classpath)
Configure your favorite logging framework
Use JMX console (JConsole or VisualVM) to monitor your log actvities.

JmxLogger Events

When you log your application events using either Java Logging or Log4J (see project site for more detail), your log events will get routed to the JmxLogger Java Logging Handler or Log4J Appender defined in your application's logging configuration file.

Below you can see a configuration that sends log messages to the Console and a JmxLogger Logging Handler.

Using a command-line Console you can see your log message messages as they are logged in your application.

The same log events are also emitted as JMX notifications. Using JConsole, you can see these events as they are logged in your application in real-time.

That's it! You have seen how JmxLogger can effortlessly integrate JMX and the two standard logging API's available (Java Logging and Log4J).

Why Modularity Matters

2009-03-30T15:12:00.000-04:00

In my previous blog, I provided a summarized view of what OSGi is and how it impacts Java developers. I got some interesting feedback. So, in this blog entry, I want to take a detour to examine modularity itself and its importance in creating robust systems that can scale in size and functionality. This blog post does not discuss any specific Java technologies or platform directly. However, it looks at how modular design has affected industries as diverse as manufacturing to software engineering. Future posts will continue to look at OSGi and other modularization technologies.

Modularity
In the Merriam-Webster dictionary, being modular is defined as "... composed of standardized, self-contained units for easy construction and flexible use ..." The notion of modularity is universal and has found usage in process (policy), manufacturing, business, finance, engineering, etc. Those who study the natural sciences have presented arguments about the modularity of nature. Biological studies have shown that the evolution of complex organisms are due in part to functional modularity (composition of smaller independent components with clear bound & functions) and behavioral modularity (having traits and attributes that can evolve independently). To stay closer to the discernible realms, let's examine how contemporary usage of modularity and has affected our modern lives.

Product manufacturers figured out the way to increase output, increase quality, and reduce cost pressures was in modularity. At the turn of last century, industrialist Henry Ford introduced the notion of modularity in his assembly line with standardized and interchangeable automobile parts. He was able to reduce his production cycles and costs to achieve mass production of his Model-T automobiles.

The adoption of modular architecture, not processor speed, has been argued to be the quintessential force behind rapid growth and adoption of computing technologies. Today's hardware, while ever decreasing in size, offers cheap information processing power that has permeated through all industries. Achieving such complex and powerful systems has been possible through the use of modularity. Manufacturers independently create standardized, interchangeable subsystems (microprocessor, memory chips, input/output devices, etc) that can function together to create complex devices. They have been able to build systems with high level of complexity by combining hardware modules (subsystems) into innumerable configurations.

In term of longevity, Unix is arguably one of the most successful operating system today. Created in 1969, Unix has been used in all conceivable computing environment from small embedded to research class supercomputers and everything in between. Unix's success is attributed to its flexibility and depth made possible by its simple, clean, and orthogonal design. As complex an operating system as Unix is, it is composed of simple, distinct, interacting modules (small programs) with clean interfaces that do one thing and does it well (and nothing more).

In the world of Java, there are numerous examples of successful modular designs. One of the earliest and most popular was the JBoss application server. The JBoss designers realized early on the power of modularity. They were one of the first to build a modular architecture on the top of the JMX (though JMX was designed for management, not a general purpose lightweight component server, its standardized API provided the tools needed to build a modular systems). Other examples of well-known, successful modular systems include the Eclipse and the NetBeans desktop platforms. Both frameworks let developers build complex desktop applications (including IDE's) using small pluggable modules that interact at runtime.

Modularity in Software
So, the question remains: how does one develop modular code? In disciplines such as engineering and manufacturing, for example, there is a natural affinity to design modularity along the physical attributes of materials. In software development, however, there are little or no affordances to provide guidance to shape code into standardized modules. As such, developers tend to take the path of least resistance and write software systems organically (i.e. monolithic) where the code produced has little or no clear boundaries. The next few paragraphs review provide some points on creating modular software. If you already create your software as modules great, otherwise, you can use the following text as guidelines for your next projects.

Logical Modularity
Generally in software, modularity can be categorized as logical or physical. Logical Modularity is associated with the internal organization of code into logically-related units. In modern high level languages, logical modularity usually starts with the class, the smallest code group that can be defined. In languages such as Java and C#, classes can be further aggregated into packages (namespace in C#) which allows developers to organize code into group of related classes (languages such as Ruby, Scala, Smalltak, Java7 support similar organizational structure with additional semantics for managed components) .

In the Art of Unix Programming, author Eric S. Raymond provides an iconic rule for modularity that states "... write simple parts connected by clean interfaces." Depending on the context, a module can be implemented as a single class, several classes in a package, or an entire API (a collection of packages). Regardless of the implementation scale of your module, you should be able to describe its functionality in a single sentence (i.e. this module calculates tax per zip code). Your module should expose its functionality as simple interfaces that shield callers from all implementation details. The functionality of a module should be accessible through a published interface that allows the module to expose its functionalities to the outside world while hiding its implementation details (it is way beyond the scope of this blog entry to provide a comprehensive treatments of design patterns and rules for modularity in software).

Physical Modularity
Physical Modularity, is probably the earliest form of modularity introduced in software creation. Physical modularity is comprised of two main components 1) a file that contains compiled code and other resources 2) an executing environment that understand how to execute the file. Developers build and assemble their modules into compiled assets that can be distributed as single or multiple files. In Java for instance, the jar file is the unit of physical modularity for code distribution (.Net has the assembly). The file and its associated meta data is designed to be loaded and executed by the run time environment that understands how run the compiled code.

Physical modularity can also be affected by the context and scale of abstraction. Within Java, for instance, the developer community has created and adopted several physical modularity strategies to address different aspects of enterprise development 1) WAR for web components 2) EJB for distributed enterprise components 3) EAR for enterprise application components 4) vendor specific modules such as JBoss Service Archive (SAR). These are usually a variation of the JAR file format with special meta data to target the intended runtime environment. The current trend of adoption seems to be pointing to OSGi as a generic physical module format (see previous post). OSGi provides the Java environment with additional functionalties that should allow developers to model their modules to scale from small emddeable to complex enterprise components (a lofty goal in deed).

Why Be Modular?
We have seen numerous disciplines have benefited by adopting modularity in process and development efforts. So, why should you invest time in implementing a modular architecture for your next project? After all, adopting a modular design introduces new overhead such as change in design practices, module files management as project grows, design- and build-time dependency management, and each group working on a module has a narrow knowledge of the code. The following is a list of benefits that you gain that outweigh the headaches you may encounter in modular design.

Scalable Development: a modular design allows a project to be naturally subdivided along the lines of its modules. A developer (or groups of developers) can be assigned a module to implement independently which can produce an asynchronous project flow.
Testable Code Unit: when your code is partition into functionally-related chunks, it facilitates the testing of each module independently. With the proper testing framework, developers can exercise each module (and its constituencies) without having to bring up the entire project.
Build Robust System: in the monolithic software design, as your system grows in complexity so does its propensity to be brittle (changes in one section causes failure in another). Modularity lets you build complex system composed of smaller parts that can be independently managed and maintained. Fixes in one portion of the code does not necessarily affect the entire system.
Easier Modification & Maintenance: post-production system maintenance is another crucial benefit of modular design. Developers have the ability to fix and make non-infrastructural changes to module without affecting other modules. The updated module can independently go through the build and release cycle without the need to re-build and redeploy the entire system.
Functionally Scalable: depending on the level of sophistication of your modular design, it's possible to introduce new functionalities with little or no change to existing modules. This allows your software system to scale in functionality without becoming brittle and a burden on developers.

Conclusion
In this post, I wanted to provide a broad overview of modularity as a concept and its effect on software system. We have seen how modularity is intrinsically entrenched in non-computing disciplines and how they all benefit from the practice. Software is no different, complex systems from desktop applications to enterprise behemoth such as application servers benefit from modularity in design. It is not the intent of this entry to insinuate that modular design means an end to buggy code. On the contrary, developers will always write buggy code as long there's code to be written. However, it is the intent of this entry to show that modularity is a step toward making software development, deployment, and management easier to scale and maintain.

References
1. Merriam-Webster, http://www.merriam-webster.com/dictionary/Modular
2. Mark Dodgson, David Gann and Ammon Salter, Think, Play, Do: Innovation, Technology, and Organization
4. Carliss Young Baldwin and Kim B. Clark, Design Rules: the Power of Modularity
4. Werner Callebaut, Diego Rasskin-Gutman, Herbert A. Simon, Modularity: understanding the development and evolution of natural complex systems
5. Eric S. Raymond, The Art of Unix Programming, 1999
6. Mark Fleury, Juha Lindfors, Enabling Component Architectures with JMX, http://www.onjava.com/pub/a/onjava/2001/02/01/jmx.html, 2001
7. P. Jalote, An Integrated Approach to Software Engineering, 1997
8. Tim Boudreau, Jaroslav Tulach, Geertjan Wielenga Rich Client Programming: Plugin into the NetBeans Platform

Java Modularity with OSGi (1)

2009-03-08T11:20:00.002-04:00

I am excited: the notion of modularity is once again taking center stage in Java land.

All technology platforms (OS's, languages, applications, etc) eventually face the struggle of providing an adequate level of abstraction to encapsulate modular code unit. On the MS Windows platform, for instance, there is myriad of technologies including VCL, VBX, OCX, ActiveX, COM, DLL, etc, that emerged over the years designed to provide modular, sharable, and distributable code units for specific domains.

On the Java platform, the story is similar. From the beginning, the JAR file format provided the means to physically package Java code and resources as modules. The file format has served its original purpose well giving the means to distribute and reuse the large number of Java API's that is available today. However, while the JAR file format works great for physical modularity, it falls short, however, of supporting a logical component model. (NOTE: vendors have developed their own component models to address their specific needs, for instance SpringSource's Spring Framework, JBoss SAR, Geronimo GBean, JMX MBeans, EJB's, etc).

OSGi
You have probably heard about OSGi and wonder how it fits in the Java landscape. In short, OSGi extends JAR's physical modularity into a logical component model (known as bundle). In OSGi, the bundle can be a living entity that provides services, not a mere container for code API. As such, OSGi affords system developers the following capabilities:

A Framework: This is an execution environment for bundles at run-time. Bundles are loaded, executed, and managed (see OSGi Frameworks below).
Service Registry: OSGi provides a container where bundles are deployed and can expose services to other registered bundles.
Life-cycle Services and Events: Allows addition, removal, and update of bundles dynamically at run-time. The framework publish lifecycle events as notifications that can be captured for appropriate reactions.
Service Model: Ability to expose and discover service interfaces at run-time.
Bundle Isolation: OSGi adheres to strict isolation rules. Each bundle gets its own class loader. Visibility of a bundle is specified at the package level, not class. A Bundles can export its internal packages or indicate its dependency on existing packages hosted by other bundles running in the framework.
Version Dependency: Expressive and flexible bundle versioning semantics with automatic dependency resolution.
Multi-version Coexistence: Multiple versions of same bundle can co-exists without any shadowing effect. Client A can have a dependency on bundle X.1 while client B has a dependency on a different version of bundle X.2 with no risks of class path collisions (commonly known as Jar Hell).
Dynamic Availability: part of OSGi's component model is the notion of bundle dynamic availability. A bundle is not guaranteed to be available. This is good because you can remove/reload/restart a bundle at runt time (without restarting the framework). This is not so good because your bundle has to have mechanism to handle dynamic availability of bundles it depends on.

The OSGi Bundle
Because OSGi was designed (from the ground up) to be a component-based platform, an OSGi application is a collection of interacting bundles running within the framework. As stated earlier, an OSGi bundle is based on the traditional JAR file. However, OSGi uses special meta-data in the META-INF/MANIFEST.MF file of the bundle to specify configuration information used by the OSGi framework at runtime. Below is an example of a MANIFES.MF file for a bundle

Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.services.demo
Bundle-Version: 1.0.0
Bundle-Activator: com.services.Activator
Bundle-ClassPath: .,com/services/api.jar
Import-Package:
com.other.services; version=“[1.0.0,2.0.0)”;
Export-Package:
com.services.sei; version=1.1;

Some important items to notice in the manifest meta data:

Bundle-Activator: specifies a class that will react to bundle life-cycle events (when the bundle starts and when the bundle stops). You can use this event as a starting point for functionalities implemented by your bundle (sort of a main() for your OSGi application).
Bundle-ClassPath: establishes a classpath for your bundle's internal library of classes (and jar files).
Import-Package: this entry specifies the name of a package that the bundle depends on (and expected to be available on the platform). Notice the version directive specified in the Import-Package declaration. It uses an interval notation to express dependency on versions 1.0.0 <= X < 2.0.0
Export-Package: declares a package in the bundle that should be made available at runtime. When the bundle is installed in a framework, package will be visible to other installed packages running.

OSGi Frameworks
You may be wondering where/how do I run an OSGi bundle? You will need a framework. A framework is an implementation of the OSGi service platform specifications that has the ability to execute bundles. The framework itself is a small core with system level logic to load bundles. All of the framework's functionalities come from installed bundles on the framework. There are several framework implementations available today, the three most popular (and open source) are:

Apache Felix - A small embeddable, developer friendly port of OSGi service platform. It's the basis for many popular projects including Glassfish and JOnAS App Servers.
Eclipse Equinox - This is the base for Eclipse IDE (which a collection of bundles known as plugins in Eclipse parlance). It's used in many popular products such as SpringSource DM Server and IBM's WebSphere.
Knopflerfish - Knopflerfish is one of the earliest implementations from the commercial side (gone open source) with presence in automotive, telecom, and home automation.

Why Should I Care?
You will certainly wonder how OSGi impacts you. Well, if you spend most of your day writing enterprise applications, then OSGi will mean little to you. As a matter of fact, vendors are working hard to keep developers away from OSGi-specific concerns. You will continue to use enterprise semantics that you are already familiar with and produce enterprise artifacts (EJB, WAR, EAR, etc) that you produce today. Life is good, keep coding!

However, if you are system level developer or simply interested in component-based development, OSGi may be of great value. Already, many vendors are decomposing their products into OSGi-ready jars to allow developers easy deployment on OSGi runtimes. There's also a movement of porting commonly used API's to OSGi by creating a bundle repository (i.e. Felix Commons and Equinox Orbit).

Another approach to OSGi integartion is to embed an OSGi framwork into your own development to create a component model. Eclipse has become the posterchild for this approach using OSGi to provide a plugin architecture for the IDE. Felix, however, has become the favorite embeddable OSGi framework because of its relative small size, easy licensing, and easy API. One great example of embedded Felix is the SIP-Communicator desktop application which uses OSGi-bundles as plugins to extend the application (I am sure there are others).

Conclusion
I hope this entry got you, at least, interested in OSGi. I think OSGi is a great start toward a unified component model for Java. It will certainly get developers to (hopefully) start viewing their systems in terms of components and not just classes. In future posts, I will look at how to use OSGi practically and integrate into your development efforts.

Even if you don't plan to adopt OSGi right away, at least check it out .

References
About OSGi - http://en.wikipedia.org/wiki/OSGi
OSGi Alliance – http://osgi.org/
OSGi Articles - http://www.osgi.org/Links/HomePage
OSGi on InfoQ - http://www.infoq.com/osgi
Free OSGi Book By Neil Barlertt (PDF) - http://neilbartlett.name/downloads/osgibook_preview_20090110.pdf
EclipseCon Presentation by Richard S. Hall (PDF) - http://felix.apache.org/site/presentations.data/osgiapachecon-2005121…
Eclipse Equinox - http://www.eclipse.org/equinox/
Apache Felix - http://felix.apache.org/
Knopflerfish - http://www.knopflerfish.org/
SpringSource OSGi - http://www.springsource.org/osgi
Sip-Communicator Presenation - http://archive.fosdem.org/2007/slides/lightningtalks/SIPcommunicator.pdf

JmxBuilder Finds New Home

2008-12-22T14:28:00.003-05:00

JmxBuilder has been officially incorporated in Groovy for the 1.6 RC-1 release. I am delighted that the Groovy team thought highly of JmxBuilder to make it an addition to the language. JmxBuilder will have much more features in 2009. Special thanks to Guillame Laforge and the rest of the Groovy team for all their help in integrating the two projects.

Because of this change, JmxBuilder will be moved from its current Google code location once everything is migrated to codehaus.

JmxBuilder (Groovy DSL for JMX) Released

2008-12-14T10:34:00.003-05:00

JmxBuilder 0.5 (beta) has been released. After some constructive feedback (see previous post about JmxBuilder in April on Dzone), I redesigned the DSL to be more robust, compact, and added new features to help export and programmatically manage MBeans at runtime. The new features focus on building JMX agents, Jmx clients, and participate in the JMX event model. So, here it is:

Full description at http://code.google.com/p/groovy-jmx-builder/

JmxBuilder is a Groovy-based domain specific language for the Java Management Extension (JMX) API. It uses the builder pattern to create an internal DSL that facilitates the exposure of Java and Groovy beans for runtime control and management via the MBean server.The Groovy JMX Builder DSL hides the complexity of creating and exporting management beans via the JMX API and provides a set of natural constructs to interact with the JMX infrastructure.

Features

Domain Specific Language (DSL) for JMX API using Builder pattern
Simplified JMX API's programmability
Maintain the natural Groovy syntax
Declaratively expose Java/Groovy objects as JMX managed MBeans
Support class-embedded or explicit descriptors
Inherent support for JMX's event model
Seamlessly create JMX event broadcasters
Attach event listeners as inline closures
Use Groovy's dynamic nature to easily react to JMX events notifications
Provides a flexible registration policy for MBean
No special interfaces or class path restrictions
Shields developer from complexity of JMX API
Exposes attribute, constructors, operations, parameters, and notifications
Simplifies the creation of connector servers and connector clients
Support for exporting JMX timers

Learn More
Here is where you can get more information about JmxBuilder

Check it out.

JavaFx Is Here! Could Sun Be on the Right Path?

2008-12-04T10:05:00.003-05:00

When I saw JavaFax at last's and this year's at JavaOne, I did walked out of the presentations a bit skeptical "... yeah right, how is Sun's going to compete with the deadly Adobe Flex/Flash combination ... it's marketing gimmic" . Well today (and if you been following JavaFx, for a while) Sun finally made good on its promise of delivering a Rich Media platform by officially releasing the SDK for JavaFx (at http://javafx.com, the site is being slammed, everything is slow now).

I must say that I am less skeptical now and cautiously optimistic on the future of Java as a rich media platform. This could actually work.

Java as viable rich medium
Using JDK 6 update 10 (released earlier) as a base, you now can see how applets are positioning themselves to be a formidable option to the Flex/Flash combo.

1. Applets load gracefully

2. Online streaming videos with Applets
Here is something you have never done/seen before with Java applets. Online videos, cool!

3. Rich Applet
Look at the skinning, the rich interaction options provided by this applet, yes this not flash, it's a Java applet

JavaFx.Com
The site has been redesigned and contains tons of examples and code for you to get started. I have already dowloaded the SDK today and will start playing around with the technology. You may encounter heavy traffic.

I hope that this is just a start and Sun and the Java community continues to support this effort that I think all Java developer will benefit from.

Processing Applets on the new JDK 6 U 10

2008-11-25T17:01:00.005-05:00

I finally downloaded the latest JDK 6 u 10 (download) recently. This is a significant release for the (once again battle front) Desktop. At this year's JavaOne, Sun made it known that it has all intentions of going back to the desktop. Update 10 is one of many shots, that, the hardware-originated organization plans to take at its competitors as it transforms itself (i think) into a media/content company (see Project Hydrazine and JavaFx).

Anyway, after I downloaded update 10, I headed to the one location where I know I will find plenty of applets: http://processing.org/

Processing is an interesting project that started at MIT where Java is used as the center piece for teaching interactive art. It comes with an IDE and its sole purpose is to quickly create compelling visualization interactive Applets. The project has, since, expanded to include a hardware platform (hardware.processing.org) and even a Java ME port (mobile.processing.org). Click above to explore other aspect of processing (go directly to the showcases or links)

Back to the applets. With the latest update, all of the applets that I looked at so far took seconds to render (on my 2 yrs old machine). Once the JRE is loaded, applets rendered in seconds, some near instantaneously. Applets that manage the download process cleverly (with a splash screen or spinning wheel, etc) provides the sort of rich media experiences that you come to expect now a day online.

I won't say that Java applets will dethrone the king of online rich media (rhymes with Flash). But, if these improvements keep up, Adobe will certainly have welcome competition in this arena. This is certainly good news for developers (choice is good) and will be a boon for the end users.

Resources
http://java.sun.com/javase/downloads/index.jsp
http://java.sun.com/javase/6/webnotes/6u10.html
http://processing.org/

Official Groovy/Grails Support in NetBeans 6.5

2008-06-30T13:22:00.002-04:00

Judging from the list of features that will be included in NetBeans 6.5, Groovy and Grails will be officially supported by the NB team. From the wiki text, Groovy and Grails will be first-class citizen in NB65 with features that will include:
- Editor support (code completion, color highlights, etc)
- Two-way Java / Groovy class integration
- Seamless Grail project support (support for all Grails artifacts and commands)
- Jetty integration for development-time deployment/testing.

It remains to be seen if NB65 Groovy support will be as comprehensive as IntelliJ which currently has the most extensive support for Groovy / Grails development.

For more, go to:
http://wiki.netbeans.org/NewAndNoteWorthyMilestone1NB65#section-NewAndNoteWorthyMilestone1NB65-Groovy

JavaOne 2008 - Last Day Notables

2008-05-09T18:19:00.002-04:00

The last day of JavaOne 2008 was heralded by the final General Session where Sun showcased several cool projects. Here are a few you maybe interested in. Some are useful others just plain cool:

1. VisualVM - This is a great (and seems to be indispensable) tool to do VM runtime monitoring and profiling. It runs outside of the an IDE and lets you look deep into the VM and your runninig application at runtime. The profiler is the same that is found in NetBeans and provides a hierarchical navigation and snapshot of all activities of a running application. Check it out at https://visualvm.dev.java.net/.

2. NetBeans 6.1 JavaScript Support - if you do a lot of JavaScript, then the NetBeans is for you. In the demo shown on stage, Netbeans manages to make JavaScript development as well-supported as regular Java. The IDE provides Javadoc-like support, code completion, data structure navigation, on-the-fly documentation, even code hints, etc, etc. While other IDE such as Intellij has had support for JavaScript for a while, this is the first glimpse of it on the NetBeans platform.

3. LiveScribe (http://livescribe.com) - this is not a developer tool, but rather a pen-base computing platform based on the Java Micro Edition. It records pen stroke and voice as you write. Describing it here does not do it justice, but the one demo that caught my attention was a translating demo where the presenter wrote words in one language and the pen automatically translates it into different language...

4. Sentilla, Pervasive Computing Device: Sentilla sells small computing devices meant to be used in sensor networks. Pervasive computing is the notion that everything around us will (some day) have a microchip. Companies such as sells a platform to build and deploy these devices everywhere.

5. JFugue, Music Processing Software - this open source software lets you programmatically build music players in Java. It uses a simple text base language to describe music timing, rythm, notes, sound bank, etc. With the JFugue API, you can create music in several ways including direct notation and pattern inference.

Integrating Spring and JBoss SAR Components

2008-05-08T21:22:00.001-04:00

Integrating Spring and JBoss SAR Components
Last time I wrote about JBoss, it was a discussion on how to create a JBoss service component (SAR). However, in many cases, a SAR component has to be integrated with other component-based technologies. In this article, I will discuss how to accomplish this by integrating the JBoss with the Spring component model and how to expose Spring components to receive management services from within JBoss JMX Console.

Integration
The architecture and implementation of the JBoss service component system differ vastly from the Spring Framework's component model. JBoss (version 4.x and below) implements its internal kernel, for its component container, completely on the Java Management Extension API. As such, when you build a JBoss components, you automatically inherits all the management facilities exposed by JMX. The Spring container, on the other hand, is designed to be a lightweight and portable container and has the ability to host POJO's as components. Therefore, Spring has become the container of choice for many system designers because of its simplicity and portability to be hosted in any environment.

As you can see, integrating Spring in another container requires some sort of adapter that controls how and when the Spring context is created and destroyed. As we will see later in this document, this can be easily accomplished using a few API calls.

Motivation
Why would I want to integrate Spring and JBoss you ask? Well, there is an application domain that is not suited to be implemented as web-based apps. Inevitably, at some point in your career, you will need to implement headless services that expose functionalities without a GUI. These type of services are temporally durable and operate without any human intervention. When creating these types of GUI-less services, you may decide to use the Spring container as your core operating environment for POJO components. Since Spring exposes a uniform abstraction layer for the Enterprise Java API's, it makes sense to code around Spring so that your implementation is portable to any environment that can host enterprise services (JBoss container, ServiceMix, Mule, EJB's, etc). Then, your Spring components can leverage services offered by that enterprise environment (database, timers, messaging, adapters, management, etc).

Integration Points
The portability and programmability of the Spring container makes it an attractive platform for developers to create POJO component-driven apps. For web-based apps, Spring provides ready-made adapters to easily integrate your Spring context within the servlet container. However, for non-web system, Spring does not readily provide specific hooks for integration (this is a good thing, it keeps things simple). On the other hand, the Spring API exposes a simple API that makes programming the integration, of Spring in your environment, a seamless effort.

The picture above shows how Spring integration with the JBoss Application Server can be easily achieved. You create a JBoss service component that serves as an adapter to the Spring container. As the JBoss service object receives lifecycle events from the application server, event-handling logic can be inserted in the adapter to control the creation and management of the Spring context. Once booted and running, the Spring container takes over and mounts its internal POJO components and registers them with the available MBean Server for management.

The Spring Directory Scanner
Extending on the example presented in the previous blog on JBoss components, this example demonstrates how to create a Spring-based directory scanner that gets hosted within the JBoss application container. The previous example, all of the logic of the scanner was implemented directly into the JBoss service component. While there's nothing wrong with that approach, it tightly couples your code with JBoss and make it far less portable. In this version of the scanner, the logic is encapsulated in POJO's hosted within a Spring context.

A JBoss service component serves as a Spring adapter and manages the creation and destruction of the Spring context from within the JBoss container. The spring context is booted up by the JBoss service component through life cycle event hooks from the server. Upon initialization, Spring mounts its POJO's and exposes the Directory Scanner component for runtime management and control through JMX. Using the JConsole or JBoss' Jmx-Console, these components can be managed at runtime locally or remotely.

The Code
The code itself is simple and self explanatory. The JBoss service component responds to JBoss application server's life cycle events. These events are used to manage the creation and management of the Spring context. The Directory Scanner Spring component is driven by a Timer Task object mounted in Spring. Every time the timer expires, it executes the scan() method on the Directory Scanner instance.

The JBoss Service Spring Adapter
The JBoss service component is a a plain Java class with life cycle methods named create, destroy, start, stop. It implements a management interface which exposes these methods for JMX control. The component deployer will automatically execute methods create() then start() upon instantiation of the service component.

 public interface JBossSpringAdapterMBean {
            void create();
            void destroy();
            long getErrorCount();
            long getSpringComponentCount();
            String[] getSpringComponents();
            String getSpringConfigPath();
            boolean isSpringLoaded();
            boolean isStarted();
            void setSpringConfigPath(String path);
            void start() throws Exception;
            void stop();
        }

Besides the life cycle methods, there are other management methods that are added for convenience. For instance, there's a method that returns the error count or one that returns the list components loaded in the spring context.

During the deployment of the JBoss Spring adapter (implemented as JBoss service component), the create(), destroy(), and start() methods of the adapter will be invoked by the JBoss service archive deployer. This provides an opportunity to instantiate and manage the Spring context at key points during the lifetime of the adapter.

Booting Spring
The create() method is called after all the setters are injected with values from the JBoss service descriptor.

public class JBossSpringAdapter implements JBossSpringAdapterMBean {
     private ClassPathXmlApplicationContext spring; 
 
 ...   
 
     public void create(){
              log.info("**** CYCLE: CREATE ****");
              if(!created){
                  try{
                      spring = new ClassPathXmlApplicationContext(springConfigPath);
                      spring.registerShutdownHook();
                      created  = true;
                  }catch(Exception ex){
                      errorCount++;
                      created=false;
                      log.error("Unable to start Spring Context", ex);
                  }
              }
          }
 
      ...

The create() method is used to instantiate the Spring context. In the code snippet, the path to the Spring context is injected during deployment from the deployment descriptor using the setSpringConfigPath() method. The registerShutdownHook() method registers Spring to listens to VM shutdown signal so the context can properly deactivate all of its registered components.

Shutting Down the Context
On the other hand, when your JBoss adapter class receives a shutdown signal (say, the server is shutting down for instance), you wan to have your Spring context gracefully go down as well. By providing a destroy() method, the JBoss deployer invoke that method when the server sends out a shutdown signal.

    public void destroy() {
            log.info("**** CYCLE: DESTROY ****");
            if(created){
                try{
                    stop();
                    if(spring.isActive()){
                        spring.close();
                      &nbsp; spring.destroy();
                        spring = null;
                    }
                    created = false;
                }catch(Throwable ex){
                    log.error(" Failed to destroy component. ", ex);
                }
            }
        }

Controlling the Spring Context
Another desirable aspect of the adapter is the ability to control the Spring context with a start / stop functionality. While it is not a necessary, it affords a runtime convenience where the Spring context can be controlled and managed from a JMX console.

...
      public void start() throws Exception {
          log.info("**** CYCLE: START ****");
          if(!started){
              try{
                  if(!spring.isActive()){
                      spring.refresh();
                      spring.start();
                  }
                  started = true;
                  log.info("**** Spring context started OK.****");
              }catch(Throwable ex){
                  errorCount++;
                  started = false;
                  log.error("**** Failed to start Spring context:", ex);
              }
          }
      }
 
  ...
 
      public void stop() {
          log.info("**** CYCLE: STOP ****");
          if(started){
              try{
                  spring.close();
                  started = false;
              log.info("**** Spring context stopped OK.****");
              }catch(Throwable ex){
                  errorCount++;
                  started = false;
                  log.error("**** Failed to stop Spring context:", ex);
              }
          }
      }
 
  ...

The JBoss Service Component Descriptor
The last part of creating the JBoss Spring Adapter, is to create a JBoss Service Descriptor file (jboss-service.xml). Using this file, you can inject runtime values, and point to a descriptive xmbean descriptor file that is used to export your service archive component as an JMX MBean.

<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="integration.jboss.JBossSpringAdapter"
name="demo.integration:name=JBossSpringAdapter,type=Adapter"
xmbean-dd="META-INF/spring-adapter-xmbean.xml">
<attribute name="SpringConfigPath">/META-INF/spring.xml</attribute>
</mbean>
</server>

For details about creating a JBoss service component and how to format jboss-service.xml and the Xmbean descriptor file, visit the JBoss 4 User Guide.

Deploying the JBoss Spring Service Adapter
Without going into the implementation of the Spring Directory Scanner component, let's see what happens when the JBoss service archive is deployed. We expect the JBoss SAR deployer to recognize our JBoss Spring Adapter component as a valid JBoss service archive component and deploy it. Once deployed, we can validate the deployment through the log and through the JMX Console.

JBoss SAR Starting

During deployment, we see the JBossSpringAdapter service component being deployed by the application server. We can also see that the Spring context is being instantiated.

JBoss JMX Console shows the JBoss service component JMX management interface.

The JMX operations for the Spring service adapter are shown above. Notice that you can start and stop the spring container at runtime. That gives you the ability to conrol the lifescyle of your Spring container at runtime without redployment of the application . This maybe useful if you want to make a configuration change in production without redeployment of the entire application.

The Directory Scanner Spring Component
The scanner is a simple Java object which uses the standard java.io.File package to get filtered list of files in a given directory. You will notice that there are some annotations around the class. These are Spring-specific annotations used to expose the Directory Scanner class as a managed JMX MBean (this is not covered in this writeup). I also introduce an interface called Controllable for good form (not necessary).

The Controllable Interface

 public interface Controllable {
     public void start();
     public void stop();
 }

This interface shows control points that can be implemented in the Directory Scanner. This is not necessary, but added for completion.

The Directory Scanner Class
The class that implements the logic for scanning the directory is divided into three distinct sections

The properties (getter/setters) for the component
The life cycle control methods
The scanning method which is invoked to do a sweep of a a directory

@ManagedResource(description="Directory Scanner Component.",
 objectName="demo.integration:name=DirectoryScanner,type=SpringComponent")
 public class DirectoryScanner implements Controllable{
 
 ...
     
     @ManagedAttribute(description="Comma separated list ....")
     public String getExtensionList() {
         return (fileFilter != null) ? fileFilter.toString() : null;
     }
     
     @ManagedAttribute
     public void setExtensionList(String extensionList) {
         fileFilter = new FileListFilter(extensionList);
     }
 
     @ManagedAttribute(description="The directory location to scan.")
     public String getLocation() {
         return (location != null) ? location.getPath() : null;
     }
 
     @ManagedAttribute
     public void setLocation(String location) {
         this.location = new File(location);
     }
 
 ...
 
     @ManagedOperation(description="Lifecycle to start component.")
     public void start() {
         started = true;
         log.info("**** Directory Scanner Compoennt started OK.");
     }
 
     @ManagedOperation(description="Lifecycle to stop component.")
     public void stop() {
         started = false;
         log.info("**** Directory Scanner Compoennt stopped OK.");
     }
 
 ...
 
     public void scan() throws RuntimeException {
         if (started) {
             if (location != null && location.isDirectory()) {
                 File[] list = location.listFiles(fileFilter);
                 log.info("Scanned files with extensions [ " + fileFilter.toString() + "]" +
                         " from [" + location.getAbsolutePath() + "]");
             } else {
                 log.warn("Unable to scan location  Make sure it's valid.");
             }
         }
     }
 
 }

As you can see, this is a simple class. The thing to notice is the Spring-specific annotations that decorate the class. They are used to export and describe the class as a JMX MBean server. It's beyond the scope of this write up to go into the details of how to do this in Spring. However the next section shows the Spring file that describes and wire it all together.

The Spring Configuration File
The configuration of this component is simple and straight forward.

    <bean id="scanner" class="component.spring.DirectoryScanner" init-method="start" destroy-method="stop">
         <property name="location" value="../../"/>
         <property name="extensionList" value="*"/>
     </bean>

Above, we see the DirectoryScanner being configured to scan two directory up from where the application is invoked. Also, we set the list of files to scan.

    <bean id="timerFactory"
           class="org.springframework.scheduling.timer.TimerFactoryBean">
         <property name="scheduledTimerTasks">
             <list>
                 <ref bean="scheduledTimerTask" />
             </list>
         </property>
     </bean>
     
     <bean id="scheduledTimerTask"
           class="org.springframework.scheduling.timer.ScheduledTimerTask">
         <property name="period" value="3000" />
         <property name="timerTask" ref="timer" />
     </bean>
     
     <bean id="timer"
           class="org.springframework.scheduling.timer.MethodInvokingTimerTaskFactoryBean">
         <property name="targetObject" ref="scanner" />
         <property name="targetMethod" value="scan" />
     </bean>

The stuff above is boiler plate for setting up timer services from Spring. Here we are declaratively setting the timer to invoke the scan() method on the DirectoryScanner POJO wired above.

    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
         <property name="assembler" ref="assembler"/>
         <property name="namingStrategy" ref="namingStrategy"/>
         <property name="autodetect" value="true"/>
         <property name="registrationBehaviorName" value="REGISTRATION_REPLACE_EXISTING"/>
     </bean>
     <bean id="jmxAttributeSource"
           class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>
 
     <!-- will create management interface using annotation metadata -->
     <bean id="assembler"
           class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
         <property name="attributeSource" ref="jmxAttributeSource"/>
     </bean>
 
     <!-- will pick up the ObjectName from the annotation -->
     <bean id="namingStrategy"
           class="org.springframework.jmx.export.naming.MetadataNamingStrategy">
         <property name="attributeSource" ref="jmxAttributeSource"/>
     </bean>

Finally, the code snippet above sets up the POJO to be exported as an MBean into the running MBeanServer. This configuration relies on the annotation embedded in the class to derive the meta data used to describe the class inside the MBeanServer.

Download Source
You can download the application sample application to get the code source.

Observations

Think in Component - component-based development is incredibly easy to get into and understand. It facilitates the separation of concerns and promotes forces you into better coding practices (testing, loose coupling, re-usability, etc).
JBoss Service Component Evolving - Starting with version 4.x, JBoss components can now be annoted (instead of using the descriptor file) to describe its meta characteristics for JMX. Starting with version 5, JBoss will switch to OSGi as the executable unit for its components.
Exception Management - When deploying components into a container (such as JBoss app server), great care must be taken to handle exceptions properly. In JBoss (version 4.x), when a component throws an unhandled exception, that component is immediately disabled and shutdown. You must catch all exceptions and handle them properly. In DirectoryScanner, for instance, if the scan() method throws an exception during a scanning request, the entire component is deactivated.
(OSGi) Components Are Here to Stay - All major containers including JBoss AS, SpringSource App Platform, IBM WebSphere, Glassfish, and JOnAs support OSGi bundles as their coarse component model.

Refereces

Source for Directory Scanner - http://vladimirvivien.com.s3.amazonaws.com/jBoss-spring-integration.zip
JBoss Server Microkernel - http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch2.chapter.html
Spring Documentation - http://static.springframework.org/spring/docs/2.5.x/reference/index.html
Spring JMX Documentation - http://static.springframework.org/spring/docs/2.5.x/reference/jmx.html
OSGi - http://en.wikipedia.org/wiki/OSGi
OSGi and Spring - http://www.infoq.com/interviews/osgi-adrian-colyer

JavaOne - OSGi Is Huge Here!

2008-05-08T12:11:00.003-04:00

If you doubted that OSGi can achieve mass appeal, the list of sessions at J1 proves contrary. Most major tool vendors has either implemented it or have plans to support OSGi bundles:

OSGi has been in IBM's arsenal for while now (Eclipse, Websphere, etc)
SpringSource's new Spring Application Platform uses OSGi has its
Glassfish Version 3 will be OSGi-bundle compatible
JBoss 5's kernel will load its component as OSGi
JSR 277, the Java Module system, slated for JDK7, can load OSGi bundles

From small embedded devices, to desktop, to the large application server, OSGi seems to be the component model that the industry is adopting. It will be interesting to see how the corporate developer integrates OSGi in their development rituals.

JavaOne 2008 - Sun, Lifestyle Company?

2008-05-07T10:08:00.004-04:00

On day one of the JavaOne, the theme is clear: JavaFx (http://javafx.com/) is here to stay. The FX story is coalescing into a platform clearly targeting digital lifestyle experiences. It is clear that tremendous of resources are being devoted to bring the FX story together as technology stack with support for rich that stretches from mobile devices, desktop, to the backend.

The Tools
- Continued JavaFX support from NetBeans
- Photoshop/Illustrator plug-in's to export art work as JavaFx artifacts directly

The Features
- JDK 6 update 10 (jdk 6u10) - setting the path for the desktop features envisioned by Sun
- Applets - Sun is going back to the Applets as a way to augment browsing experiences.
- Audio/Video - under the FX unbrella Sun is offereing an HD qualility a/v codec for Java
- FX is slated to target devices such as cellphones and other mobile stacks with a consistent user experience from device to desktop.
- Project Hydrazyne: another Sun initiative to let users easily create rich content and experiences dritributed in a Sun hosted cloud.

I would like to see this effort successeed, for anything elese, just to have competition in the content technology market place. Adobe leads that sector, Microsoft is making inroad with Silverlight, now Sun wants to give Java developer a way into the rich content user exeperience.

You just have to read the blogs around the net to find doubters about this strategy laid out by Sun. However, I think if the company remains on message, provide the tools, continue to share the vision, there will be new convert. Lets see what happens!

Introducing Groovy JMX Builder

2008-04-09T06:41:00.002-04:00

After I attended the Groovy/Grails Experience in February this year, I realize that the Groovy builder pattern can be used to façade many other API's (not just swing). So, I decide to create, yet another builder, for the JMX API and here it is!

http://code.google.com/p/groovy-jmx-builder/

Features

Ability to expose any class instance for management for both Java and Groovy classes.
No need to implement a specific management interface.
Shield developer from complexity of JMX API
Use familiar Groovy builder pattern
Exposes attribute, constructors, operations, parameters

Suppose you have a class called Greeter (on your class path) that prints out greeting to a specified person in a specified language, so the class may look like this

public class Greeter {
private String name;
private String language = "en";

// ...

public String getName() {
    return name;
}
public void setName(String name) {
    this.name = name;
}

// ...

public String greet(){
    String greet = (String) (langs.containsKey(getLanguage()) ?
        langs.get(getLanguage()) : langs.get("en"));
    return greet + " " + getName();
}

 String greet(String person){
    return  langs.get(language) + " " + person
}
}

You can use Groovy Jmx Builder to expose an instance of that class for management as an MBean.

def greeter = new Greeter()
JmxBuilder jmx = new JmxBuilder()
def server = jmx.export(svr){
 bean(greeter){
     name("greeterDemo:service=greeting")
     desc("This service prints a greeting on console")
     attribute(name:"name", desc:"name of person to greet", writable:true)
     attribute(name:"language", desc:"the language to use", editable:true)
     operation(name:"greet", desc:"Sends greeting to user")
     operation(name:"greet", desc:"Send greeting to user"){
         parameter(type:"java.lang.String", name:"Person", desc:"The person to send greeting to")
     }
 }

 bean(object:greeter, name:"greeterDemo:service=greeting2")
}

You use the JmxBuilder() class to capture meta data about your class instance that will be made available at runtime for management.

In JConsole, the generated MBean may look like this

Feedbacks
I am interested in feedbacks for this project. So, download it and give it a try. I will be adding more features to it in the future.

Using Groovy's FactoryBuilderSupport to Build Internal DSL

2008-03-04T19:02:00.001-05:00

Using Groovy's FactoryBuilderSupport to Build Internal DSL

Couple of weeks ago at the Groovy/Grails Experience conf, Groovy's meta programming was a big theme there. Since then, I blogged about using Groovy's built-in Meta Object Protocol (MOP) mechanism to create a simple XML builder. Then I got curious about other builders such as Swing and SwingX. Talking to James Williams (SwingXBuilder creator), I found out that Groovy's FactoryBuilderSupport interface is designed specifically to allow developers create builder-style DSL. While the FactoryBuilderSupport provides a rich interface to create your own DSL, examples are hard to come by. Thankfully, James had just created another builder called Java3DBuilder which uses the FactoryBuilder interface and a good starting point. This shows a small example on using the FactoryBuilderSupport.

The FactoryBuilderSupport along with Groovy's Factory interface offer a structured approach to constructing internal DSL's. Unlike tapping directly into MOP to manage your DSL nodes, the factory approach requires you to explicitly register by name each node with the FactoryBuilder. The Factory interface exposes event callbacks to intercept different phases of node traversal by the FactoryBuilder which lets manage state and behavior of your DSL. Here is how Groovy's website describes the Factory interface and its methods:

A quick note about newInstanceMethod() - when the factory builder creates a new instance of your node, it will pass in these params: an instance of the factory builder, the name of the node being processed, an argument value (if used as the form node(arg) ), and optionally a map if the node is used as node(key:value...).

Saying Hello, the DSL Way
So, using the information above (and some some sleuthing on my part), I was able to figure out how to use the FactoryBuilderSupport class to build a simple DSL to display a greeting message. So, the first thing is to specify how the language will look and feel. Since we are using the builder pattern, our DSL will have the familiar construct we have seen in other builders:

builder.using(a given language) {
greet(person1)
greet(person2)
greet(person4)
...
greet(personN)
}

A call to builder.build() will print out the greeting in the proper language.

The Code
First, let us look at the backing structure that will support our DSL. It consists of a Person object and GroupGreeter class. The latter actually stores the persons we want to greet and apply the logic to build the greeting string.

The greetings can be in several languages including English, French, German, Spanish, Italian, and Portuguese. The greetings map (line 9)stores the greeting text as well as the conjunction to use when we are greeting more than one person.

Disclaimer: I am not a language geek. This translation is straight from Google Language Tools . So, I am not responsible for greetings that are colloquially incorrect or used in the wrong context!

On to the Builder
The next code snippet shows the FactoryBuilderSupport and the factories that it manages. Each node in your DSL is implemented by a factory instance. In our example, the nodes are are using and greet. Node using is registered with GroupGreetingNode and greet is registered with class GreetingNode.

GroupGreetingNode represents the parent node. It sets up a GroupGreeter object (see previous section) with the language passed in as its argument and returns the newly created GroupGreeter object. The GreetingNode is a child node of the GroupGreetingNode. When the "greet" node is encountered, the builder calls newInstance() on GreetingNode and a new instance of the Person object with the name as an argument and returns the newly created person back to the builder. The builder will eventually call setParent() on the GreetingNode. At that point, the person object that was created in is added to the parentNode (which is an instance of GroupGreeter). That's it!

Running the Code
The following shows two usage of the Greeting DSL

The code above produces

Hallo, Jon, David und Ella
Salut Mireille

Observations

The semantic for your DSL requires an appropriately fitting backing API and data structure
Model your backing data structure close to your DSL. It makes implementation of the builder simpler.
If you can't change the backing API, try model your DSL syntax and semantic close to your API.
FactoryBuilderSupport and Factory simply facilitates the traversal of the DSL nodes. They should not be used to implement the backing data structure.
How you process the nodes is subjective and depends on how your backing data model is structured.
Process data at the intended node level. So, a child node should process all of its data not pass it to the parent.

Conclusion
There's no doubt that Groovy makes developing DSL easy. As we have seen the combination of the FactoryBuilderSupport class and the Factory interface provides a structured approach to creating DSL that conforms to the builder pattern. In this write up I demonstrated how to create a simple DSL to print out greeting on the screen. The same techniques used here are used to create more complex DSL such as Java3DBuilder.

References
0. Download Groovy source code - http://vladimirvivien.com.s3.amazonaws.com/GreetingBuilderDemo.groovy
1. Dynamic Groovy - http://groovy.codehaus.org/Dynamic+Groovy
2. Groovy FactoryBuilderSupport - http://groovy.codehaus.org/FactoryBuilderSupport
3. Jame William's Java3DBuilder - http://www.jameswilliams.be/blog/entry/60

Hope you enjoyed it!

Creating a Simple Builder with Groovy's methodMissing()

2008-02-25T18:16:00.001-05:00

Creating a Simple Builder with Groovy's methodMissing()

One of the main theme here at Groovy/Grails Experience is Meta Programming: the ability to use Groovy to dynamically modify the behavior of the language at runtime. During one of Graeme Rocher's session, he did a live demo on how to build a simple Xml builder and Vankat Subramaniam demo'ed the creation of a simple DSL using Groovy. These sessions showed the simplicity and power of Meta programming in Groovy. So, rather than go on and praise the merits of Groovy and make this an all fluff write up (and get crap for it from my buddy James Williams ), I will show a concrete example below.

A Simple Xml Builder in Groovy
This simple xml builder is able to handle most xml tag constructs including:

<tag/>
<tag atrrib="val"/>
<tag>String content</tag>
<tag attrib="val">content</tag>
<tag attrib="val"><tag>... tag[n] ...</tag></tag>

Sorry, there is no namespace support of the form <namespace:tag/>

So, here is a sample usage of the SimpleXmlBuilder class to build XML nodes:

The code snippet above will generate this HTML code:

<html xmlns="htt://namespace" ><header><title>Hello</title></header><body><p>Hello World Sample</p><span id="greet" style="font-family:sans-serif" >Hello World!!</span></body></html>

The Code
Disclaimer: this was put together in less an hour while sitting in a session at the G2 Experience. I am sure it can be done in a more elegant way. The code simply evaluates each of the syntatic possiblities (discussed above) and take appropritae action. So, with that out of the way, here is the code for simple xml builder:

Click to download the Groovy source code.

MOP - methodMissing()
If you are new to Groovy then you may not understand what's going on. Groovy's meta object protocol (MOP) lets developers expand the syntactical constraints of the core language at runtime. This capability makes Groovy the perfect platform to create Domain Specific Language (DSL) where you develop small language with a concise syntax to address a given domain (software dev, business, etc). The methodMissing() method is one of the hooks exposed by Groovy's MOP mechanism that intercepts all calls to undefined methods on a given object. By overriding methodMissing(), you can implement behaviors of methods that are not statically defined on the class.

When Groovy's MOP intercepts an method call, it invokes methodMissing(String methodName, args) with two parameters: the name of the missing method that was invoked and an array representing the method's parameters. So, for instance, when Groovy intercepts xml.title("Hello"), the first parameter of methodMissing() has a value of "title" and args.length = 1 where arg[0] = "Hello".

When the syntax is as follows, xml.header {...}, methodMissing's method name has a value of "header". Here, however, args[0] is a closure. A closure is an executable (callable) code block that can be treated as a variable. As such, we must tell Groovy that we want to execute that code block. However, before we blindly call the closure, we reassign the closure's target to be the SimpleXmlBuilder class (args[0].delegate = this line 11 and 49). Therefore, the next method dispatch request on the closure will be handled by the SimpleXmlBuilder.

Finally, when the syntax of our builder takes the form of xml.html(xmlns:"http;//somenamespace"){ ... }, Groovy's MOP invokes methodMissing where the method name is "html" as expected. In this case, however, argument array has two memebers: the first one is a map and the second member is another closure. Knowing this, we can handle tags with both attributes and function as a container tag as shown above (starting with line 37).

Conclusion

This sample code above demonstrates how Groovy's MOP mechanism can let developers change and extend the language's syntactical behavior to build functional DSL that fit specific needs. Here, in about 30 lines of code, we created a simple XML builder which is able to output well-formed xml document. This is a simple example and shows just a small glimpse of the capabilities of Groovy's meta programming. I hope this inspires you to continue to explore Groovy and come up with your own use for MOP.

References
0. Download Groovy source file - http://vmatters.googlepages.com/SimpleBuilderDemo.groovy
1. Dynamic Groovy - http://groovy.codehaus.org/Dynamic+Groovy
2. Using methodMissing and propertyMissing - http://groovy.codehaus.org/Using+methodMissing+and+propertyMissing
3. Meta Programming with Groovy Part 1 - http://groovy.dzone.com/articles/metaprogramming-groovy-i
4. Meta Programming with Groovy Part 2 - http://groovy.dzone.com/articles/metaprogramming-groovy-ii-expa
5. Google Doc version of this write up - http://docs.google.com/Doc?id=df3qdpw5_53chtkh89r

Integrating Groovy Classes in Spring

2008-02-05T11:12:00.000-05:00

Spring Meets Groovy!

[View in Google Doc: http://docs.google.com/Doc?id=df3qdpw5_51fqxz7cft ]

If you don't use Spring or care to know about it, then this write up is not for you. I will look at how your Java-based Spring component can made Groovier!! Again, as a pre-requisite, you must already be using Spring (2.0 or better) and have a working knowledge of Groovy.

Why Groovy and Spring?
After more than ten years of Java, we can all agree that one language does not fit all. We (collective Java community) have been banging square pegs into round holes (with patterns, anti-patterns, best practices, frameworks as lubricant). With the advent of dynamic languages such Groovy and Ruby in the enterprise, we are realizing that it is time to start building polyglot systems. Poly-who, you ask?? A system that is made up of one or more languages. Each language addresses a specific domain (i.e. structural, configuration, business, ui, etc) so that your pegs fit where they should. We are already do this today when we write our views in JSP's, controllers in Java, retrieve data using SQL, and configure our apps using XML.

Groovy in Spring Example
Wiring Groovy beans in Spring is easy and require little deviation from what you already know. You can create your beans following these steps

1. Create a Java Interface
Currently, Groovy beans in Spring must implement an Java-defined interface so that Spring can get type information about your Groovy beans. So, let's create a Payment interface:

package demo.vladimirvivien;

import java.util.HashMap;

public interface Payment {
void pay(HashMap info);
}

2. Implement in Groovy
Create a Groovy class that implements the interface. Place your Groovy file somewhere on the classpath. In this example, the file is placed in groovy/CreditCardPayment.groovy. Your Groovy class has access to any classes on the classpath as well, so you can reference other Java classes or other Groovy classes. The class has two properties (mechantId and serviceUrl) which can be injected at runtime by Spring (see below).

import demo.vladimirvivien.Payment
import java.lang.Util.*
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

class CreditCardPayment implements Payment {
static Log log = LogFactory.getLog(Payment.class)

String merchantId;
String serviceUrl;

void pay(HashMap info) {
log.info("Processing Payment...")

println "---------------------------"
println "Merchant ID:t${merchantId}"
println "Service URL:t${serviceUrl}"
println "Payer:nt${info.PAYER_NAME}nt${info.PAYER_ADDR}ntCard:${info.PAYER_CCNUM} Exp:${info.PAYER_CCEXP}"

// process payment here
}
}

3. Wire in Spring
The first thing to notice is the XML schema declaration. It makes reference to the XML lang namespace and the lang XSD. This allows you to use the specially provided <lang:groovy/> tag. The tag lets you wire in Groovy beans and inject property values into them. Here, we are injecting mechantId and serviceURL with values just as we do regular Java POJO's.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:lang="http://www.springframework.org/schema/lang"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.5.xsd">

<lang:groovy id="payManager" script-source="classpath:groovy/CreditCardPayment.groovy">
<lang:property name="merchantId" value="ID343432-4434-34" />
<lang:property name="serviceUrl" value="http://paymentservice/processor.do" />
</lang:groovy>

</beans>

Run the Example
Here, we have a Java class that runs the example. However, you can imagine this setup working in other context such as a web application, a standalone process, or any other context where Spring can live. Note in the code that once the Groovy bean is retrieved from the Spring context, it is used as a regular Java class.

package demo.vladimirvivien;

import java.util.HashMap;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Main {
public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("META-INF/spring-context.xml");

// pull an instance of the Groovy Payment bean
Payment payment = (Payment) ctx.getBean("payManager");
HashMap<String,String> info = new HashMap<String,String>();
info.put("PAYER_NAME", "John Foo");
info.put("PAYER_ADDR", "12345 Main Street, USA");
info.put("PAYER_CCNUM", "1234564343343");
info.put("PAYER_CCEXP", "0910");

// call the implemented mehod pay()
payment.pay(info);
}
}

You should see the followings on the screen:

So What?
You may be saying "Why should I care? I can do the same thing in Java!" You would be correct. This is not meant to supplant Java but rather complement it. Integrating a dynamic language such as Groovy into your enterprise development gives you a new level of flexibility and configurability that was not there before (or at least requires additional steps to work smoothly). You can use this approach in several scenarios
- Configuration: Use Groovy beans to capture configuration rules for your system or for your business logic including page flow, process flow, etc.
- Business Rules: some business logic tend to change. You can use Groovy to
- Handle Event: Use Groovy to react to system or application events (i.e. if inventory falls below a level, send email. This works well in conjunction with JMX)
- Validation: validation rules is another context susceptible to changes. Capturing your validation in Groovy lets you adjust to your business needs.
- Expose Edge Services: these are the services that expose functionalities at the boundaries of your system (i.e. MVC controllers, web services, REST services, etc). See project Grails .

Conclusion
We looked at how Groovy can be integrated in your application using Spring. Groovy is a natural choice for Polyglot programming on the Java VM given its flexibility and growing popularity. This write up shows a small instance how Groovy can be integrated into your system using the Spring Framework. Groovy can be injected in your enterprise stack to handle the more fluid context where logic tends to be updated to keep up with business requirements.

References
0. Google Doc for write up - http://docs.google.com/Doc?id=df3qdpw5_51fqxz7cft
1. Spring Dynamic Language Support - http://static.springframework.org/spring/docs/2.5.x/reference/dynamic-language.html
2. Ola Bimi - Language Exploration (blog) - http://ola-bini.blogspot.com/2008/01/language-explorations.html
3. Neal Ford - Polygot Programming (blog) - http://memeagora.blogspot.com/2008/01/polyglot-programming-parallels-perched.html
3. Grok - Polyglot Programming (blog) - http://www.grok-programming.com/2007/11/25/polyglot-programming-is-it-just-too-much-to-ask/

Grails Is Changing My Entrepreneurial Ambitions

2008-01-20T09:36:00.000-05:00

I have been playing with Grails for a couple months now. It made me realize the power of (G)Rails approach, mainly "... get things done ... " I have used ASP Dot Net, at least 3 Java Web Frameworks, ColdFusion (not to mention Perl), I must say Grails is by far the most enjoyable.

Why all the buzz about Grails? Well, after you understand Grails and its paradigm, In about , hmmm, 7 minutes you can have a simple, fully-functional, web application. Grails' intuitive MVC mechanism and data access objects do most of the tedious, mind-numbing boiler plate infrastructural crap you usually have to do in other Java frameworks. You concentrate on what you know "... your business logic ..."

Grails (http://grails.codehaus.org/) is based on Groovy, Hibernate, Spring and have a well-defined Plug-In architecture. Now, you are probably thinking "... I don't want to learn these technologies ...." The cool thing is, you don't have to! You never see Spring nor Hibernate (unless you want to) Grails does an excellent job of shielding its users from the low-level infrastructural crap. O, yeah, hmmm, grails generates a WAR file that you can drop on any web container. Nothing special is needed!

So, I say this length intro to Grails to get to this: if you are a consultant, own a small operation, or the guy looking to develop the next social site, Grails maybe for you. As a startup, you know the name of the game is to get things done... Well, Grails lets you get things done... and you can actually get things done fast and the right way (did I mention that you get all the benefits of a full JEE environment without the fuss).

After a few hours of development, my next project is so far along that it feels unfair... yes... it feels unfair. It feels as if I should have more code to write... or more design decisions to make, or more academic bs that I should be concerning myself with (pattern this pattern that)... Instead, I actually have a product, something I can play with, make changes to, and derive motivation from.

Grails is all about agility... Grails bring dynamics to not only your code, but also the way you develop by giving you the ability to change make changes in mid-development with minimal impact to your level of efforts. Give it a try! I have!

Groovy + Spring + Broadway = { -> Resource Monitoring }

2008-01-10T22:20:00.000-05:00

So, I have been getting some feedbacks regarding Broadway after I first announced it. So, now it's time to delve into how you can use Groovy, Spring, and Broadway to create monitors. Using these technologies along with the Broadway API, you can build monitors that evaluate a given expression (default is Groovy) and execute a specified action when that expression returns the desired value (true or false). In this write up, I will show how to use Groovy, Spring, and Broadway to observe two directories and keep them synchronize. This is a trivial example, however it shows how Broadway can be integrated with Spring and Groovy to build powerful monitors (see Google Doc).

Directory Synchronizer [Google Doc]
Broadway was designed as component-based API and therefore it plays really well with the Spring component container. As the name implies, we will setup Broadway to monitor two directories (one primary and a secondary). The monitor will keep the secondary directory synchronized with the primary.

How Does It Work?
A monitor component will observe two directories directory for size differences. When the sizes of the two directories differ, files from the primary are copied to the secondary automatically. This can be easily accomplished using Broadway and Spring. The only required piece of code is the logic for the Action component. The action will be executed when the monitor detects the condition (in this case, directory sizes differ). As we will see, the logic for the Action can be captured in Groovy Beans (POGO's) wired in within Spring.

NOTE: this is by no mean meant to be a robust directory synchronizer, you are welcome to explore ways to make this more robust (i.e caching, thread safety, two-way synchronization, etc).

An Observed Resource
To make it easier to observe the directories, we will create a component that represents the directory structure being observed. This class provides a facade to the a file system and expose specific states to be observed. This sort of domain-specific observed components are not required. However, they can expose richer set of data to be observed by your monitors. NOTE: this observed directory class can be integrated using Groovy as well.

// Java code for ObservedDirectory
public class ObservedDirectory {
private String root;

public String getRoot() {
return root;
}

public void setDirectoryName(String root) {
this.root = root;
}
public String getDirectoryName(){
return root;
}

public boolean isEmpty(){
long size = org.apache.commons.io.FileUtils.sizeOfDirectory(new File(getDirectoryName()));
return (size > 0) ? false : true;
}

public long getDirectorySize(){
return FileUtils.sizeOfDirectory(new File(getDirectoryName()));
}

}

Using Spring's Dynamic Language Support
Spring's Dynamic Language support feature was introduced in starting with version 2.0. where you can wire a Groovy (JRuby or BeanShell) beans into a Spring context as if they are regular Java POJO's. This implies that you can inject values into your Groovy bean and wire with other beans in Spring context. If you want to learn more about Spring's Dyanamin Language Support, go to Spring Dyanamic Language Support online documentation.

Spring must be configured properly to use the dynamic language support. You must have the proper XML schema declarations or your bean will not be mounted properly in the Spring context.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:lang="http://www.springframework.org/schema/lang" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.0.xsd"> ... </beans>

[See the full Spring Config File ]

Now, we are ready to wire the remainder for the Broadway components to create the directory synchronizer.

Wiring Broadway Components
Since Broadway components follow the JavaBean notation, it's easy to wire them together in Spring. To build the directory synchronizer with Broadway, we will wire the Observed Directory component, the Monitor component, and an Action component.
Wire Observed Directory
In the Spring configuration file, we have two observed directory components wired. The primary directory is ./dir1 and the secondary directory is ./dir2. When the size of observed directory one differ from that observed directory 2, the Action component will execute its script to syncrhonize the two directories.


<bean id="firstDir" class="org.broadway.demo.spring.ObservedDirectory"> <property name="directoryName" value="./dir1" /> </bean> <bean id="secondDir" class="org.broadway.demo.spring.ObservedDirectory"> <property name="directoryName" value="./dir2" /> </bean>

Wiring the Monitor
The Monitor component observes state changes that is expressed by the "monitorExpression" property below. Here, we can see how we can use Groovy as an expression language to define when to take action based on the observed condition.


<bean id="monitor" class="org.broadway.monitor.BeanMonitor"> <property name="monitorExpression"> <value><![CDATA[context.resources.firstDir.directorySize != context.resources.secondDir.directorySize]]></value> </property> <property name="action" ref="action"/> <property name="resourceCollector"> <bean class="org.broadway.monitor.MappedResourceCollector"> <property name="resources"> <map> <entry key="firstDir" value-ref="firstDir" /> <entry key="secondDir" value-ref="secondDir" /> </map> </property> </bean> </property> </bean>
The monitor sets up three main properties 1) The monitoring expression using Groovy as an expression language 2)A reference to the action component (see below) 3) the collection of the observed resources (stored in a map).

Wiring the Action
The Action component is wired into Spring using Spring <lang:groovy> tag. This tag facilitates the integration of Groovy objects into the Spring context and provides several other settings (such as refresh, etc). Here, we are using the tag to point to script file located on the class path.

<lang:groovy id="action" script-source="classpath:scripts/SyncAction.groovy"/>

The Groovy Action Class
The Groovy Action class implements the Action interface (from Broadway API) directly to carry out the logic for the synchronizer. If you don't care about the Spring dependency, this is a better option then using the ScritpedAction component provided by Broadway (see below). However, you need to do some tedious class casting to get to the values in the context object. Here is what the Groovy Action class looks like:

class SyncAction implements Action{
public Object execute(Context ctx){
HashMap resources = (HashMap)ctx.getValue(MonitorConstants.MonitorKeys.RESOURCE_COLLECTION);

String dirPath1 = resources["firstDir"].directoryName;
String dirPath2 = resources["secondDir"].directoryName;

File dir1 = new File(dirPath1);
dir1.eachFile {origFile ->
String origFileName = origFile.name;

File destFile = new File(dirPath2+ File.separator + origFileName);

if(!destFile.exists() || (destFile.lastModified() <>
print "Synching file File $origFile.name ...\n";
def fis = origFile.newInputStream();
new FileOutputStream(destFile).withStream {fos ->
fos <<>
}
}
}

}
}

An Alternative to Groovy Action Class
If you do not want to use Spring's dynamic language support, you can still use Groovy to execute the action. Broadway provides a component called ScriptedAction that lets you specify a script file on the classpath or the system file path. Using this option, you can specify the script for your action in a simpler way.

To wire the ScriptedAction do:

<bean id="action" class="org.broadway.monitor.ScriptedAction"> <property name="scriptFileLocation" value="scripts/synchronizeDir.groovy" /> </bean>

Here, the component points to a Groovy script file located on the classpath. The Groovy script that gets executed by the ScriptedAction component is the following:

def dirPath1 = context.resources.firstDir.directoryName;
def dirPath2 = context.resources.secondDir.directoryName;

print "***** Synchronizing Directories [Mirror dir2 to Dir1] *****\n";

def File dir1 = new File(dirPath1);
dir1.eachFile {origFile ->
def origFileName = origFile.name;

def destFile = new File(dirPath2+ File.separator + origFileName);

if(!destFile.exists() || (destFile.lastModified() <>
print "Synching file File $origFile.name ...\n";
def fis = origFile.newInputStream();
new FileOutputStream(destFile).withStream {fos ->
fos <<>
}
}
}

Conclusion
We've seen how easy it is to use Groovy, Spring, and Broadway to wire together monitors. This example shows how to create a directory synchronizer with little effort. I encourage you to take a look at Broadway and let me know what you think.

More Info
Google Doc - http://docs.google.com/Doc?id=df3qdpw5_50hs7pn3fv
Broadway - http://code.google.com/p/broadway-monitor/
Download Broadway - http://broadway-monitor.googlecode.com/files/broadway-0.5.zip
Download Tutorial - http://broadway-monitor.googlecode.com/files/broadway-tutorial.zip

Introducing Project Broadway Monitor

2007-12-31T03:45:00.000-05:00

I have been working on this on and off for the past 3 years. As with free-time projects, it started out as something completely different and progressively turned into what it is today. If you find the project interesting, send some feedbacks! So, here it is:

Project Broadway is an extensible and customizable monitoring API. Broadway lets developers easily create monitor components to observe pre-defined conditions and specify how to react when these conditions are encountered.

At its core, Broadway lets you separate the monitoring concerns from the observed resources. It has a flexible design, which allows it to work in any context where JavaBean-style getter property values can be read either directly through in-VM method invocation or through some detached mechanism (i.e. proxy, reflection, rmi, jmx, web service, etc). Broadway's simplified design offers two major high level components a Monitor and an Action. The Monitor components lets you specify resources to monitor and express some rules to monitor using a scripting language (Groovy is the default). The Action component specifies the action to execute when a specified condition is realized. Action can be pure Java classes or they can be written in scripting languages such as Groovy or JavaScript, etc.

Broadway Offers

Ability to monitor both in-VM and distributed resources.
API with rich level of programmability through a monitor DSL.
Leverages existing frameworks including JavaBean, JMX, Java scripting, Apache BSF, etc.
Support expressive monitoring rules using scripting language (default is Groovy)
Create compound expression to monitor multiple resources which can be in different context.
Architecture allows plug-in of different scripting engine supported Apache BSF (default is Groovy).
Scripted action component to execute script files to react to monitor expressions.

For more details, visit http://code.google.com/p/broadway-monitor/

NFJS Atlanta

2007-10-13T14:04:00.000-04:00

Last weekend I attended the No Fluff Just Stuff Atlanta as a speaker. The series has a wide set of topics ranging from front-end development to ESB. There was something for everyone doing enterprise computing. I especially enjoyed the general session talk "No I Won't Tell You Which Web Framework to Use..." by Scott Davis and Neal Ford's presentation "Building DSLs in Static and Dynamic Languages."

One recurring theme gaining momentum this year is turning Java into a platform for creating and using other languages. Java 6 introduced inherent support for hosting dynamic languages (see also Apache's Bsf). It's interesting to see how people are using or plan to use dynamic languages in their development. Groovy/Grails are definitely catching people's attention. I heard less of Rails and more of Grails (hmmm.... it could be because I of my own bias). While Grails provides a world class web framework, the focus is also on "how to use Groovy as the glue code to quickly integrate the heavier static Java components at the edge layers."

My JMX Presentation
People are still interested in JMX. If anything, just out of curiosity to see what JMX is about. Not suprisingly, more and more people are using JConsole (which is good). But, not too many folks realize that, they too, can create apps that can expose management components in JConsole. So, I will continue to talk about Jmx.

barCamp Orlando!

2007-09-23T08:21:00.000-04:00

On Wednesday, after visiting a James Williams page (Tampa JUG speaker for September), and seeing a link for Orlando's barCamp, I decided to also attend. I figure it's a good way to spend a Sunday with people talking about technology all day. The gathering is described as anti-conference, where almost everyone is sort of expected to contribute. I will talk about Flex (it's been a while since I visited the front-end).

Anyway, if you are heading to Orlando, see you there!

BeOS Lives On?

2007-08-29T07:21:00.000-04:00

Back in the mid 90's (so long ago), BeOS was all the rave. I bought and used a copy of the OS (yes, my nerdiness extends back awhile) and liked it very much. However, there were few software and drivers available and eventually the company went under.

Be Inc got disbanded (I think the intellectual properties went to 3M or Palm, Inc, not sure) and there were little activity on the OS for about 10 years. I always wondered if anyone else thought BeOS was cool enough to be kept alive...

Yes! The guys at Haiku Inc seems to think so and have been supporting a project called Haiku OS for about 6 yrs (who knew). Now, it seems that Google Inc is interested in the small project. It's described as a binary-compatible reverse-engineered OS (smells litigious you may say, but I think Google will just buy the remainder of the IP from its owners).

Among its many aspirations, Google is missing an OS of its own. It would be nice to see GoogleOS comes out of this effort. I mean, it only makes sense if Google will compete againstMS and eventually Apple. As a user and lover of technology, I am all for an OS that will energize the community based on its technical merit (not just overblown hypes).

Check it out :
http://haiku-os.org/ - Site link.
http://video.google.com/videoplay?docid=236331448076587879 - Google Talk: Haiku
http://haiku-os.org/index.php?q=gallery&g2_itemId=1288 - Haiku at Google

2007-06-13T17:16:00.000-04:00

Part 2 – Creating an Advanced JBoss 4.x Service Archive (SAR) Components

In part one of this write up provided an introductory look into JBoss' Service Archive architecture (SAR). Service archives are components that are deployed on JBoss that can be used to extend the capabilities of JBoss or your deployed applications. The SAR architecture is the basis for JBoss’ component-based development and allows the deployment of modules that can easily be reused by other deployed modules.

The previous post included an example of a simple service archive that illustrates the ease with which a service archive component can be created and deployed on JBoss. This write up explores the use of JBoss service API to create more advanced components that can receive life-cycle notifications for a deeper integration with the JBoss container. We will take a look at how to use the JBoss XMBean descriptor file which is used to create rich set of attributes for describing JMX MBeans. All concepts covered here, are reinforced through an example that builds on the previous example in part 1 to create a directory monitoring system deployed as SAR in JBoss.

Click here to read part 1 of this post.

Integrating with JBoss Server

The JBoss service API provides different points for deep integration with the JBoss container. These integration points are event callbacks that are fired during at different stages of the container’s lifecycle.

org.jboss.system.ServiceMBean

The core interface that provides access into the container’s service architecture is the org.jboss.system.ServiceMBean. This interface exposes several lifecycle callback methods. Instead of directly implementing the interface, your SAR component class should extend the convenience class org.jboss.system.ServiceMBeanSupport and override the following methods:

protected void createService() throws Exception;

protected void destroyService() throws Exception;

protected void startService() throws Exception;

protected void stopService() throws Exception;

As the method names imply, you override the methods that correspond to the phase in the service lifecycle you are interested in. The createService() is called when the container’s SAR Deployer is about to initialize your service. Once your service is fully realized, the deployer calls the startService() automatically. The destroyService() is invoked by the deployer when server is stopping or when your service is about to be deregistered from the MBean container.

The ServiceMBeanSupport class also makes available other convenience callback methods that maket it easier for your service to receive a larger set of container events. These methods include:

public ObjectName preRegister(javax.management.MBeanServer server,

javax.management.ObjectName name) throws Exception;

public void postRegister(Boolean registrationDone);

The preRegister() method provides access to couple of key JMX objects including the MBean server and reference to the ObjectName for the component being registered. These methods are fired right before and right after the component’s registration into the MBean’s server respectively.

NOTE: Deep integration with the JBoss container means that your code will introduce dependencies on the JBoss service API. However, that’s should not be a problem if your code follows good OO practices and well-know patterns that lessen architectural dependencies.

The JBoss XMBean Descriptor File

In part one of this write up, I presented a simple SAR example that was implemented using the JMX API's Standard MBean which relies on a prescribed naming pattern. While this works, it has several drawbacks:

It forces the undesirable burden of naming your classes using a management interface naming pattern which may not fit well in your development.
The Standard MBean does not allow you to control which methods / properties are exposed for management. JBoss will automatically expose all management interface properties as JMX attributes and all methods as management operations.
Lastly, the Standard API has no mechanism to expose descriptive metadata regarding the exposed attributes and operations.

While the simple Standard MBean approach works well for simple cases, it may prove inefficient for complicated domain models and force you to insert JMX management matters into your business object graphs. JBoss alleviates this issue by providing the XMBean Deployment Descriptor XML file. XMBean provides the ability to expose any class (POJO) as a JMX MBean and therefore be exposed as a service archive component.

The XMBean descriptor mechanism also lets you expose your MBeans with richer descriptive metadata. Using the XMBean, one may specify description for all expose attributes, getters, and setters exposed by your MBean component. You can also use the XMBean to specify attributes persistence policy, and security interceptors classes supported by JBoss. For further information, see the JBoss XMBean documentation.

Using the XMBean Descriptor File

Declare your SAR component class in the jboss-service.xml file (same as before). Instead of specifying the attributes and operations in the service file, as before, point the component to an XMBean file using the xmbean-dd attribute. In the code snippet below, the component: points to file timer-xmbean.xml to get its definition:

<mbean code="service.SimpleTimer"

name="service.directory.monitor:service=MonitorTimer"

xmbean-dd="META-INF/timer-xmbean.xml">

</mbean>

Create the XMBean XML descriptor file (with an arbitrary name) that matches the name specified in step 1. In it, insert any number of XML emlements (see JBoss Admin Guide) to describe attributes, methods, notifications, interceptors, and remote access interfaces. Here's an excerpt of the XMBean file for the class service.SimpleTimer:

<class>service.SimpleTimer</class>

<constructor>

<description>The default constructor</description>

<name>SimpleTimer</name>

</constructor>

<attribute access="read-write" getMethod="getPeriod" setMethod="setPeriod">

<description>The timing period for the timer. Defaults to 1000 mill sec (1 sec)</description>

<name>Period</name>

</attribute>

<operation>

<description>
This operation starts the timer. Registered listeners will start receiving timing notifications.
</description>

<name>start</name>

</operation>

<operation>

<description>This operation stops the timer service.</description>

</operation>

<operation impact="ACTION">

<description>

When invoked, it sends a timing notification to registered (connected) services.

</description>

</operation>

The XMBean produces the following in the jmx-console:

XMBean extends the service descriptor file to provide features such as dependency injection and descriptive metadata capabilities for the JBoss JMX container. Additionally, <name/> and <description/> tags can be used to describe their enclosing constructor, operation, or attributes. The text will be exposed to the management console for increased usability during management of the component.

Under the hood, XMBean is JBoss' implementation of the Model MBean. The JBoss API does the heavy lifting to generate the sizeable amount of code required to dynamically create model MBeans. You simply specify a POJO and JBoss handles the rest. This approach lets you create complex domain models independent of any container specific API. In future write up, we will explore how to accomplish integration using Java-style annotations.

The Advanced Directory Monitor Example

This example demonstrates several concepts in developing service archive components including the ability to receive life cycle notifications from the JBoss SAR Deployer. Since the service infrastructure is based on JMX, you will inevitably create additional JMX management API dependencies to fully take advantage of the JBoss infrastructure.

For that reason, great care must be taken to implement management infrastructures in your code that separates management concerns away from your core business concerns.

The Directory Scanner Components

The implementation of the scanner is achieved using three distinct components. The segregation of the code into these components is a purely subjective decision. However, creating loosely-coupled components promotes good OO practices, increases code re-use, and, above all, makes implementation of management concerns easier since they can be separated out of business concerns.

Timer

The Timer component (implemented as SimpleTimer) provides timing service to other interested components. It extends the JMX API class NotificationBroadcasterSupport which allows it notify interested components (registered as listeners). For each time period t, the Timer sends a JMX notification of type "service.SimpleTimer.time" to registered listeners. In our sample code, the component Directory Monitor component will register itself as a listener to the Timer service.

Directory Monitor

This component (implemented as DirectoryMonitor2) scans a specified directory for files with specified extensions. When the files with the extension are found in the scanned directory, the monitor sends a notification to registered Directory Monitor Listener. During a scan sweep, if one or more files with a specified extension is detected in a specified directory, the directory monitor sends a notification of type "service.DirectoryMonitor.scan."

The DirectoryMonitor2 class extends the JBoss API class "org.jboss.system.ServiceMBeanSupport" to receive lifecycle notification from the JBoss container. When the SAR Deployer is deploying this component, it calls methods create(), preRegister(), postRegister, and start() respectively. You can implement any of these methods to take advantage of the callback mechanism to customize the registration sequence. In our example below, the DirectoryMonitor2 uses these callback method create() to register itself as a listener of the Timer component:

public ObjectName preRegister(MBeanServer svr, ObjectName obj) throws Exception {

super.preRegister(svr, obj);

this.server = svr;

...

}

public void create() throws Exception {

super.create();

registerForTimer();

...

}

private void registerForTimer() {

if(server != null) {

NotificationFilterSupport filter = new NotificationFilterSupport();

filter.enableType(EVENT_TYPE);

try {

ObjectName timerName = new ObjectName(this.getTimerName());

server.addNotificationListener(timerName, this, filter, null);

} catch ( ... ) { ... }

}

. . .

}

From the code sample, you can see that the create() method is implemented as a callback to programmatically register the DirectoryMonitor as a listener to the timer component. Review the code for details on these classes.

MonitorListener

As a design decision, the logic that handles the notifications from the directory monitor is placed in a separate component. Though not necessary, it makes for a cleaner implementation. The MonitorLister handles notifications broadcasted from the Monitor components of type "service.DirectoryMonitor.scan." One advantage of this separation is that the directory monitor code is separated from the code that provides logic on handling the scanned directory resources from the monitor.

Running the Sample Code

Download the code (see Resources below)
The zipped file contains a project which can be opened in either Eclipse or NetBeans
Edit file srcMETA-INFjboss-service.xml to uncomment the Advanced service declaration
Compile into SAR (basically a JAR file or exploded directory with a .SAR extension)
Drop SAR package in your JBoss deployment directory
Log unto your JBoss jmx-console to validate your deployment.

Log into your jmx-console and you should see the following components deployed

You can also validate the deployment of your component by seeing output in the console similar to the console image shown below.

Conclusion
In this post, I looked at how to create SAR components with deep integration with the JBoss container. SAR’s are JBoss components based on the JBoss container service architecture which itself is based on JMX technology. In a previous post, we have seen how to create simple SAR components using the JMX standard MBeans. In this post, we have seen how to create a more advanced example where the SAR components can be deeply integrated with the JBoss container.

Using the service management interfaces provided by the JBoss service architecture, we’ve seen how you can create SAR components that can listen to container generated lifecycle events including when the components is being created, registered into the container, and destroyed. By overriding methods in class org.jboss.system.ServiceMBeanSupport, we have seen how to implement methods that take advantage of the different lifecycle callbacks invoked during the instantiation sequence of the SAR component. You can download the sample code discussed here using the link found in the resource section.

In future post, we will explore JBoss’s support for annotated class to easily create SAR components using POJO’s.

Resources
1) JBoss Server Documentation - http://docs.jboss.com/jbossas/guides/installguide/r1/en/html_single/
2) JMX - http://en.wikipedia.org/wiki/JMX
3) Download Example – http://vladimirvivien.com/download/demos/jboss-service.zip