I’ve had a few conversations lately about software tools and technologies — how to use them, how to pick them, how to know when to change, etc. These conversations can be exciting, educating, emotionally charged, productive, and sometimes not.
In a recent, very positive exchange, one colleague asked if I preferred Maven over Ant or Ant + Ivy simply because I had more experience on Maven.
Generally, I couldn’t say I preferred one technology stack over the other because I simply don’t know enough about the organization to make the call.
From a purely technical perspective though, my gut told me there is a brighter future in Maven than in Ant+Ivy. My reasons for this opinion are grounded in my experience, so I decided to research a few factors I consider important when it comes to technology tool selection.
Latest Stable Release
Couple of interesting observations from the stats above:
- While Ivy is ‘2 years newer’, it’s last stable release was roughly 2 years earlier than Maven.
- There are roughly 1500% more GitHub repositories referencing Maven than Ivy
- There are roughly 1400% more contributors for Maven than Ivy (according to ohloh.net, anyway)
Google Trends also has an interesting view contrasting these two projects: Google Trends: Apache Maven, Apache Ivy
When discussing open source software projects, I usually think “we need to consider the vibrancy of the community”. How many people and organizations are contributing? How often? What other well known projects integrate with this tool?
From my view - when it comes to technology selection, it’s often OK to “follow the crowd”.
It always bothered me that the JSR168 <portlet:actionURL /> and <portlet:renderURL /> tags didn’t encode their HTML character entities. The lack of encoding causes your HTML 4 or XHTML 1 markup to fail automated validation. After flipping through a bit more of the JSR286 spec, it mentions that in JSR168 “the behavior in regards to XML escaping URLs written by the tag library was undefined” 1. So, some vendors may have encoded and some may not have (as of 2.7 JBoss Portal, for example, does not).
Well, it turns out that the JSR286 expert group noticed that and accounted for it. Section 10.4.1 defines a new container runtime option: javax.portlet.escapeXml. The option causes portlet URLs to be escaped and is true by default. This is primarily for backwards compatibility so that older portlets that dependended on unencoded URLs will work on a portlet 2.0 container.
For example, you wouldn’t want to call the following:
Because the URL above would be encoded, your ‘id’ parameter wouldn’t be passed along properly.
It’s always nice to see this kind of improvement in the spec; hope this is helpful for you!
I thought I’d throw together a quick precursor to another post I plan on finishing in the next few days. This post is about portlets - or, how to structure the HTML markup for a JSR168/JSR286 portlet, to be more specific.
I’ve worked on theming portal user interfaces for a few years now, primarily on IBM WebSphere Portal and JBoss Portal. On WebSphere, you develop what’s called a ’skin’ - where the markup for a given portlet lives. JBoss has a similar but more granular concept called ‘renderers’. Being a big fan of the principle of semantic markup or POSH, I’ve come to think that all portlets should have the same general shell or HTML markup.
So, I present the perfect portlet markup:
<div class="portlet-window"> <div class="decoration"> <h2 class="title">portlet title</h2> <ul class="controls"> <li class="skip"><a href="#skip_$PORTLET_ID">skip this window</a></li> <li class="mode edit"><a href="#">edit this window</a></li> <li class="mode view"><a href="#">view this window</a></li> <li class="windowstate minimized"><a href="#">minimize this window</a></li> <li class="windowstate maximized"><a href="#">maximize this window</a></li> </ul> </div> <div class="portlet-content"> portlet content </div> </div> <a name="skip_$PORTLET_ID"></a>
You might notice this layout:
- follows the JSR168/JSR286 naming standards for window, decoration, controls, etc.
- marks the portlet title up as a level 2 heading; from my experience this is the ‘right’ choice for the portlet title as the portal page title itself should be the level 1 heading
- to promote accessibility, renders actual text content in the mode/state menu anchor links (which should be internationalized and can be replaced with appropriate icon images using your css image replacement technique of choice, of course)
- to promote accessibility, adds a skip link to the mode/state menu for skipping the content of a given portlet (this is very useful for screen readers and can be removed from the page using your css text hiding method of choice)
Note that one or more the elements in the shell may be removed. For example, sometimes portlets won’t display their portlet title, which is often the case with content-manged portlets (ideally, this would be a configuration rather than separate skin or renderer).
By the way, this post is intended to be a bit controversial; hoping to challenge my audience (if there is one =P) and maybe to come to some kind of consensus.
So what do you think? Did I get it right? What would you change or improve to this portlet markup?
Sometimes I look at old draft blog entries and ask myself “what was I thinking?”. Every once in a while, though, I look at an old draft post and say “hey, that’s pretty cool!”. This article fell into the pretty cool category, not so much for the content, but the example app, so I hope you enjoy it (OK, you can skip to the end now).
There’s a long-standing, accepted pattern for handling form submissions in web applications; it’s usually called the post redirect get pattern. The goal of the pattern is to prevent the payload of a HTTP POST request from being stored in the browser history.
Keeping the POST data out of the browser history helps prevent duplicate form submissions and also is the best way to make sense out of navigating backward/forward through the history after a post. Imagine refreshing a webpage without the PRG pattern after making a credit card purchase.
To speak in HTTP terms, the PRG pattern intends to handle the non-idempotent nature of the POST method. As defined by the HTTP specification, it’s not safe to submit the same POST data more than once, so the PRG pattern prevents the user from resubmitting POST data when refreshing their browser window or navigating through their browser history.
As I mentioned, this is a long-standing pattern and as such, there are several references available that describe it in full detail:
It is also widely implemented in most modern web application frameworks (eg: JBoss Seam, Ruby on Rails) and because it avoids problems caused by HTTP itself, it is implemented in various web-specific languages/frameworks (JavaEE, .NET, PHP, Python, Ruby, etc).
OK, so why did I think this post was worth finishing? Well, many moons ago, I built out an example application in PHP demonstrating the post redirect get pattern.
Hope you find it useful.
Packt Publishing recently published a book on JBoss Portal; the book, titled JBoss Portal Server Development, is written by Ramanujam Rao - a JavaEE architect who currently works for Nationwide. Packt sent me a copy and asked that I write a review of the book, which I plan on doing in the next few weeks.
Until then, Packt has made available a sample chapter of the book - JBoss Portal Server Development, Chapter 6: Portals and AJAX (download the sample chapter at: http://www.packtpub.com/files/jboss-portal-server-development-sample-cha...).
In the sample chapter, Rao discusses the basics of AJAX in the Portal environment, describing the enhancements for asynchronous communication JSR286 brings to the table. He also provides some basic code examples implementing a portlet with AJAX functionality, in addition to describing JBoss Portal’s out of the box AJAX support (drag and drop, partial page refreshing, etc.).
I’m excited about the book, because I think it’s one of the first on JBoss Portal, which speaks to the products coming maturity and will give it some clout to compete with the other portal vendors. I’m sure the folks at JBoss Mass would agree.
At first glance, the book appears to be a solid companion to the jboss.org documentation, adding an additional level of architectural guidance; it’s a great addition to the bookshelf if you’ll be working with JBoss Portal.
Do you use Spring Portlet MVC? Have you ever noticed the ImplicitModel request parameter in your URL? It looks something like:
Well, it’s a Spring Portlet MVC 2.5 feature and I was scratching my head trying to figure out what it does. It’s set by Spring under the covers, so I dug into their source code to understand it and thought I would share.
The ImplicitModel is defined in Spring’s AnnotationMethodHandlerAdapter (which I describe in another post on annotation-driven portlet development w/Spring). In short, the AnnotationMethodHandlerAdapter is primarily responsible for scanning the @RequestMapping annotations on a given controller and executing the best matching method. It also sets and retrieves the ImplicitModel on portlet requests.
So what does the ImplicitModel do? Well, because most portal implementations redirect to the render phase after an action request (applying the post-redirect-get pattern), request attributes set in the action can’t be used in the subsequent render phase.
Spring Portlet MVC uses the ImplicitModel to overcome this limitation. On an action request, if the request’s model (see ModelMap class) isn’t empty, the AnnotationMethodHandlerAdapter will automatically store the ModelMap in portlet’s session for use on the upcoming render request. It also sets the render parameter (org.springframework.web.portlet.mvc.ImplicitModel), to tell the render phase to pre-load its model from the ImplicitModel stored in the session.
One additional tip: after a successful action method call, you may want to manually clear the model to prevent the action model data from being stored in the ImplicitModel. As an example, say you submit a form in an action request and render the same form with a success message after a successful submission. If you don’t want to display the originally submitted data on the success view - call ModelMap.clear() to prevent it from being stored as an ImplicitModel.
I have to admit, I can totally relate to Eric Spiegelberg’s article, JSR-286: The Edge of Irrelevance.
It’s a great article; in case you don’t have time to check it out, Eric’s main thesis is that:
the portal architecture lacks enough technical advantages and distinguishing features to warrant an increase in acceptance.
Over the past few years, I’ve complained about there being a “portlet spec, not a portal spec” - a thought Eric seems to echo in pointing out that most real-world projects require modifying the portal server but that in doing so, you’re tied to your vendor’s API and are no longer JSR168/286 compliant.
One of the other running themes in the article is that the portlet specs are perpetually out-dated. For example, the JSR286 spec itself (which went final release in June 2008) mentions its aim to align the portlet spec with JavaEE 1.4 (which went final release in November 2003)!
All-too-often portal is an after-thought: first came Spring MVC, then came Spring Portlet MVC; first came JSF, then came a new spec (JSR301 - the portlet bridge) to make JSF work in the portal environment. As frameworks like JBoss Seam are solving the truly challenging problems with web applications (contextual state management, back button, multiple browser windows), portal lags behind, requiring patchwork to support fundamental pieces of the new JavaEE.
Finally, I also agree with Eric that portal’s “greatest strength, the portlet, remains its greatest weakness”. On my current project, we fight with the portlet programming model every day. One could argue that if we’re having constant problems w/portal, then we’ve either got a bad design, bad developers, or we’ve incorrectly chosen to apply portal to our problem. I can hear the crowd now: “you’re doing it wrong”.
Regardless, I think our woes support the author’s point that the portlet development paradigm is “overly restrictive” and that the technology and features provided by portal don’t add enough value for the costs.
So, given the downsides, portal does have its benefits - IMHO portal’s primary strong suit is in aggregating web applications. Yet still I agree with the author that this benefit doesn’t outweigh the costs - you don’t get your money’s worth, so to speak.
So what do you all think?
Does Java EE need a new, less restrictive means for aggregating web applications?
Or do the author and I understate the benefits of portal? What other benefits do JSR168 and JSR286 provide?
Jared Richardson spoke at a Richmond Java Users Group meeting I attended last week; his topic was about investing in yourself and your career - what he called career 2.0. At one point during the presentation, he noted that “if you can’t draw something, you don’t understand it”, which motivated me to finish a blog post I started a while back about Spring Portlet MVC.
I gave a presentation at CapTech’s Feed Your Brain series about using Spring Portlet MVC’s annotation-driven development style, and I wanted to diagram how the lifecycle works under the covers.
The following diagram never made it into the presentation so I wanted to post it here.
Sorry if the graphic doesn’t blow you away; I have an older version of OmniGraffle - but want to get one of these.
So, in short the graphic depicts:
- like most implementations of the Front Controller pattern, the DispatcherPortlet sits in front of all PortletRequests
- if a DefaultAnnotationHandlerMapping is set as the default HandlerMapping implementation in your Portlet’s Spring application context, the DispatcherPortlet will use it to find a @Controller
- the DefaultAnnotationHandlerMapping itself searches your application context for the best matching class annotated as a @Controller
- the DefaultAnnotationHandlerMapping then passes control back to the DispatcherServlet, which then needs a AnnotationMethodHandlerAdapter to determine which method to call on your controller
- the AnnotationMethodHandlerAdapter then checks for methods annotated with @RequestMapping and, again, finds the “best match” method to handle the PortletRequest
- the request is served, and control is passed back to the DispatcherPortlet - voila!
Hope this is helpful to those looking to use Spring Portlet MVC’s nifty annotation model.
I’ve always been an open source fan and for the past 2 or 3 years I’ve been working with JBoss products - lately JBoss Portal. So, I decided I want to become more active in the JBoss Portal forums on JBoss.com - unfortunately, though, their forums aren’t RSS-enabled and I’m a big RSS user.
So, I decided to use one of my favorite, free web-tools - Yahoo Pipes - to build an RSS feed for the JBoss.com forums.
In short, the pipe does the following:
- uses a URL Builder object to “scrape” the jboss.com forum site
- passes in a parameter of the forum ID to read (ie: 215 for the Portal User’s forum, 205 for the Portal design forum)
- uses regular expressions to slice and dice the fetched page into an aggregated RSS feed
Because the forum ID is a parameter, you can add any JBoss.com forum to your RSS client of choice. The feed results aren’t perfect (eg: doesn’t get the original post date right), but it does the trick for my needs.
So check out the JBoss.com Forum Feeds Pipe at: http://pipes.yahoo.com/pembertonandy/jbossforums
Feel free to clone the pipe and use it to your liking; the same technique can be used on any publicly available site. Let me know if you like it!
Before the Portlet 2 specification (JSR286), the recommended method for adding AJAX functionality to a JSR168 portlet was to deploy an additional servlet to the portal server (either inside the same WAR as your portlet(s) or in a stand-alone WAR) to handle asynchronous requests. Requests to these servlets are then handled by the servlet container as opposed to being routed through the portlet container, so they don’t automatically inherit the security context from the portal, as your portlets would.
The goal of this article is to describe how to enable security in your AJAX servlets in JBoss Portal 2.6.
JBoss Portal 2.7 supports JSR286, which has features built into portlets for serving AJAX requests. So while this technique may be less useful in that environment, nothing precludes the use of AJAX servlets in the 286 environment, so this technique may still come in handy.
Securing AJAX servlets in JBoss Portal 2.6 involves four high-level steps.
Step 1: Add the Portal’s Security Application Policy to the Servlet Container
Step 1 is mostly a copy/paste effort. The key point here is that you’re configuring the servlet container to use the same JAAS settings that you’ve configured the Portal to use. You’ll want to look at the Portal’s JAAS settings in: $PS_HOME/server/default/deploy/jboss-portal.sar/conf/login-config.xml
There should be a block that looks something like: - you’ll want to copy this block into the login-config used by the servlet container at: $PS_HOME/server/default/conf/login-config.xml
<application-policy name="portal"> <authentication> <login-module code="org.jboss.portal.identity.auth.IdentityLoginModule" flag="required"> <module-option name="unauthenticatedIdentity">guest</module-option> <module-option name="userModuleJNDIName">java:/portal/UserModule</module-option> <module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option> <module-option name="userProfileModuleJNDIName">java:/portal/UserProfileModule</module-option> <module-option name="membershipModuleJNDIName">java:/portal/MembershipModule</module-option> <module-option name="additionalRole">Authenticated</module-option> <module-option name="password-stacking">useFirstPass</module-option> </login-module> </authentication> </application-policy>
Step 2: Secure your AJAX Servlet Web Application
This step is standard for securing web applications; just add the appropriate security settings to the web.xml deployed with your AJAX servlet WAR.
For example, these settings may look like:
<security-constraint> <web-resource-collection> <web-resource-name>Security</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>Authenticated</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>JBoss Portal</realm-name> </login-config> <security-role> <role-name>Authenticated</role-name> </security-role>
Step 3: Configure your Servlet Web App to use the Portal Security Policy
At this point, we need to tell the servlet web app which JAAS security-domain to use, ie: the one we added in step 1. To do this, JBoss has a proprietary extension to the servlet spec that uses a file: jboss-web.xml in the same location as your web.xml. Add in the following:
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd"> <jboss-web> <security-domain>java:jaas/portal</security-domain> </jboss-web>
At this point, your servlet web application should be secured and using the same security-domain as the Portal. There’s only one small problem: when you first log in you’ll notice (if you used BASIC as your auth-method as in my example), you’ll get prompted to login from your AJAX calls in addition to logging in to the portal. This is because the Portal and your AJAX servlet application are separate web applications deployed to the application server, and do not inherently trust eachother’s authenticated sessions.
Step 4: Enable Single Sign On between the Portal and your Servlet Web App
Luckily, JBoss uses Tomcat under the covers as the servlet container, and Tomcat has a nice, out-of-the-box feature for enabling single-sign-on (SSO) between web apps. To do so, you simply need to enable the SSO valve in Tomcat’s server configuration at: $PS_HOME/server/default/deploy/jboss-web.deployer/server.xml
See the Portal reference guide for more information on enabling SSO in Tomcat.
So that does it. Your AJAX servlets are now secured using the same security-domain as your Portal install and are configured for SSO.
Hopefully you found this technique helpful; if you have any comments, questions, or improvements please comment.