Introducing project: breakingwoods - Components Repository and resources for JBoss ESB

Introduction


First of all, the main objective of this project is to be a source of new ideas, resources, components and actions for JBoss ESB.  Nobody is interested in creating a fork (or anything like that), but we believe that it could be a nice way to contribute to the evolution of this incredible project, as well as to be an accurate information source and filter for candidate components to be integrated into the core JBoss ESB project.

At breakingwoods, anybody will be able to contribute.  All contributions are welcome, whether that be a new ESB component, a review of an existing compoenent, ideas, fixes, testing etc... all will be really appreciated  The only thing you need is a Gmail/Google account.


Freedom to Contribute


Everybody at the breakingwoods's team believes that JBoss ESB is a very robust solution, but would be even better if we would add more Adapters, Listeners, Gateways (in JBoss ESB it might be the same), as well as new Actions. The same happened with another popular opensource ESB solution: Mule, made by MuleSource.  The Mule community has Mule Forge, which is an extension's repository for MuleESB.  We hope that breakingwoods can be exactly the same for JBoss ESB, offering lots of components, and showing valuable information about which new ideas are rocking or the most downloaded, rated, commented etc.

Why this project is not hosted under JBoss.ORG?

Firstly we would like to make the project strong in its own right.  Once it is hosted at Google, we hope people will feel comfortable enough to contribute with whatever they want, once it is not so close to the crowd and the spotlight. Nevertheless, maybe in the future, we could move from Google Code to JBoss.ORG.  This will depend of the success of this initiative.  Alternatively, it could be great to have it isolated.


How can I contribute?


There are several ways in which you can help to make this project a success:

• To Propose / To Create / To Review/ To test: New Adapters/Gateways/Listeners
• To Propose / To Create / To Review/ To test: New ESB Actions
• To Propose / To Create / To Review/ To test: New Ideas, Designs, Quickstarts

Already at breakingwoods:

• esbgen:  A basic CLI tool similar to seam-gen.  Helps you create the first esb project.
• TwitterAction:  Action for publishing an ESB Message in Twitter.
• EMailListener:  Periodically polls in the configured e-mail account, publishing incoming emails to JBoss ESB as an ESB Message.
• Google Spreadsheet Listener:  Connects to Spreadsheets hosted by GoogleDocs, publishing new records to JBoss ESB.
•  Apache DBUtils:  Action that executes plain SQLs.
  

There are new Actions and Listeners in the pipeline.  The following are some of the next Listeners we are planning.  Maybe you will be able to help:

• Apache Camel Listener/ Action
• SalesForce Listener / Action
  
• Infinispan Listener/ Action
  
• Terracota Listener / Action
• AMQP Listener/Action
• Where is yours ? :)
  

We are working in some of these, so stay tuned, as lots of good things will appear here at this project.


Another good point, is that most of these components will be compatible to JBoss SOA Platform.  Obviously Red Hat will not support problems regarding SalesForce, Terracota or anything that is not part of the JBoss SOA-P supported distribution.  However, you will still be able to add these components into your solutions, possibly reducing your development time and increasing your productivity.

If you have chance, check it out here: http://code.google.com/p/breakingwoods/

Enjoy one of the best things about open source development: "To learn with others essentially doing something useful".

• Visit the Project Website
• Visit the Official Blog

breakingwoods Team.

POSOS: Plain Old Services Objects in JBoss ESB

Introduction

What? One more buzzword? You can complain with Burr Sutter, he is the guy that created this one for what some customers are wondering and they asked me how do that possible in JBossESB! The question is: "We would like use or reuse as easy as possible my just plain Pojos or "legacy beans" acting as ESB Actions configured in the listeners from protocol's providers in ESB.

ESB Traditional Actions for Experienced Developers...Easy Pojos for non-experienced ones

When you are writing your ESB Action classes, you have some rules to follow, for instance: a) extends AbstractActionLifecycle or , b) A Constructor with a ConfigTree object as a parameter , c) The process methods must returns a Message as well as you need a Message parameter using this type, so your simplest ESB Action is not that easy for non-experienced ESB Action developers.

Ok, Show me this POJO that can run inside JBoss ESB

See the following pojo:

Easy right? See the changes I did to enable this simple POJO as an Action Processor for a Listener in ESB, basically creating two annotations: @In and @MessageParam, which can tell me which methods from the pojo I have to invoke from my processor method in the action, as well as the parameters that I can get via the attributes stored in the Message.Body :

Basically, what I did was a first action, that is traditional action, where I put a value in the message body identified by the name "s", which is the value from "name" in the annotation @MessageParam, so the value will be transfered for my methods as a parameter properly, my action is very simpple as you can see in the following image:



On this point, I am using a strategy similar you can see at any regular Web application, which a portion can store some information into some context that will be accessible when necessary.

The convention here is that, I am telling that the annotation @In (like Seam) in the method must be processed into the BUS, in addition, the parameter @MessageParameter tells me that I have to get an object identified by name "s" from the Message.Boby from my ESB Message.

To do that, I created an Action that can accept into one of their properties, which a called "classses", a list of full classes names separated by commas. It is the easiest way to discover the classes without use any other sofisticated engine. See those actions configured into JBoss ESB Eclipse Plugin in the following image:


The following code shows how I configured my jboss-esb.xml, and the configuration of the actions. Look that I can fill in the classes property in how many annottated pojos I want, once they are annotated with our "Esb" annotations:

Once again, the only thing I did on my pojo was add the following annotations, as you can see in the following image:


Conclusions

Of course something much more sophisticated could be done, but like I did is easy for anybody understand, maybe in the future use some similar strategy that RestEasy does, or even create something in memory using JavaAssist.
Another point, I also created annother annotation @Out which would be useful when you change the information inside the parameter that you receive from Message.Body, but after the method you wanna take the changed value to the Message.body context with the changed information... Perharps it sounds like a bijection originally a concept from in JBoss Seam applied for JBoss ESB as well. The actual sources are not the most beautyful, but are working fine, e-mail-me if you need the source code, which basically runs as any other regular quickstart.

I hope someday see such feature like that out-of-the-box in JBoss ESB, while it is not true, I am happy with I have done.

JBoss Profiler 2.0 Plugin for JON

I just started create a JON-plugin based on actual MBean that is the controller for execute the profiler commands, basically what I am doing for now is just "declare" the Services and Actions based on JMX-Actions, take a look on the actual result:

In addition, the Profiler Actions, I will be working a little bit more, when I get it done I will commit and create a distro into JBoss Profiler web site:

We are promoting a lot JON and RHQ-Project in Brazil, for many customers, JON is a good answer for an "Enterprise JBoss Management", if you have some MBeans ready that are really important for your Application, you can manage them using RHQ or JON much better than if you try do just using the legendary JMX-Console. Basically I did an rhq-plugin.xml describing my MBeans, see the following code:

For more information in how create Plugins for RHQ/JON:

• http://support.rhq-project.org/display/RHQ/RHQ+Plugin+Community
• http://support.rhq-project.org/display/RHQ/Writing+Custom+Plugins

Here some others screenshots:

New Commands available

Some Metrics, in a near future we will have profiler's reports available here

Installing, testing and Using JBoss Profiler 2.0 - beta2

This entry will show how start use the jboss-profiler beta2, first of all , download the software from here:
http://www.jboss.org/downloading/?projectId=jbossprofiler&url=/jbossprofiler/downloads/jboss-profiler-2.0.Beta2.tar.gz , save in some folder in your disk and unzip it.

Once you have the files in your disk, basically to setup jboss-profiler you will have to do the following steps:

1. Copy jboss-profiler.jar to jbossas/bin
2. Copy jboss-profiler.properties to jbossas/bin
3. Edit jboss-profiler.properties in jbossas/bin to include the classes to be profiled
4. Copy jboss-profiler-plugins.jar to jbossas/bin
5. Edit run.conf (Unix) or run.bat (Windows) in jbossas/bin to include JBoss Profiler in JAVA_OPTS ( See you run.conf and add use this example: JAVA_OPTS="-javaagent:jboss-profiler.jar -Djboss-profiler.properties=jboss-profiler.properties -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000")
6. Copy also to jbossas/bin the javaassist.jar if you are using JBoss AS 4.2.x
   
7. Copy jboss-profiler.sar to jbossas/server//deploy
8. Boot application server, if the following log appears everything is ok:

========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /opt/java/jboss/profiler/as JAVA: /opt/java/jdk1.6.0_03/bin/java JAVA_OPTS: -Dprogram.name=run.sh -server -javaagent:jboss-profiler.jar -Djboss-profiler.properties=jboss-profiler.properties -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true CLASSPATH: /opt/java/jboss/profiler/as/bin/run.jar:/opt/java/jdk1.6.0_03/lib/tools.jar ========================================================================= JBoss Profiler 2.0.Beta2 (Sun Microsystems Inc. 1.6.0_03) JBoss Profiler depends on external communication module 10:55:51,681 INFO [Server] Starting JBoss (MX MicroKernel)... 10:55:51,707 INFO [Server] Release ID: JBoss [Trinity] 4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)

Profiling your Application with JBoss Profiler beta2

In order to show the testing, I will do some profiler in JBPM classes, just to check what is happening behind the scenes. To do that I have to edit the jboss-profiler.properties in jbossas.bin directory to add the reference for JBPM's classes, as which is: org.jbpm.* (includes=org.jbpm.*).

Actually JBoss Profiler uses JMX and MBeans as its infrastructure which allows you profiler either JBoss 4.2.x or future 5.x versions. When you deploy the .sar file, you can see the profiler in the jmx-console as you can see in the following image:

You can do several options using the commands via JMX-Console, or as well as you can use command-line interface. At this moment we will use the JBoss profiler CLI, so go to jboss-profiler2-beta-2-folder/ in your shell (Unix or Win) and type the following command: java -jar jboss-profiler-client.jar , the result will be the following:

[jsilva@jsilva jboss-profiler-2.0.Beta2]$ java -jar jboss-profiler-client.jar
Usage: Client [-h host] [-p port]
startProfiler : Start the profiler
stopProfiler : Stop the profiler
snapshot : Take a snapshot
getSnapshot : Get a snapshot
listSnapshots : List snapshots
clearSnapshots : Clear snapshots
gc : Trigger garbage collection
enable : Enable the profiler
disable : Disable the profiler
load : Load a snapshot
save : Save a snapshot
diff : Difference between snapshots
add : Add classes (repository must be enabled)
remove : Remove classes (repository must be enabled)

As far you can see you have all these options to invoke profiler operations, for testing I used the following:

1- java -jar jboss-profiler-client.jar snapshot - Which generated a snapshot.
2-java -jar jboss-profiler-client.jar listSnapshots - Which shows all snapshots I had taken from my App Server.
[jsilva@jsilva jboss-profiler-2.0.Beta2]$ java -jar jboss-profiler-client.jar listSnapshots
1: 21 August 2008 11:23:54:296 -> 21 August 2008 11:24:17:117
2: 21 August 2008 11:39:05:687 -> 21 August 2008 11:39:31:255
3: 21 August 2008 11:41:59:145 -> 21 August 2008 11:43:25:691
3- java -jar jboss-profiler-client.jar getSnapshot 3 - Which tells to my client flush in my disk the info about my snapshot number 3, after this if you type a ls (dir for win), you can see the folder with thesnapshot timestamp. Please enter on this folder and list the files and folders again, the results would be something like:

[jsilva@jsilva 20080821114159145-20080821114325691]$ ls
caller classes classes.txt hotspots.txt methods.txt overview.txt packages.txt threads

On the files above you can see the information about your classes, in my case, I just did some operations with my simple bpm application. Take a look on the overview.txt report content:

From: 21 August 2008 11:41:59:145
To : 21 August 2008 11:43:25:691

Threads:
========
Thread-60 20063.47 ms

Most time:
==========
Count Ms % Method
1 13453.22 67.05 org.jbpm.persistence.db.DbPersistenceServiceFactory#getSessionFactory()
1 6078.74 30.30 org.jbpm.db.hibernate.HibernateHelper#createConfiguration(String, String)
3 134.04 0.67 org.jbpm.configuration.ObjectFactoryImpl#getObject(org.jbpm.configuration.ObjectInfo)
6 116.03 0.58 org.jbpm.configuration.ObjectFactoryImpl#loadClass(String)
1 84.82 0.42 org.jbpm.persistence.db.DbPersistenceServiceFactory#openService()
1 79.14 0.39 org.jbpm.persistence.db.DbPersistenceServiceFactory#getConfiguration()
1 56.08 0.28 org.jbpm.persistence.db.StaleObjectLogConfigurer#wrap(org.apache.commons.logging.Log)
14 29.55 0.15 org.jbpm.calendar.Day#(String, java.text.DateFormat, org.jbpm.calendar.BusinessCalendar)
24 4.53 0.02 org.jbpm.calendar.Holiday#(String, java.text.DateFormat, org.jbpm.calendar.BusinessCalendar)
2 3.51 0.02 org.jbpm.calendar.Holiday#parseHolidays(java.util.Properties, org.jbpm.calendar.BusinessCalendar)

Hotspots:
=========
Count Ms Avg % Method
1 13453.22 13453.22 67.05 org.jbpm.persistence.db.DbPersistenceServiceFactory#getSessionFactory()
1 6078.74 6078.74 30.30 org.jbpm.db.hibernate.HibernateHelper#createConfiguration(String, String)
1 84.82 84.82 0.42 org.jbpm.persistence.db.DbPersistenceServiceFactory#openService()
1 79.14 79.14 0.39 org.jbpm.persistence.db.DbPersistenceServiceFactory#getConfiguration()
1 56.08 56.08 0.28 org.jbpm.persistence.db.StaleObjectLogConfigurer#wrap(org.apache.commons.logging.Log)
3 134.04 44.68 0.67 org.jbpm.configuration.ObjectFactoryImpl#getObject(org.jbpm.configuration.ObjectInfo)
6 116.03 19.34 0.58 org.jbpm.configuration.ObjectFactoryImpl#loadClass(String)
14 29.55 2.11 0.15 org.jbpm.calendar.Day#(String, java.text.DateFormat, org.jbpm.calendar.BusinessCalendar)
2 3.51 1.76 0.02 org.jbpm.calendar.Holiday#parseHolidays(java.util.Properties, org.jbpm.calendar.BusinessCalendar)
1 1.35 1.35 0.01 org.jbpm.util.XmlUtil#parseXmlInputSource(org.xml.sax.InputSource)

Allocations:
============
org.jbpm.db.hibernate.StringMax 149
org.jbpm.db.hibernate.ConverterEnumType 49
org.jbpm.configuration.AbstractObjectInfo 32
org.jbpm.calendar.Holiday 24
org.jbpm.calendar.Day 14
org.jbpm.configuration.FieldInfo 9

Conclusion

JBoss Profiler 2 is built on top of really cool technologies, such as JBoss AOP and JavaAssist, feel you free to contribute with bug-fixes, documentation or with whatever you think could be valuable for the project, it would be a great chance for joining at a JBoss Project as a contributor, as far the actual contributors: Jesper Pedersen, Clebert Succonic and I are not dedicated as a full-time developers for Profiler, the work you can see as the result is a really big effort that Jesper and Clebert are doing. Beyond simple CLI interface, we are planning 2 really cool news, one of that is a new JBoss Profiler console based on RichFaces and related technologies, besides a Plugin for JBoss Operations Network/RHQ Project as well.

Visit: http://www.jboss.org/jbossprofiler/