Patrick Lightbody: Java

WebWork 2.0 Coming Along

Thu, 23 Jan 2003 09:11:19 GMT

So everyone has decided on the WebWork 2.0 Mission Statement and the XWork 1.0 Mission Statement (thanks to Jason Carreira for wording these statements so nicely). This means that development on both platforms will now begin to roll ahead. In fact, just tonight I did a few things for WebWork:

Added simple PropertyTag and PushTag implementations
Added a FilterDispatcher that allows you to access a view of the action and have the action itself execute. This means that SimpleCounter.action and success.jsp will have the same effect when accessed from the browser. They can both be running in your web app together, or you can choose to use only the *.action way, or the view way. Whatever you want!

Jason has also put in some nice validation stuff in to XWork that is worth checking out. We're going to see if FormProc would be a good fit here as well.

WebWork 2.0 and SiteMesh

Thu, 16 Jan 2003 07:37:23 GMT

Now that I'm toying with the idea of WebWork 2.0 and XWork, I'd like to mention that I've been thinking about using SiteMesh to replace the IncludeTag stuff in WebWork 1.x. They have a very strong overlap, but SiteMesh is a bit more powerful and it'd be great to make use of SiteMesh in an area other than what it's famous for (the PageFilter). Don't have time for an example of the overlap, but maybe later I'll put one up if someone asks.

What about XWork AND WebWork

Thu, 16 Jan 2003 07:34:14 GMT

I got an idea today (it was entirely my idea, no one else suggested it first -- hehe, J.O.): What if XWork and WebWork were both developed actively and released as seperate projects? XWork would be the "kernel" for WebWork and would focus entirely on non-web-related stuff. Essentially, it would be be nothing more than a generic command pattern framework as well as a nice lifecycle/IoC system (thanks again, JoeW) similar to Avalon. But the point is that it'd be small. In fact, I built this in sandbox and it came out to 1500 lines of code and only 32KB as a jar file.

Then there would be WebWork, which would include a ServletDispatcher, better configuration settings for the web, and a huge amount of focus on the the taglibs and macros for JSP and Velocity. This would include Jasper Reports stuff as well, and all that jazz. And of course, WebWork 2.0 would depend on XWork 1.0 (which, as stated above, would be a tiny jar file)

I think that this would solve the complaints of both parties ("it won't be web-specific enough" and "it won't be generic enough") and would allow for both projects to bloom in the direction that they should. I don't think that this is a far-fetched idea. In fact, I know it's possible and I think it'll work out well. I've already made a "webwork" subdirectory in the sandbox CVS module and moved the web-specific stuff of XWork in there.

Any thoughts?

Ant console

Thu, 16 Jan 2003 07:24:45 GMT

Anyone know why there hasn't been a nice ant task that essentially gives the user a little text input field where they can type in task names and have them executed? This would be just like the maven console, but of course for ant. Would make building apps even quicker, since we could keep the ant process running and just press "[up-arrow] [enter]" to rebuild. Of course, this is for when you aren't using it with IDEA... you ARE doing that, right?

Setting it straight: What is XWork?

Tue, 14 Jan 2003 23:18:17 GMT

So I saw today that there was a blog entry discussing XWork and that it might be less powerful for the web... or less powerful as a command framework. And I'm not saying David is the one who things this, he's meerly interpreting the nonsense that is going on the WebWork mailing list. About a month ago I emailed the "OpenSymphony" mailing lists stating that I would no longer participate in the flamefests that so often appear on the list. Of course, I still continue to developer for a ton of the projects there and I respond to all the emails as possible (as long as they aren't pointless flames).

With that said, you may or may not know that I'm the main driver of XWork right now. I've been the one who's been mucking around in the sandbox CVS module and making lots of changes. Some have been controversial (like switching the action context from ThreadLocal to a simple Map), but the point I've made all along is that this is a play pen. A place for various developers (such as Rickard and Jason) to toy with as well. It's a very loose process that I think can work very well if the damn idiots would stop screaming and just let things play out. Once we're ready to present something, if it sitll sucks, then bitching and moaning is acceptable. Anyway, enough about the sandbox module politics, now on to what XWork is all about...

As nice as WebWork is, it has a lot of problems. In many cases, it's over engineered (just look at BeanUtil). The configuration scheme used in it can be clearly seen as one that started simple and slowly evolved but never quite grew up. What I wanted to do with XWork was start with a clean slate in terms of code, and then re-build the great ideas in WebWork, but this time go through and do it in a manner that was a much cleaner implementation. Yes, it will be a great command framework, similar to Avalon, in fact. But let me make this next part clear: it will work better for the web than WebWork does as well.

The code in CVS currently behaves just like WebWork and has all the web-based features WebWork had. But right off the bat it does one thing better: type conversion. Since the web uses Strings for inputs of all forms, inputting "YYYY/mm/DD" and having it converted to a Date object in your Action is a nice feature. WebWork did this, and it was nice. WebWork even (after my constant badgering, Matt was kind enough to get this in even during his busy sschedule) could get the Date object as a String value of "YYYY/mm/DD". But the problem here is that you couldn't customize type conversion on a per-Action or per-Attribute level. Type conversion was very static and limited. So what I did in XWork was include type conversion in the very core: The Configuration object.

But type conversion by itself is a weak argument. I know. If that was it, I would have just proposed we fix up WebWork's type conversion and possible configuration and that's it. But XWork is so much more. There are now Interceptor and Inversion of Control patterns represented (thanks Jason and JoeW!). The expression language uses Ognl, which is (arguably) much better than the old WW EL. The dispatcher code has been simplified down to the point that all you need to do is the following to have an action invocation execute:

Dispatcher d = new Dispatcher("FooAction");
// the action has already executed at this point, 
// including the View, such as an action chain
// or HttpServlet request dispatcher or redirect
String result = d.getResult(); // might be "success"
FooAction foo = (FooAction) d.getAction();
OgnlValueStack vs = d.getStack();

So what this means is that in order to execute an action, all you really need to do is "new Dispatch()" and that's it. This makes using actions in a generic framework very easy. But it doesn't hurt XWork from being fantastic in the Web context. While I haven't written any taglibs yet, I have made sure that an example WAR will be part of the main deployment. So please, please, don't think that XWork is ditching the web, or that XWork won't be generic enough to justify a name change from WebWork 2.0. It's possible to achieve both goals.

And if you don't believe me, instead of sending out some flaming email to the list, I suggest you download the sources, and try to write up some use cases that won't work with the current source. Then email the list with your findings and we'll address it, because that's what we're looking for with this sandbox approach. I don't really want to hear from people that won't take at least a fraction of the time I've invested. That's not to say that I won't address their concerns, but their concerns won't take a priority at this stage. And for anyone who hasn't figured it out yet, this stage is considered exploratory.

So please... I ask anyone that cares... remember, actions speak much louder than words. And even louder than flamefests. This is sandbox, go make a mess, that's what it's there for.

OSUser - Overhaul

Thu, 09 Jan 2003 04:09:57 GMT

So work has finally begun on the real OSUser overhaul -- it's going to rule! David Smiley and Phillip Mudd have started some serious work. You can find it in the CVS module "sandbox" in the subdirection "osuser". I'm VERY excited about this!

Commons Digester

Tue, 07 Jan 2003 04:45:58 GMT

Just saw what Digester is all about... damn it's cool. I'll make sure that all my "OpenSymphony" configs switch to using it (unless it has like a million dependencies).

Calling all Orion users

Tue, 07 Jan 2003 04:45:12 GMT

Anyone actually ever get Orion to auto-compile sources? Can it see when sources change, then compile and redeploy?

OSWorkflow query support

Sat, 04 Jan 2003 20:58:51 GMT

OSWorkflow 2.5 is coming right along. The biggest thing that will be in this release will be query support. I've already got it implemented in the MemoryWorkflowStore and it is demonstrated in the example web app (which btw, will also be beefed up in the next release). I'm not entirely sure how dynamic queries can be implemented in EJB -- this is a tough problem. JDBC and Ofbiz won't be very hard at all, however.

This brings me to another idea: what about using Lucene for workflow queries? Is that even possible? Could a query like, "find me all workflows where bob is the owner of the current step 'Review'"? My main problem is the relationship between a Workflow entry and it's steps might be hard to feed to Lucene:

One WorkflowEntry has many CurrentSteps and also has many HistorySteps. Not sure how Lucene could handle this... or maybe I'm asking too much.

Resin sorta works

Tue, 31 Dec 2002 18:38:04 GMT

An ugly hack that can still let me get almost what I want with quick development was to make a proxy to transactions and then turn them off for Resin. Ugly, not production quality, but lets me get almost all of what I need. Still not very happy about the sad state of app servers, especially Orion since it offers features that don't seem to work and otherwise would be everything I need. But I guess that's the story of Orion... it's always just "almost perfect".

Why do all app servers suck?

Tue, 31 Dec 2002 18:29:03 GMT

OK, after thinking I'd found the holy grail of super quick webapp development (see previous story), I found that Resin's JTA implementation is the pits. Great. So I tried to apply the same technique to Orion. Except that Orion doesn't have any feature in orion-web.xml to let it deploy from my src structure (outlined below). Specifically, it can't be told where WEB-INF/lib is, where-as Resin and Jetty can. Also, Orion (even though the options are there in orion-web.xml) doesn't seem to see my source changes (or class changes even!) and redeploy the webapp. Great.

Jetty and Tomcat are a no-go, because that would mean I have to use Tyrex, which I refuse to do. JBoss+Jetty might work, but is hard to get working inside of IDEA and also still doesn't solve the redeploy issue I'm trying to address.

So here's by directory structure:

build/java (IDEA compiles classes here)
src/java (sources)
src/webapp (complete webapp, minus WEB-INF/classes and WEB-INF/lib)
lib/core (what will become WEB-INF/lib)

I'm sure a lot of you see a familiar structure here (a la maven, but not quite maven). Any thoughts of how I can get a good app server (say, Orion) to quickly redeploy (I'm fine if I having to touch web.xml, I can automate this with an ant task that automatically runs after compile) while also running within IDEA (that's key for me)? Another problem with Orion was that the classpaths that IDEA sets up when running Orion inside of IDEA screw up Orions ClassLoaders, and so touching web.xml has no effect. Sigh, I give up.

Anyone got any tips to share?

More on Resin + IDEA

Mon, 30 Dec 2002 19:58:00 GMT

I was pointed to check out the Resin plugin for IDEA, but I found that it still wasn't as nice as launching Resin from within IDEA using the technique I described in my last post. Basically, using the plugin gets you JSP debugging, but the debugger and overall integration (especially in terms of libraries and classpath stuff) is not as tight as it is in the way I described. Either way is great though and totally speeds up development. If you're still running ant or maven targets that build a war file and then redeploying that each time, you need to move in to the 21st century ;)

Resin Speeds up Web Development!

Mon, 30 Dec 2002 06:35:46 GMT

During the last couple of weeks I've been playing with news ways to speed up development on webapps, and through a tip by Joe Walnes, I found that using Resin speeds up development by a great deal! Basically, here's what I've done:

Using IDEA, I placed all the resin libraries in my classpath (make a Library called Resin so you can use it in all your projects)
Then make a local application configuration inside of IDEA called "Resin" with the following settings:

class - com.caucho.server.http.HttpServer
VM params - -Dresin.home=.
program params - -conf resin.conf

Lastly, you need a resin.conf file in your root project directory. You can take the default resin.conf file and trim it down, but some key settings you need are:

servlet-classloader-hack - true
doc-dir - src/webapp
make your webapp id be "/" (the root)
classpath id='../../build/java', source='../java', compile='true' (inside of webapp)
place extra classpath elements to where your settings, such as osworkflow.xml, might be

That's it! Fire up resin and if all goes well it'll automatically recompile your sources every time you make a change and then redeploy the app. The end result is that working on your java classes becomes as simple to work with as JSPs are, especially since IDEA saves the files when you switch to your browser, and Resin reloads the classes on the next HTTP request.

The only problem I ran in to is if a third party libary (say, WebWork) is invoking one of your classes, after a reload you might start getting ClassCastExceptions. To get around that you need to add a classpath entry to the jar file (webwork.jar, for instance) in resin.conf.

AOP - A simple tutorial

Fri, 22 Nov 2002 08:07:45 GMT

I've taken absolutely zero time to learn about AOP, but since it seems to be one of the latest buzzwords in BlogLand (along with Maven and Jelly), I wonder if anyone is willing to provide a VERY simple tutorial/description of AOP, with maybe a few simple code examples. Or got any place where I can read up on this? I guess my lazziness is getting the best of me.

FreeRoller acting up?

Fri, 22 Nov 2002 08:06:08 GMT

Maybe it's just me, put are all the blogs that are using FreeRoller totally screwing up with their RSS feeds? I get the strangest RSS behavior from folks like Rickard, Ara, and Anthony. Makes it hard to see what's new and what is from October. I believe Mike just commented on a FreeRoller post from October, maybe he is having the same trouble?

JIRA 2.0 EAP

Fri, 15 Nov 2002 07:51:53 GMT

Awesome, JIRA 2.0 EAP release #1 is out, get it while it's hot! The biggest feature (for me, but of course, I'm biased) is the addition of workflow :)

http://www.atlassian.com/software/jira/eap/

More on Ognl, XWork

Fri, 01 Nov 2002 17:16:53 GMT

So Drew Davidson (one of the "Ognl" guys) is going to be releasing version 2.3.0 very soon (possibly today) which will include type conversion both to and from beans. This is great news, and means that Ognl will be the first such tool to support this kind of feature. I personally find it odd that no one else had thought of this before! Jason Carriera mentioned that I check out JBeans and while it supported most of the type conversion I'd want, it had no concept of type conversion going the other way. In thea meantime, Drew is working on Ognl to have even better performance, so I think Ognl will be what I'll end up recommending for XWork.

Thu, 31 Oct 2002 17:41:34 GMT

Why stateful session beans suck....

An interesting article by Tyler Jewel on why stateful session beans should typically be avoided if you're using a Servlet engine. Here's another article that shows that using them is more trouble than its worth and typically have zero performance benefit.

So if entity beans suck, and stateful session beans suck, all thats left of EJB thats of any real value is stateless session beans. Which is kinda like RMI with a simple transactional interceptor.

Its no suprise to see that all the EJB vendors have been quietly de-emphasizing EJB and talking up web servies instead for quite some time.

[James Strachan's Radio Weblog]

eee jay bees suck?

Thu, 31 Oct 2002 17:41:01 GMT

Another Blogger, Another EJB naysayer.

Listen to the EJB's go Pop.
My friends who still work in the J2EE group at Sun that are charged with telling people how to write enterprise applications are now muttering about how there's a sudden demphasis on EJB's. Everyone is talking about other solutions now. Servlets (and tech built on top of them) and JDBC. Hell of a combo. Hey, I think I said that about 5 years ago while wandering the halls of CUP02. Course, not many people were listening back then. But a few were...
[James Duncan Davidson]

Hmmm. Cool. Another RSS feed subscribed. And another person making me really ponder the truth usefulness of EJBs. Having had a wonderful run down today by Mike on Sitemesh/Webwork/OFBiz EE I can honestly say that I can't see EJB's value proposition. Apart from buzzword compliance.

Which, from my understanding, is still about 80% of most funding decisions ... ;-)

[Brett Morgan's ~~Insanity Weblog~~ Zilla]

Well, I haven't been saying it for five years, but I did give a talk on why EJBs aren't exactly needed to my local San Diego Java Users Group early this year. I haven't been back to another JUG meeting since, maybe I should and try to stir up more controversy. Although it appears that it isn't controversy anymore, it's actually starting to be somewhat widely accepted. Anyway, my JUG talk was turned in to an article by "Mike" and can be found here.

Jumping on the bandwagon

Thu, 31 Oct 2002 17:37:08 GMT

Look at Nanning. Nice one!

[Joe's Jelly]

OK, I guess it's time I too hop on the AOP bandwagon. Basically, I know nothing about AOP save a few of Rickard's ramblings I've read and a couple web pages I read back when AspectJ was being heavily promoted (I hear AspectJ is dead now, is that right? A professor of mine worked on AspectJ when he was at Xerox Parc, maybe I should talk to him about all this AOP magic).

Petriwhat?

Thu, 31 Oct 2002 17:33:40 GMT

Petri Net Reading. The Application of Petri Nets to Workflow Management - van der Aalst (ResearchIndex) is probably what I'd call the starting-point in your journey through CiteSeer to accumulate knowledge of Petri nets. Brett Morgan had asked that I produce references to the papers I read to go from zero to Petri in 2 days. Overall, W.M.P. van der Aalst seems to be the shinig light in the world of Petri nets for workflow systems. For what it's worth, petridish supports coloured petrinets, but werkflow does not take advantage of them. Werkflow has exactly one colour of token flowing through the network:... [bob mcwhirter]

Man, I really should go read up on this stuff when I get a chance, though I'm sure most of it will be well over my head :)

Jakarta-BeanUtils... no dice

Thu, 31 Oct 2002 08:47:41 GMT

commons-beanutils comes with a ConverterUtils helper class for performing type conversions if you need it, which can work both directions.

However it sounds like what you really want to do is to use internationalization to convert the value into a localised String representation? If its any help, there's various JSP custom tags in JSTL for doing this kinda thing.

[James Strachan's Radio Weblog]

Well I gave commons-beanutils another shot (I looked at it about 6 months ago) and I'm still running in to two major problems:

            ConvertUtils.register(new DateConverter(), Date.class);
            BeanUtils.copyProperty(o, "blah", "02/12/1982");
            System.out.println(o.getBlah());
            System.out.println(PropertyUtils.getProperty(o, "blah"));
            System.out.println(BeanUtils.getProperty(o, "blah"));

1) I don't see any way for conversion to work the other way around. I want the String value of the the date to come back as "MM/dd/yyyy" and currently the above code seems to just be calling Date.toString() on the Date object being returned, so the output for all three lines is: "Fri Feb 12 00:00:00 PST 1982", which is not what I want.

2) Converters need to be registered globally. I believe converters should be registered globally (for defaults), but also be allowed to be specified per bean as well as per property.

So, still no dice... I'd rather not write my own stuff since 90% of what I need is already here or in OSCore's BeanUtils or in Ognl. But without solutions to the above two issues, sticking with WebWork's BeanUtil class would offer the same benefit.

OpenSymphony Guideline Document

Thu, 31 Oct 2002 01:51:25 GMT

A long time ago I promised I'd get a "guideline" document for "OpenSymphony". Well that item is still on my task list and it doesn't appear to be getting done. But I think I'm going to actually focus on getting this done. Joe Ottinger is also going to be helping me out, so hopefully in the not-too-distant future a concrete guideline covering everything from a high mission statement to low level details like logging and third party libraries will be covered.

XWork, Ognl, and type conversion

Thu, 31 Oct 2002 01:27:54 GMT

Today I spent some time on seeing if Ognl would be a good choice for bean manipulation in XWork. Well, things were running well until I hit two very large snags

1) Performance is the pits. I mean, Ognl is literally 25X slower than WebWork's BeanUtil method.

2) Ognl, like BeanUtil, OSCore BeanUtils, and Jakarta Commons-BeanUtils, has no way to get data in a type-specific way. This is actually more important than people tend to think. Sure, converting from input is important (setValue in all the above implementations has a way to convert data), but getting the data back in the same way we set it is equally important. Example:

User inputs a date as "02/12/1982". This should be calling FooAction.setBar(Date). FooAction also has a method "Date getBar()". But when we display the data back to the user, we want to display it as "02/12/1982" or "12/02/1982" or however the user first entered it. This means that type conversion needs to happen both ways, not just for setting values. So I think I'll write my own code that does this and is tuned specifically for XWork (Ognl has too much other stuff going on, which is probably why it's so much slower).

XWork in the works? Maybe.

Sun, 27 Oct 2002 02:05:08 GMT

it's actually really simple.

Web-the_simplest_thing_that_can_possibly-Work. I get WebWork. Finally. For some reason I've had a mental block on it up until now. Every time I sat down to explore it something came up, or I got bored. Finally cracked it this afternoon. Turns it I was expecting something complex, and it's actually really simple. This appeared to cause me as much (or more) mental discontinuity as when I'm expecting something to be trivial, and it turns out to be much more complex. WW really is very simple, but it lacks an 'idiots guide' which would have been very helpful to me. I'll see if I can retrace my steps and post my experiences up sometime. [Pushing the envelope]

Great! A WW idiots guide would be fantastic. Did you read Joseph Ottinger's tutorial? Maybe that would be a good starting point to collaborate on?

[rebelutionary]

Yup, it's simple indeed! I'll be starting work on XWork soon (think of it as WebWork 2.0, but geared for more generic usage). Keep posted, it's going to rock!