On Thu, 2005-03-31 at 16:10 +0100, Daniel Perry wrote:
> I've used both setter and constructor dependency injection. I much prefer
> the constructor approach:
> -All dependencies are in one place - the constructor - this causes bloat,
> but makes maintenence easier as it's only one method.
> -Cons
> I think that there would be thread pools management at
> least for RemoteDelivery, don't we?
Actually, I've wanted to move that logic out of RemoteDelivery, and make it
generally available in spooling. For example, if we can't handle DNS
queries at some point, we could requeue the mail to be tr
[EMAIL PROTECTED] wrote:
I think that there would be thread pools management at least for
RemoteDelivery, don't we?
I don't know whether JMS can do the delayed processing, so perhaps we
use something like Quartz in conjunction with JMS. But the goal is to
remove this thread/timing management cod
> http://activemq.codehaus.org/
>
> a) we adopt JMS and get the standard messaging framework
> abilities to...
>1) dump our thread pools and scheduling logic
I think that there would be thread pools management at least for
RemoteDelivery, don't we?
> Anyway, this is an incredibly non-trivia
> http://activemq.codehaus.org/
Yes, it is something we talked about related to clustering and spooling.
One of my top items to look at post-merger, along with JNDI integration.
This is why we wanted to separate spooling from message store.
--- Noel
-
http://activemq.codehaus.org/
The benefit of using JMS is...
a) we adopt JMS and get the standard messaging framework abilities to...
1) dump our thread pools and scheduling logic
2) cluster spools
3) monitoring of spools (out of the box web front end to monitor # of
messages in a topic/spoo
On Friday 01 April 2005 11:06, [EMAIL PROTECTED] wrote:
> > Someone asked for a road-map:
> > 1. POJOification
> > 2. Possibly taking ownership over a few Phoenix things
> > [...]
> > But I see this as done in concert, as you probably need to do
> > 2. while doing 1.
>
> Here is a count of package
> Someone asked for a road-map:
> 1. POJOification
> 2. Possibly taking ownership over a few Phoenix things
> [...]
> But I see this as done in concert, as you probably need to do
> 2. while doing 1.
Here is a count of package dependency from the current svn 2_1_fcs branch
(pls note that I groupe
On Thursday 31 March 2005 17:59, Serge Knystautas wrote:
> Soren Hilmer wrote:
> > Serge recently posted a mail to server-user saying that a container
> > switch was a minor concern of ours (or at least something to that
> > extent).
> > I disagree on this, I believe that we have to make a decissio
