June 10, 2010
During my long flight to Frankfurt last month, I responded to an interview by Jan Groth about Seam for the German Java Magazin. In the interview, I reflect on the value of Open Source, how I got involved in Seam and where we are headed with Weld and Seam 3. I ended up writing so much (surprise, surprise) it had to be split into two parts. I justify my thoroughness in my first response:
I'm going to be a little long-winded [...], but I think it's important to communicate what led me to Seam because it says a lot about the software itself.
The full, 2-part interview is available online at the JAXenter Magazine website:
In part 1, I share the thoughts I had after reading the Seam reference documentation the first time:
It's like the Seam developers were reading my mind. [...] I felt like a kid in a candy store. I started banging out applications in no time and I was happy with how they looked.
I go on to explain that it wasn't just enough for me to know about it. I wanted other to benefit too.
I didn't want others to overlook this framework given how much it helped me. While the manual made sense, I knew it wasn't enough. [...] I decided to yell from the mountaintops by writing a series about it for IBM developerWorks.
The overwhelming feedback from that series made it pretty clear, someone needed to write a book about it (a higher mountaintop) that was going to explain every last detail. I took on that challenge (and believe me, it was quite a challenge.) [...]
I quite literally immersed myself in Hibernate, JPA, EJB 3, JTA, JSF and Java EE 5 in general. I came to appreciate the value of the platform, the remaining limitations and what Seam had to do to fill in the gaps.
I squeeze in a short review of the Art of Community at the end of the first part because it really sums up my vision of this project:
The Art of Community is a truly inspiring book and it reminded me why I love doing what I do...it's really about the people and the ideas. We are not just writing software for the community and publishing it as Open Source. It's the community's software, solutions to problems that come from the real world. We want to support and foster that engine and the Seam Community Liaison is the spark plug of the engine and ensures it's properly greased.
Part 2 dives more into the technical details and where we are headed.
CDI and Seam 3 are the Future of Both the Seam Community and Red Hat.
I explain our standards strategy as a defender of choice:
Red Hat is strong when the Java EE platform is strong. Our strategy does not depend on the platform remaining weak to justify the existence of our projects. It's quite the opposite. If we make one of our own projects obsolete, or some part of it, that's progress.
To quote Jay Balunas, it's cyclic:
Find a void. Fill the void. Standardize the fill.
I liken Seam modules to JSF UI component libraries and explain how we will ensure portability:
- Seam 3 is primarily built on the CDI portable extension SPI, insulated from handling low-level concerns that run a high risk of breaking portability.
- One of the principal requirements of Seam 3 modules is portability.
- The Arquillian in-container test framework allows modules to be continuously tested against an array of application servers.
But with the improvements to Java EE, the question comes up whether Seam is still needed:
Is Java EE 6 a solid platform? Yes. Will you still need extensions? Yes. And CDI was designed specifically to be able to root and foster such an ecosystem. You can even write your own extensions, which really wasn't possible with Seam 2. Now we just need a plug-in site ;)
I'm very excited about all the innovation that is taking place in the JBoss Community right now and I encourage you to become a part of it. You never know where it will lead, but I can guarantee you it will open doors for you.
This post is syndicated from my JBoss Community blog.
Posted at 12:19 PM in Java, Seam, Seam News, Seam in Action
| 
del.icio.us
| 
digg
| 
Comments (3)
March 30, 2010
Despite all that I have written, explained and presented about Seam, I often find myself struggling to sum it up in a few short breaths. Fortunately, Matt Campbell does an superb job of defining the essence of what Seam provides eloquently and concisely in his blog series An Honest Look at Seam. (And I'm not just saying that because he credits Seam in Action as being his guide in his exploration of Seam).
In part 1, Matt explains how the attention to scoping of components is what sets Seam apart from Spring and makes it more suited for the web environment. In my talks on Java EE 6, I often say that JSR-299 (CDI) considers the scope of a bean (where it's stored) to be just as important as the component instance itself. Speaking of Java EE 6, Matt does some comparisons of his own between Seam and CDI.
Having established the importance of context, Matt opens part 2 introducing the conversation scope. He quickly delves into the symbiotic relationship between this scope, the persistence context and the multi-request use case (which is just about any use case on the web). He raises the ever important issue of manual flush mode in Hibernate and how it enables use of an optimistic transaction.
Matt takes a break from the theory in part 3 to address the developer's first experience with Seam. He calms the anxiety a typical newcomer might have the first time the developer observes seam-gen churn out application. While some may appreciate the huge boast that a fully-functional application provides, the shear number of artifacts is daunting for those expecting "Hello World". But as Matt clarifies,
There is a lot to Seam, but not becuase Seam itself is vastly huge and complex, but because Seam integrates so many things together.
So take your time and explore it all. Use what parts you need and skip the parts you don't.
In the future, rather than struggling to find the words to describe Seam on a trip in an elevator, I'm just going to hand the interested listener a card with the URL to these blogs on it ;)
It's important to zero in on what Seam 2 provides, especially as we look ahead to Java EE 6 and the development of the Seam 3 portable extension library. So regardless of where you are in your adoption of Seam 2 or Java EE 6, take a moment to read through these entries.
Posted at 01:05 AM in Seam, Seam News, Seam in Action
| del.icio.us
| digg
|
No Opinions?
August 02, 2009
Information about the proposed Unified EL update slated for Java EE 6 is hard to come by, so I decided to put together a blog entry with some useful links.
If you haven't heard yet, which is understandable given the lack of publicized information, the Unified EL is getting an update for Java EE 6. The update consists of functionality we have all wanted for a long time. Most notably, literal method names in value expressions for more flexible data retrieval and method arguments for both value and method expressions. To see examples of these feature enhancements, take a look at this blog entry by Kim-Man Chung. (If you are using Seam or Spring Web Flow, you are already enjoying these enhancements courtesy of the JBoss EL).
But you probably don't just want to take my word for it. You want to know where these enhancements are officially documented. That's the point of this entry :)
Let's start by looking at the big picture. The Unified EL is defined in Part II of the JSR 245: JavaServer Pages 2.1 specification, lead by Kim-Man Chung. The maintainence release 2 of JSR 245 is the one on the ballot for Java EE 6.
I'll pause in anticipation of your pressing question. No, there is no dedicated specification for the Unified EL. (I'm lobbying for one, though). The Unified EL evolved out of JSP (where it was just the EL) and was later adopted by JSF. It's just as much a part of JSF as it is a part of JSP, which is why the situation is so awkward right now.
To find the proposed changes for the Unified EL, you have to look at the JSR 245 MR2 Change Log. Specifically, focus your attention on the Expression Language page. Believe it not, that's as official as it gets. Trust me, the absence of process disturbs me too.
Great, so what about the implementation? Can you try this stuff out? I had some difficulty finding that information too, but alas, I have more links for you.
The reference implementation of the Unified EL is hosted at java.net. The project is named uel, short for Unified EL. There are several tags corresponding to beta releases in the Subversion repository and the artifacts (JARs) for most of the beta releases have been published to the java.net Maven repository (EL api, EL impl). However, I can't find any announcements about these releases.
The version of the Unified EL you are looking for is 2.1.2. "How did the version jump from 1.1 to 2.1.2?" you may ask. I happen to know the answer to this question because I was in the EG meeting at JavaOne in which Kim-Man Chung gave a status update of the JSR 245 MR2 spec. He said that the version was bumped to align it with the JSP version, which will also be 2.1.2. Given that the Unified EL should be it's own spec, this makes absolutely no sense, but at least you know the reasoning behind it (and don't think you missed a haf-dozen versions in between). I'm also not happy at all about the closed-door decision, but I digress.
At some point, the Unified EL update will show up in GlassFish V3. As far as I can tell, it is not bundled today (but could be by the time you read this). How can you tell if it's there or not? The EL API can be found in the glassfish/modules/javax.servlet.jsp.jar file and the implementation is glassfish/modules/web/jsf-impl.jar. Extract the JARs and look at the META-INF/MANIFEST.MF or the pom.xml file to determine which version it is. You could also look for the presence of the javax.el.ValueReference, which is a new class in the API.
In case you were wondering, JBoss EL 2.0 is not (yet) and implementation of the Unified EL 2.1.2 API. Stay tuned.
So there you have it, information about the Unified EL update. I'm sorry this information is so hard to piece together. I think this would all be a lot simpler if EL was its own spec and/or there was decent information published about JSP. Oh, if the spec were actually open. The thing is, I don't give a care about JSP and frankly I want to divorce that spec in every way.
UPDATE: I put together a formal list of proposed enhancements requested by the Seam community on seamframework.org .
UPDATE: Ryan Lubke also blogged about the Unified EL update for Java EE 6. He included tips on how to update GlassFish with the latest EL build.
UPDATE: The EL spec document has been updated, making the changelog I cited above official. Grab the EL spec document from the "for evaluation" link on the JSR-245 maintenance release download page.
Posted at 01:46 AM in Java
| del.icio.us
| digg
|
Comments (5)
May 04, 2009
Ever since I first started using Maven 2, I envisioned having a console in which I could execute life-cycle goals without having to incur Maven's startup cost between every run. It just seemed to me such a waste for Maven to build up the project object model (POM) from the pom.xml only to run a single sequence of goals and immediately shutdown. It also gives the impression that Maven is slow. In fact, it's extremely slow when it's used in this way, especially multi-module projects. But it doesn't have to be if you take advantage of...
The maven-cli-plugin
Today my vision has come true thanks to Mr. Don (and the ease of collaboration made possible by git). Having a similar vision to mine, he wrote the maven-cli-plugin, hosted at github.com. This plugin uses the jline library to create an execution console for Maven 2 (i.e., command shell), shown here:
maven2>
At the prompt you can issue Maven 2 life-cycle phases or plugin goals. The console even supports tab completion of commands! In this entry, I'll explain how you setup and use this console to put Maven into hyperdrive.
Technically, the plugin has two consoles. One is for executing Maven 2 life-cycle phases, including all prerequisite phases, and the other is used to only run plugin goals (the life cycle is not executed). Those are the same two ways you use Maven 2 from your normal shell. In this entry, I'll be focusing on the execute-phase console.
A fork in the road
I was thrilled when I first discovered the plugin, but after giving it a shot I was disappointed to discover that it wasn't honoring profiles, which are a critical piece of the build (see issue 2). I didn't give up hope though. Since Mr. Don had done most of the legwork in creating the plugin, I figured it wouldn't be that difficult for me to figure out why the profiles weren't working. Sure enough, in under an hour I discovered the source of the problem and was able to apply a fix. That left me with the dilemma of how to distribute my changes. I wanted to be able to use the plugin in the Seam 3 examples, so I couldn't just maintain a hacked version on my computer. Github.com (and git) saved the day.
Following the process for creating a fork on github.com (for which they practically spoon feed you the instructions), I forked the code and committed my changes to a publicly accessible repository. You can access both the master tree and my forked tree. You'll need the version from my tree to use all the features I cover in this entry. Hopefully Mr. Don will merge my changes into the master tree soon, but the fact that you can get my code today is a true testament to the influence git can have on open source collaboration.
Now let's "git" on with the presentation.
Getting started
To get started, add a plugin repository where the maven-cli-plugin is hosted as a top level element in your pom.xml. I recommend using the JBoss maven repository because it hosts my forked version.
<pluginRepositories>
<pluginRepository>
<id>repository.jboss.org</id>
<name>JBoss Repository</name>
<url>http://repository.jboss.org/maven2</url>
</pluginRepository>
</pluginRepositories>
Alternatively, you can publish the plugin to your local or company repository. Grab the source from github.com or the binaries from the JBoss Maven repository. Remember, you need my forked version until my features get merged in. Follow the project at github.com to find out when that happens.
Next, define the maven-cli-plugin inside the build > plugins element in your POM. This just allows you to use the plugin prefix from the commandline, which is cli. You're also going to use this section to add some configuration options later.
<plugin>
<groupId>org.twdata.maven</groupId>
<artifactId>maven-cli-plugin</artifactId>
</plugin>
With the setup out of the way, I'm going to demonstrate three reasons why this plugin is game-changing. By the end, I guarantee you'll be jumping out of your chair.
#1 - Speed
Let's face it, Maven is dog-slow. That's because it has to parse that heap of XML the Maven developers call a POM. Then it has to figure out what it's supposed to execute. Then it pings the internet for updates. Then it enforces constraints. Then it runs through all the precursor phases (likely including tests). And finally it arrives at the phase you really want it to execute.
Of course, some of those steps can be trimmed using various flags, switches, and properties. But that means having to type, and remember, a ridiculously long command that is just something no human should be expected to do. More on that later. Let's deal with this startup cost once and for all.
We'll begin by firing up the maven-cli-plugin phase executor console. You run it just like you would any other Maven plugin:
mvn cli:execute-phase
After Maven goes through it's normal loading process, you are presented with a command prompt:
maven2>
From here you can type any of Maven's life-cycle phases, such as package, or a plugin goal (more on plugins later). Give it a try:
maven2> package
The first time the life cycle executes, you'll see a noticeable improvement in speed. By the second execution, it's blazing fast! You can just feel years being added back to your life. Power up!
Now it's time to extend the build with...
#2 - Profiles
One of the most powerful features of Maven is profiles. In fact, I think Maven is pretty useless without them. That's because in Maven, you really only have one "command" you can execute, the Maven 2 life cycle. There must be a way, then, to instruct that execution pass to perform different steps along the way. That's what profiles are for. With a profile, you can hook additional plugins to a phase as a way to weave that extra behavior into the build.
But we have a dilemma. Profiles are typically activated from the commandline either explicitly using the -Pprofile flag or through an activation, typically by assigning a property such as -Dproperty=value. How can we set the profile once we are in the command console? This is where my contribution to the maven-cli-plugin comes in.
The commands typed in the console are processed by the jline ConsoleReader from the maven-cli-plugin, not by Maven. That means we can allow any command we want, including flags like -P and -D. Fortunately, Maven was designed in such a way that an execution is isolated internally from parsing the POM. So it's possible to execute a life-cycle phase with a different set of profiles and properties, or even put Maven into offline mode for a single execution, without having to start the console again.
I hacked up the maven-cli-plugin to support the following flags:
- -P activates the profile specified immediately after the flag (no spaces); this flag can be used multiple times
- -D assigns a property specified immediate after the flag (no spaces) in the form name=value; this flag can be used multiple times
- -o puts Maven in offline mode for a single execution; if not specified, will inherit the setting used to start the console
- -N instructs Maven not to recurse into projects in the reactor
- -S skip tests, an alias for -Dmaven.test.skip=true
Here's an example of a command you can issue:
maven2> clean package -Prun-integration-tests -o
That would activate the run-integration-tests profile, run the clean plugin and the life cycle up to the package phase, all while executing Maven in offline mode (to avoid checks for missing pom files, snapshots, and plugin updates).
In addition, the maven-cli-plugin already supported specifying individual projects by artifactId. This allows you to execute a phase on a sub-project without having to descend into that project or use the -f flag.
Let's say you are working with an standard EAR project and you want to build the WAR. To package just the WAR, you would either have to change into the war directory and execute Maven or use the -f flag as follows:
mvn -f war/pom.xml package
With the maven-cli-plugin, you can accomplish the same thing using this command (note that "seam-booking-war" is the artifactId of the module):
maven2> seam-booking-war package
Ah, the simplicity! And now, for the grand finale!
#3 - Aliases
Aliases are the Holy Grail of Maven 2. When I switch people from Ant to Maven, the first thing they get annoyed about is the ridiculous commands they are required to type. To put it simply, if you want to run clean and package, there is no way to specify that with a single command. You have to type:
mvn clean package
Things get worse with plugins. All plugin goals must be namespaced. That's because Maven 2 technically supports any command in the world, as long as there is a plugin to execute it. To run Jetty on a WAR project, for instance, you have to type:
mvn run:jetty
If you want to run clean, package, and then start jetty, you have to type:
mvn clean package run:jetty
Let's say that you also need to expand the WAR in-place and you want to run offline. Then the command becomes:
mvn -o clean package war:inplace run:jetty
I think you can see where this is going. When I first setup the booking examples for Seam 3, the record for the longest commandline in the readme went to this command, which undeploys, packages, and redeploys an EAR to JBoss AS:
mvn -o -f ear/pom.xml jboss:undeploy && \
mvn -o package && \
mvn -o -f ear/pom.xml jboss:deploy
Uuuuugly! That's why the aliases feature of the maven-cli-plugin is absolutely game-changing (perhaps even life changing). In fact, combined with the other two features I have covered, they make Maven 2 better and faster than Ant, hands down. I'll go so far as to say that there has never been a faster, more convenient way to execute builds.
So what is an alias? Quite simply, a string of commands you would otherwise have to type in the console, aliased to a single word. You define them in the plugin configuration. Here's an alias I put together to deploy an exploded EAR archive to JBoss AS in the Seam booking example:
<plugin>
<groupId>org.twdata.maven</groupId>
<artifactId>maven-cli-plugin</artifactId>
<configuration>
<userAliases>
<explode>package -o -Pexplode</explode>
</userAliases>
</configuration>
</plugin>
After starting up the console, the user only has to type one word:
maven2> explode
It's no longer even necessary to prefix commands with mvn (or ant in the old days). Just one command. One word.
The execute-phase console also supports direct execution of plugin goals. That means you can include them in the alias command. The only limitation is that when you include one in an alias, you have to specify the fully qualified name of the plugin (groupId:artifactId) before the goal rather than just it's prefix (e.g., org.codehaus.mojo:jboss-maven-plugin rather than jboss). This next alias invokes the harddeploy goal of the jboss-maven-plugin after packing the project.
<userAliases>
<deploy>seam-booking-ear package -o org.codehaus.mojo:jboss-maven-plugin:harddeploy</deploy>
</userAliases>
You can even mix aliases with regular commands. Perhaps you want to clean first:
maven2> clean deploy
I find it nice to alias commonly used built-in Maven goals too, such as the one that lists the active profiles:
<userAliases>
<profiles>org.apache.maven.plugins:maven-help-plugin:active-profiles -o</profiles>
</userAliases>
The maven-cli-plugin also provides a handful of built-in aliases.
If this plugin isn't game changing, I don't know what is. All I can say as hell yeah!
See the Seam 3 booking example to see this plugin in action and read additional commentary.
Update: There is also a cli client for IntelliJ IDEA that can invoke builds remotely. Of course, the plugin supports this from the commandline too.
Update: I should also mention that this is a great way to debug Maven since you get an opportunity to attach a debugger before executing a command. First, set the MAVEN_OPTS environment variable:
MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
Then run cli:execute-phase, attach a debugger (port 8787 in this case) and execute a command.
Posted at 02:18 PM in Java, Programming, Usability
| del.icio.us
| digg
|
Comments (35)
April 02, 2009
What a year! There's no question that year 30 was the most eventful and life changing year of my life to this point. I truly feel like I have grabbed life by the horns and got it steered in the direction I really want it to head.
By far, the biggest accomplishment of the year was getting Seam in Action published. But writing my first book was the catalyst for many of the other events that took place. From start to finish of year 30, I presented for the first time at a software conference, which led to a half a dozen speaking engagements, more travel than I've ever done in one year, including my first ever trip to Europe, and the chance to meet a lot of prominent industry leaders. Writing the book also helped me be more prolific. I passed my 100th blog entry and posted 1000 tweets on Twitter, which I began using just before JavaOne. The gutsiest and most permanent decision I made all year was deciding to get LASIK, and in the words of Tiger Woods, "the results were fantastic". What follows is an account of this passage into my 30 somethings, most of which can be found in my tweet archive.
[ Continue Reading » ]
Posted at 10:27 AM in Personal, Seam in Action
| del.icio.us
| digg
|
Comments (2)
March 17, 2009
I didn't expect Ken Rimple for Chariot Solutions to be so quick in getting up part 2 of my Seam interview, which I introduced in a previous entry, so you get two posts in one day. If you had iTunes or your RSS feed reader working, you'd already be in the know.
In the second part of this two-part interview, we focus on the future of Java EE 6, including JSR-299, formerly known as Web Beans, and how Seam will change as the Java EE specification evolves. We also discuss varying front-end technologies such as Flex and AJAX, and a bit about workflow.
Resources we mentioned in the talk include:
- Granite DS - A Flex remoting framework that includes support for Seam as well as other platforms such as Guice, Spring and POJOs
- Flamingo - Another Flex (and JavaFX) remoting framework that exposes Seam and Spring services using a variety of protocols including AMF and Hessian.
- JSR-299. I emphasize that it is well worth your while to read it and something I think every Java EE developer needs to be aware of at some point in the near future.
- Web Beans - The namesake of the reference implementation (RI), which is being developed by Red Hat and its community as an open source project.
Thanks again to Ken for the hard work that I know went into publishing this interview.
Posted at 11:22 AM in Java, Seam, Seam News
| del.icio.us
| digg
|
Comments (1)
March 17, 2009
I'll be speaking at two conferences back-to-back in March, which is about as much madness as I can handle. First I'll be traveling to Vegas to speak at TheServerSide Symposium at Caesar's Palace on my birthday (March 20th). It's interesting to note that just over 6 months ago I was near Caesar's real palace, or what's left of it. Then I'll be coming back home and speaking at Emerging Technologies for the Enterprise in nearby Philadelphia the following Friday. In both cities, I'll be speaking about Seam Security.
Always wanting to put on a good show (I mean, it is Vegas after all) I put together a fresh application that leverages Seam's new identity and permissions management API. It's a design comp manager that allows a designer to share designs with clients. The application showcases how Seam Security blends ACLs and rules in a truly unique and revolutionary way to provide a powerful and expressive security model.
While creating an application like that may sound difficult to achieve, my talk demonstrates that it's shockingly simple setup and start using. Like poker, though, it does take time to perfect. Authoring complex rules are not always easy. I spent nearly two days getting a feel for the API. But then again, I've got a killer app to show for my labor.
The full abstract of the talk is below.
Security is the cornerstone of your application's integrity and, consequently, you need to weave it throughout each layer, often in diverse ways. Seam Security allows you to evolve the security model of your application over time, keeping pace with the development cycle. You can start with a very simple configuration that applies an exclusive security blanket over the application to keep out guests and establish a basic identity for the user. You can then mature the security infrastructure gradually by adopting Seam's declarative approach to authentication or defining fine-grained authorization rules that enforce contextual restrictions at the level of database records, database fields, object fields and UI fragments.
Seam's security module, a central aspect of the Seam framework, offers a significantly simpler alternative to JAAS - the monolithic and cumbersome security model in Java EE. The talk begins with some definitions to sort out what we mean when we say "security". The talk then switches to a tutorial style, showing you first how to get your foot in the door by setting up a JSF form-based authentication routine in Seam using either a custom authentication method or a declarative approach where the authentication is handled by the framework. You are then presented with the numerous authorization styles that Seam supports ranging from binary, role-based, rule-based (Drools), and ACLs. Examples are presented to help you differentiate the four styles of authorization and when it is appropriate to use each one. In the process, you learn to appreciate that Seam's authorization is able to take the context (the target) of the restriction into account, a feature than many security frameworks overlook. Finally, the talk zooms out to show how to bring authentication under one roof using Seam's Open ID module.
See you at the tables...er, I mean conferences!
Posted at 05:26 AM in Java, Seam
| del.icio.us
| digg
|
Comments (1)
March 17, 2009
Ken Rimple from Chariot Solutions connected with me over Skype to discuss Seam (which in truth turned out to be a series of long monologues by me about Seam and web application development).
In this first part of a two-part interview, I introduce the Seam framework and how it represents departure from both J2EE of old and Spring. We discuss ways in which it marries JSF to POJOs and EJB components, provides a stateful view of the world and makes programming easier for APIs such as Java Persistence. The most intriguing point you'll learn from this first part is how Seam appealed to me as an application developer working out in the field, a testament to the fact that Seam is first and foremost a practical solution.
There are three ways you can track down the podcast:
- Search iTunes for Chariot TechCast (Look ma, I'm on iTunes!)
- Subscribe to the RSS feed
- Cheat and get the MP3 using a direct download
This Tech Cast promotes the upcoming Emerging Technologies for the Enterprise conference in Philadelphia, PA hosted by Chariot Solution, at which I will be speaking about Seam Security.
This entry is the 100th post I have made on this blog. Add that to the list of major milestones I've hit while being 30.
Posted at 02:52 AM in Java, Seam, Seam News, Seam in Action
| del.icio.us
| digg
|
Comments (1)
March 17, 2009
I'm speaking again this year at the Emerging Technologies for the Enterprise conference in Philadelphia, PA hosted by Chariot Solutions. It's one of few enterprise development conferences held on the East Coast that attracts high caliber speakers (and lots of framework passion) with such a remarkably low price tag (which is music to our savings accounts these days). Last year I gave an introductory to Seam talk. This year, I'll be presenting on Seam Security, highlighting its ease of use and showcasing the new identity and permission management API that was added in Seam 2.
I got involved with the conference last year through Manning, who, as event sponsor, was rounding up a bunch of its authors to speak so that they could take part the Web Framework Shootout panel. If you missed it, the audio from that panel discussion is available online, divided into two Chariot TechCast episodes (part 1, part 2). It's worth checking out because there certainly was a lot of shooting...off at the mouth, that is.
You can listen to the whole discussion to get the context. But I've distilled my responses for you into three short segments. I realize this post is long overdue, but since it retains more than just historical value, I've decided to move forward with publishing it.
- Segment #1: (01:10) I define what exactly Seam is in response to Marjan's poignant question about it
- Segment #2: (02:35) I introduce myself and give a broad overview of what Seam provides
- Segment #3: (01:30) I identify the business value in adopting Seam and contrast that with how little Struts 1 provides
The shootout was supposed to be about Web Frameworks, but the debate ended up playing out on two separate playing fields. The first debate was about Ruby vs the World, which got quite heated at times thanks to Obie and someone denouncing Twitter's ability to scale (which it mistakes for a fail whale). The second debate was about RIA built on JavaScript vs the more traditional server-side UI component model.
As you'll hear, I abstained from making incendiary comments and instead tried to emphasize the value Seam provides and how it really allows you to forget about much of this debate. First, because it makes the Java EE platform attractive and accessible and second, because it can plug into a wide variety of other UI frameworks, whether it be GWT, Wicket, Flex, or JSF and non-web frameworks, like JMS, Quartz, and jBPM.
Keep in mind that these excerpts are nearly a year old at the time of this post. However, it's interesting to hear what I had to say about Seam at the halfway point of writing Seam in Action. Seam's message hasn't changed all that much since then, even though the number and quality of the integrations has improved substantially. I wouldn't be surprised if I look back in a year and have the very same thing to say. Seam is all about trimming the fat (i.e., framework code) resident in the application so that what is left is core business logic. Some of the business logic may even get wrapped up in Seam's declarative programming model.
Posted at 02:25 AM in Java, Seam, Seam News, Seam in Action
| del.icio.us
| digg
|
No Opinions?
January 21, 2009
As were many, I was moved by the passion of Inauguration Day 2009 in Washington. But one phrase, in particular, from President Obama's speech resonated especially strong with me because I feel it captured the principle of which a majority of us believe in as open source developers and supporters (substitute public dollars with community-developed software):
And those of us who manage the public's dollars will ... do our business in the light of day - because only then can we restore the vital trust between a people and their government."
The words that are not said, but somehow implied, is that by being open, you mobilized an enormous workforce to assist, guide, and support your effort, thus making your cause even stronger.
One can't help but to wonder what government would be like if it were run on mailing lists, IRC chats, and web forums instead of behind closed doors. Time will tell whether Obama will steer the US government in that direction, or perhaps a more suitable variant. There's no doubting his intent that he is going to try. In fact, the first post on the new whitehouse.gov blog states this goal quite candidly.
Posted at 03:15 AM in Open Source
| del.icio.us
| digg
|
Comments (3)
