On Wed, Aug 19, 2009 at 4:06 PM, Norman Maurer<[email protected]> wrote: > 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.
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: [email protected] For additional commands, e-mail: [email protected]
