Raible Designs

[DJUG] JUG Central and BPEL

Last night, I attended Denver's JUG meeting. Below are my notes from the event.

I'm at DJUG listening to Christian and Kris (from Adigio) talk about their experience with using Spring, WebWork, Hibernate, Lucene and SiteMesh to develop JUG Central (I wonder if they knew this name and concept already exists?). JSPs are for the view and MySQL powers the data. This presentation is designed to explain a bit about each framework, and also tips/tricks and pitfalls they experienced when developing the site. They started working on the application in August of last year and deployed it into production in December.

Christian said they weren't going to go into the how for each framework, but Kris has had quite a few slides on SiteMesh so far. I don't blame him - it's a great tool and only a handful of folks (of about 50-60) have heard of it.

SiteMesh Pitfalls: Poor integration with Velocity and some other frameworks. BTW, if you're using Tapestry - Erik Hatcher recently created a JIRA patch with a Tapestry Decorator.

Now Kris is talking about WebWork and since he's a framework junkie, apparently this is going to be the largest part of the presentation. I think one of the nicest parts of WebWork is its auto-type conversion. The only other frameworks I've seen that have this is are JSF and Tapestry. For those that like WebWork and don't like JSF - you might find it disturbing that the WebWork actions (and their tests) in AppFuse are very similar to the JSF managed beans. I would take it as a compliment if I were a WebWork developer.

One nice thing about XWork's action configuration is you can specify a "method" parameter for a particular action. Struts recently added this with its MappingDispatchAction. I'm using this on my current project and it works quite well. Kris really likes WebWork's front-page controller pattern - where you use the <ww:action> tag to execute the action when the page is loaded. Personally, I don't have a problem with going through actions to get to my view templates. Kris finished up his WebWork piece with a plug for AppFuse (thanks!) and WebWork in Action. Congrats to all the authors - wonder if it'll be published before WebWork Live?

Now Christian is talking about Hibernate and its mapping files - and how you can generate your database schema from them - or generate your mapping files from a database. They used XDoclet to generate the mapping files in this particular project.

Hibernate Pitfalls: Think about lazy-loading early. Problems arise when you try to share Hibernate-managed objects across (Hibernate) sessions transparently. Christian mentions that Spring's OpenSessionInViewFilter is a nice way to solve the problem.

Hibernate Tips: Spring simplifies using Hibernate and makes declarative transactions easy. Read Hibernate in Action before starting development. Plan to spend some time learning how to express your data model with Hibernate relationships (one-to-one, one-to-many, many-to-many, etc.).

Christian is now talking about Spring and how it works. After thinking and writing about Spring so much in the last year, I'll just skip over regurgitating this part. ;-) His main recommendation: use real injection instead of appContext.getBean("beanName").

Other tools used: Lucene for searching and POI for indexing Word, Excel and PowerPoint files. Velocity used for templating e-mail messages.

Service-oriented Architecture (SOA) with Business Process Execution Language (BPEL)
Presented by Kevin Geminiuc and Owen Newnan from Policy Studies

This point of this presentation is to communicate what it's like to implement BPEL in a J2EE Container. BPEL is a layer on top of web services. BPEL is a programming language that you can use to program business processes. Allows you to divorce your business process from being human-centric to being document-centric. At Policy Studies, they're using iLog JRules rules engine and Oracle's BPEL implementation.

Benefits:

• Process Visiblity
• Process Agility
• Powerful Language
• Open
• Backed by "the Big Boys" (BEA, Microsoft, IBM)

History: Formerly knows as BPEL4WS, WSBPEL. Open standards based. Orchestrates web services with SOA.

Where we are today: Emerging technology (prepare to bang your head against the wall). .NET and Java products exist, as well as J2EE container integration.

BPEL & WS Standards: BPEL, XPath, WSDL, WS-Addressing, SOAP, XML-Schema, WSIF (Axis), TBD (WS-ReliableMessaging and JSRs 207/208). Note that since BPEL depends on web services (which is not a truly reliable service). Because of this, there are some proprietary extensions available.

At this point, I became bored with the presentation and quit taking notes. While the speakers had good intentions with their knowledge sharing, their delivery needed some work. The code walkthrough and demos were presented with a monotonous and unexcited tone, and a handful of folks left during this part. In summary, BPEL looks like a good way to orchestrate your various business processes. It allows you to call web services, EJBs and whatnot simply by defining their locations and methods in XML.

In his demo, Kevin used Oracle's BPEL Designer, which is an Eclipse plugin that has a nice drag-n-drop editor for managing your BPEL XML files. He also used Oracle's BPEL Process Manager, which seemed to be a lot like Jetspeed - you just drop in the .ear and then deploy your processes to it. The only bad part about the Process Manager is it's administration/deployment interface only runs in IE.

If you're using BPEL in your projects, I'd be interested to hear the tools you're using. As far as open-source BPEL process engines, they mentioned Twister and ActiveBPEL.

Denver's No Fluff Just Stuff starts today

It's time for another NFJS conference. I attended the one in June and had an awesome experience. I doubt I'll cover it as much as I did last time, that's just a lot of work - not to mention my cell phone's data bill was $300! As I look through the sessions, I'm noticing that it's a great thing to attend 2 of these conferences - b/c you can skip all the sessions you saw the first time. Since there's usually 2-3 good ones per time slot, reducing that down to 1-2 is nice.

This afternoon, I'm planning to attend sessions by Erik Hatcher and Stuart Halloway. Erik for Ant 1.6 and Subversion (maybe even Lucene) and Stuart for "dynamic, reflective languages". Since much of AppFuse's build.xml is based on Erik's Java Dev with Ant sample app, it'd be nice to figure out how to take advantage of 1.6 features (especially since 1.6.2 is required). I've never seen Stuart speak before, but I've heard he's excellent.

Saturday I plan on learning more about Tapestry from Erik (in a 3-hour session!). Since adding Tapestry to AppFuse is my next open-source development effort, this weekend and ApacheCon are good opportunities to learn more about it. I know, I should just buck up and read the book (I made it to page 100 a couple of weeks ago, nothing since), but it's tough to find the time.

I'll probably skip out tomorrow afternoon and work on Spring Live since Chapter 10 is due by Monday and I'm not done yet. Sunday, I'll be talking about AppFuse making open-source easier. "Brain, get ready to be stuffed."

Tapestry and Hibernate Tutorial

Wanna use Hibernate with your Tapestry application? Or maybe learn about Tapestry for the first time? If so, Warner has a great set of tutorials. His first tutorial on creating a CRUD application with Tapestry was exactly what I needed - right when I needed it - thanks Warner! I'm looking forward to his next tutorials, especially Spring, Hivemind and Lucene. Integrating Spring with Tapestry is pretty simple - we'll have to see how Hivemind compares.

A few thoughts on AppFuse

I've been thinking about how to structure AppFuse for the upcoming Spring and iBatis enhancements. These enhancements shouldn't require any directory structure changes. However, I've received some suggestions to change the common, ejb and web directory structure to be a little more inline with the tiers. So it would become something more like database, business and web (or dao, service and web). After thinking about this for the last couple of days, it seems to make sense. I picked up the notion of common from Erik Hatcher's JavaDevWithAnt, which I borrowed heavily from when creating AppFuse. Erik used common because this represented classes that would be included in both the web tier and the EJB tier. But since I (currently) don't plan on every adding EJBs to AppFuse, does it make sense? Even if I did, I'd probably only use SessionBeans, and those could easily fit into the service layer. The nice thing about moving the business layer (currently in web/**/services) to it's own directory is that it will get it's own JAR (with hardly any modifications to build.xml) and can be used outside of the webapp.

The nice thing about isolating the web directory to web-only classes is I can use Ant to replace any Struts-specific classes with WebWork or Tapestry. To prevent AppFuse from being cluttered with too many options, it'll ship with Struts out-of-the-box. If users want WebWork for their framework, they can download a WebWork version of the web-tier and run an Ant target that will replace all the Struts stuff with WebWorks stuff. It seems like the cleanest way to do web framework switching.

Another thing that might happen to AppFuse, caused by my enthusiasm to try out everything, is that it will contain too much stuff for a basic web application. It currently has security and user management built in, which is what most webapps need. I recently added in OSCache and Clickstream. OSCache is not enabled, but most webapps can probably use it somewhere. Clickstream is a different story. For most of the webapps I've built, this is not needed at all. Most of the apps are no more than 20 screens, and it's unlikely the client will care where people go the most. Another option that deserves ripping out is the idea of Struts' submodules. I tend to rip this out as the first thing when starting a new project. File Upload is something I've used rarely, so I should probably lose that feature too.

There are also other technologies that I've thought of adding to AppFuse, namely Quartz and Lucene. However, I've only used Quartz on 1 of my last 5 projects and Lucene on 2 - so obviously these might be considered bloat for a basic webapp. I think the best thing would be to implement these in AppFuse, on my own, and then document how I did it on the wiki (for an example, see diagramming build.xml with Vizant). If folks need to use it they can add it on their own. Documentation is always good, and if I can just document how to add stuff, I can certainly reduce the bloat.

Whaddya think - is it better to include options out-of-the-box or simply document them? Should I restructure the directories to match the tiers more?

Roller Searching - Powered by Lucene

Thanks to Min, we now have searching in Roller. He wrote a wicked-ass Lucene implementation using the util.concurrent package from Doug Lea. Here's how it works:

• When Roller starts, it checks to see if the index is OK, and if not, rebuilds it. The index then goes into RAM and stays there until you destroy the servlet context - then it's written to disk. The location is configurable, but defaults to $(user.home} + File.separator + "roller-index".
• A user's index is updated when they add/delete weblog entries.
• A user can rebuild their own index via a button on the Website Settings page.
• An Admin can rebuild a user's index from the "Admin" page and rebuild all users' indexes from the Config page.
• The IndexManager is the central entry point, and it lives in RollerContext.getIndexManager(). For indexing, searching, etc. you use one of the following operations:
  
  - AddWeblogOperation
  - RebuildUserIndexOperation
  - RemoveWeblogOperation
  - SearchOperation
  
  After creating these ops, set any op-specific configuration options and then pass it to the IndexManager.executeIndexOperation() method.
• Behind the scenes, there is an background thread running. This thread only performs one operation at a time. If an op is added when the thread it busy, the op will be queued. The way Lucene works is that most operations can be threaded. Lucene supports the concept of add, delete, read, query, and optimize. The only methods that cannot be active at the same time are IndexReader::delete() and IndexWriter::add(). Therefore, the operations that perform these operations are put into the background thread queue that garantees that these ops wont be performed at the same time. Searching doesn't interfere with these ops, so it can be run in any thread.

I created a #showSearchForm macro that renders a <form> with a textbox (size=20) and a "Search" submit button. I also added this to all the current themes - so if you developed a theme for Roller - you might want to check it out (username: test, passwd: roller). You can edit it right on the site if you want, then copy/send me the adjusted files. CSS seems to need the most tweaking for these to look right.

Please enter any bugs/enhancements in Roller's JIRA instance. The only one I've seen so far is that a user has to build their index manually before they get any search results. I don't know that this is a bug, just wanted to mention it. Doesn't get comments yet either - a NPE from weblogMgr.getComments() (when adding a new post) kept me banging my head against the wall for an hour - so I commented it out.

Try it, you might like it. ;-)

2 minutes later: Here's a bug - if you update an entry numerous times, it will get presented as numerous times (should be deleted and re-indexed).

Luke - Lucene Index Browser

If you're working with Lucene, and you need an easy way to inspect your index, checkout Luke.

Luke is a handy development and diagnostic tool, which accesses already existing Lucene indexes and allows you to display their contents in several ways:

• browse by document number, or by term
• view documents / copy to clipboard
• retrieve a ranked list of most frequent terms
• execute a search, and browse the results
• selectively delete documents from the index

Added Google search to this theme

The idea hit me like a cold beer pouring down my throat on a hot summer day. Crisp, clean and exciting. I've been wanting to add a search form to this theme, but I didn't want to add another tab, and putting it anywhere in the header would conflict with the background image. And then I spotted the perfect spot. Right under the categories, in the banner of the first entry on this page. With a little love from the DOM, you can now search this site using this theme and Google. Here's the relevant code that I added to the bottom of this theme.

<div id="search" style="display:none; margin-top: -17px; text-align: right">
    <form id="searchForm" method="get" action="http://www.google.com/search"
        onsubmit="return search()" style="margin: 0; padding: 0">  
        <input type="text" id="q" name="q" size="20" maxlength="255"
            value="search this site" onclick="this.value=''" /> 
</div>
<script type="text/javascript">
    // get the first entry shown in the page and append the
    // hidden 'search' div from above
    document.getElementById("entries")
            .getElementsByTagName("div")[0]
            .appendChild(document.getElementById("search"));
    toggle("search");
    function search() {
        form = document.getElementById("searchForm");
        if (form.q.value == "search this site" || form.q.value == "") {
            alert("Please enter a search term to continue.");
            form.q.focus();
            return false;
        } else {
            form.q.value = form.q.value + " site:www.raibledesigns.com";
            form.submit();
        }
    }
</script>

Boy oh boy does the DOM make it easy to do web sites! Seems to work in all the browsers I use regularly (IE/Moz on Win, Camino/Safari on Mac). It doesn't work in Opera 6, but does in Opera 7. Now back to that cold beer - I'm gettin' thirsty...

Java Development with Ant, The Application

If you've been fortunate enough to read Erik Hatcher's Java Development with Ant, you know that there's tons of good tips in it. I read it and I've been recommending it every since. Erik has been continuing development of the sample app for the book ever since it was released. I got many tips from Erik in developing AppFuse and I have to say, it really is a nice example. Maybe I'll get some more stuff now that it appears to have jumped from version 0.4 to 0.9! Here's a message Erik sent about the latest release.

All -

I'm proud (and worried about the support e-mails! :) to announce the 
near-final release of a project demonstrating Ant, XDoclet, Struts, 
JUnit, Cactus, and Lucene.  Its called JavaDevWithAnt as it was written 
for the book Steve and I co-authored and has been refined during 
several presentations I've been giving on Ant, XDoclet and Struts.

The documentation is in draft stage, and my primary goal is to collect 
feedback on polishing the documentation (and the application if there 
are any bugs that surface).  The site where I'm hosting the 
distribution and documentation is:

	http://www.ehatchersolutions.com/JavaDevWithAnt/

Please let me know if you try it out and have suggestions for 
improvement, or just to let me know you tried it and hate it or love 
it, etc.  Feedback more than welcome!  Direct feedback to me at 
[email protected]

	Erik

p.s. Since this e-mail is directed to the XDoclet, Lucene, and Cactus 
lists, here is a brief teaser for you:

XDoclet - its used extensively, even using a custom tag handler to 
generate starter JSP's from Struts form beans.

Lucene - my <index> Ant task is used to index text and HTML files, and 
Lucene's API is used at run-time to query the index.

Cactus - StrutsTestCase is used, although no direct Cactus tests.

Happy information-overload! There's a lot there, but if I could figure it out - I'm sure you can. Erik - finally on Jaguar eh? What took you so long ;-)

Erik's Struts/XDoclet example application

Erik Hatcher has released his "much hyped and long awaited sample application" demonstrating how to generate some Struts goodness with XDoclet. You'll be happy to know that I've been swapping e-mails with Erik a lot in the past couple weeks - so my struts-xdoclet app is very similar. Here are the details:

It is a trimmed down version of the application Steve and I developed
for our Java Development with Ant book.

Relevant to Struts folks are these tidbits:

  - XDoclet is generating struts-config.xml, validation.xml, web.xml, 
and antbook.tld

  - LabelTag (currently mysteriously busted for required tagging) is 
included.  This tag styles field labels differently if its in error, and 
(when its not busted, it works on my production app actually) it shows 
an asterisk by required fields.

  - strutsgen: a one-off starter generation for JSP's and 
ApplicationResources.properties snippets for cutting and pasting into 
the main application.  It uses XDoclet to process a specified form bean 
and uses the fields it finds for generation.

  - Use of StrutsTestCase for Cactus testing.

  - Maybe some other Struts goodies lurking there that I've forgotten to 
mention.

The application itself is a document search engine, based on Lucene, and 
should run out of the box in Tomcat or JBoss.  It even has the ability 
to (at build time) toggle between whether to use a session bean or not 
(functionality is the same either way).  By default, you can simply 
deploy the WAR that you've built and it will work without EJB, but if 
you are interested in exploring the session bean piece it can be turned on.

I am in the process of creating much more detailed documentation, but I 
wanted to get this out sooner rather than later.  If you find any 
problems or have any questions, please do not hesitate to let me know so 
I can refine it and post updates.

The one documentation I need to provide now is to note that you'll need 
j2ee.jar to build.  I include all other API's.  To build, unzip the file 
(link below) and it will expand into JavaDevWithAnt directory.  In that 
directory, run Ant.  If you have J2EE_HOME set you shouldn't need to do 
anything... just "ant".  You'll also need to build a site index, so run 
"ant build-site-index".  This is intentionally two separate steps.  If 
you don't have J2EE_HOME set, then you need to provide j2ee.jar to the 
build.  Do it this way:

	ant -Dj2ee.jar=/path/to/my/j2ee.jar

Where "/path/to/my/j2ee.jar" is the actual path to your j2ee.jar

Post any questions/problems to me directly.  E-mail me at 
[email protected].

Download: http://www.ehatchersolutions.com/downloads/

You will need JUnit 3.8(.1) as I take advantage of the new lack of 
required String-arg constructors.  junit.jar should live in 
ANT_HOME/lib.  Ant 1.5(.1) is required also.

There will be updates in the next week or so as I polish the 
documentation and address any issues that turn up.

	Erik

Struts-XDoclet 0.2

I've posted an updated version of struts-xdoclet. I spent most of the day trying to get my build.xml and directory structure in line with Erik Hatcher's. He is planning on releasing a sample app based on his Ant book later this week, so I want to be relatively similar in our approaches. His app is a best-practices app for using Ant, JUnit and Lucene - while mine is more geared for Struts, Security and UI/Persistence Generation. I don't know if I'll commit to saying it's a best-practices app, but it's filled with a number of things I've learned in my Struts projects. I'd like to think of it as a kickstart app - kind of like struts-blank.war, but with more meat.

One of the things I discussed with Erik today was that I'd like to add the ability to choose Castor, Hibernate, EJB, or DAO with some switches in the build script. Yeah, that'll only take me until March to get done, so don't hold your breath! His response was to take a look http://www.keelframework.org/. The idea of it, supposedly, is being able to take the same business logic and swap out UI and persistence tiers easily. I guess it was started by the Expresso Team. Hmmm, I don't know if that is good or bad. I shied away from Expresso when I saw that they promoted putting a bunch of HTML into your Java classes.