Announcement Announcement Module
Collapse
No announcement yet.
JNDI for resource lookup Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JNDI for resource lookup

    Hi all,

    I've been recently skimming through the 12th chapter of Spring in Action, 2nd edition. In the section which deals with sending mails, the author mentions:
    The mail serverís hostname and the username/password pair are explicitly configured in Spring. However, this setup may raise red flags for you with regard to security. Maybe you donít want to hard-code this information in the Spring configuration.

    You may already have a javax.mail.MailSession configured in JNDI (or perhaps one was placed there by your application server). If so then Springís JavaMailSenderImpl offers you an option to use the MailSender in JNDI.
    What kind of "security" implications is the author talking about here? Does this refer to the fact that the mail configuration lies in open in plain text as opposed to being published on a server as a managed resource which can be accessed by only those people who have the password for the application-servers' management console?

    What are the practical design decisions which influence your choice of preferring one over the another (JNDI v/s non-JNDI)? Are there any reasons/motivations why an architect would bring in a full-fledged application server in the deployment cycle just to use JNDI?

    Some points which I can come up with:
    • JNDI not a feasible option unless you are using some kind of full-fledged application server.
    • JNDI a wise choice if security really becomes a concern (plain text configuration not a possibility)

    Suggestions/opinions/experiences appreciated. TIA,
    sasuke

  • #2
    Why would you need a full fledge app server for that... Tomcat and Jetty also have JNDI support and those aren't really full fledged app servers...

    Also you probably don't want any configuration details (usernames/passwords/urls) in your xml but preferably in properties files which are easy to maintain. If you need to change the xml for each environment (dev, prod, accept) it means rebuilding the application each time.

    Comment


    • #3
      Hi Marten,

      Thanks for the response. When I mentioned 'plain text' I was kinda referring to the configuration information presented as plain text via properties + Spring XML config file (using PropertyPlaceholderConfigurer). Also I'm not very sure whether a simple web container (not app server) is not required to provide JNDI support (not lookup but creation of JNDI entities) and hence my mention of full-fledged app server. :-)

      These things aside are there *really* any advantages of preferring JNDI?

      TIA,
      sasuke

      Comment

      Working...
      X