- Andrew Kos
- Bill Burlein
- Bryan Williams
- Christian Vozar
- Jeff Brown
- John Kraus
- Joseph Mak
- Josh Durbin
- Mark Daugherty
- Matt Van Bergen
- Melissa Geoffrion
- Michael Kang
- Michael Chan
- Michael Hodgdon
- Mike Motherway
- Molly McDaniel
- Nadia Maciulis
- Pat McLoughlin
- Paul Michelotti
- Puru Hemnani
- Rohit Srinath
- Ryan Lunka
- Tom Kelly
Existing Seam application converted to a JBoss Portlet
Wednesday, February 25, 2009
Recently, I had the need to port a standalone web application that was written in Seam to be a portlet within JBoss Portal. Overall, I was surprised at how easy this process was, but also wanted to write about a “gotcha” to maybe save someone else some time.
Some background: I have a standalone web application written in Seam and the client wanted to add some basic content management around this web site. One option was to integrate a JCR-compliant repository directly into the application in the same manner as my colleague did for another client and discussed here. However, I chose to go with JBoss Portal because I was wanting more out-of-the-box functionality related to CMS. IE: JBoss Portal is already wired to Apache Jackrabbit and has the CMS-related portlets already created that I would need. This would also allow the client to eventually add in some additional applications in the future with a single sign-on for the users.
Porting the application from standalone to a portlet is misleading because what you are really doing is just adding the ability for the application to run as a portlet. It can still run as a standalone web application as well. Take note of that even if you don’t ever plan to do it in production. The face that a developer can test and troubleshoot the application as a standalone application without introducing the additional portal complexities is a very useful practice.
How does this all work?
The JBoss Portal Bridge did the heavy lifting for me. The bridge is an implementation of JSR-301 and goes beyond vanilla JSF integration to include Seam and Richfaces JSF applications as well. I simply followed the directions included with the bridge download for integrating the Bridge, which is just 2 JAR files in my application’s WEB-INF/lib directory. If you are not familiar with JBoss Portal, realize that a portlet is deployed as a WAR within the JBoss /deploy directory. So, I had to add these 2 portletbridge JAR files to the existing Seam project. I also had to add a few XML files required by any portal. These are spelled out in detail with examples in the short documentation included with the bridge download so I won’t repeat them here.
So, I followed the directions in the documentation to update my existing WAR with 2 new JAR files and some additional XML and deployed to a JBoss Portal 2.7 instance instead of the plain JBoss App Server it had been running on. I then brought the site up directly as a standalone site still in order to verify I had not broken anything by adding these new JARS and XML files. All worked great. Then, I switched over to the /portal context and as an admin I created a new portlet instance based on my new portlet and added it to a page. However, when I accessed that new portlet within the portal, I received a not-so-pretty exception stack.
The “Gotcha” – or why I should read all the instructions first!
The stack trace was caused by a “method does not exist” error in a Richfaces class called by one of the bridge classes. Looking into this, I realized the JBoss Portal Bridge was expecting and actually came bundled with a newer version of the RichFaces libraries than I had been using in the existing Seam application (Seam 2.1.0_SP1). This is all spelled out in the wiki site for the Bridge – which I did not bother to read until I saw the problem! Once I updated my Richfaces libraries to the versions provided with the Bridge things worked fine. Note – if I had used the proper version of Seam tested with the Bridge version to begin with I would have been fine.
Based on what Red Hat presented at the JBoss Virtual Event on February 11th, my understanding is that the next version of JBoss Enterprise Portal Platform will include support for the JBoss Portlet Bridge. Plain JSF based portlets would have full support and Seam-based portlets will be supported as a Technology Preview, meaning they will not have an SLA attached to that support.
For more than 19 years, Jeff has been developing well-designed, high-quality software products to meet business needs across many sectors, including: retail, government, insurance, education, and manufacturing. He has expertise in distributed messaging systems, service-oriented architecture design and implementation, and most recently has worked extensively with content management systems.
- Descriptive JMX Beans in AEM/CQ
- Invisible requirements within Business requirements
- Building a better Options Predicate
- Extensionless URLs with Adobe Experience Manager
- The Life of a Tester in Adobe CQ World!
- Limitations of the CQ Parsys Model and the Implementation of a Nested Paragraph System
- Using Apache FOP to generate a PDF document based on a form submission data
- Configuring SAML in AEM 5.6