I've added the basic underlying functionality for mail lists, so far it exists in a memory version. Members are added in jboss-service.xml, and changes to list permissions and members etc. are only done in memory and not persisted. In other words pretty useless! I'll be adding an entity version over the next few days, which should be more useful.

It is not plugged into anything yet, so you cannot use lists just yet. I just wanted to get it in place so we have something there when we start integrating it with the rest. The interfaces might need some teaking, but we'll see when we start adding it in.

OK, I got the entity maillist stuff commited now. The tests (via JMX-console) work fine. Just as the memory version, it works as an isolated MBean, but will need integrating with the rest of the system.

Actually the first test is not nukes integration just the JBoss newsletter. So all we need is to be able to send mail to a list that doesn't allow replies.

I need to look at nukes in more detail to give an intelligent answer on what challenges nukes integration will bring. Tomorrow I'll be working on getting this set up so that we can send out the JB newsletter and I'll be working on getting a new code contribution (a profiler) compiling. However I can look at Nukes on Monday if you like. Also note that the jboss website is actually in the public CVS.

I have this itch to work on a hibernate mailbox that I'm dying to scratch (Gavin was just in Raleigh and told me that there is a hibernate deployer + interceptors in the hibernate module in JBoss CVS), but I must resist. For M3 I want to do that and refactor the mail store because its not as fast or generic as I'd like. I'd also like to see if there is a way we can make the the JMSMailListener stuff more generic. It seems there is a lot of behavior that would likely be reused in any mail listener.

I've been thinking about the chainable unchained stuff. And it seems that I have it backwards. The DEFAULT *ought* to be chained and the exception ought to be unchained (because for unchained we ought to make a deep copy or pass some kind of protected or immutable object).

What did that have to do with mail lists...well it was all connected in my mind somehow... ;-)

2) Nukes, that'd be cool. I did some initial investigations, documented in a thread somewhere. I still don't really get the chainable mail listeners stuff, but am wondering if they would/could/should play a role in the Nukes integration. I'll get the latest release of Nukes and get that working here.

3) I started looking a bit at hibernate, but didn't go into it due to seeming to have to need to include a lot of additional jars as you mentioned somewhere, and couldn't find a nice way to include all this in cvs. But with the hibernate deployers etc. in place this now sounds like it could be done tidier. I think the persistent version of the mail list would definitely improve from using hibernate rather than entity beans.

4) I kind of cluttered up the JMS maillistener with retry/bounce mail logic, and am in two minds about what is best to do.a) Either create a separate retry/bounce mbean that is called by the mdb's which handles this.b) or something to do with the chainable maillisteners