About 3; I imagine that this can be used for integration into Spring & OSGi, and possibly proprietary internal frameworks, to allow an external hand to help in the wiring so to speak. If digging deeper, perhaps an aim should be to have hooks for the entire Service instantiation process, so importService would perhaps not be needed. And another thing not to forget; We want to achieve a smaller Qi4j footprint in business classes, so both existing "beans"/pojos can be used unaltered as well as have much less Qi4j import statements. That eases adoption, so more stuff to Assembly and less in classes and interfaces, is my basic principle.
-- Niclas On Fri, May 11, 2012 at 6:46 PM, Paul Merlin <[email protected]> wrote: > Hey, > > I'm in for removing Activatable completely in favor of @Activation and > @Passivation annotations! > > I'll second Stanislav in that the method number 3 seems complicated but I > have a gut feeling that it's still necessary for not-so-complex cases. > Niclas do we have a use case in the codebase that could be used as an > exemple? > > > I'm in for removing Initializable in favor of @Initialize annotation too in > the same run as it is really similar to Activatable. If applying method > number 3 we could have MixinInitializer and MixinContext usable as a base of > ServiceActivator and ServiceContext. > > Now Qi4j runtime would have only one "Internal Qi4j Method" case left to > handle : Lifecycle (see the isInternalQi4jMethod() method present in > FragmentClassLoader and TransientClassLoader). Here we could introduce > @Creation and @Removal annotations and why not EntityLifecycle and > EntityContext. > > WDYT? > > /Paul > > > Niclas Hedhman a écrit : > >> Gang, >> >> I have been thinking a lot about the QI-310, and I conclude that I am >> not at all happy with current situation. >> >> I often find myself with needing a "activation task", for instance to >> connect (and maintain connectivity) to an MQ feed, and like that out >> of the way of the actual service's purpose. But since such Mixin would >> not have any public methods, nor private mixin methods, Qi4j will >> simply not include such Mixin in the service. The work-around is to >> have Activatable in the public composite interface, but we have >> introduced special meaning to Activatable at Mixin level. >> >> I would like to suggest a series of incompatible changes in this space; >> >> 1. Activatable is removed completely. >> >> 2. Introduce @Activation and @Passivation annotation, which can be >> placed on any number of methods of any Mixin, as long as the method >> has zero arguments, or Qi4j annotated arguments that can be resolved, >> such as @Structure and @Service. >> >> 3. Add custom "Activators" as a concept, which can only be assigned >> to a Service at bootstrap, and is not partOf the composite itself. For >> instance; >> module.addService( MyService.class).withActivators( >> MqConnection.class, PubSubConnection.class ); >> and possibly also allow activators to be instantiated at assembly >> module.addService( MyService.class).withActivators( new >> MqConnection(host,port) ); >> >> The activator implements an interface which provides access to all >> internal bits of the ServiceComposite, probably via a new interface >> called ServiceContext; >> >> public interface ServiceActivator<T> { >> void activate( T instance, ServiceContext<T> context ); >> void passivate( T instance, ServiceContext<T> context ); >> } >> >> I have not yet worked out what the ServiceContext is exactly, but it >> should have methods for easy access to methods, annotations, service >> configuation (incl, on-the-fly creation, validation and modification), >> private mixins and more. >> >> >> WDYAT? >> >> >> Cheers > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
