You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2009/08/19 10:27:28 UTC
First Steps Towards An Avalon Free Future
Loader Service
------------------
create loading services (LoaderService interface?) for classes. this
can be used to replace the classloading each uses ATM. API probably
something like:
<T> load(class<T> type)
once this is done, we switch the implementation to use guice primed
with a module dynamically assembled by PhoenixLoader. would need to
support JSR250 annotation.
Switch To Direct Excalibur In Socket Library
---------------------------------------------------
i started looking at this on the branch. should be possible to replace
the avalon service approach for the sockets with injectors and
annotated lifecycle management. the protocols would still use the
Configuration
----------------
configuration needs thinking about. the protocols are strongly coupled
to the avalon configuration mechanism. i would prefer configuration
POJOs perhaps using AOP to cross cut an adaption layer but i'm have no
strong bias.
any volunteers?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Norman Maurer <no...@apache.org>.
Will have a look soon.
Thx,
Norman
2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> On Wed, Aug 19, 2009 at 7:52 PM, Robert Burrell
> Donkin<ro...@gmail.com> wrote:
>> On Wed, Aug 19, 2009 at 5:24 PM, Norman Maurer<no...@apache.org> wrote:
>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>> On Wed, Aug 19, 2009 at 4:56 PM, Norman Maurer<no...@apache.org> wrote:
>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>> On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
>>>>>>> Comments inside..
>>>>>>>
>>>>>>>
>>>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>>>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>>>>>>>> Hi Robert,
>>>>>>>>>
>>>>>>>>> comments inside...
>>>>>>>>>
>>>>>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>>>>>> Loader Service
>>>>>>>>>> ------------------
>>>>>>>>>>
>>>>>>>>>> create loading services (LoaderService interface?) for classes. this
>>>>>>>>>> can be used to replace the classloading each uses ATM. API probably
>>>>>>>>>> something like:
>>>>>>>>>>
>>>>>>>>>> <T> load(class<T> type)
>>>>>>>>>>
>>>>>>>>>> once this is done, we switch the implementation to use guice primed
>>>>>>>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>>>>>>>> support JSR250 annotation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>
>>>>>>>> anyone want to take a look at this?
>>>>>>>>
>>>>>>>
>>>>>>> Yeah I would like to tackle this.
>>>>>>
>>>>>> cool
>>>>>>
>>>>>> i've been looking at the mailet side of things today
>>>>>>
>>>>>>> Just to understand your vision a bit
>>>>>>> I want to make sure I understood correct:
>>>>>>>
>>>>>>> 1) Add a new LoaderService which will get injected via Service
>>>>>>> livecycle into the "core" services, and will get used to create new
>>>>>>> instaces via Injector.getInstance(..)
>>>>>>
>>>>>> easier just to use the JSR250 annotation support that's already in
>>>>>> there for setter based service injection
>>>>>
>>>>> Sorry not understand :(
>>>>
>>>> for services loaded by phoenix, PhoenixLoader already supports setter
>>>> injection and injection-aware lifecycles via JSR250 annotations
>>>>
>>>> - robert
>>>>
>>>
>>> Ah got it..
>>
>> i've been playing around trying to reuse the same interface for
>> service injection (by name) and component injection (by type name). my
>> thinking was that it'd be better to centralise the class loading foo.
>> i'm not going to be able to make this play with the spring deployment
>> and the PhoenixLoader changes turned out to be pretty ugly. so, i
>> think we need to go with plan A and an LoaderService interface with
>> API
>>
>> <T> load(class<T> type)
>>
>> i think it'd be best if i go ahead and add an example of the wiring
>> into the mailet loaders. once this is in, the tasks split down into
>> wiring the handlers and guicing PhoenixLoader, which should be
>> more-or-less independent.
>
> committed
>
> hopefully the idea will be a bit clearer now
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 7:52 PM, Robert Burrell
Donkin<ro...@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 5:24 PM, Norman Maurer<no...@apache.org> wrote:
>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>> On Wed, Aug 19, 2009 at 4:56 PM, Norman Maurer<no...@apache.org> wrote:
>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>> On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
>>>>>> Comments inside..
>>>>>>
>>>>>>
>>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> comments inside...
>>>>>>>>
>>>>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>>>>> Loader Service
>>>>>>>>> ------------------
>>>>>>>>>
>>>>>>>>> create loading services (LoaderService interface?) for classes. this
>>>>>>>>> can be used to replace the classloading each uses ATM. API probably
>>>>>>>>> something like:
>>>>>>>>>
>>>>>>>>> <T> load(class<T> type)
>>>>>>>>>
>>>>>>>>> once this is done, we switch the implementation to use guice primed
>>>>>>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>>>>>>> support JSR250 annotation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>
>>>>>>> anyone want to take a look at this?
>>>>>>>
>>>>>>
>>>>>> Yeah I would like to tackle this.
>>>>>
>>>>> cool
>>>>>
>>>>> i've been looking at the mailet side of things today
>>>>>
>>>>>> Just to understand your vision a bit
>>>>>> I want to make sure I understood correct:
>>>>>>
>>>>>> 1) Add a new LoaderService which will get injected via Service
>>>>>> livecycle into the "core" services, and will get used to create new
>>>>>> instaces via Injector.getInstance(..)
>>>>>
>>>>> easier just to use the JSR250 annotation support that's already in
>>>>> there for setter based service injection
>>>>
>>>> Sorry not understand :(
>>>
>>> for services loaded by phoenix, PhoenixLoader already supports setter
>>> injection and injection-aware lifecycles via JSR250 annotations
>>>
>>> - robert
>>>
>>
>> Ah got it..
>
> i've been playing around trying to reuse the same interface for
> service injection (by name) and component injection (by type name). my
> thinking was that it'd be better to centralise the class loading foo.
> i'm not going to be able to make this play with the spring deployment
> and the PhoenixLoader changes turned out to be pretty ugly. so, i
> think we need to go with plan A and an LoaderService interface with
> API
>
> <T> load(class<T> type)
>
> i think it'd be best if i go ahead and add an example of the wiring
> into the mailet loaders. once this is in, the tasks split down into
> wiring the handlers and guicing PhoenixLoader, which should be
> more-or-less independent.
committed
hopefully the idea will be a bit clearer now
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 5:24 PM, Norman Maurer<no...@apache.org> wrote:
> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>> On Wed, Aug 19, 2009 at 4:56 PM, Norman Maurer<no...@apache.org> wrote:
>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>> On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
>>>>> Comments inside..
>>>>>
>>>>>
>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> comments inside...
>>>>>>>
>>>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>>>> Loader Service
>>>>>>>> ------------------
>>>>>>>>
>>>>>>>> create loading services (LoaderService interface?) for classes. this
>>>>>>>> can be used to replace the classloading each uses ATM. API probably
>>>>>>>> something like:
>>>>>>>>
>>>>>>>> <T> load(class<T> type)
>>>>>>>>
>>>>>>>> once this is done, we switch the implementation to use guice primed
>>>>>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>>>>>> support JSR250 annotation.
>>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>
>>>>>> anyone want to take a look at this?
>>>>>>
>>>>>
>>>>> Yeah I would like to tackle this.
>>>>
>>>> cool
>>>>
>>>> i've been looking at the mailet side of things today
>>>>
>>>>> Just to understand your vision a bit
>>>>> I want to make sure I understood correct:
>>>>>
>>>>> 1) Add a new LoaderService which will get injected via Service
>>>>> livecycle into the "core" services, and will get used to create new
>>>>> instaces via Injector.getInstance(..)
>>>>
>>>> easier just to use the JSR250 annotation support that's already in
>>>> there for setter based service injection
>>>
>>> Sorry not understand :(
>>
>> for services loaded by phoenix, PhoenixLoader already supports setter
>> injection and injection-aware lifecycles via JSR250 annotations
>>
>> - robert
>>
>
> Ah got it..
i've been playing around trying to reuse the same interface for
service injection (by name) and component injection (by type name). my
thinking was that it'd be better to centralise the class loading foo.
i'm not going to be able to make this play with the spring deployment
and the PhoenixLoader changes turned out to be pretty ugly. so, i
think we need to go with plan A and an LoaderService interface with
API
<T> load(class<T> type)
i think it'd be best if i go ahead and add an example of the wiring
into the mailet loaders. once this is in, the tasks split down into
wiring the handlers and guicing PhoenixLoader, which should be
more-or-less independent.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Norman Maurer <no...@apache.org>.
2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> On Wed, Aug 19, 2009 at 4:56 PM, Norman Maurer<no...@apache.org> wrote:
>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>> On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
>>>> Comments inside..
>>>>
>>>>
>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>>>>> Hi Robert,
>>>>>>
>>>>>> comments inside...
>>>>>>
>>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>>> Loader Service
>>>>>>> ------------------
>>>>>>>
>>>>>>> create loading services (LoaderService interface?) for classes. this
>>>>>>> can be used to replace the classloading each uses ATM. API probably
>>>>>>> something like:
>>>>>>>
>>>>>>> <T> load(class<T> type)
>>>>>>>
>>>>>>> once this is done, we switch the implementation to use guice primed
>>>>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>>>>> support JSR250 annotation.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>
>>>>> anyone want to take a look at this?
>>>>>
>>>>
>>>> Yeah I would like to tackle this.
>>>
>>> cool
>>>
>>> i've been looking at the mailet side of things today
>>>
>>>> Just to understand your vision a bit
>>>> I want to make sure I understood correct:
>>>>
>>>> 1) Add a new LoaderService which will get injected via Service
>>>> livecycle into the "core" services, and will get used to create new
>>>> instaces via Injector.getInstance(..)
>>>
>>> easier just to use the JSR250 annotation support that's already in
>>> there for setter based service injection
>>
>> Sorry not understand :(
>
> for services loaded by phoenix, PhoenixLoader already supports setter
> injection and injection-aware lifecycles via JSR250 annotations
>
> - robert
>
Ah got it..
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 4:56 PM, Norman Maurer<no...@apache.org> wrote:
> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>> On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
>>> Comments inside..
>>>
>>>
>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>>>> Hi Robert,
>>>>>
>>>>> comments inside...
>>>>>
>>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>>> Loader Service
>>>>>> ------------------
>>>>>>
>>>>>> create loading services (LoaderService interface?) for classes. this
>>>>>> can be used to replace the classloading each uses ATM. API probably
>>>>>> something like:
>>>>>>
>>>>>> <T> load(class<T> type)
>>>>>>
>>>>>> once this is done, we switch the implementation to use guice primed
>>>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>>>> support JSR250 annotation.
>>>>>>
>>>>>
>>>>> +1
>>>>
>>>> anyone want to take a look at this?
>>>>
>>>
>>> Yeah I would like to tackle this.
>>
>> cool
>>
>> i've been looking at the mailet side of things today
>>
>>> Just to understand your vision a bit
>>> I want to make sure I understood correct:
>>>
>>> 1) Add a new LoaderService which will get injected via Service
>>> livecycle into the "core" services, and will get used to create new
>>> instaces via Injector.getInstance(..)
>>
>> easier just to use the JSR250 annotation support that's already in
>> there for setter based service injection
>
> Sorry not understand :(
for services loaded by phoenix, PhoenixLoader already supports setter
injection and injection-aware lifecycles via JSR250 annotations
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Norman Maurer <no...@apache.org>.
2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
>> Comments inside..
>>
>>
>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>>> Hi Robert,
>>>>
>>>> comments inside...
>>>>
>>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>>> Loader Service
>>>>> ------------------
>>>>>
>>>>> create loading services (LoaderService interface?) for classes. this
>>>>> can be used to replace the classloading each uses ATM. API probably
>>>>> something like:
>>>>>
>>>>> <T> load(class<T> type)
>>>>>
>>>>> once this is done, we switch the implementation to use guice primed
>>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>>> support JSR250 annotation.
>>>>>
>>>>
>>>> +1
>>>
>>> anyone want to take a look at this?
>>>
>>
>> Yeah I would like to tackle this.
>
> cool
>
> i've been looking at the mailet side of things today
>
>> Just to understand your vision a bit
>> I want to make sure I understood correct:
>>
>> 1) Add a new LoaderService which will get injected via Service
>> livecycle into the "core" services, and will get used to create new
>> instaces via Injector.getInstance(..)
>
> easier just to use the JSR250 annotation support that's already in
> there for setter based service injection
Sorry not understand :(
>
>> 2) Why this would need to support JSR250 Annotations ? (even if I see
>> no problem here with guicy-fruit)
>
> already used for lifecycle management for some areas of the system. if
> you want to use injection, all the avalon stuff needs to get itself
> built first. when working in a mixed environment, need a later
> lifecycle event for injected resources. the IMAP-sieve binding is
> injected so some of trunk is already ported to JSR250 from avalon.
>
> taking a look at PhoenixLoader should make things a little clearer.
> ATM only some phoenix loaded services need JSR250 support for setter
> based service injection and lifecycle so i think that should be
> possible to retain the existing foo and just add Guice into the mix in
> the PhoenixLoader.
>
> take a look and tell me what you think
>
Will do...
> - robert
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<no...@apache.org> wrote:
> Comments inside..
>
>
> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>>> Hi Robert,
>>>
>>> comments inside...
>>>
>>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>>> Loader Service
>>>> ------------------
>>>>
>>>> create loading services (LoaderService interface?) for classes. this
>>>> can be used to replace the classloading each uses ATM. API probably
>>>> something like:
>>>>
>>>> <T> load(class<T> type)
>>>>
>>>> once this is done, we switch the implementation to use guice primed
>>>> with a module dynamically assembled by PhoenixLoader. would need to
>>>> support JSR250 annotation.
>>>>
>>>
>>> +1
>>
>> anyone want to take a look at this?
>>
>
> Yeah I would like to tackle this.
cool
i've been looking at the mailet side of things today
> Just to understand your vision a bit
> I want to make sure I understood correct:
>
> 1) Add a new LoaderService which will get injected via Service
> livecycle into the "core" services, and will get used to create new
> instaces via Injector.getInstance(..)
easier just to use the JSR250 annotation support that's already in
there for setter based service injection
> 2) Why this would need to support JSR250 Annotations ? (even if I see
> no problem here with guicy-fruit)
already used for lifecycle management for some areas of the system. if
you want to use injection, all the avalon stuff needs to get itself
built first. when working in a mixed environment, need a later
lifecycle event for injected resources. the IMAP-sieve binding is
injected so some of trunk is already ported to JSR250 from avalon.
taking a look at PhoenixLoader should make things a little clearer.
ATM only some phoenix loaded services need JSR250 support for setter
based service injection and lifecycle so i think that should be
possible to retain the existing foo and just add Guice into the mix in
the PhoenixLoader.
take a look and tell me what you think
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Norman Maurer <no...@apache.org>.
Comments inside..
2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
>> Hi Robert,
>>
>> comments inside...
>>
>> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>>> Loader Service
>>> ------------------
>>>
>>> create loading services (LoaderService interface?) for classes. this
>>> can be used to replace the classloading each uses ATM. API probably
>>> something like:
>>>
>>> <T> load(class<T> type)
>>>
>>> once this is done, we switch the implementation to use guice primed
>>> with a module dynamically assembled by PhoenixLoader. would need to
>>> support JSR250 annotation.
>>>
>>
>> +1
>
> anyone want to take a look at this?
>
Yeah I would like to tackle this. Just to understand your vision a bit
I want to make sure I understood correct:
1) Add a new LoaderService which will get injected via Service
livecycle into the "core" services, and will get used to create new
instaces via Injector.getInstance(..)
2) Why this would need to support JSR250 Annotations ? (even if I see
no problem here with guicy-fruit)
>>> Switch To Direct Excalibur In Socket Library
>>> ---------------------------------------------------
>>>
>>> i started looking at this on the branch. should be possible to replace
>>> the avalon service approach for the sockets with injectors and
>>> annotated lifecycle management. the protocols would still use the
>>>
>>
>> use the **what** ? Maybe some word is missing ;)
>
> yep ;-)
>
> the protocols would still use the excalibur components but would
> manage their lifecycle directly
>
Sounds like a plan
>>> Configuration
>>> ----------------
>>>
>>> configuration needs thinking about. the protocols are strongly coupled
>>> to the avalon configuration mechanism. i would prefer configuration
>>> POJOs perhaps using AOP to cross cut an adaption layer but i'm have no
>>> strong bias.
>>
>> Why not just create a Properties or commons Configuration object
>> on-the-fly and inject that ? This will only contain the config needed
>> for the specific handler / whatever..
>
> ATM james uses tree structured configuration so switching to either of
> these options would mean breaking configuration compatibility
>
> it would be possible to flatter the structure. for example
>
> <smtpserver><handler><connectiontimeout>36</connectiontimeout></handler></smtpserver>
>
> could be mapped to property smtpserver.handler.connectiontimeout=36
>
> i think there would be difficulties trying to do this with fetchmail
> or spoolmanager. for example,
>
> <fetchmail enabled="false">
> <fetch name="mydomain.com">
> <accounts>
> <account user="myglobalaccount" password="password"
> recipient="postmaster@localhost" ignorercpt-header="false"/>
> </accounts>
> </fetch>
> <fetch name="anotherdomain.com">
> <accounts>
> <account user="anotherglobalaccount"
> password="password" recipient="postmaster@localhost"
> ignorercpt-header="false"/>
> </accounts>
> </fetch>
> </fetchmail>
>
> there the 'name' attribute is used to distinguish different services.
> AIUI a typical flat mapping is
>
> fetchmail.fetch."mydomain.com".accounts.account.user=anotherglobalaccount
>
> i think that this would need to be wrangled by hand for each case like this
>
> IMHO configuration is a container issue and should be sorted out
> without invasion. we could use AOP to inject configuration support for
> the container.
>
> - robert
>
got it, makes sense.
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<no...@apache.org> wrote:
> Hi Robert,
>
> comments inside...
>
> 2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
>> Loader Service
>> ------------------
>>
>> create loading services (LoaderService interface?) for classes. this
>> can be used to replace the classloading each uses ATM. API probably
>> something like:
>>
>> <T> load(class<T> type)
>>
>> once this is done, we switch the implementation to use guice primed
>> with a module dynamically assembled by PhoenixLoader. would need to
>> support JSR250 annotation.
>>
>
> +1
anyone want to take a look at this?
>> Switch To Direct Excalibur In Socket Library
>> ---------------------------------------------------
>>
>> i started looking at this on the branch. should be possible to replace
>> the avalon service approach for the sockets with injectors and
>> annotated lifecycle management. the protocols would still use the
>>
>
> use the **what** ? Maybe some word is missing ;)
yep ;-)
the protocols would still use the excalibur components but would
manage their lifecycle directly
>> Configuration
>> ----------------
>>
>> configuration needs thinking about. the protocols are strongly coupled
>> to the avalon configuration mechanism. i would prefer configuration
>> POJOs perhaps using AOP to cross cut an adaption layer but i'm have no
>> strong bias.
>
> Why not just create a Properties or commons Configuration object
> on-the-fly and inject that ? This will only contain the config needed
> for the specific handler / whatever..
ATM james uses tree structured configuration so switching to either of
these options would mean breaking configuration compatibility
it would be possible to flatter the structure. for example
<smtpserver><handler><connectiontimeout>36</connectiontimeout></handler></smtpserver>
could be mapped to property smtpserver.handler.connectiontimeout=36
i think there would be difficulties trying to do this with fetchmail
or spoolmanager. for example,
<fetchmail enabled="false">
<fetch name="mydomain.com">
<accounts>
<account user="myglobalaccount" password="password"
recipient="postmaster@localhost" ignorercpt-header="false"/>
</accounts>
</fetch>
<fetch name="anotherdomain.com">
<accounts>
<account user="anotherglobalaccount"
password="password" recipient="postmaster@localhost"
ignorercpt-header="false"/>
</accounts>
</fetch>
</fetchmail>
there the 'name' attribute is used to distinguish different services.
AIUI a typical flat mapping is
fetchmail.fetch."mydomain.com".accounts.account.user=anotherglobalaccount
i think that this would need to be wrangled by hand for each case like this
IMHO configuration is a container issue and should be sorted out
without invasion. we could use AOP to inject configuration support for
the container.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: First Steps Towards An Avalon Free Future
Posted by Norman Maurer <no...@apache.org>.
Hi Robert,
comments inside...
2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> Loader Service
> ------------------
>
> create loading services (LoaderService interface?) for classes. this
> can be used to replace the classloading each uses ATM. API probably
> something like:
>
> <T> load(class<T> type)
>
> once this is done, we switch the implementation to use guice primed
> with a module dynamically assembled by PhoenixLoader. would need to
> support JSR250 annotation.
>
+1
> Switch To Direct Excalibur In Socket Library
> ---------------------------------------------------
>
> i started looking at this on the branch. should be possible to replace
> the avalon service approach for the sockets with injectors and
> annotated lifecycle management. the protocols would still use the
>
use the **what** ? Maybe some word is missing ;)
> Configuration
> ----------------
>
> configuration needs thinking about. the protocols are strongly coupled
> to the avalon configuration mechanism. i would prefer configuration
> POJOs perhaps using AOP to cross cut an adaption layer but i'm have no
> strong bias.
Why not just create a Properties or commons Configuration object
on-the-fly and inject that ? This will only contain the config needed
for the specific handler / whatever..
>
> any volunteers?
>
> - robert
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org