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.

11:37:23 PM    comment []

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?

11:34:14 PM    comment []

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?
11:24:45 PM    comment []

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.

3:18:17 PM    comment []

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!
8:09:57 PM    comment []

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).
8:45:58 PM    comment []

Anyone actually ever get Orion to auto-compile sources? Can it see when sources change, then compile and redeploy?
8:45:12 PM    comment []

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.

12:58:51 PM    comment []

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".

10:38:04 AM    comment []

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?

10:29:03 AM    comment []

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 ;)
11:58:00 AM    comment []