Network Deployment (Distributed operating systems), v8.0 > End-to-end paths > Mail, URLs, and other J2EE resources


Enable J2EE applications to use mail resources with JavaMail

We can enable your Java EE applications to use mail resources with the JavaMail API. Use the JavaMail API, a code segment can be embedded in any Java EE application component, such as an EJB application or a servlet, allowing the application to send a message and save a copy of the mail to the Sent folder.

The following is a code sample that you would embed in a Java EE application:

javax.naming.InitialContext ctx = new javax.naming.InitialContext();

   javax.mail.Session mail_session = (javax.mail.Session) ctx.lookup("java:comp/env/mail/MailSession3");
   MimeMessage msg = new MimeMessage(mail_session);

   msg.setRecipients(Message.RecipientType.TO, InternetAddress.parse("bob@coldmail.net"));

   msg.setFrom(new InternetAddress("alice@mail.eedge.com"));

   msg.setSubject("Important message from eEdge.com");

   msg.setText(msg_text);

   Transport.send(msg);


   Store store = mail_session.getStore();

   store.connect();

   Folder f = store.getFolder("Sent");

   if (!f.exists()) f.create(Folder.HOLDS_MESSAGES);

   f.appendMessages(new Message[] {msg});



Java EE applications can use JavaMail APIs by looking up references to logically named mail connection factories through the java:comp/env/mail subcontext that is declared in the application deployment descriptor and mapped to installation specific mail session resources. As in the case of other Java EE resources, this can be done in order to eliminate the need for the application to hard code references to external resources.


Procedure

  1. Locate a resource through Java Naming and Directory Interface (JNDI). The Java EE specification considers a mail session instance as a resource, or a factory from which mail transport and store connections can be obtained. Do not hard code mail sessions (namely, fill up a Properties object, then use it to create a javax.mail.Session object). Instead, follow the Java EE programming model of configuring resources through the system facilities and then locating them through JNDI lookups.

    In the previous sample code, the line javax.mail.Session mail_session = (javax.mail.Session) ctx.lookup("java:comp/env/mail/MailSession3"); is an example of not hard coding a mail session and using a resource name located through JNDI. We can consider the lookup name, mail/MailSession3, as an indirect reference to the real resource.

  2. Define resource references while assembling the application. We must define a resource reference for the mail resource in the deployment descriptor of the component, because a mail session is referenced in the JNDI lookup. Typically, you can use an assembly tool that shipped with the application server.

    When you create this reference, be sure that the name of the reference matches the name used in the code. For example, the previous code uses java:comp/env/mail/MailSession3 in its lookup. Therefore the name of this reference must be mail/Session3, and the type of the resource must be javax.mail.Session. After configuration, the deployment descriptor contains the following entry for the mail resource reference:

    <resource-reference>
    
    <description>description
    </description>
    
    <res-ref-name>mail/MailSession3
    </res-ref-name>
    <res-type>javax.mail.Session
    </res-type>
    
    <res-auth>Container
    </res-auth>
    </resource-reference> 
  3. Configure mail providers and sessions. The sample code references a mail resource, the deployment descriptor declares the reference, but the resource itself does not exist yet. Now configure the mail resource that is referenced by the application component. Notice that the mail session you configure must have both its transport and mail access portions defined; the former required because the code is sending a message, the latter because it also saves a copy to the local mail store. When you configure the mail session, you need to specify a JNDI name. This is an important name for installing the application and linking up the resource references in the application with the real resources that you configure.

  4. Install the application. We can install your application using either the admin console or the scripting tool. During installation, the application server inspects all resource references and requires you to supply a JNDI name for each of them. This is not an arbitrary JNDI name, but the JNDI name given to a particular, configured resource that is the target of the reference.
  5. Manage existing mail providers and sessions. You can update and remove mail providers and sessions.

    To update mail providers and sessions:

    1. Open the administrative console.

    2. Click Resources > Mail in the console navigation tree.

    3. Select the appropriate Java Mail resource to modify by clicking either Mail Providers or Mail Sessions.

    4. Select the specific resource to modify.

      To remove a mail provider or mail session, select the check box next to the appropriate resource and click Delete.

    5. Click Apply or OK.

    6. Save the configuration.
    Optional. Debug a mail session.


What to do next

If the application has a client, you can update mail providers and mail sessions using the Application Client Resource Configuration Tool (ACRCT).


Related


Configure mail providers and sessions
Debug mail sessions
JavaMail API
Mail service providers and mail sessions
JavaMail API security permissions best practices
Mail: Resources for learning
JavaMail support for Internet Protocol 6.0
Develop applications that use JNDI
Assembling applications
Install enterprise application files with the console
Monitor overall system health


Related


Update mail session configurations for application clients

+

Search Tips   |   Advanced Search