On Wed, Aug 19, 2009 at 9:35 AM, Norman Maurer<[email protected]> wrote:
> Hi Robert,
>
> comments inside...
>
> 2009/8/19 Robert Burrell Donkin <[email protected]>:
>> 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="postmas...@localhost" ignorercpt-header="false"/>
</accounts>
</fetch>
<fetch name="anotherdomain.com">
<accounts>
<account user="anotherglobalaccount"
password="password" recipient="postmas...@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: [email protected]
For additional commands, e-mail: [email protected]
