I was in need of writing a mail sender application for a web application and whilst researching on the Java Mail API i found out there was many error handling and specifics to be worried about. Then i stumbled upon the Spring Java mail wrapper which they have written and this greatly simplifies the amount of time taken to write a simple mail sending module. I have wrapped it up and written my own API to send mails which i have blogged about in the following link: http://dinukaroshan.blogspot.com/2009/09/spring-mail-api-wrapper.html Any comments/ improvements are very much appreciated.

and how many XML files should be provided for simple mail?

not xml, but there are some nitty gritty details you have to take care of if your writting using the Java Mail API it self which the Spring API abstracts so you do not have to deal with it....

isn't the implementation in org.springframework.mail.* simple enough? does it really need to be wrapped?

Well i have wrapped it so that an application can call one single interface to delegate all the methods. Ofcourse Spring provides all the functionality required, but they are dispersed. I just brought together them so that one can use this API straight to send a mail as you normally would by providing the mail address, msg body and the subject. This is like a single module which can act independently, only supports SimpleMessage, which was the requirement in my case. I published this because i actually could not find a cohesive document explaining the same as i had to refer several articles and documentation to get this working. If you look at the code i believe you would understand what i was trying to accomplish here.

The various aspects of it are encapsulated in classes/interfaces that make sense. The params of the email (sender, recipient, body, etc.) are in the MailMessage interface, the sender is a different class. This allows your construction/encapsulation of the message, etc., to be separate from the sending mechanism - as it should be. Please take this in the spirit intended: constructive feedback: Your API fans out the params of the email into method signatures instead of encapsulating them in an interface, and it then uses a specific impl of that interface. Now your API is coupled to those params and that implementation, instead of using the MailMessage interface as intended. The main value of Spring is not the functionality of its implementations, but the decoupling of the implementations via interfaces and dependency injection. Your API defeats that and is more of a utility class with limited functionality than an API or interface. In short, work with the interfaces and use them the way they are intended, don't try to subvert them. In the long run you will get used to the way things are done in Spring and see the value of it. Rather than hiding Spring interfaces, use them, maybe extend them, but most of the time you don't need to hide them in a facade that doesn't do much. Some specific points of your implementation: 1) An empty message body is allowed and sometimes even desirable. I often send myself empty emails (with a subject) as a simple reminder to do something when I get home. Therefore I would allow it, not throw an exception. 2) You essentially throw away an exception by wrapping the text only of any sending exceptions in MailSenderException. Almost always you want to pass in the throwable, the cause, the exception, into your exception and on up to Exception, so the stack trace can be maintained and the exception is properly wrapped. People debugging your code will thank you. 3) Some instances of email servers are setup to allow sending with no password for the user, if the email is coming from within the network. Personally I think this is insecure (if somebody gets access to your network, they can spam from it), but I am not a network admin either. You may want to allow for that use case - I forget how the placeholder configurer handles empty properties, but I ran into an error this way by not taking this into account and I see you have that property in your setup.

Like this: public class MyException extends RuntimeException { public MyException(final String message_, final Throwable cause_) { super(message_,cause_); } }

Hi Developer Dude, First of all thank you so much for you feed back. Thats the first useful comment i got :) ... I wanted to make this code better and hence thats why i posted it here. Your comments are much appreciated. Few doubts i would like to clear with you; "Your API fans out the params of the email into method signatures instead of encapsulating them in an interface" My intention here was to allow any calling party to send emails my providing which email addresses they want to send with a subject and a message body. Of course i understand that the message body being null must be allowed, but this was not my intended use case and hence i have restricted that. Could you explain why its a bad idea to give the email addresses the user wants to send mails to? "Now your API is coupled to those params and that implementation, instead of using the MailMessage interface as intended." The mail message interface is used but it is encapsulated so that this can act as a separate module and calling parties does not have to know about that Spring is used as the base. That was my intention and thats why i threw a custom exception rather than throwing the MailSenderExeption already defined by Spring so that the calling party is fully separated and can be non Spring aware. This is still an emerging API and hence still a limited set of functionality as the use case permits. "Your API defeats that and is more of a utility class with limited functionality than an API or interface." Agreed here, it can be seen as a utility class that provides mail sending capabilities. But how can the API defeats the decoupling capabilities? i have decoupled the application calling party from the Spring implementation and hence they do not have to be aware of using Spring Mail but can just use the interface to send mails. Isnt that separation of concerns? Thank you for the pointer on throwing the exception with the throwable. I did not think of that. Very much appreciated. And i appreciate taking the time to comment on my work which can help be better my self. Regards, Dinuka

Few doubts i would like to clear with you;

"Your API fans out the params of the email into method signatures instead of encapsulating them in an interface"
My intention here was to allow any calling party to send emails my providing which email addresses they want to send with a subject and a message body. Of course i understand that the message body being null must be allowed, but this was not my intended use case and hence i have restricted that.

The problem with that restriction is that it is very specific to your current use case, which may change in the future, and therefore not very reusable. One solution (just throwing it out there as an example, not necessarily recommending it), would be to have a property in the class that you can set where this allowed or not allowed. This is one of the really nice things about dependency injection is that you could have two beans using the same class/logic, and without changing the logic or hard coding the property value somewhere in your app, you set it in the bean def in Spring (or other DI framework). This (IMO) makes the code more reusable (generally a good thing) and flexible, because no you don't have to write another class (or sub-class) when you want to allow this - both use cases are available. Note: I am just saying this is an example - I don't know enough about your use case, and I would not have written the code this way anyway.

Could you explain why its a bad idea to give the email addresses the user wants to send mails to?

Not a bad idea, but this is already available via the Spring API. There are some things you need to decouple from and/or hide/encapsulate when it comes to Spring, but the Spring mail API is just an extension of Java Mail and I don't think much of it needs to be hidden with yet another wrapper. Moreover, you hide much of the usefulness of the API. If you are going to wrap it, then do it in such a way that makes setup easier, but doesn't hide the underlying API and doesn't couple the user to a specific class - for example the SimpleMailMessage - use MailMessage instead and supply SimpleMailMessage setup as the default - what if a caller needs to use a MimeMailMessage instead? I meant to supply a link to an article on API design, but I must have forgot to, this will help: http://jdegoes.squarespace.com/journal/2009/5/2/good-api-design-part-1.html

Oh and one more thing. Why is it a RuntimeException that your extending from? Shouldnt the calling party be aware of the Exception because if you put runtime then they do not have to catch that exception explicitly right? Wouldnt the calling party be needed to be aware of the Exception so that they can do proper error handling? Thx and regards, Dinuka

Oh and one more thing. Why is it a RuntimeException that your extending from? Shouldnt the calling party be aware of the Exception because if you put runtime then they do not have to catch that exception explicitly right? Wouldnt the calling party be needed to be aware of the Exception so that they can do proper error handling?

Google 'checked exceptions evil'. Others have covered it better than I can.

Oh and one more thing. Why is it a RuntimeException that your extending from? Shouldnt the calling party be aware of the Exception because if you put runtime then they do not have to catch that exception explicitly right? Wouldnt the calling party be needed to be aware of the Exception so that they can do proper error handling?

Google 'checked exceptions evil'.

Others have covered it better than I can.

Shocking. Now the Zombie of Checked exceptions has clawed *its* way from the grave. No coincidence that the "I like checked exceptions crowd." intersects with the "I don't like Spring crowd." Let's resurrect Hibernate vs. JDBC and complete the trifecta of circa 2005 programming wars.

Shocking. Now the Zombie of Checked exceptions has clawed *its* way from the grave.

No coincidence that the "I like checked exceptions crowd." intersects with the "I don't like Spring crowd."

Let's resurrect Hibernate vs. JDBC and complete the trifecta of circa 2005 programming wars.

Rather than snide remarks, how about helping the OP out with a few pointers? He/she seems open to feedback. As for 'this' v. 'that' - I have used a lot of different APIs/tools/etc. in the last 20 years of being in s/w dev, and for the most part there aren't bad tools v. good tools, just tools that are inappropriately used. Each has its advantages/disadvantages and appropriate uses. No one tool works everywhere for everything. I prefer iBatis, but in some cases I have also used Hibernate - it depends on the context. So I don't belong to any 'crowd' - I think such debates are silly. As for Spring, I don't like the aspect of Spring that forces me to mess around in XML so much, but for now I am willing to pay that price to have the flexibility that Spring DI gives me, and I don't mind reusing most of their frameworks either.

Shocking. Now the Zombie of Checked exceptions has clawed *its* way from the grave.

No coincidence that the "I like checked exceptions crowd." intersects with the "I don't like Spring crowd."

Let's resurrect Hibernate vs. JDBC and complete the trifecta of circa 2005 programming wars.

Rather than snide remarks, how about helping the OP out with a few pointers? He/she seems open to feedback.

As for 'this' v. 'that' - I have used a lot of different APIs/tools/etc. in the last 20 years of being in s/w dev, and for the most part there aren't bad tools v. good tools, just tools that are inappropriately used. Each has its advantages/disadvantages and appropriate uses. No one tool works everywhere for everything. I prefer iBatis, but in some cases I have also used Hibernate - it depends on the context. So I don't belong to any 'crowd' - I think such debates are silly.

As for Spring, I don't like the aspect of Spring that forces me to mess around in XML so much, but for now I am willing to pay that price to have the flexibility that Spring DI gives me, and I don't mind reusing most of their frameworks either.

Hmmm...I thought I came off more amazed than snide...oh well...perhaps more smileys? No, I don't believe that any tool is necessarily better than another. I still believed that Struts was a great tool for its time, but I am honestly amazed that in 2009 there is still any debate about the merits of Spring along the lines of 1) I don't like XML. 2) Why use Spring to wrap X? With the intro of the check exceptions, it just seemed to me that the ORM mapping debate would be the next logical topic.

2) Why use Spring to wrap X?

While the comment you responded to could be taken as a slight of Spring, I think it was more pointed towards people who wrap Spring APIs. I have to say that regardless of what you think of Spring, it has to seem kind of silly to wrap Spring functionality in plain Java APIs.

2) Why use Spring to wrap X?

While the comment you responded to could be taken as a slight of Spring, I think it was more pointed towards people who wrap Spring APIs. I have to say that regardless of what you think of Spring, it has to seem kind of silly to wrap Spring functionality in plain Java APIs.

Well, I don't necessarily agree. While I wouldn't want to see twelve layers of indirection, I can see why someone would want to place something behind a wrapper, assuming this is something that would potentially have Spring swapped out for something else later. I had very few direct dependencies on Spring in my main app code. It was all pretty much localized in library code. I'm referring to places where you took advantage of Spring wrappers like the jdbc or hibernate templates or AOP classes.

Well, I don't necessarily agree. While I wouldn't want to see twelve layers of indirection, I can see why someone would want to place something behind a wrapper, assuming this is something that would potentially have Spring swapped out for something else later.

I had very few direct dependencies on Spring in my main app code. It was all pretty much localized in library code. I'm referring to places where you took advantage of Spring wrappers like the jdbc or hibernate templates or AOP classes.

I 100% agree with that approach. I was thinking that the author was proposing a new 3rd party API that depends on Spring. My bad. On a side note, since you brought up Hibernate, do you see a lot of people trashing their sessions before each transactions? I had to clear my hibernate session on each transaction in order to get around a 'feature' of the Criteria API. I was talking to a coworker about this and it seems our all knowing all seeing consultants are going even farther and creating a new session on each query. They also use a lot of SQL backed mappings. This would appear to defeat a lot of the point of using Hibernate but I see this kind of thing everywhere I look, even with 'experienced' Hibernate users.

Hi James & David, This was exactly my intention. Maybe my wording must have been put wrong for people to understand it as im trying to develop a new 3rd party API wrapping Spring. That was not my intention. i was merely giving an abstraction. Thx all for the pointers given. Much appreciated. Special thx to the Developer Dude who gave some really good comments. Appreciate it.

Hi James & David,

This was exactly my intention. Maybe my wording must have been put wrong for people to understand it as im trying to develop a new 3rd party API wrapping Spring. That was not my intention. i was merely giving an abstraction. Thx all for the pointers given. Much appreciated. Special thx to the Developer Dude who gave some really good comments. Appreciate it.

No. It was my mistake. What you wrote was fine.

Hi James & David,

This was exactly my intention. Maybe my wording must have been put wrong for people to understand it as im trying to develop a new 3rd party API wrapping Spring. That was not my intention. i was merely giving an abstraction. Thx all for the pointers given. Much appreciated. Special thx to the Developer Dude who gave some really good comments. Appreciate it.

No. It was my mistake. What you wrote was fine.

BTW...it is always a pleasure to discuss something with James Watson. I've been reading his stuff for years, a true gentleman, and he almost always gives you something to think about.

BTW...it is always a pleasure to discuss something with James Watson. I've been reading his stuff for years, a true gentleman, and he almost always gives you something to think about.

Wow, thanks. I would have never gotten the idea that you thought that if you hadn't written that. I hope you are being sincere. I've been trying hard lately to seem less contentious. It's so easy for meaning and intentions to be misunderstood on forums. Not that I haven't ever been cranky and pushed it a little ;)

Hi James & David,

This was exactly my intention. Maybe my wording must have been put wrong for people to understand it as im trying to develop a new 3rd party API wrapping Spring. That was not my intention. i was merely giving an abstraction. Thx all for the pointers given. Much appreciated. Special thx to the Developer Dude who gave some really good comments. Appreciate it.

I'm with you on the abstraction. I did it all the time. A thin layer strategically placed has can reap big benefits. Now, if we can just upgrade TSS with editing. Have we considered one of the OSS forum tools? Threads, searching, EDITING, avatars...perhaps a picture of an Object?

Well, I don't necessarily agree. While I wouldn't want to see twelve layers of indirection, I can see why someone would want to place something behind a wrapper, assuming this is something that would potentially have Spring swapped out for something else later.

I had very few direct dependencies on Spring in my main app code. It was all pretty much localized in library code. I'm referring to places where you took advantage of Spring wrappers like the jdbc or hibernate templates or AOP classes.

I 100% agree with that approach. I was thinking that the author was proposing a new 3rd party API that depends on Spring. My bad.

On a side note, since you brought up Hibernate, do you see a lot of people trashing their sessions before each transactions? I had to clear my hibernate session on each transaction in order to get around a 'feature' of the Criteria API. I was talking to a coworker about this and it seems our all knowing all seeing consultants are going even farther and creating a new session on each query. They also use a lot of SQL backed mappings. This would appear to defeat a lot of the point of using Hibernate but I see this kind of thing everywhere I look, even with 'experienced' Hibernate users.

I went back and looked at some code. Because of the nature of our projects, I favored opening the session at the start of the first transactions and leaving it open until the rendering phase of the JSPs were done. In apps with GWT for front-ends, I used the same basic approach, but left the transaction open as far as a GWT service, which is basically a servlet, so is roughly the same thing. This was all combined with lazy instantiation, usages of the Criteria API in some instances and HQL in others depending on how complex a particular query was. I have a friend who used a library that enabled access to a hibernate session using GWT objects, but I didn't work with that directly. I didn't open/close the session per query, for example. I tended to count of Hibernate to properly propagate changes down the graph. Hope this helps.

In apps with GWT for front-ends, I used the same basic approach, but left the transaction open as far as a GWT service, which is basically a servlet, so is roughly the same thing. This was all combined with lazy instantiation, usages of the Criteria API in some instances and HQL in others depending on how complex a particular query was.

I'm using Hibernate for some stateless services and what I found was that however child objects were initially filtered in the session would be cached and returned for different criteria. For example, say I have a parent-child relationship like John has a red truck and a blue car. If I first create a criteria for people named John, I'll get John and both vehicles. If in a second query, I look for all people with blue cars, I'll get John and both his cars. If on the other hand I reverse the order of the queries, I'll get John and with just the blue car in both results. Since most of the time the first query is for the full set in my case, it appears you can't filter the children with the criteria API (I want to) which is what most of the Hibernate forum answers say. But that's not the case. It's the first-level cache that's the issue.

No coincidence that the "I like checked exceptions crowd." intersects with the "I don't like Spring crowd."

Let's resurrect Hibernate vs. JDBC and complete the trifecta of circa 2005 programming wars.

David, do you believe that Spring and Hibernate will never be improved upon, at least in the Java space?

No coincidence that the "I like checked exceptions crowd." intersects with the "I don't like Spring crowd."

Let's resurrect Hibernate vs. JDBC and complete the trifecta of circa 2005 programming wars.

David, do you believe that Spring and Hibernate will never be improved upon, at least in the Java space?

Of course they will be improved upon. They have been, but I just think this particular line of debate has been done to death. This specific thread hasn't offered anything new. If one isn't convinced of Spring's usefulness by now, I doubt if that person can ever be convinced. This, by now means, implies that Spring is the ultimate expression of programming technology. I just believe that this "why use spring to wrap X", in this case JavaMail, is an old argument with little value in 2009.

No coincidence that the "I like checked exceptions crowd." intersects with the "I don't like Spring crowd."

Let's resurrect Hibernate vs. JDBC and complete the trifecta of circa 2005 programming wars.

David, do you believe that Spring and Hibernate will never be improved upon, at least in the Java space?

Of course they will be improved upon. They have been, but I just think this particular line of debate has been done to death. This specific thread hasn't offered anything new.

If one isn't convinced of Spring's usefulness by now, I doubt if that person can ever be convinced. This, by now means, implies that Spring is the ultimate expression of programming technology.

I just believe that this "why use spring to wrap X", in this case JavaMail, is an old argument with little value in 2009.

Should read "If one isn't convinced of Spring's usefulness by now, I doubt if that person can ever be convinced. This, by *NO* means, implies that Spring is the ultimate expression of programming technology." Why can't we edit The ServerSide? Again, it is 2009.

Why can't we edit The ServerSide? Again, it is 2009.

Bah, editing is so Web 2.0. We have to be on Web 5.0 by now. It's purely functional, all data is immutable.

If one isn't convinced of Spring's usefulness by now, I doubt if that person can ever be convinced. This, by *NO* means, implies that Spring is the ultimate expression of programming technology.

BTW, I have no doubt of Spring's usefulness. What annoys me is how much of the Java community seems to think that it is prerequisite for Java development. It's just like when most everyone assumed that if you weren't doing EJB, you were some sort of weirdo or idiot.

If one isn't convinced of Spring's usefulness by now, I doubt if that person can ever be convinced. This, by *NO* means, implies that Spring is the ultimate expression of programming technology.

BTW, I have no doubt of Spring's usefulness. What annoys me is how much of the Java community seems to think that it is prerequisite for Java development. It's just like when most everyone assumed that if you weren't doing EJB, you were some sort of weirdo or idiot.

That *may* mean that it is time to move on. As soon as "everyone" is on board, the ship tends to take on water. :-)

That *may* mean that it is time to move on. As soon as "everyone" is on board, the ship tends to take on water. :-)

With EJBs the ship capsized because it was top heavy.

Dizayn Restorasyon Karo silimi çini silimi   Karo Silimek hakkinda teknik bilgiler. Granit Silimek Granit Silimi hakkinda teknik bilgiler.

Karo Silimi nedir nasil karo silinir

 

 

I'm eagerly waiting for Spring to provide an abstracted API for String, so that I can abstract it again and implement my own MyWrappedSpringString.

I'm eagerly waiting for Spring to provide an abstracted API for String, so that I can abstract it again and implement my own MyWrappedSpringString.

LOL, yeah. Before jumping on such "enhancements", I would like to see some discussion as to why the API needs a simplifying wrapper: - Is the API designed badly - does the wrapper cover only a certain, but common, usage scenario? If the former is true, what exactly are the design flaws that are getting fixed? If the latter, what scenario is being adressed, and is there any loss in flexibility for other scenarios incurred? good luck, chris

I would like to see some discussion as to why the API needs a simplifying wrapper

Embrace, extend and extinguish: http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish Tom

I'm eagerly waiting for Spring to provide an abstracted API for String, so that I can abstract it again and implement my own MyWrappedSpringString. Actually i havent abstracted the Spring API it self, but have just used the functionality provided by it and encapsulated an API to send simple mail messages. The Spring Mail API does provide a diverse set of functionality to send mail, and i have just extracted the needful for my scenario and posted it so that anyone else can use it if the need arise. Ofcourse a String wrapper would be pretty useless given the immutability factor aint it ;) .... Cheers

I'm eagerly waiting for Spring to provide an abstracted API for String, so that I can abstract it again and implement my own MyWrappedSpringString.

+1

I'm eagerly waiting for Spring to provide an abstracted API for String, so that I can abstract it again and implement my own MyWrappedSpringString.

+1

+1 I know just the team to do that too!

I'm eagerly waiting for Spring to provide an abstracted API for String, so that I can abstract it again and implement my own MyWrappedSpringString.

Holy Crap. It is 2009 and you guys are *STILL* arguing over Spring? It has still around. It has proved its value time and time again. Get over it. Sheesh.

Holy Crap. It is 2009 and you guys are *STILL* arguing over Spring?

It has still around. It has proved its value time and time again.

Get over it. Sheesh.

+1

Why is this in 'News' ? -- Freddy Daoud http://www.stripesbook.com

How is this better than writing a utility class without Spring? No spring.xml, no spring.jar. Don't you find that many people overuse Spring just to say "I wrote another Spring wrapper" or "I used Spring in my Project"? Java Development on Demand http://www.hitech.com.ua/en/

Well its not better, but more easier than writing a utility class using just the Java mail API due to the fact that Spring already handles all the exceptions and session creations so you can get a simple mail sending application started up with a few lines of code. I just provided an interface which gives allows applications to send simple mails with various options. For example the comma separated mail addresses is not supported by Spring and hence i wrote a utility method for that. And by using Spring DI we can swap in and out different implementations and the calling party would not know of the difference as the client will always be dealing with the interface contract.That kind of abstraction can be achieve through Spring which you cannot if you just wrote a utility class. Ofcourse it is possible but then you end up writing factory methods and the sort.

and you can even at a later time add velocity templates capability which again spring provides which you will have to write on your own if you just wrote a "utlity class".

I really don't know why are you enraging such a discussion against a thing that Spring tried to simplify. Probably, someone of you have use the JdbcTemplate and you agree that this is a real good design, instead of the horrible pure JDBC, throw SQLException everywhere stuff that Sun did. People @ Spring rock, I always see good code from them.

been there, done that. agree that the Java API is too general for the beginner to master. so.... why not build your wrapper around the Java API and save an unnecessary layer of abstraction and dependencies? handling attachments will come next (I want to send a Word document). handling other messaging services is certainly on the horizon (Text, MMS, Chat...).

I am currently working on a Command framework which allows you to wrap snippets of biz logic in commands so they can be reused. In my current gig, and in some of my personal projects, I have need to send emails for notifications/verifications/etc., so I am wrapping the Spring email API in commands, both simplifying and generalizing the sending of email such that not only the impl of sending a message is abstracted, but also the method (whether email, or IM, or whatever). I also use it for wrapping FTP transfers and so on. The main purpose was to wrap and reuse various biz logic so that it can be reused whether it is in a Swing/SWT app, or console app or servlet/server app. Commands will be able to wrapped in a delegate such that they can be invoked in a SwingWorker/Spin/Foxtrot, or not, or in a background thread in some other context.

I used JavaMail extensively and in real projects, I never found any of the wrappers to be of any use. A wrapper that sends plain emails doesn't provide any real value - this is straightforward with the JavaMail API. In the end of the day, you usually wire all parameters except the pop3, imap and smtp servers names and need to implement provide your own service that takes care of formatting and content. Maybe if the wrapper helped to send nice fancy html emails, I would find it of some use but otherwise this is wrapping for the sake of wrapping. Erik.