robjsoftware.info

A blog about software – researching it, developing it, and contemplating its future.

Archive for the ‘Seam’ Category

GWTJSF broken with Seam 2, sorry folks!

leave a comment »

So I’ve gotten past a number of the issues I blogged about previously, and I now have a Tomcat-only no-EJB3 version of the Seam blogging example. I’ve tried rolling the GWTJSF code from my original example back into it, and it looks like Seam 2 has thrown another wrench in the works.

As Chris Alfonso at JBoss warned me, Seam 2 installs the SeamPhaseListener by default. The Seam/GWTJSF integration as it previously existed needed its own phase listener, as explained in my article on the topic. This delegating-PhaseListener technique seems to be impossible in Seam 2. (Unless I’m missing something.)

With the GWT conference breathing down my neck, I may need to sideline this for a while until I get a fallback presentation together — I was hoping to be able to demo GWT 1.5 (if it gets done in time!) with JSF 1.2 and Seam 2, but I can’t count on that at this point, there are only four weeks to go and I don’t have the hacking time I’d need. So it’s Plan B time. I’ll take a week or so and get the presentation together with the previous version of the code, and then I can pound on Seam 2 some more.

Also, it looks like the GWTJSF code has officially been left behind in the Ajax4JSF 1.1.1 code tree, which has been rolled into the RichFaces project — except for GWTJSF, which is nowhere to be found in the RichFaces code tree. GWT can definitely be considered a competitor to RichFaces, so I guess I see why JBoss isn’t supporting GWTJSF, but still it’s a shame. It’d be great to see some more synergy there, but I’m not sure how to bring it about. (other than blog about it and rock the boat a little 😉

Anyway, sorry to those who’ve been wanting to use GWTJSF with Seam 2 — it’s going to be a longish road. All help very much appreciated if anyone else has cycles to hack on this with me!!!

Advertisements

Written by robjellinghaus

2007/11/08 at 06:08

Posted in GWT, Java, JSF, Seam

Friendship and fraternal aid

leave a comment »

Last week I griped about some hassles I was having with Seam 2, Java 6, Tomcat, and JBoss Embedded. I grumpily grouched about the grim gloom of an open source world where things break and people don’t get along very well, and how non-fun it is.

And hey presto, what should happen but two Red Hatters read my kvetching and chimed in with some downright helpfulness. First, Jason Greene mentioned this workaround for the bizarre Java 6 ClassNotFoundException I mentioned. Seems there is a magic JVM flag you can provide to revert to the Java 5 classloading behavior if it causes you too much trouble. That’s good to know, and I appreciated the clue.

Second, Chris Alfonso — who’s been asking me when I’m going to get around to fixing my GWT/JSF/Seam demo to work with Seam 2 — said that he’s got a Maven 2 version of the GWTJSF demo building as an EAR that runs under JBoss with EJB3. Which is cool, because I now have a plain old Hibernate version of the Seam 2 blogging demo that deploys under vanilla Tomcat, so it’s nice to have both flavors. (Chris, can you send me your version? I’d like to poke at it some — I won’t post it without your say-so.)

So that’s the great thing about the open source community — it is a community, and people offer each other helping hands. Thanks for brightening my week, guys! You put the fun back in 🙂

Written by robjellinghaus

2007/11/06 at 04:19

Posted in Java, Maven, open source, Seam

Finger-pointing and frustration

leave a comment »

One of the tough things about open source is that the world never stands still. Actually, it’s not just open source, it’s software in general, but open source exacerbates it. See, one of the main motivations for open source developers is fun and the enjoyment of sharing something cool you did. So you’d like to be able to do something cool and then have it stay cool.

But the problem is, once you get something cool working, it’s almost guaranteed that it’s going to stop working soon. Why? Because everyone else is doing other cool things. Including all the developers whose projects yours depends on. So the odds approach 100% that before long your cool thing is going to break with the latest version of FooBarLib. And broken things are no longer cool.

And fixing your cool thing, that broke for no fault of your own and for reasons you don’t agree with, is the absolute opposite of fun.

Even large developers are vulnerable to this. Right now I’m banging my head against trying to get my Seam + GWT example working with the latest 2.0 release of Seam. But Seam made a number of changes that are frustrating me rather deeply right now. For one thing, they changed the packaging for their embeddable EJB support such that you have to install the JBoss embedded EJB container directly onto your Tomcat. No more delivering a nice simple WAR file that uses Seam and EJB3, now it’s a multi-step process that leaves your Tomcat fairly JBossified.

The nominal rationale for doing this is that it lets the EJB3 services be shared by all the apps inside that Tomcat instance. So you might think, great, now my Seam+EJB3 WAR file is 6MB instead of 20MB. (Which is indeed a problem with the demo version on my page — it’s stinkin’ HUGE.) But, BUT, it turns out you can’t actually run multiple Seam apps under the Embedded EJB3 container!

Why not? Well, because Bill Burke and Gavin King, both of whom work at JBoss and both of whom are fairly bullheaded, can’t agree on whose problem it is that multiple Seam apps collide in the Embedded EJB3 component registry. Not only that, but the Embedded EJB container’s development has stalled. So, Tomcat is a seriously second-class citizen as far as Seam is concerned now. Of course from a JBoss perspective this is arguably good, because JBoss doesn’t get support revenue from Tomcat installations. For me, though, it sucks, because I don’t want my Seam / GWT example to require JBoss.

And the icing on the cake is that the Embedded JBoss container doesn’t run under Java 6. I like to run on the latest Java. It’s just a funny preference I have, I don’t know why. But JBoss does classloader tricks that Sun apparently considers invalid loopholes, which Sun closed in Java 6. This results in charming errors like:

ERROR 01-11 21:56:07,921 (AbstractController.java:incrementState:456) -Error installing to Instantiated: name=DeploymentFilter state=Described java.lang.IllegalStateException: Class not found: [Ljava.lang.String;

And JBoss and Sun are finger-pointing about who broke who. So Seam isn’t at all guaranteed to run under Java 6 in any way, and JBoss and the Seam team consider it Sun’s problem, not theirs.

So what am I going to do? I’ve got a conference presentation coming up and I wanted to use this demo with the latest Seam and latest GWT. But it’s starting to look like I’m going to have to sink way too much time into mucking about with Seam for reasons I’d rather not have anything to do with. I’ll probably follow the path of least resistance, which is just to roll back to Java 5 and grin and bear it. It’s definitely demotivating, though. Definitely. Demotivating.

Written by robjellinghaus

2007/11/02 at 05:37

Posted in Java, open source, Seam

GWT, JSF, declarative markup, and lunch with Gavin

leave a comment »

Just had an interesting lunch with Gavin King (original author of Hibernate and Seam), and came up with a somewhat crazy idea that needs more eyeballs on it.

EXECUTIVE SUMMARY

The GWT toolset lacks a way to do declarative markup. The only way to compose GWT components is through Java code. Joel Webber of the GWT team said at Google Developer Day 2007 that one of his personal ambitions for GWT is to build a declarative markup system.

The Seam toolchain lacks a way to build custom JSF widgets easily. Building a custom JSF widget with plain Javascript is extremely painful. The GWTJSF integration library goes partway towards addressing this, but doesn’t currently support building composable trees of GWT-based widgets.

What if we brought the two together? What if we could create a JSF-based and Facelets-based markup system that enabled composability of independently developed JSF widgets implemented in GWT? This could both leverage an existing declarative markup system (Facelets) for GWT’s purposes, and deliver a much better toolset for creating Seam applications with richer UI functionality.

That’s the basic idea. If you Get It, then please skip to the DETAILS section. Otherwise, read on.

BACKGROUND

The first chunk of lunch was walking through my Seam/GWT example, clarifying what it does and how it does it. Basically, as the page explains, it takes GWT modules and encapsulates them in JSF components. This allows GWT modules to exist within the context of a larger JSF / Seam application, leveraging other JSF page components and directly communicating with Seam components through GWT RPC.

The main use for this, it seemed to us, is taking existing GWT modules and wrapping them as JSF components, to enable their use in a larger JSF application. This was one of the original use cases that motivated the Exadel guys (Sergey Smirnov and Alex Smirnov) to create their GWTJSF integration library.

Where do we take it from here, though? Originally it seemed to us that if all you need is GWT, then this JSF integration isn’t of much use to you. Michael Neale has already landed — in the Seam 2.0 beta — a GWT integration that doesn’t require JSF at all, but just lets your GWT app communicate with Seam components. (He hasn’t, evidently, integrated my RPC refactoring in GWT 1.4, so it doesn’t yet support native GWT-style RPC, but that’ll be easy to do now that GWT 1.4rc1 is out.)

So, is the only use case for GWTJSF really for people who want to take existing GWT components and build them into JSF apps? Well, Gavin saw the code for the GWT module in my demo, and his feeling was, wow, this is a much better programming model than writing custom JSF components in Javascript. So what would it take to make GWTJSF better at creating reusable JSF components?

There are two main things that the current GWTJSF library lacks. One of them is support for Seam conversation propagation. This is important if you want to have GWT components that can participate in a Seam web application which uses both GWT-based AND non-GWT-based components. You want the GWT components to be able to carry the conversation state in RPCs, so they can participate in the Seam server-side conversation state management. (Yes, I know it is totally against the GWT religion to even mention the words “server-side session state.” This isn’t the main point, so don’t get hung up on that.)

But that’s actually not the most interesting possible extension.

THE DETAILS

The current Seam blogging example is basically a tree view of blog posts. Each tree node can be expanded to show the full text of a blog post, with an inline edit button that lets you edit the post’s text right there in the tree.

Here’s the GWT/JSF markup for instantiating this tree-view-blog-editing component:

<!– This is a JSF component encapsulating a GWT module. –>
<bloglist:component id=”main2″>
  <!– This widget routes GWT RPC requests to the Seam component named “gwtBlog”. –>
  <gwt:gwtListener serviceBean=”#{gwtBlog}”/>
</bloglist:component>

This creates a JSF component wrapping a GWT module. The GWT module exposes an interface which is implemented by the server-side Seam component named “gwtBlog”. So the GWT module uses a single interface to communicate with the server.

The GWT service interface is this:

public interface BlogService extends RemoteService {
  public Blog getDtoBlog ();
  public List getDtoBlogEntryList ();
  public String getFormattedHTML (String wikiText);
  public void updateBody (String id, String newBody);
}

This interface conflates operations on the whole list of posts (getDtoBlogEntryList) with operations on individual posts (getFormattedHTML, updateBody).

Overall, this widget is great and all, but it really consists of two orthogonal pieces: a tree view component, and an individual-post-editing component. They’re bound together in the current GWT code. This widget is monolithic; all it does is make a tree of blog posts. It can’t be repurposed by tweaking the JSF page.

When showing this to Gavin, his feeling was that it was not nearly generic enough. The typical Seam way of doing this would be something like (edited for brevity):

<!– Generic tree view, using a post-edit widget for each node. –>
<ice:tree id=”tree” value=”#{tree.model}” var=”item”>
  <ice:treenode>
    <ice:panelgroup style=”display: inline;”>
      <ice:commandlink value=”#{ item.userObject.text}”>
      </ice:commandlink>
    </ice:panelgroup>
  </ice:treenode>
</ice:tree>

This builds a JSF component tree that declaratively nests multiple widgets, using Seam expression language ( e.g. “#{tree.model}”, “#{item}”) to specify where the components get their data.

Now, here’s the rub. What if you could write JSF / Facelets markup that instantiated a tree of GWT widgets this way?

Something like this:

<gwt:tree id=”tree” value=”#{blogEntries}” var=”item”>
  <gwt:blogpostedit value=”#{item.blogPost}”>
</gwt:blogpostedit>

What you’d be doing here is writing a JSF page that creates a component tree that is purely instantiated on the client. The only rendering would happen on the client via GWT. The GWT components would (WAVING HANDS MADLY) have some protocol for nesting themselves, and would have some data-binding style coupling to the server components from which they pull data. The RPC could be GWT-style RPC via service interfaces generic to each specific component.

This would essentially turn the JSF UI component tree into a structure that can be either rendered purely on the server (original-style JSF controls), or rendered partially on the server and refreshed using AJAX (the Ajax4JSF / RichFaces style of user interface), OR rendered entirely on the client (GWT-style widgets). This would also enable declarative construction of GWT-based interfaces, using the exact same syntax and UI component tree as used for other JSF interfaces.

This is good for Seam, because it enables a graceful path towards Seam-based JSF apps with lots of custom UI code, without losing the compositional good qualities of Facelets. And it’s good for GWT, because it gives a declarative framework for building GWT applications, with a great story for coupling to server-side business logic.

ARE YOU CRAZY?

This is not quite a half-baked idea yet. In fact I’d say it’s about 10% baked. But it’s definitely interesting, and it definitely bears more thinking about.

There are many issues with it, just a few of which are:

  • This doesn’t really let you mix arbitrary non-GWT and GWT JSF widgets; the only allowable children of GWT JSF widgets would be other GWT JSF widgets. (Unless you get really sneaky with partial rendering invoked FROM GWT, which probably isn’t worth it….)
  • I have no idea at all what Joel Webber (of GWT fame) has in mind for declarative markup, so this concept may be totally wrong for his use cases.
  • On the face of it this idea seems to imply some kind of EL (expression language) parser implemented in GWT, which is no small chunk of work.
  • Who exactly implements this is a totally open question; I still want to get back to the offline Blogger client done with GWT/Gears, which has basically nothing to do with this 😉

I don’t claim to have answers to these; this post is just a starting point.

I’m going to post in the GWT developers forum, in the Seam users forum, and in the Ajax4JSF developers forum to see what kind of reactions this idea provokes.

Discuss!

Written by robjellinghaus

2007/07/01 at 04:49

Posted in GWT, JSF, Seam

Why start this blog?

leave a comment »

[ObNewBlogIntentions] Will try to update often. Will try not to spend so much time farting around with templates that I never get around to posting. [/ObNewBlogIntentions]

So, with that out of the way, hello. I’ve been planning a blog for a year and a half now. I realized in early 2006 that I’d spent my whole life programming for companies who owned everything I did, and I wanted to do something open source on my own time. So I thought, what about a blog system? Clearly the world needs more of those 🙂

(The nice thing about programming on your own time is you don’t have to justify anything to anybody! Except your wife. But if you cut back on the computer games, so you’re not blowing your personal time budget away, then it’s all good.)

The thing is, I really wanted a blogging system that would support offline editing and offline backup of my blog content. I ride the commuter train, and I don’t entirely trust any single system (even one run by Google) — I like lots of redundant backups that I personally maintain.

So I started on a project to implement a distributed blog application. Which, of course, since I’m a Java weenie, meant that I really needed a Hibernate-based peer-to-peer distributed object version control system.

I built most of that over the bulk of 2006 (or prototyped it, anyway), using a Seam / EJB3 / /Tomcat / JSF stack. Then I thought, how do I build the UI? I started looking into GWT and liked it. I even found a JSF / GWT integration library. But it didn’t handle GWT RPC properly.

Then GWT got open sourced. I started working on fixing the RPC issues in GWT in early 2007, and that led to my submitting what I think was the first major external patch to GWT. I also put together a demo of Seam + JSF + GWT — adding a GWT blog-reading interface to the Seam blog example.

Michael Yuan from JBoss mentioned this at his JavaOne BOF this year, and I got to demo it at the GWT hack session at JavaOne, where I had the pleasure of meeting Bruce, Joel, Kelly, Bob, and the Dans (Peterson and Morrill) from the GWT team. Then I took a couple of weeks off to recuperate — my wife is expecting our second child in late July (our first child is two and a half), so there’s plenty of other distractions keeping me busy!

So that brings us to yesterday. Google Developer Day in Mountain View. And the announcement of Google Gears and GWT for Gears. Now, remember that my original use case was to build a blogging app that could work offline. I was using a technology stack that was Seam + EJB3 + Tomcat + JSF + GWT + Postgres. So to use this app I was building, you’d have to be running a local Postgres install and a local Tomcat install, and you’d have to do a bunch of Java deployment. I might have wound up with a few dozen users, or maybe only myself. (The code could have wider applicability, but direct product usage would’ve been low.)

Along comes Gears. Suddenly there’s a whole new stack option: Gears + GWT + Blogger. Offline functionality usable with any Blogger blog, and a much, much, much easier deployment, with a possibly much larger user base as a result.

So yesterday at GDD07 I brainstormed about this a bunch with Dan Morrill, Miguel Mendez, and Bob Vawter from the GWT team. It looks like a go. My next post will be about the detailed plan for that.

Meanwhile I still have to finish landing the JSF+GWT code, and documenting and submitting the Seam example. This whole project has been one surprise after another, and it’s only getting more fun so far 🙂

Onwards!

Written by robjellinghaus

2007/06/02 at 03:32

Posted in GDD07, GWT, Java, Seam