TODO: (post M1)

[acoliver]

I've been talking to Scott about JCA and JavaMail. He's made a request as follows:

1. I want a JavaMail provider that supports the javax.mail.Session
object for sending mail through an smtp gateway. This should be an
mbean service built ontop of the mail services with a jca provider
that is used to bind the session into JNDI and integrate with security
just like a database connection does. A database connection can either
be bound to a single user, take the identity of the caller as the
connection identity, or take the connection identity as an argument to
the connection factory create.

2. The jca piece is part of the mbean providing the JavaMail Session
binding. Just having a simple smtp provider that is used in the same
fashion as we currently do with the sun provider does not promote
the JavaMail Session to the same level as JDBC connections. Further,
with the JCA 1.5, you have not only integration with the JAAS security
layer, you also have integration with the same connection pool and
threading
pools.

----
This might make a lot of sense. Anyone interested in taking this and seeing what it woudl take? I'd like to wait on the JCA 1.5 stuff unless we can do it in such a way that we can build it seperately as Mail Services is presently intended to be 1.0 probably prior to the JBoss 4.0 release and I'd like people to feel confident running it on 3.2.x. Any takers?

[acoliver]

Yeah it's probably not *real* hard, but there definitely is a learning curve between trusting run.bat and bootstrapping your own. But this is stuff I've always wanted to learn.

If Andy thinks uploading the path is okay, that'd be fine with me. I don't want anyone to make a special excuse for me on the "no patches without unit tests" rule. I don't mind learning the hard way, that way I won't forget as easy.

[spiritualmechanic]

Hey Steve. I put a patch page: http://jboss.org/wiki/Wiki.jsp?page=MailServicesPatches

Send it on through! Remeber the nice and gooey unit tests :-)

[spiritualmechanic]

I did a JCA adapter once, actually two, but I didn't have the release/closing working right, and I didn't have the time to test it correctly, so we ripped it out.

I'm on vacation right now, but I can start looking into it, if someone can help me with unit tests. The structures of JCA are pretty consistent, but it seems to be a little finicky/sensitive in getting the exact behavior you want.

Steve

[spiritualmechanic]

Just to get something clear, does the JCA use the MBean, or does the MBean use the JCA?

Right now I'm planning on just doing JCA 1.0, passing the subject in, depending on single user/caller identity/connection identity.

So I'll create an Authenticator that passes in the subject/CRI, decides which to use based on JMX config, and returns the correct session.

Let me know if I'm on the right track.
Steve

[acoliver]

on mbeans, my answer: Yes.

I think you're going in the right direction. We can always get more scott-speak for how to tweak later.

[spiritualmechanic]

Do we want to get the session from JNDI, or do we want to create each one with new properties/authentication? I'm thinking we want to create a new one.

Steve

[acoliver]

Gut says join the session but why do you feel we should create it.

[spiritualmechanic]

I may be completely wrong, but if I'm binding to a mail server on port 25, with certain permissions, I want to make sure who I'm authenticating with. If I grab it from the session, I'm not sure what user it will be using, most likely the default user from the javamail MBean.

Maybe I can extend the javamail stuff to use the subject, if it's not null.

Steve

[spiritualmechanic]

Let me start looking that the standard javamail stuff in JBoss and maybe I'll get my answer.
Steve

[spiritualmechanic]

Now I'm wondering:

Am I securing the connection to an outside mail server (i.e. the socket to a port 25) or am I securing access to the Mail Session itself?

Steve

[spiritualmechanic]

Currently, also, I'm allowing multiple handles to access the same session. We may hit some synchronization issues eventually, but I'm basically copying the structure of the JDBC adapter in jbosscx.

In JCA, you have the option of handing out multiple handles per connection, or just one per.

Steve

[spiritualmechanic]

Also, I'm curious as to where the MBean falls in. If I remember my JBossSX correctly, if you set the property in *-ds.xml to Container, it'll send in the Subject. If not, subject is null, and you use whatever static user/pw there is.

Are there MBean properties we'll need to be using outside of the current MailService?

Steve

[adrian.brock]

Concurrency should not be an issue as long as you are doing pooling correctly.
Don't allow access to handles across threads (e.g. storing them in static fields
or shared objects).
Even then, this is only really an issue if you support transactions, it depends upon
what constraints you use outside a transaction.
e.g. jdbc allows concurrent access -it requires internal synchronization.
JMS says you must use external synchronization on the jms session.

I would say the JavaMail spec requires internal synchronization.
"When sharing the session object, all applications share authentication information, properties, and the rest of the state of the object."

Regards,
Adrian

[spiritualmechanic]

Interesting. Thanks, Adrian.

Is what Scott is asking for (at the end of all this) a relay server built on jboss-mail and the JCA-mail adapter? Like a subsystem of jboss-mail? Or maybe a subsystem on top of jboss-mail.

Right now I'm just focusing on promoting "the JavaMail Session to the same level as JDBC connections" via JCA.

Steve