Back at Apache's Jakarta project some time ago, I was involved in a bit of a row over how to accept a project and its very motivated leader, Howard Lewis Ship. Howard is a cool guy with two last names. His project, Tapestry is a great alternative to JSPs and (more or less) JSP-based frameworks like struts. Recently, Tapestry has started moving from XML to annotations and has even posted about some ready to run examples distributed with JBoss 4.0.2. You can find the examples here and their instructions here.

 

Howard Lewis Ship

 

...I go a ways back with JBoss, so it was easy for me to build and package, and is a good use of my very scarce time.

JBoss Mail Server is so stable and the installation is so clean that after only one month of having dedicated company support for it and full time development (well 75% since all developers are expected to do 25% services), I'm already getting pressured to call it 1.0. It is a high compliment.

Moreover, a user emailed me saying his boss told him he was outsourcing their mail server unless they could get one up in running in 30 minutes. He installed JBoss Mail Server and wrote me to tell me about it.

I picked up the phone.

"Hello?"

"Andy. Marc."

"Hi Marc, how is it going?"

"Listen, this JBoss Mail Server thing...its really good...lot of people use it...but after a year of stable releases there is no business... we have to dump it... You shouldn't have made the Installer and admin tools so good."

"What do you mean?"

"Well no on needs support because it is too easy to use."

"Yeah, I see what you mean."

"Good luck in your next endeavor."

I woke up in a cold sweat.

So I thought about this seriously. Could an open source mail server be too easy to use such that it was a commercial failure? However, the more I thought about it, the more I realized how ridiculous it is. While we're already incredibly easy to use, running your mission critical software without some guarantee of support is not a smart thing to do. For most businesses an email outage costs money. Lost mails are a critical problem that affect the bottom line. Take "sales@jboss.com" as an example. They don't want to miss a potential support, consulting, training or partnership opportunity because of the latest Exchange security hole or the upgrade cycle to prevent the next 10 of them...

Yet despite this, we put up with outages in critical services every day and often times due to the unreliability of existing vendors (you know who I'm talking about -- remember the helicopter joke) and their support offerings, we go it alone and sometimes spend needless hours of downtime instead of getting the prompt answers we need from the experts and guys who develop the software we use.

I suspect if the software is good enough and the tools are good enough then there are some who will go it alone who might not have gone it alone with other software, but frankly those are the same people who drive around with no insurance or don't wear seat belts because they don't usually get into car accidents. Moreover, I don't expect to do consulting for simple installs, frankly consulting for simple installation and configuration is a cost sink not a profit center. I want to eliminate that opportunity where possible. Instead I want to open up a high end consulting service opportunity. Ultimate scalability, big organizations who need help figuring out how to structure their mail infrastructure to allow it to handle an enormous (and ever growing) messaging load. Mail based/Mail driven application developers wanting to do new and interesting things on a mail platform. Complex routing. Custom plugins. Partner integration.. Those are where I expect the project to make a profit, I hope to never have to do consulting for a simple 1-3 server configuration -- I'd rather handle that as a simple support offering (and those should be few and far between because the installer should be that good).

To me, in order to get to the high end, we need to make the low end a nearly brainless venture. We're not there yet, while installation and initial configuration is trivial (a mail server in 30 minutes or less supporting POP/SMTP over SSL/TLS), administration beyond initial configuration is still a jungle of XML. While I exaggerate when I say we're nearing the XML version of sendmail.cf, it is something I fear. We've made progress and have plans to solve this in the next milestone release after M4(which won't be called 1.0-final ;-) ). However, the final piece will be a bang-up GUI that dynamically configures a cluster of JBMS instances. What form the GUI will take hasn't been decided (if it can use the same stuff as is being built for the appserver or what). My take is that the counter-intuitive notion of making thing easier to use and less difficult will drive adoption and hence support (how many of you really drive with no seatbelt and no car insurance, if you're on the high end and an expert can save you weeks or months by helping out for a few hours/days/etc then are you really going to balk). We see some of the same logic happening in the Appserver world with EJB3 and the upcoming admin console, it is time we had a reliable mail server that takes 30 minutes or less for simple installation, is easy to administer, and yet flexable and scalable enough to handle anything from 1 user or a complex enterprise.

I'd really be interested in talking to GUI people interested in getting involved in open source. You're a hot commodity! Join us in the JBMS forum and/or email me. I may not reply immediately as I'm conducting my 25% services in Matsuyama Japan this week, but I value you and your contributions! In addition to JBoss, we have a great bunch of volunteers I think you'll enjoy working with. I'm lucky to work on the best damn project in all of JBoss. :-)

JBoss Mail Server 1.0-M3rc1 has been released. You can install the JDK 5.0 version of JBMS-1.0M3rc1 via Java Web Start. You can also download it directly and install by typing java -jar install-jbms-1.0m3-rc1.jar. We do recommend JDK 5.0 (aka 1.5) as the garbage collector is significantly improved especially on enterprise grade systems.

If you still want to run with JDK 1.42, you can download the JDK 1.4 build of JBMS-1.0M3rc1 directly.

This is a release candidate of the third (of approximately 10) milestones of JBMS. It is primarily a stability, performance and usability release, however some significant features have been added and the architecture has gone a significant evolution. We request that early adopters assist with testing this release candidate in order to ensure the final release of this milestone (which will be released on August 20th barring major issues) is as stable and useful as possible.

While there are already production users of earlier milestones of JBMS, it is not a "final" release, it is suggested that early adopters be cautious and undergo rigorous testing before deploying this release. We eagerly invite participation in the JBMS Forum and request your feedback on the release and project direction and thank you in advance for your continued assistance and support.

With this release, some emphasis has been placed on increasing the usability and graphical installation of the software (now based on izPack). You will find many answers in this set of wiki pages as well as an installation tutorial with pictorial walkthrough, and instructions on setting up Mozilla's Thunderbird Mail Client to work with JBMS.

We hope that you and your organization will enjoy installing/using this milestone release and happy hunting!

A little while back, I put up this wiki page in order to determine what is generally viewed as:

• The best operating system for development
• The best operating system for production
• The best IDE

Thus far, a group of passionate Windoze lovers have managed to put it at the top for development, but it seems settled that Linux is "the man" when it comes to production. Eclipse seems to take the day as well. I personally vacillate between Eclipse and the greatest editor ever, vi.

I have to say, Linux with a 2.6 kernel (but not the bizzare Redhat backported 2.6 threadmodel to 2.4 hybrid that they sadistically put in RHES 3.0 which mostly just crashes Java on a good day) with Sun JDK 5.0 is a pretty impressive combination for performance.

I am somewhat shocked that Solaris didn't make a bigger showing. I've yet to see too many really large successful deployments that weren't Solaris. Save your comments for the wiki showdown (but respect the brevity).

Personally, I usually think that the tech industry has gotten a little too "standards happy". Moreover, I think that good standards need "extension points" that ensure extended capabillity without sacrificing compatibility. J2EE has a good and bad history with this.

On one hand, each appserver has different strengths and weaknesses. On the other hand, sometimes these change how you write your code. For instance, clustering options. If you are aware that you'll have a mid-tier proxyless load balanced RMI implementation (ala JBoss -- confusingly provided via dynamic proxies) you might write your code a little more liberally on its remote call usage than if you know you'll have a mid-tier proxy balanced RMI over IIOP implementation. If you know your appserver has an RMI/HTTP implementation then you might not swallow all of web services just to do site-site communication within your organization accross firewalls.

Still, standards should assure the code will still run (at least badly) between servers provided you've been careful ("import com.bea.*" would be a good clue). And where that falls apart they should assure that the "able" in "portable" (meaning able to be ported which isn't a synonym for "plug n' play") isn't a huge effort. I think despite all of the whining, J2EE deserves a lot of credit here. Personally, I've been a long time critic of the Java Community Process (my own opinion only) mainly because I think good APIs are designed via code not by committee discussions, but getting the major players to come to the table deserves some commendation (whoa did I say something nice about the JCP). Open source is really starting to thrive and drive this. Let's face it. The programming model and even some of the technical decisions behind EJB 1.x-2.x sucked. EJB 3 is really a whole different beast. Built on the core provided by J2EE but really kind of a "how real Java developers think" approach.

Lastly, standards should assure integration at the protocol layer. The W3C and really open source has done a lot in this area. Examples from Apache to Sam Ruby's spawning the Atom effort (originally called Pie and then NPie IIRC) among many other examples. However, I think this is an area we have a lot further to go. Web Services has created a huge number of specs and I'm getting a bit of de ja vu from the CORBA days (though I mostly observed). Now we are approaching a potential integration brick wall as companies create road blocks in the form of software patents. Moreover, not all web services implementations actually work together properly the way they are supposed to. Standards are a good faith effort and sometimes the faith isn't that good and other times... well... we kinda screw it all up, as is probably the case with Apple's iTunes syndication and Disney's Gears behind the Ears (there you go Sam).

Driving this process has been new techniques of communication. When I first installed this blog and invited the other JBoss guys to post on it, it was treated with some trepidation as was the JBossWiki. However, I think you can see they've been fully embraced here, especially by management. I'm not going to hype cluetrain because it was written like some kind of weird manifesto anyhow, but new standards like syndication are changing the way we communicate. It even appears to be working...mostly! More importantly the way we communicate is changing the way standards and technology in general are created. I think this is why things tend to fall short of our expectations. Conway's Law is nearly inescapable and we need to create better communication and structures of communication to counter balance this or we are just stuck.

That's actually one of my major goals for JBoss Mail Server. I want to do more than build just a mail server but to really change the way we communicate. I want to do more than kill spam for good, but find ways to make effective communication easier. Of course, we have to walk before we run, but I think we'll get there. Its really about trying to think different and drive the standard forward. For instance, why are IM and mail different at the lower levels? Why can't we syndicate our HAM to kill our spam? Why do 12 copies of the same attachment get sent rather than one get syndicated and why do I have to deal with that oppressive document management system just to make that happen? Why can't my email just arrange itself topically and appropriate materials syndicate automatically? Drag the standards forward kicking and screaming if we must, while making sure we stay compatible and continue to communicate.

That being said, what do I do about how bad JavaMail sucks, especially performance-wise (maybe a big synchronized singleton hashmap for all the mime types wasn't such a great idea)?

For people who use the "shorthand" form of xmbean descriptors and embed it directly in their -service.xml descriptor here is a quick hint. This is something that regularly trips me up at least.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server
    PUBLIC "-//JBoss//DTD MBean Service 3.2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-service_3_2.dtd">
 
<server>
    <mbean code="org.jboss.mail.MailListenerChainService"
           name="mail.test:service=mlchain">
           <xmbean>
   <class>org.jboss.mail.MailListenerChainService</class>     
      <constructor>
       <description>The no-arg constructor</description>
       <name>org.jboss.mail.MailListenerChainService</name>
      </constructor>
               
   <attribute access="read-write" 
                                         setMethod="setListeners" 
                                         getMethod="getListeners">
     <name>Listeners</name>
 <type>org.w3c.dom.Element</type>
   </attribute>        
           
           <attribute access="read-only" getMethod="getNumberListeners">
            <name>NumberListeners</name>
            <type>org.w3c.dom.Element</type>
           </attribute>
           
           <operation>
            <name>processMail</name>
            <parameter>
            <name>mail</name>
            <type>org.jboss.mail.message.Mail</type>
            </parameter>
            <return-type>org.jboss.mail.message.Mail</return-type>
           </operation>
           
               &defaultOperations;
           </xmbean>          
    </mbean>
</server>

The problem is that for the JBoss deployer to detect that "yes, it is an xmbean" and not a "regular mbean" it requires the xmbean-dd attribute on the "mbean" element even though you've embedded the xmbean element. If you forget it (like I did above) you get a very unsatisfying "org.jboss.deployment.DeploymentException: Class does not expose a management interface: java.lang.Object;".

meaning:

...
<server>
    <mbean code="org.jboss.mail.MailListenerChainService"
           name="mail.test:service=mlchain" xmbean-dd="">
...

I want to offer my congratulations to Heiko W. Rupp. Heiko announced that his book JBoss Server-Handbuch für J2EE-Entwickler und Administratoren is hitting the presses.

 

Today I got the first copy of my JBoss book from the publisher. Really neat. Within the next days the printing plant will supply more copies to the distributors and stores, so it will be available until around the start of next week in stores.

Maybe I'll pick up a copy so I can work on my kaput-Deutsch.

For those of you hoping to use JBoss Blog to enhance your google ratings for you medical enhancement products, I have enabled Google's nofollow feature for trackbacks and comments. This is a feature of Blojsom, the weblog software that we use. This will hopefully restore the PG-13 rating of older posts to which these unscrupulous persons have added. If it doesn't get better than maybe Roy "Backstreet Boys are cool" Russo can help me require registration for comments and trackbacks.