Future of JavaMail-configuration: Request for comments

[Stephan Sann-5]

Hello all,

caused by a problem I had with setting an own TrustManager
(http://forum.java.sun.com/thread.jspa?threadID=5287250&tstart=0) I
decided to sign the Sun Contributor Agreement to improve JavaMail in
this matter. Meanwhile I exchanged a few mails with Bill Shannon and now
we decided to carry out our discussion to the list.

The problem is that the (String-)Property-approach to configure JavaMail
reaches its limit if you need to initialize an object-to-pass by yourself.
Example: With "mail.pop3s.socketFactory.class" you can configure a
SocketFactory-class(-name) to use with a POP3S-connection. You can
define the class, but you don't have the control about when or how it is
initialized. And giving this SocketFactory (or a TrustManager created in
this Factory) access to certain objects is hard to achieve.

What is needed is a better way to pass objects to the lower layers of
JavaMail. Bill and I discussed a few approaches to solve the problem.
The major three are stated below (@Bill: please correct things if I got
anything wrong).

We would like to hear about your opinions about them.

Thank you very much for any comment!

BTW: my favorite is 3. I always found that the Properties-configuration
is a little bit of a hack and not much Java-like...

Best regards
Stephan


1.) Retain the existing configuration with "java.util.Properties". Small
extension to pass an (SSL)SocketFactory as an object via the underlying
Hashtable of the Properties-object.

Example:
Properties props = new Properties();
props.put("javamail.key.for.sslSocketFactories", new MySSLSocketFactory());
Session session = Session.getInstance(props);

Pros:
- No need to change the API (at least no method-signatures must be
changed, but: "API is not just the class and method signatures" (Bill
Shannon))

Cons:
- No type-safety
- Using the underlying Hashtable is strongly discouraged by the Java-API
("Because Properties inherits from Hashtable, the put and putAll methods
can be applied to a Properties object. Their use is strongly discouraged
[…]"). (My opinion: An official Java EE Product shouldn't set a bad
example and defy this dissuasion.)
- A gross hack


2.) Extension of the Session-class. Getter- and setter-methods for the
things you can configure with properties today. Maybe an additional
"setAttribute(String s, Object obj)"-method (like in HTTPSession) to
pass custom objects.

Example:
Session session = Session.getInstance();
session.setSmtpSocketFactoryFallback(false);
session.setSSLSocketFactory(new MySSLSocketFactory()); // type-safety
session.setAttribute("myKey", new NeededInLowerJavaMailLayerObject());

Pros:
- Type-safety for the "known" properties
- No search for the adequate property-key to set something – it's all in
the API of the Session-class

Cons:
- Need to change the API (but: Session will still have a
getInstance(Properties props)-method for backward-compatibility!)
- "setAttribute" takes Objects -> no type-safety here


3.) A new SessionContext-class to configure the Session.
Default-implementation could hold getter- and setter-methods for the
things you can configure with properties today. If you need further
objects in lower layers, you could subclass the SessionContext.

Example 1:
SessionContext ctx = new SessionContext(); // to think about:
//SessionContext.getInstance() ? /
//SessionContextFactory.createSessionContext() ?
ctx.setSmtpSocketFactoryFallback(false);
ctx.setSSLSocketFactory(new MySSLSocketFactory()); // type-safety
Session session = Session.getInstance(ctx);

Example 2:
MySessionContext ctx = new MySessionContext(); // MySessionContext
//extends SessionContext
ctx.setNeededInLowerJavaMailLayerObject(new
NeededInLowerJavaMailLayerObject()); // type-safety
Session session = Session.getInstance(ctx);

Pros:
- Type-safety for the "known" properties
- Type-safety for own properties
- No search for the adequate property-key to set something – it's all in
the API of the SessionContext-class

Cons:
- Need to change the API (but: Session will still have a
getInstance(Properties props)-method for backward-compatibility!)
- If you need one special subclass for the trust manager and another
special subclass for something else, you're stuck. (My opinion: This
should almost never happen. Normally you will mesh with JavaMail just
for one adjustment - and most of this cases should be to set an own
TrustManager (just my 50 cents...)).

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".