Steve
No disagreement in principle. Refactoring the bulk of James into POJOs would
be a good thing.
Refactoring the bulk of James to also have POJO capability ... (we'd not
be taking avalon capability).
Just not good enough on technical merit alone. I don't see
a 'killer' reason. Without one I
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 16:03
To: James Developers List
Cc: [EMAIL PROTECTED]
Subject: Re: Avalon - moving away from ?
On Thu, 2004-07-29 at 09:27, Paul Hammant wrote:
This is an enabler, not migration
As you say Paul's proposal would be bet hedging, I can see (and hope I've
articulated) a good justification for doing that, but if we chose to do
that would we have the resources and incentive to see it through? Is Paul
offering to lead this and perform a significant part of the work?
That is
Yup I forgot the the internals of Mailet are entangled with Avalon.
When 3.0 is mooted, and
backward compatability for mailets is not required, someone ping me :-)
Hi Paul, Ping...
We've gone some way down the road to making the Mailet API free from the
hidden dependance on avalon.
I've
A user view:
What I want as a solution provider is a stable ( i.e. reliable, not frozen )
platform to deliver services. I want it to evolve as both hardware and
software evolve.
I want it to be pure Java, but I don't particularly care how it is
implemented - meaning within a container /
Noel,
Huh? No they aren't. Quite the opposite. You had advocated that years
ago, and there was resistence to doing so. There are a few mailets with
Avalon ties, but those are being removed. Mailets will depend upon standard
services, such as JNDI, not Avalon.
I think that I suggested that
Refactoring the bulk of James into POJOs would be a good thing.
Just not good enough on technical merit alone. I don't see a
'killer' reason. Without one I cannot see why effort should be
diverted from enhancing James up to v3 as previously envisaged.
I said that first off, but if Paul is
Do others have their own killer reasons right now?
I've got some killer reasons to get into some restructuring once James
is on svn. For example - breaking out James subsystems into discrete
units enabling:
* better management of unit tests
* improved separation of api and implementation
Is there any interest (beyond me) for refactoring the James
server implementation to allow non-Merlin/Avalon use ?
Yes, but not a lot of energy to put into it, unless you're offering. And at
least one container to target would be the Geronimo kernel.
We're finding that Constructor Dependency
Paul Hammant wrote:
Folks,
OK, so perhaps this idea is not as controversial as the subj
line would
indicate. Is there any interest (beyond me) for refactoring the James
server implementation to allow non-Merlin/Avalon use ?
We're finding that Constructor Dependency Injection (CDI) is
Hi,
On Tue, 2004-07-27 at 19:00, Noel J. Bergman wrote:
Is there any interest (beyond me) for refactoring the James
server implementation to allow non-Merlin/Avalon use ?
Yes, but not a lot of energy to put into it, unless you're offering. And at
least one container to target would be
Steve,
Yup I forgot the the internals of Mailet are entangled with Avalon. I
was on this list a couple of years ago advocating separations, and don't
really want to go back into those discussions. When 3.0 is mooted, and
backward compatability for mailets is not required, someone ping me :-)
Rather than port James to a new set of Foo interfaces,
why not implement Avalon's Serviceable/Configurable/etc
interfaces to your own Foo environment, enabling you to
port all apps. conforming to the Avalon interfaces?
Because the goal would be container independence, not another container
Paul Hammant wrote:
I forgot the the internals of Mailet are entangled with Avalon.
Huh? No they aren't. Quite the opposite. You had advocated that years
ago, and there was resistence to doing so. There are a few mailets with
Avalon ties, but those are being removed. Mailets will depend
Paul Hammant wrote:
We're finding that Constructor Dependency Injection (CDI) is pretty
popular now. There is a way for most Serviceable/Configurable/etc
components to split into AbstractFoo, AvalonFoo and SimpleFoo type
classes that would facilitate a non-Avalon capability for James.
I'd rather
I'd rather movement towards no framework-related dependencies, using
something like the Spring Framework (http://www.springframework.org/).
Actually, I fundamentally disagree with one of Spring's mission statements.
I seriously dislike unchecked exceptions, which although easier for the lazy
16 matches
Mail list logo
