Skip navigation
2005

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="">

...

 

For many moons I've been running what is basically JBoss Mail Server 1.0-M2 as my personal mail server as well as the mail server of choice for a few friends and collegues. Not only has it run quite nicely, but its held up to the load and been quite stable as well. Now you may think "so what", but my server is a cheesy little Athlon PC box and chances are my friends and I get more mail in a day than most people get in a week between mail lists, spam and more. I get a few thousand a day. Many of which include large attachments.

 

While this is by no means up to our ultimate goal, its pretty darn good for a milestone release. My prevous mail server was Apache JAMES which tended to choke when I got a lot of email and had some kind of weird leak where I had to restart it all of the time. Moreover, its nice to get the occassional fan mail with my usual collection of medical anatomical enhancement ads. A colleague wrote me and told me how easy it was to install and how well it worked for him immediately.

 

We're a bit behind on the M3 release but committers have been hard at it. I'm working on getting the unit tests to work in JBoss 4.0.x (there was a feature regression that prevents JBoss microkernel from being started inside of JUnit). The M3 release is going to cut memory consumption and increase performance and scalability pretty dramatically. I'll need to get a more formal benchmarking systme up at that point because we're already able to handle the load of a small enterprise.

 

One important thing we'll need to get working soon is some form of conventional spam filter, probably just a mailListener or two. Just to save my sanity. I'd prefer a Java solution, but possibly one that can use data from more popular ones. Suggestions would of course be welcome (contributions more welcome).

 

All in all, things are progressing better than expected. We'll probably trim the feature set of 1.0 and release it sooner rather than wait for stuff like calendaring and preliminary Exchange protocol support (I'd planned 1.0 to happen at the end of the year). So take a look at JBoss Mail Server and stay tuned to the JBMS forum.

acoliver

Congrats to Heiko

Posted by acoliver Apr 27, 2005

 

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.

 

JBoss has been featured in the New York Times.

 

I would have liked to see a bit more analysis into the differences in various open source ventures and their business models. Other articles have been a bit more in depth on the evolution of JBoss and its business model, here are a few in "Google Knows Best" order:

acoliver

NoFollow enabled

Posted by acoliver Apr 26, 2005

 

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.

 

Our CTO, Scott Stark doth not partake of the blog. Thus I will repeat the jist of his words here since I suppose there are those who don't subscribe to the jboss-development mailing list for the very reasons this change has been made.

 

We have made a number of changes to address the growing JBoss project set.

 

The cvs repository has been moved to anoncvs.forge.jboss.com to provide more reliable and resposive access for both anonymous access and comitter access. See http://www.jboss.org/wiki/Wiki.jsp?page=CVSRepository for the CVSROOT details.

 

The jboss.jira.com event mail messages have been moved from the jboss-development@lists.sourceforge.net list in favor of a new jboss-jira@lists.sourceforge.net list. See the http://lists.sourceforge.net/lists/listinfo/jboss-jira page to subscribe to jboss project jira events.

 

The developer forums postings have been removed from the jboss-development@lists.sourceforge.net list in favor of a new jboss-dev-forums@lists.sourceforge.net. See the http://lists.sourceforge.net/lists/listinfo/jboss-dev-forums page to subscribe to all dev forum postings.

 

The jboss-development@lists.sourceforge.net is now for free-form cross-project jboss discussion and automated build error messages. All committers should be subscribed to this list for general development issue discussion and notification of build errors.

 

So now we have a place for discussing larger project issues and those who find having email copies of the forum posts useful can have that too.

 

For those who prefer to use aggregators, you can also still get RSS feeds of forums by replacing the forum's number in this link (where 186 is the number for the JBoss Mail Server forum). Presently there is a bug where the posts don't always come out in the order that you'd expect (at least not in firefox).

I was pitching in with support cases when I came upon this one:

Created By: Support Customer, 4/15/2005 11:27 AM Last Modified By: Stan Silvert, 4/15/2005 12:18 PM

Subject: JBoss on Commadore 64

Description: How do I get the JBoss Application server to run on my Commadore 64?

 

Will 64K be enough memory?

And while it is rare, I have seen enough similar questions to where it did not immediately occur to me that this was a joke. (April fools being over and all) Upon further inspection, I realized it was a test case. I thought I'd share:

Case Comments   Help

Action  Public   Comment 

Make Private   4/18/2005 9:59 AM | Adrian Brock

To enable clustering on the C64 you need to:

POKE 17645,89

:-)

Make Private   4/15/2005 11:58 AM | Luc Texier

it is called "Commodore" not " Commandore"

 

http://www.silicium.org/cbm/c64/c64.htm

http://www.silicium.org/english.htm

 

Pay some respect punks!

Make Private   4/15/2005 11:35 AM | Support Customer

Any chance you will build a version of JBoss using BASIC? That would make it more popular among Commadore 64 users.

Make Private   4/15/2005 11:34 AM | Jim Moran

To get the performance you need you may want to consider clustering 4 of your 64s.

This way you will be running with a full quarter meg of memory.

Make Private   4/15/2005 11:30 AM | Stan Silvert

JBoss runs great on the 64.

 

JBoss will run on any Java VM, including those platforms for which no VM exists.

 

No application will ever need more than 64K. That's a LOT of RAM dude.

This is a sign that there are not enough support cases being logged today. Please go mess something up. :-)

 

Check out Does EJB 3.0 really make application development easy ? over on a blog called Loosely Coupled. Its a really great simple example. (PDF version)

 

(Download the PDF version of this article)

After reading through articles and posts regarding how EJB 3.0 is going to make application development simpler, I decided to give EJB 3.0 a spin and see if the claims are true.

I decided to take a publicly available demo application which is part of the J2EE 1.4 tutorials. I took the RosterApp application which has three Entity beans (LeagueBean, TeamBean, PlayerBean), one Session bean (RosterBean), three Data Transfer Objects (LeagueDetails, PlayerDetails, TeamDetails), a Debug utility class and a Client class. I converted/migrated/ported these beans and classes to an EJB 3.0 based application.

I migrated the application with the following steps:
Entity Beans
Data Transfer Objects (DTOs)
Session Bean
Client
and gave my final conclusion.



 

Only some minor nits: The blog can't be valid RSS or XML.

 

Currently there doesn't seem to be any support for using Native SQL queries, though the specification seems to say so. I would have loved to make use of those queries instead EJBQL, as database portability isn't a priority for me.

 

Generally the performance of that isn't worth it, moreover the opportunities for different kinds of appserver-side optimizations should eventually make this a useless feature in serious high-pro apps anyhow. Never say never but I wouldn't do everyday stuff with db specific queries.

Filter Blog

By date: