james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Wed, 02 Feb 2005 18:33:37 GMT
Danny Angus wrote:
> We do see some separation of "binding times" for configuration.
> a) Assembly configuration asks, what objects should be instantiated to
> satisfy a requirement for a service implementation.
> b) Operational configuration asks what parameters should be supplied
> to instantiated services in order to modify their behaviour at
> runtime.
> We are likely to see two different classes of user attending to the
> two different areas, and if there are two different approaches then
> that is not necessarily a bad thing. Let IoC take care of "a" but
> provide a simple mechanism for users to attend to "b".
> Or not? What do you think?

I'm having trouble trying to draw the line between what's in "a" and 
what's in "b"...

1. add users to a domain... we do this dynamically already (userstores, 
either file or jdbc) so clearly "b"
2. add domains to the server... this is "binding time" right now, but 
that would be nice to change.
3. change the list of mailets for a processor... this is "binding time" 
right now, but again, I'd really rather avoid restarting and since there 
are no threading issues (since we're simply defining a list of tasks 
that a thread will use), this /should/ be very doable.
4. change handler(s) for the MAIL FROM command during SMTP... this is 
hardcoded into Java right now (pre-"a"), but we talked about supporting 
the mailet/matcher API here, so does that push it to "a", and if not 
"a", why not "b"?
5. change handler(s) of an incoming socket on port 25.  this is also in 
Java hardcoded, but we hope to get away from this.  So is this an "a" 
issue, or do we let someone dynamically register a new handler to watch 
incoming connections and then dynamically register another handler to 
start rejecting incoming connections?

I dunno where we head with this.  I don't really see how 
commons-configuration would be useful to us.  This does look about as 
anti-IoC as it gets (and ironically what would have been very useful for 
me for the first 8 years of java development).

JNDI is widely accepted in J2EE, and I was behind using it in James 
originally.  In my defense, I was comparing it to what we had with 
Avalon, and now that I have seen a simple IoC framework in practice, I 
don't like JNDI and also appreciate what Avalon was trying to do.

Working from my Spring experience (very limited), anything in JNDI, 
Hibernate, JDBC, or other category "b" sources can be provided in the 
IoC framework by bean-factory wrappers, so it's just a question of us 
defining the right POJO interfaces.  Then any "operational" task can get 
loaded from whatever underlying resource.

I think it largely comes down to defining the right set of POJO 
interfaces.  We'll ultimately need to tackle what the default James impl 
bundles, but I don't know if we need to address that now since we all 
seem to agree that POJOs are the way to go.  It seems like we have a lot 
of work to talk about there before we get into how they're instantiated.

Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message