camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" ...@silverbullet.dk>
Subject [HEADS-UP] - Camel mail refactorings
Date Fri, 02 May 2008 16:11:00 GMT
Hi

 

Lars was so kind of pointing out that in ServiceMix 3 he had added a mail binding component
that we could use as inspiration for CAMEL-335.

 

I have used his code for inspiration and feels that I needed to refactor the internal code
of the mail component to cater for

- proper resource handling (not closing all the resources we have claimed)

- not change protocol under the covers from smtp to pop3 for consuming mails. Should we really
do this!!! This is dangerous in my mind. 

- deprecate and change a few public APIs to remove usage of our JavaMailConnection class that
doesn't server a purpose

- throw proper exception for folder not found

 

So basically a few spots in the java mail break old code if

-        you extend Camel mail component and do you own magic mail stuff on top of this?

-        You create a MailConsumer directly in your code with its old constructor

-        Fluent API if you use incidentally typed smtp as the scheme to consume mails (you
should use pop3 or imap)

 

Before doing any action on commits I would like for the Camel developers to cast your opinions
on this matter?

We have in the Camel 1.3 lifreframe also breaked a few public APIS but appending new parameters
to existing constructors or the like.

So I do not anticipate that this would break any end-users codebase if they upgrade from Camel
1.x to 1.4.

 

 

 

 

Med venlig hilsen

 

Claus Ibsen

......................................

Silverbullet

Skovsgårdsvænget 21

8362 Hørning

Tlf. +45 2962 7576

Web: www.silverbullet.dk

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message