Remove usage of plexus-mail-sender to Spring JavaMailSender
See related thread
I can't remove the plexus-mail dependency (it has to be done in redback too).
If I override the current mailSender with :
<bean id="mailSession" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/mail/Session">
<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
<property name="session" ref="mailSession"/>
This works for continuum mail notification but not for redback registration :
Caused by: org.springframework.beans.factory.BeanCreationException: Error creati
ng bean with name 'mailer': FactoryBean threw exception on object creation; nest
ed exception is org.springframework.beans.TypeMismatchException: Failed to conve
rt value of type [org.springframework.mail.javamail.JavaMailSenderImpl] to requi
red type [org.codehaus.plexus.mailsender.MailSender]; nested exception is java.l
ang.IllegalArgumentException: Cannot convert value of type [org.springframework.
mail.javamail.JavaMailSenderImpl] to required type [org.codehaus.plexus.mailsend
er.MailSender]: no matching editors or conversion strategy found
As redback is moving to Spring too, it isn't a problem to migrate the mail component in redback too
fixed in rev 699509 (1.2.x branch)
merge in trunk rev 699511.
This changes the configuration in application.xml to override all mail notifications from <to-override> to <toOverride>. (r705894, r705896)
It's not mandatory plexus-spring handle this. And transform all fields with "-" to a camelCase syntax in the spring container.
to-override is transform to toOverride by plexus-spring. source
After having lots of email messages go out when they shouldn't have, (we had <to-override> configured) I tracked the change down to r699509 and this issue.
I'm not sure if your comment means we could put it back to to-override?
It's fine with me the new way, I just want the change documented somewhere...
I say both should work you can use in the xml file :
Yep, just confirmed that both <to-override> and <toOverride> work in the latest snapshot.
Sorry, your "good catch" response on the mailing list and subsequent change to application.xml made me think that <toOverride> was the new (and only) way to configure this.
Not sure what happened with our testing... maybe we missed applying part of the change, because <to-override> did not work.