There have been a few requests in the jBPM forum about how to integrate jBPM4 with an application's domain. So this is a first pass at whipping up a sample project that does exactly that.
I will be refining this once I get some more time, but I thought I would put as much of it out there as I have working, maybe it will help someone right away.
This is a Maven2, Hibernate3.2.6.ga based project. We will be working with jBPM v4.0. This is the GA release that came out under a couple of weeks ago.
The goal is to have a running web application that uses jBPM4 in the embedded form. This would be a typical way in which jBPM4 would be used. This will help guide people to work with a simple hibernate based jBPM web application that beginners can build upon to build their own web application.
This post will be updated in the next couple of days, w.r.t instructions.
But just wanted to put the code out there. So that one can get going,
We will also be working with integrating with something like Google Guice, down the line. This is something I wanted to play with myself.
The code is hosted at Google Code.
You can check it out as follows:
svn checkout http://jbpm-hibernate-demo.googlecode.com/svn/trunk/ jbpm-hibernate-demo-read-only
The important files are
1.) jbpm_demo.jbpm.cfg.xml
2.) jbpm_demo.hibernate.cfg.xml
They have the configuration required to boot up hibernate and setup the jbpm engine.
Tuesday, July 21, 2009
Thursday, March 12, 2009
Maven on Leopard
Mac OS X keeps updating and installing patches which has broken my maven installation a couple of times.
Looked around for a solution and there really was not one place that could help. Well finally figured out the problem and just thought I would post it in case anyone happened to run into it.
1.) install maven. I like to do everything in a local directory in my home directory. So something like ~/local/apache-maven/apache-maven-2.0.10 would be the target install directory.
2.) Fire up ~/.bash_profile in an editor and type in the following:
export M2_HOME=/Users/svemuri/local/apache-maven/apache-maven-2.0.10/
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
export PATH=M2_HOME/bin:/usr/local/bin:$JAVA_HOME:$PATH
This way the mvn and java that you specify will be the ones running and not the ones installed by default by Mac OS X. Of course you can use any of the versions that you choose to and you could point to /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home if you wish to use JDK 1.6.
This should fix the following problems:
Permission Denied when running mvn
or
NoClassDefFoundError for a Launcher class.
HTH,
Looked around for a solution and there really was not one place that could help. Well finally figured out the problem and just thought I would post it in case anyone happened to run into it.
1.) install maven. I like to do everything in a local directory in my home directory. So something like ~/local/apache-maven/apache-maven-2.0.10 would be the target install directory.
2.) Fire up ~/.bash_profile in an editor and type in the following:
export M2_HOME=/Users/svemuri/local/apache-maven/apache-maven-2.0.10/
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
export PATH=M2_HOME/bin:/usr/local/bin:$JAVA_HOME:$PATH
This way the mvn and java that you specify will be the ones running and not the ones installed by default by Mac OS X. Of course you can use any of the versions that you choose to and you could point to /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home if you wish to use JDK 1.6.
This should fix the following problems:
Permission Denied when running mvn
or
NoClassDefFoundError for a Launcher class.
HTH,
Monday, April 16, 2007
JavaONE 2007
I am attending JavaONE 2007 from May 8th - 11th at the Moscone center in San Francisco.
Finally got through with the registration. Got a headache going through all the sessions and picking the ones I want to go to!
Glad to see that we are moving towards taking some GREEN steps everywhere, here's JavaONE's commitment to being eco-friendly.
Finally got through with the registration. Got a headache going through all the sessions and picking the ones I want to go to!
Glad to see that we are moving towards taking some GREEN steps everywhere, here's JavaONE's commitment to being eco-friendly.
Sunday, April 8, 2007
Bamboo - Continuous Integration Product From Atlassian
Atlassian had come out with their continuous integration product - Bamboo a few months ago was a preview release. We recently evaluated it and used it on our project. Have to say that it is pretty good.
We use a lot of Atlassian products at work, And they are all characterized by clean, smart , modern, light yet efficient UIs.
Let's look at some of their products:
JIRA - Bug/Issue Tracking / Project Management Software(in a few ways, YES!)
There have been collaboration based software for the whole Bug/Issue tracking domain around for quite a while. I have used Bugzilla for quite a while. Mantis is one more that comes to mind. Pretty decent software, but JIRA takes it to the next level.
What's the first thing that comes to mind? Usability, it really is pleasant to use. Might not be the most feature rich product ever out there. But it is small, clean highly extensible and slick. That is something they have managed to build in across the board. Confluence, Their wiki product. Clean efficient to use and solves the purpose without any hassles.
Both of these are applications that still though having their advantages do not take the solution to the next level.
In comes Bamboo. Their Continuous Integration solution.
Bamboo takes it to the next level. Of course part of the reason could be that Cruise Control and Damage Control are the ones I am really benchmarking against.
Feature set is much richer this time around and has been put together rather beautifully. The interplay is real good. Amazingly good to look at. So that gets some brownie points. But real simple to use. Essence of what they have been doing. Working with developing web applications and looking at what extent we need to go to develop a usable product, I know how tough it can be. Some of the features are what I would label as ideas most people thought of and have always wanted but never bothered to ask for in a Continuous Integration product.
After all, a CI product is just something that plays the role of a baby sitter , right? Enforce that people do not check-in something in that does not work(not compiling or fails tests). Plain as simple as that.
But Bamboo can change some of that,. at least it gives the potential to take a better look at the quality trend that a product is following. OK, a build broke, but when was it fixed? What was the fix? Were tests commented out? What piece of code that changed was central to the issue that was the problem. Also seamless integration with JIRA allows for a one stop solution of which issue number the check in was made against. We can observe as to how often builds are breaking,. and whether we are being reactive in the approach to development of whether we are being proactive.
There are a lot of statistics that can be pulled up against your builds. A lot of people might argue that it is very little value added overall to the project. I still am yet to make a definite call either way as of now. But I would certainly not discount the use of it. Especially for us, we get an Academic License and its 600 bucks across the enterprise. The small amount of additional productivity goes a long way in terms of ROI.
We use a lot of Atlassian products at work, And they are all characterized by clean, smart , modern, light yet efficient UIs.
Let's look at some of their products:
JIRA - Bug/Issue Tracking / Project Management Software(in a few ways, YES!)
There have been collaboration based software for the whole Bug/Issue tracking domain around for quite a while. I have used Bugzilla for quite a while. Mantis is one more that comes to mind. Pretty decent software, but JIRA takes it to the next level.
What's the first thing that comes to mind? Usability, it really is pleasant to use. Might not be the most feature rich product ever out there. But it is small, clean highly extensible and slick. That is something they have managed to build in across the board. Confluence, Their wiki product. Clean efficient to use and solves the purpose without any hassles.
Both of these are applications that still though having their advantages do not take the solution to the next level.
In comes Bamboo. Their Continuous Integration solution.
Bamboo takes it to the next level. Of course part of the reason could be that Cruise Control and Damage Control are the ones I am really benchmarking against.
Feature set is much richer this time around and has been put together rather beautifully. The interplay is real good. Amazingly good to look at. So that gets some brownie points. But real simple to use. Essence of what they have been doing. Working with developing web applications and looking at what extent we need to go to develop a usable product, I know how tough it can be. Some of the features are what I would label as ideas most people thought of and have always wanted but never bothered to ask for in a Continuous Integration product.
After all, a CI product is just something that plays the role of a baby sitter , right? Enforce that people do not check-in something in that does not work(not compiling or fails tests). Plain as simple as that.
But Bamboo can change some of that,. at least it gives the potential to take a better look at the quality trend that a product is following. OK, a build broke, but when was it fixed? What was the fix? Were tests commented out? What piece of code that changed was central to the issue that was the problem. Also seamless integration with JIRA allows for a one stop solution of which issue number the check in was made against. We can observe as to how often builds are breaking,. and whether we are being reactive in the approach to development of whether we are being proactive.
There are a lot of statistics that can be pulled up against your builds. A lot of people might argue that it is very little value added overall to the project. I still am yet to make a definite call either way as of now. But I would certainly not discount the use of it. Especially for us, we get an Academic License and its 600 bucks across the enterprise. The small amount of additional productivity goes a long way in terms of ROI.
Tuesday, March 20, 2007
Using DUML for your AJAX applications
Part I
Have been wanting to write about this for quite a while, AJAX applications. Everyone's using them. #ell everyone seems to be writing them too!!
There are many flavors, frameworks and approaches all depending on the XmlHttpRequest object. But each differs in the way they use it.
The whole process is pretty simple. A call is made behind the scenes to the server and some content is returned which could take any conceivable format really. Now somehow the client DOM then has to be updated to reflect the changes in data/structure/presentation.
Complications arise because the whole browser base model was built out for one simple thing. Documents. Period. Which are very different from applications. Data although being central to applications forms only a subset.
It is amazing that we are delivering applications on this big a level on a model that really only supports documents. And it really does go a long way to proving the utter simplicity/flexibility of the whole model.
But unfortunately web applications can SEEM a little less than ideally responsive. One Small thing changes on the page and we have to load it all up. The server has to process everything, generate everything even though only one simple item might really have been changed or needs to be displayed differently. We simply keep recreating the whole page. Why? That's a DUMB way to do things. Not really,in the beginning it was a brilliant way to do things after all it was dynamic. but as all other brilliant things, it needs to improve, it needs to move on, it needs to evolve.
AJAX and its various forms are what step in to spice it all up. They allow for the submission of what can be considered an inline, on the fly request to a server. This request comes back and some amount of JS code then processes this response.
To make these things work we are now in the situation wherein we have a lot of complex UI based logic on the client side to manage the loading and display of the data that comes back from the server. We are writing mini-applications in the browser using lots of JavaScript.
There is a fair number of articles/tutorials/guides/books and blogs that talk discuss or preach the various approaches/frameworks. Most of the stuff being on the client side.
Client requests -> Server processes -> sends out response -> client processes -> DOM Manipulated.
The fourth step highlighted is the one that tends to become heavy and fat, But isn't that the goal? Are we not trying to emulate fatter clients using a real classic thin client?
Yes and Yes, but it does not have to be so. The server can still be in control of both the data it sends out and also dictating as to how the data should be structured/presented on the client.
So in comes a slightly different approach.
A few of my colleagues have been working towards building something that makes life easier for us folk. Write AJAX applications like totally normal web apps. It is quite possible that you can almost circumvent the usage of JavaScript. In comes, DUML - Document Update Markup Language.
The instructions to manipulate the client side DOM(resulting a change in the Data/Structure/Presentation) are sent back from the Server side. We do not have to write anything to process the data that comes back. A JS library(an implementation of the DUML specification) on the client side simply takes care of all this for us. It processes these instructions on the client side and builds out the DOM tree as intended by the developer. Hence it changes the application.
Let's quickly run through a small example.
Duml Based AJAX.
Ingredients:
1.) Client + Client side DUML implementation. A JS library available at DUML.org.
2.) Server side component. Handles the request and processes it and sends out the appropriate response. Dictates both the content and the presentation details.
Now, I can code my server side component using any technology I choose. It could be a Java app, It could be a .Net app, something whipped up in PHP! Irrespective of the server side technology all that needs to be spit out is XML compliant with the DUML specification. And in simpler terms all it amounts to is simple block(s) of html wrapped around in some DUML instructions.
These instructions serve as metadata for the client side JS library and define the manipulation of the DOM on the client side.
After all in a very crude way, that's all AJAX ultimately is, on the fly manipulation of the DOM based on inline requests that do not result in a total page refresh.
So say I write my web based pages in jsps. My response really needs to be XML. Or in other words it should be WF XML compliant with the DUML spec.
So there is a root node that identifies and defines that this is a DUML document. Now all the data will be sent back as regular HTML surrounded by DUML instructions as different blocks/nodes under this particular root node. Each instruction in this document sent back to the client denotes one particular operation to be performed on the client's DOM.
Say I need something on the lines of what GMail does. Every once in a while it polls the server to check for email. Whenever I get new email it should display a message in the status bar portion of my Inbox stating that I have new mail.
How would I do that?
1.) A client side submit to a page on the server. If you read up on any basic HttpXMLRequest stuff, this is pretty simple.
2.) Server side code handles the request, processes it and if it finds any new email it sends back the markup written out below. The DUML engine traps the response on the client side and then processes the set of instructions lined out in response and updates the DOM accordingly.
< duml version="1.0">
< instruction manipulation="appendChild" originnodeid="inbox" replaceifexists="true">
< div id="statusBar"> You've got Mail! </div>
< /instruction>
< /duml>
3.) So, what are we doing here? We have some node that is on the client page already as a result of some previous page refreshes or loads or AJAX calls. This node has an id of inbox. We need to add a div to this particular node that displays the message stating "You've Got Mail!".
That is all we are doing in the particular case.
How is this a good idea? Since all the updates done to the DOM were triggered by instructions sent out by the server. So all I need to write is proper instructions in Java/jsp, ASP.NET or anything that I choose in. The DOM manipulation is in a sense abstracted out and generalized to maintain the separation of concerns.
My client(browser) is truly bothered about one thing and one thing only, display, But I personally do not have to write and maintain complex script code to decide what goes where and how it looks.
Clean and clutter free. Of course it does add some complexity and added burden on the server side,. but hey,. Yes, the devil is in the details, but that's what pays the bills. :)
This is a very small introduction to DUML. It works great for us. We have a number of applications using it actively. I would say that it is still maturing and rapidly developing. I will dive into a few more details in a future article.
Please go and visit the DUML home page. Who knows, it might change your life or help you attain AJAXian Nirvana. No kidding, seriously, check it out!
I will be making this particular post a multi-part series. After all there is so much we can talk about when it comes to this. It will be my feeble attempt to supplement some of the stuff on the DUML site.
Duml and Dumler!
Have been wanting to write about this for quite a while, AJAX applications. Everyone's using them. #ell everyone seems to be writing them too!!
There are many flavors, frameworks and approaches all depending on the XmlHttpRequest object. But each differs in the way they use it.
The whole process is pretty simple. A call is made behind the scenes to the server and some content is returned which could take any conceivable format really. Now somehow the client DOM then has to be updated to reflect the changes in data/structure/presentation.
Complications arise because the whole browser base model was built out for one simple thing. Documents. Period. Which are very different from applications. Data although being central to applications forms only a subset.
It is amazing that we are delivering applications on this big a level on a model that really only supports documents. And it really does go a long way to proving the utter simplicity/flexibility of the whole model.
But unfortunately web applications can SEEM a little less than ideally responsive. One Small thing changes on the page and we have to load it all up. The server has to process everything, generate everything even though only one simple item might really have been changed or needs to be displayed differently. We simply keep recreating the whole page. Why? That's a DUMB way to do things. Not really,in the beginning it was a brilliant way to do things after all it was dynamic. but as all other brilliant things, it needs to improve, it needs to move on, it needs to evolve.
AJAX and its various forms are what step in to spice it all up. They allow for the submission of what can be considered an inline, on the fly request to a server. This request comes back and some amount of JS code then processes this response.
To make these things work we are now in the situation wherein we have a lot of complex UI based logic on the client side to manage the loading and display of the data that comes back from the server. We are writing mini-applications in the browser using lots of JavaScript.
There is a fair number of articles/tutorials/guides/books and blogs that talk discuss or preach the various approaches/frameworks. Most of the stuff being on the client side.
Client requests -> Server processes -> sends out response -> client processes -> DOM Manipulated.
The fourth step highlighted is the one that tends to become heavy and fat, But isn't that the goal? Are we not trying to emulate fatter clients using a real classic thin client?
Yes and Yes, but it does not have to be so. The server can still be in control of both the data it sends out and also dictating as to how the data should be structured/presented on the client.
So in comes a slightly different approach.
A few of my colleagues have been working towards building something that makes life easier for us folk. Write AJAX applications like totally normal web apps. It is quite possible that you can almost circumvent the usage of JavaScript. In comes, DUML - Document Update Markup Language.
It is a specification that defines a set of processing instructions to manipulate the DOM.The USP of this approach:
The instructions to manipulate the client side DOM(resulting a change in the Data/Structure/Presentation) are sent back from the Server side. We do not have to write anything to process the data that comes back. A JS library(an implementation of the DUML specification) on the client side simply takes care of all this for us. It processes these instructions on the client side and builds out the DOM tree as intended by the developer. Hence it changes the application.
Let's quickly run through a small example.
Duml Based AJAX.
Ingredients:
1.) Client + Client side DUML implementation. A JS library available at DUML.org.
2.) Server side component. Handles the request and processes it and sends out the appropriate response. Dictates both the content and the presentation details.
Now, I can code my server side component using any technology I choose. It could be a Java app, It could be a .Net app, something whipped up in PHP! Irrespective of the server side technology all that needs to be spit out is XML compliant with the DUML specification. And in simpler terms all it amounts to is simple block(s) of html wrapped around in some DUML instructions.
These instructions serve as metadata for the client side JS library and define the manipulation of the DOM on the client side.
After all in a very crude way, that's all AJAX ultimately is, on the fly manipulation of the DOM based on inline requests that do not result in a total page refresh.
So say I write my web based pages in jsps. My response really needs to be XML. Or in other words it should be WF XML compliant with the DUML spec.
So there is a root node that identifies and defines that this is a DUML document. Now all the data will be sent back as regular HTML surrounded by DUML instructions as different blocks/nodes under this particular root node. Each instruction in this document sent back to the client denotes one particular operation to be performed on the client's DOM.
Say I need something on the lines of what GMail does. Every once in a while it polls the server to check for email. Whenever I get new email it should display a message in the status bar portion of my Inbox stating that I have new mail.
How would I do that?
1.) A client side submit to a page on the server. If you read up on any basic HttpXMLRequest stuff, this is pretty simple.
2.) Server side code handles the request, processes it and if it finds any new email it sends back the markup written out below. The DUML engine traps the response on the client side and then processes the set of instructions lined out in response and updates the DOM accordingly.
< duml version="1.0">
< instruction manipulation="appendChild" originnodeid="inbox" replaceifexists="true">
< div id="statusBar"> You've got Mail! </div>
< /instruction>
< /duml>
3.) So, what are we doing here? We have some node that is on the client page already as a result of some previous page refreshes or loads or AJAX calls. This node has an id of inbox. We need to add a div to this particular node that displays the message stating "You've Got Mail!".
That is all we are doing in the particular case.
How is this a good idea? Since all the updates done to the DOM were triggered by instructions sent out by the server. So all I need to write is proper instructions in Java/jsp, ASP.NET or anything that I choose in. The DOM manipulation is in a sense abstracted out and generalized to maintain the separation of concerns.
My client(browser) is truly bothered about one thing and one thing only, display, But I personally do not have to write and maintain complex script code to decide what goes where and how it looks.
Clean and clutter free. Of course it does add some complexity and added burden on the server side,. but hey,. Yes, the devil is in the details, but that's what pays the bills. :)
This is a very small introduction to DUML. It works great for us. We have a number of applications using it actively. I would say that it is still maturing and rapidly developing. I will dive into a few more details in a future article.
Please go and visit the DUML home page. Who knows, it might change your life or help you attain AJAXian Nirvana. No kidding, seriously, check it out!
I will be making this particular post a multi-part series. After all there is so much we can talk about when it comes to this. It will be my feeble attempt to supplement some of the stuff on the DUML site.
Duml and Dumler!
Saturday, February 17, 2007
Enso - Get Humanized
Enso: Something I just took a look at recently.
When will Operating Systems become more than simply an interface between the hardware and the Applications that run on the machine and really an interface between the user and the applications? There are these bunch of macros; I use the term loosely for lack of another appropriate term at my disposal; that really are cross applications. .
It is frustrating at times as to why this is not the case. I have to install 3-4 programs to really get to use my OS and the gazillion other addons to their fullest, a more convenient application launcher, a more convenient search, and each of these needs to be something that is quickly accessible right at the touch of a couple of keystrokes.
This particular pseudo rant is triggered off by taking a look at Enso, WHY is something like this not part of my explorer shell for example? WHY? is it that big a deal, NO! Part of the problem is that this is savvy and power user stuff. But I look around myself and more and more people are getting there. People are realizing the power of commandline stuff, writing scripts, avoiding having to do repetitive stuff simple yet stupidly repetitive,..
At work too, I got a friend of mine hooked onto using the GNU tools for Windows and a few of the other timesavers, but all said and done they still meet very very specific needs, we definitely need more generic ones that meet our requirements, across applications and are more extensible. They are a little more cumbersome to use, and the functionality that they offer; sometimes I need from within a text editor itself. Some of what Enso does is something that is replicated across multiple applications, why this should not be part of the OS shell(Explorer style) I do not understand.
If you are developing software, as I do, Neal Ford's Productive Programmer is a good read if you find yourself doing the same thing over and over and if you want to gain an extra 20 minutes(at the very least) a day. I attended his presentation on the same, and as keyboard happy I thought I was I did pick up a few tricks. Thanks Neal.
Enso's a great start, and I do think that in part it does seem to be a one thing fits all solutions, but it still is a different app! I need it to be part of my OS/shell, better integrated with the internals.
When will Operating Systems become more than simply an interface between the hardware and the Applications that run on the machine and really an interface between the user and the applications? There are these bunch of macros; I use the term loosely for lack of another appropriate term at my disposal; that really are cross applications. .
It is frustrating at times as to why this is not the case. I have to install 3-4 programs to really get to use my OS and the gazillion other addons to their fullest, a more convenient application launcher, a more convenient search, and each of these needs to be something that is quickly accessible right at the touch of a couple of keystrokes.
This particular pseudo rant is triggered off by taking a look at Enso, WHY is something like this not part of my explorer shell for example? WHY? is it that big a deal, NO! Part of the problem is that this is savvy and power user stuff. But I look around myself and more and more people are getting there. People are realizing the power of commandline stuff, writing scripts, avoiding having to do repetitive stuff simple yet stupidly repetitive,..
At work too, I got a friend of mine hooked onto using the GNU tools for Windows and a few of the other timesavers, but all said and done they still meet very very specific needs, we definitely need more generic ones that meet our requirements, across applications and are more extensible. They are a little more cumbersome to use, and the functionality that they offer; sometimes I need from within a text editor itself. Some of what Enso does is something that is replicated across multiple applications, why this should not be part of the OS shell(Explorer style) I do not understand.
If you are developing software, as I do, Neal Ford's Productive Programmer is a good read if you find yourself doing the same thing over and over and if you want to gain an extra 20 minutes(at the very least) a day. I attended his presentation on the same, and as keyboard happy I thought I was I did pick up a few tricks. Thanks Neal.
Enso's a great start, and I do think that in part it does seem to be a one thing fits all solutions, but it still is a different app! I need it to be part of my OS/shell, better integrated with the internals.
Subscribe to:
Posts (Atom)