Comments inside..
2009/8/19 Robert Burrell Donkin <[email protected]>: > 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? > 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="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 > got it, makes sense. Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
