1) we shouldn't create a dependency on commons stuff. our users will use it as well and that way we get library version conflicts. using standards directly we don't have that problem. commons email is intended as a convenient api abstraction on top of JavaMail. we don't need that convenience. we should be good enough to figure out JavaMail on our own. our users will see neither. not our mail session, not commons mail abstraction. so it is an internal only implementation detail. 2) the api i proposed is based on the functionality that we build: use named templates to prepopulate fields in an email. i don't see the arguments why you think a separate email class is better. 3) true. the name session is only inspired by the rest. but a mail mnager would be just as good. i'll have a look at the branch this evening View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226004#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...