Author: noel
Date: Fri Apr 8 14:45:13 2005
New Revision: 160621
URL: http://svn.apache.org/viewcvs?view=rev&rev=160621
Log:
FIX. Did not handle list names with a '-' in the list name. Fix by skipping
the start of the address for the length of the list name
Modified:
james/server/branches
The current discussion is valuable, but isn't converging and some of it
borders on silly religious debate. Let's clarify a few points, and
establish a direction.
-- much of JAMES is ALREADY independent of Avalon.
Only a few major components care about Avalon, and those are not too hard to
conv
Mike Heath wrote:
Can we stop the debate and just vote on a DI design pattern we should
follow? I for one am a strong proponent of providing both methods for
DI. Each POJO should have a default constructor and a dependency
injecting constructor that calls the setter dependency injectors. This
wo
Soren Hilmer wrote:
> On Wednesday 06 April 2005 22:47, Steve Brewin wrote:
> > My interpretation of the CDI metaphor allows no tolerance
> for ambiguity.
> > There should be exactly one public constructor for a Class
> that encompasses
> > all possible parameters. Optional parameters may be passe
> +1, let's get started doing some POJO
+1
After I posted about working on a Mina based SMTP protocol handler, I've
received off-list Emails from two different groups wanting me to work
with them on developing their own open-source Email server. I'm sure
others on this list have received Emails
--- Soren Hilmer <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 April 2005 22:47, Steve Brewin
> wrote:
[snip]
> >
>
> Unfortunately all these patterns to deal with
> parameter bloat introduces more
> complexity and are thus violating the KISS
> principle.
I agree. In the name of KISS, let's wr
--- Soren Hilmer <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 April 2005 22:47, Steve Brewin
> wrote:
> > > No, I see (as you) JavaBean==POJO, but
> CDI!=JavaBean. And I
> > > prefer using the
> > > JavaBean approach instead of CDI.
> > > My concern is that CDI does not facilitate
> optional
> >
>
> This is a very good point!
> It is very easy to make a CDI wrapper around an SDI POJO, but the
> other way
> around is rather difficult.
>
> This is probably the strongest argument for SDI, I gave seen.
>
> --Søren
So, so far we've settled on SDI POJOs (possibly with CDI wrappers :)
And presu
This is a very good point!
It is very easy to make a CDI wrapper around an SDI POJO, but the other way
around is rather difficult.
This is probably the strongest argument for SDI, I gave seen.
--Søren
On Friday 08 April 2005 12:47, Simon Funnell wrote:
> Use of CDI 'only' limits a component to
[EMAIL PROTECTED] wrote:
I think we should stop loosing time in this never-ending discussion.
We can create SDI POJO (JavaBeans) with setters and no-argument constructor
and then create an extended class with only the new constructor for the CDI.
public class SomePOJO {
SomePOJO () {}
public fu
Use of CDI 'only' limits a component to certain types of containers, for
example components with getter/setters patterns can have their dependencies
changed at runtime, I believe CDI limits a components reuse in other
projects.
A container should ideally be able to use any component by supporting
> > I agree that we should not focus on any given container.
> > Apparently we cannot
> > agree upon which concept JavaBean/CDI is the way to go, so
> I then move
> > in favour of supporting both. That way we can run in any POJO
> > container. As someone (sorry forgot who) posted earlier
Me ;-
> Okay, so you prefer code looking like:
> p = new SomePOJO ("bla", null, null, null, null, "bli", null,
> null, null);
>
> to code looking like:
> p = new SomePOJO ();
> p.setBla("bla");
> p.setBli("bli");
>
> I must say, I prefer the latter.
I prefer the CDI one.
Take two cases:
In a normal en
On Wednesday 06 April 2005 22:47, Steve Brewin wrote:
> > No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I
> > prefer using the
> > JavaBean approach instead of CDI.
> > My concern is that CDI does not facilitate optional
> > properties very well.
> > If you have some POJO, with just 2 o
AddFooter couldn't process mails which MimeType is multipart/related
Key: JAMES-368
URL: http://issues.apache.org/jira/browse/JAMES-368
Project: James
Type: Bug
Components: Matchers/Mailets (bundl
15 matches
Mail list logo
