-
1. entity structure for stored messages
i was wondering if we may benefit from some entity sub-structure to stored messages. let me explain:
right now, org.jboss.mail.mailbox.entity.message.LocalMessage is the only entity bean interface we have, and there are basically two methods that allow access to the data of any given message: getBody() and getHeaders(), both of which return strings that need to be parsed. headers are ultimately parsed into their respective lines and bodies are parsed into their respective BodyParts, when appropriate. drilling down into the headers part, there are many standard headers that are repeated in every email, like date, subject, etc etc, and further, some headers contain references to other entities we will eventually want to persist in the database, like email addresses on 'from' or 'to' header lines.
if we have some entity structure to reflect the actual regular structure in email messges themselves, we'll be able to do things like search for all email messages from a particular email address, without having to load in all the bodies and headers from all the stored emails in the database; we'd rather just execute an ejb-finder method. there are lots of other examples of neat things that can be done easily and efficiently, too, if we create some structure in the Entity layer.
so, for instance, rather than have LocalMessage have a CMP field 'headers', it may be useful to have a CMR field 'headers', in a many-to-many relationship with a 'header' entity bean.
the 'header' entity bean would then have a CMR field in a many-to-one relationship with a 'header-type' bean. the 'header' entity bean would also have a CMP field for the string value of the header, such as the actual subject of a message.
the 'header-type' bean would have a CMP field with the name of the header-type, such as 'Subject' etc.
the LocalMessage object would also have a CMR field called 'from' in a one-to-many relationship with an 'email-address' bean, and another CMR field called 'to' which would be in a many-to-many relationship with the 'email-address' bean, etc.
basically what i'm proposing is something as close as possible to 'third normal database form' for our entities, given that they're ultimately stored in a relational database. if the persistent store is in third normal form, whether in the database layer or entity layer, its very easy to query and manipulate since all the dependencies are tightly controlled and redundancies essentially eliminated.
if we want to eventually support things like contact lists, calendaring, etc, this kind of structure may become especially useful. in that case, we may even want to deepen the structure and add beans like 'person' that represent a person, with a CMR field in a one-to-many relationship with the 'email-address' bean, for instance.
this short note just scratches the surface of this topic, but i wanted to get some early feedback on it.
mike -
2. Re: Unit tests question
i also have not been able to get tests to run through successfully, with them failing immediately on the twiddle test (which i deleted). then i noticed that deleting TestJMSMailListener helped alot too --- although i quickly ran into another roadblock i'm still trying to push through getting the tests to run. so you may be onto something being assumed in the configuration which doesn't always hold.
BTW, how is one supposed to run the tests? in other words, is there a document describing the framework the tests run in? i see that something like a jboss server starts up, and would like to know how that works etc etc.
this would be useful to know for many reasons, including that since a real security TestCase will undoubtedly involve multiple machines --- since whether or not a client is executing on the local host matters as to how his requests are handled (because of spam and relaying etc).
thanks
mike -
3. Re: Unit tests question
I haven't looked too deeply into how this works, but basically the unit tests run their own JBoss instance via calling org.jboss.system.server.ServerImpl methods directly from org.jboss.mail.MBeanServerUtil in the test suite. There is some info about this here:
http://jboss.org/wiki/Wiki.jsp?page=ExceptionsInTheMailServicesUnitTestsWithJBosslt3.2.4RC1
The steps I have taken to get it all to run (apart from the issues mentioned below - it was all fine a few weeks ago) are:
1) checkout and build JBoss 3.2.4RC1 with jdk 1.4.2
2) Copy the following from JBoss 3.2.4RC1 to jboss-mail/lib
javax.servlet.jar
jboss-common.jar
jboss-jmx.jar
jboss-system.jar
junit.jar
mail.jar
twiddle.jar
3) Set the following environment variables:
ANT_HOME=<root of your ant 1.5.x installation>
JBOSS_HOME=<root of jboss-3.2.4RC1>
PATH=%ANT_HOME%;%PATH%
4) Then do an
>ant clean deploy test
(No instances of JBoss should be running since it is starting its own)
There is also the org.jboss.mail.dev.ClientScriptRunner. I'm not sure what state this is in, but the idea is you deploy mail.ear in JBoss and it allows you to run scripts against the server:
S: 220 %ANYTHING%
C: EHLO noone.nowhere.com
END
S: 250-%ANYTHING% Hello noone.nowhere.com (localhost.localdomain [127.0.0.1])
C: %NOTHING%
END
S: 250 AUTH LOGIN PLAIN
C: AUTH LOGIN
END
S: 334 VXNlcm5hbWU6
C: %encode(test)
END
S: 334 UGFzc3dvcmQ6
C: %encode(testpw)
END
S: 235 Authentication Successful
C: MAIL FROM: <test@badmojo.superlinksoftware.com>
END
S: 250 Sender <test@badmojo.superlinksoftware.com> OK
C: RCPT TO: <test@badmojo.superlinksoftware.com>
END
S: 250 Recipient <test@badmojo.superlinksoftware.com> OK
C: DATA
END
S: 354 Ok Send data ending with .
C: bla
bla
.
END
Cheers,
Kab -
4. Re: Unit tests question
I think I've fixed the TestJMS though now we have to pass in the name of the connection factories in the constructor. for some dammed reason the TestTwiddle is working on OS X but not on Linux. Will look into that further. Its not critical for M1, if I have to I'll delete the test temporarily. I only intend Twiddle to be a demo on how to add a protocol though it might be a cool way to shut RMI down and backend the twiddle tool itself...
The ClientTestRunner is intended to run scripts. Its not done yet but it does basically work. Give it a whirl and enhance it.
Mike, if you want a document on how the unit tests should work, get cracking bud ;-) http://jboss.org/wiki/Wiki.jsp (scroll down to mail services). I disagree that serious unit tests need multiple machines, etc. You can test the behavior of the component without said machines. The only thing you can't test easily that way is the SMTPSender...but I'm sure we can find some way to work around it. These are unit tests. Integration testing and manual testing are seperate. M1 should uncover these issues. My biggest concern with M1 is that we have no error reporting/message bouncing. Meaning if we fail to send, we do so silently ATM.
-andy -
5. Re: Unit tests question
I'm currently refamiliarising myself with everything (starting with SMTP), and could look at the error reporting/message bouncing. I should be able to get something up and running.
Having not looked at this in any detail whatsoever yet, my initial guess is something along the lines of:
-if you are authenticated/the mail comes from a local user, the error report should be delivered to the local mailbox of the sender.
-if you are not authenticated/the mail comes from a remote user, the error report should be set to the originator
Feel free to correct me, and impose any ideas you have about how this could/should be done, as I am not familiar with this at all yet :-( Should be in a day or two though. -
6. Re: Unit tests question
Aha, found this regarding my earlier post
http://linuxintegrators.com/blog/acoliver/code/?permalink=0116.html -
7. Re: Unit tests question
Yes I have many questions regarding this as well as you see. Implement something and we can tweak it later. BTW try to remember to start a new thread for each topic. I actually monitor it all with an RSS reader (forums are syndciated)... I'm thinking we should hold off on M1 until I'm back from vacation for the same reason I delayed it last week -- even if we get the stuff working I'd hate to release it and then stick you guys with the potential problems.. I guess I have release anxiety ;-)
-
-
-
10. Re: Unit tests question
integration testing is not so trivial. We can do the basic Client script runner stuff. However, we'll need to do a lot of admin work to have real integration testing. I'm working on building myself a small test lab. I may be able to get JBI to foot the bill for some machines and eventually figure out how to get everyone access to them (dyna DNS or something). Basically, we'll need to test multiple server set ups, relays, etc. So we'll need a few boxes to catch the scenarios. Should be fun. However, the good news is that we can rely on early adoptors for now :-) I love open source