Raible Designs

Java CMS Systems

Michael Levin is at the JavaPosse Roundup this week. Today, they're discussing Java CMS Systems. I recently had an e-mail discussion with a reader regarding Java-based CMS Systems. In hopes of getting these questions answered by Michael today, here's that thread:

Original E-Mail:
OpenCMS, Magnolia CE/EE, Atleap, Alfresco, Liferay.

Magnolia EE, Day Communique, Hannon Hill, Refresh, Vertical Site.

We are leaning towards Magnolia EE since we have a load balancer and two production server, but I bet we could hack in support in the community edition.

Any comments/recommendations? -------- My response:
I'd check out Alfresco's new 2.0 WCM - just released last week. I haven't looked at many of the CMSes in a year or so, but I'm willing to bet that OpenCMS still has issues installing. I still like Drupal too and recommend it for folks just wanting a website they can edit.

In reality, my experience with CMS systems is outdated and you shouldn't consider me an authority. -------- Thanks for the lead. We actually eliminated Alfresco, b/c I thought they were more of a portal.

The reason we were leaning towards Magnolia and Vertical Site was b/c of JSR 170 (which Alfesco claims to support).

I wonder about the scalability of JCR, do have an opinion? -------- I don't have an opinion because I don't have much experience with it. It's supposed to be the JDBC of CMSs, so I imagine it's pretty scalable. However, it's pretty new, so I'm sure there will be growing pains. I know that Infoq.com uses Magnolia as their backend (and WebWork as their frontend), so obviously it scales well for them.

What are your thoughts on Java-based CMS Systems? Comments from experienced developers appreciated more than vendor pitches.

Upgrading to Tomcat 6

Erik did it, so I tried it as well. This site is now running Tomcat 6.0.10 and it has to be the least painful major Tomcat upgrade I've ever done. By major, I mean upgrading from one version number (5.5.17) to the next. Apparently, no XML files changed (like they did from 4.1.x -> 5.0.x -> 5.5.x) because I was able to copy over conf/server.xml and conf/Catalina/** without any issues. The only change I had to make was to copy commons-logging.jar from Roller's WEB-INF/lib to JSPWiki's.

I have seen a couple of the following errors in my log files since I upgraded, so if you see any strange behavior, please let me know.

2-Mar-2007 12:36:10 AM org.apache.tomcat.util.http.Parameters processParameters
WARNING: Parameters: Character decoding failed. Parameter skipped.
java.io.CharConversionException: EOF
        at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:83)
        at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:49)
        at org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:410)
        at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:392)
        at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:508)
        at org.apache.tomcat.util.http.Parameters.handleQueryParameters(Parameters.java:266)
        at org.apache.catalina.connector.Request.parseParameters(Request.java:2404)
        at org.apache.catalina.connector.Request.getParameterValues(Request.java:1089)
        at org.apache.catalina.connector.RequestFacade.getParameterValues(RequestFacade.java:396)
        at javax.servlet.ServletRequestWrapper.getParameterValues(ServletRequestWrapper.java:189)
        at org.acegisecurity.wrapper.SavedRequestAwareWrapper.getParameter(SavedRequestAwareWrapper.java:325)
        at org.apache.roller.ui.rendering.velocity.deprecated.OldPageRequest.(OldPageRequest.java:164)
        at org.apache.roller.ui.rendering.velocity.deprecated.RedirectServlet.figurePageRedirect(RedirectServlet.java:285)
        at org.apache.roller.ui.rendering.velocity.deprecated.RedirectServlet.doGet(RedirectServlet.java:131)

I tested AppFuse 2.0 on Tomcat 6.0.10 earlier today and impressed that 1) Cargo worked perfectly and 2) most of the web frameworks worked. Which one didn't? You guessed it - good ol' JSF. That's OK though, the JSF version of AppFuse (MyFaces 1.1.5 with Facelets 1.1.11) doesn't work with Jetty 6.1.1 either. The good news is I found a workaround - removing the el-api dependency from my pom.xml makes it work on both.

    <dependency>
        <groupId>javax.el</groupId>
        <artifactId>el-api</artifactId>
        <version>1.2</version>
    </dependency>

If I remove this dependency, everything works fine on Tomcat 6.0.10 and Jetty 6.1.1. Unfortunately, it seems this dependency is needed for Tomcat 5.x. Hopefully some fancy stuff with Maven profiles can fix this incompatibility.

Java is more complicated than .NET ... unless you use AppFuse

From Java to .NET, Back To Java Again, My Little Impression of The Two:

Having said all these, integration of various java projects together really do take a lot of Java people's time, it's no joke, but it's not desperate. For example, the open source project "AppFuse" does a fantastic job integrating various frameworks for us, I strongly encourage everyone to give it a shot and see how much time it saves you.

So which platform do I like? My impression is Java offers a lot flexibility and choices, but at the same time introduced the "Paradox of Choices", having so many things and integrate them together is no easy task, it simply overwhelm the human brains. .NET on the other hand is in a controlled environment, less choices, but easy to develop.

In other words: Java development is way more complicated than .NET ... unless you use AppFuse.

AppFuse Book!

David Whitehurst (an AppFuse committer) has taken on the task of writing a book on AppFuse 2.0. I don't envy him, but it looks like he's got a lot of good ideas.

If you'd like to help David shape AppFuse Primer, please post a comment on his blog.

Maven 2 hates Commons Logging

It's true that most people hate commons-logging, but Maven 2 hates it even more. There are many open source projects that use this library, so you're likely to depend on it when you never intended to. Of course, this is Maven 2's transitive dependencies fault - but currently there's no option to turn transitivity off. I tried changing to SLF4J, but that causes some Maven plugins to fail.

Since the Maven team refuses to fix this (even though it's an *obvious* exception to their rule about not changing anything), I've fixed it myself. The AppFuse repo has a fixed version of commons-logging's pom.xml. To get the fixed version of commons-logging, delete it from your local repo, then add AppFuse's repository to your pom.xml:

    <repositories>
        <repository>
            <id>appfuse</id>
            <url>http://static.appfuse.org/repository</url>
        </repository>
    </repositories>

Since the burden of this issue clearly rests upon the shoulders of the commons-logging developers - can we please get a new release with a fixed pom? Pretty please?

Update: I tried to get slf4j to work again today. While I succeeded, I found a critical bug. The bug is that log messages don't print out the method name, just debug(), info() or whatever from your classes. It's possible to fix this by using slf4j instead of clogging. However, that won't help you get method names printed when cranking up the logging for 3rd party libraries like Spring and Hibernate. Since this won't be fixed, it seems better to stick with commons-logging. I doubt I'd have any luck getting all the libraries that AppFuse uses to move away from commons-logging.

[TSE] Hop into Real Object Oriented (ROO) with Ben Alex

This session's goals are to:

• To detail the "ROO" DDD architecture
• To show you how productive ROO can be
• To profile an Australian project using ROO

ROO is more of an implementation than an architecture. So what is ROO? It's not an Australian marsupial or an Australian airline. It's a Domain-Driven Design (DDD) implementation.

Real Object Oriented (ROO) is both an architectural approach and a framework with code generation.[Read More]

[TSE] Keynote: The Bigger Picture with Adrian Colyer

We've seen a lot of things over the last few days, but what about the big picture? It's not just about the Spring Framework anymore, but there's also a lot of sub-projects: SFW, SWF, SWS, S-OSGi. Then there's Enterprise services: clustering, persistence, messaging and scheduling. Industry trends: SOA, Web 2.0/RIA, RAD stacks.

Agenda

• Spring portfolio: unifying themes, fitting the pieces together (by layer) and future direction
• Facing the feature: my boss says I need a SOA, from auto-suggest to RIA and the quest for ever-increasing productivity

[Read More]

[TSE] The Holy Grails of Web Frameworks with Guillaume LaForge

Under the hood, Grails uses Spring MVC. It has support for "flash scope" between requests.

I find it funny that flash scope is so popular these days, we've had this in AppFuse for four years. However, web frameworks didn't add native support for it until it had a name (provided by Rails). To be fair to Struts Classic, they had support for it before Rails was even invented.

Rather than JSPs, Grails uses Grails Server Pages, which look much like JSPs. Grails uses SiteMesh by default and allows you to easily change the layout used with a meta tag.

<meta name="layout" content="main"/>

Most of the dynamic attributes in a GSP are rendered using the various "g" tags. There's dynamic taglibs for logic (if, else, elseif), iterating, linking, ajax (remoteFunction, remoteLink, formRemote, submitToRemote), form (select, currencySelect, localeSelect, datePicker, checkBox), rendering (render*, layout*, paginate), validation (eachError, hasError, message) and UI (i.e. richtexteditor). [Read More]

In Boise, heading to Florida on Thursday

This week, I'm in Boise, Idaho teaching a Spring Fundamentals course. It's cold here, just like it is in Denver this week.

I'm heading out early Thursday morning (Country Bry is teaching a Hibernate class that day) for The Spring Experience in Florida.

I'll be staying with Julie's Mom in West Palm Beach, so hopefully the commute to the show won't be too bad. My AppFuse session is on Saturday night, but I'm expecting a light showing after Terracotta's recent announcement. Jonas Bonér is doing a session at the same time as mine. Maybe if I bring a bunch of beer, I can still draw a crowd.

How do you get open source frameworks past the red tape?

From an e-mail I received earlier this month, with a subject of "Acceptance red tape":

After requesting permission to use the Spring Framework for the business logic and data access layers of an application, how do you fight something like this? Spring is not an approved Framework for the ********** environment. We understand the benefits of the framework. However, we have not certified it in our environment. Additionally, we have concerns that this framework will not gain long standing traction among the J2EE community. We would like to reduce the number of frameworks used in our environment, and do not want to be left with "legacy" frameworks that have little acceptance or support as is the case with the pico container. This is a response from one of our clients after asking about the use of a framework in our development after another vendor had used the PicoContainer without their permission. We have Spring experience and we love it. My responses have been to ask what they have certified that we could use and to ask their business staff to override their tech staff. I'm caught needing to redesign an aging J2EE application with an awfully over-architected original design confined to EJB 2.1, JSP 2.0, Servlet 2.4, and JDK 1.4.X in a very short amount of time. The additional responses were that they have only certified Struts and although both the business staff and the tech staff admit they know the benefits of Spring, neither of them are allowing us to use it.

My response:

Wow - I don't know what to say, especially when they say "Additionally, we have concerns that this framework will not gain long standing traction among the J2EE community." They're probably using Struts and they thinks it's wonderful, eh?

I could compose a long response with lots of details, but the fact that they prefer EJB over Spring is baffling. Spring is so much easier to program with, it's not even funny. Granted, EJB does have its place, but it's often used as a hammer for a problem that doesn't exist.

Have you experienced similar "Acceptance red tape" in your company? If so, how did you work around or work through it?