-
1. Re: Mail lists
acoliver May 16, 2004 10:59 AM (in response to kabirkhan)Excellent. Don't forget that list memeber often aren't local users... I can't wait to put this behind nukes.
-
2. Re: Mail lists
kabirkhan May 20, 2004 4:04 PM (in response to kabirkhan)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.
What do you think we need to do to test it with Nukes?
Cheers,
Kab -
3. Re: Mail lists
acoliver May 20, 2004 6:47 PM (in response to kabirkhan)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'll look at Nukes and tell you what I think is needed (I detailed the basic features on the plan: http://www.jboss.org/wiki/Wiki.jsp?page=MailServicesPlan). Then I will look into that concurrency bug and JAAS integration.
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... ;-) -
4. Re: Mail lists
kabirkhan May 21, 2004 4:24 AM (in response to kabirkhan)1) How many subscribe to the JB newsletter :-)
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 -
5. Re: Mail lists
acoliver May 21, 2004 9:04 AM (in response to kabirkhan)Number:
A whole lot... I forget, somewhere I ahve the list.
Unchained melody:
The difference between chainable and non-chainable mail listeners. Chainable mail listeners affect what the mail listeners downstream see. They can even *change* the mail.
non-chainable always get an exact copy of what came in originally and what they do does not affect the others.
Its roughly similar to queues versus topics but not exactly.