Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2.1
    • Component/s: Notifier - Mail
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Remove usage of plexus-mail-sender to Spring JavaMailSender
      See related thread

        Activity

        Hide
        Olivier Lamy added a comment -

        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">
            </property>
          </bean>  
          
          <bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
            <property name="session" ref="mailSession"/>
          </bean> 
        

        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
                at org.springframework.beans.factory.support.FactoryBeanRegistrySupport$
        
        Show
        Olivier Lamy added a comment - 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" > </property> </bean> <bean id= "mailSender" class= "org.springframework.mail.javamail.JavaMailSenderImpl" > <property name= "session" ref= "mailSession" /> </bean> 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 at org.springframework.beans.factory.support.FactoryBeanRegistrySupport$
        Hide
        Emmanuel Venisse added a comment -

        As redback is moving to Spring too, it isn't a problem to migrate the mail component in redback too

        Show
        Emmanuel Venisse added a comment - As redback is moving to Spring too, it isn't a problem to migrate the mail component in redback too
        Hide
        Olivier Lamy added a comment -

        fixed in rev 699509 (1.2.x branch)
        merge in trunk rev 699511.

        Show
        Olivier Lamy added a comment - fixed in rev 699509 (1.2.x branch) merge in trunk rev 699511.
        Hide
        Wendy Smoak added a comment -

        This changes the configuration in application.xml to override all mail notifications from <to-override> to <toOverride>. (r705894, r705896)

        Show
        Wendy Smoak added a comment - This changes the configuration in application.xml to override all mail notifications from <to-override> to <toOverride>. (r705894, r705896)
        Hide
        Olivier Lamy added a comment -

        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

        Show
        Olivier Lamy added a comment - 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
        Hide
        Wendy Smoak added a comment -

        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...

        Show
        Wendy Smoak added a comment - 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...
        Hide
        Olivier Lamy added a comment -

        I say both should work you can use in the xml file :

        <to-override><to-override>
        <toOverride><toOverride>
        

        TIMTOWDI

        Show
        Olivier Lamy added a comment - I say both should work you can use in the xml file : <to-override> <to-override> <toOverride> <toOverride> TIMTOWDI
        Hide
        Wendy Smoak added a comment -

        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.

        Show
        Wendy Smoak added a comment - 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.

          People

          • Assignee:
            Olivier Lamy
            Reporter:
            Olivier Lamy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: