On 8/4/11 10:07 , Niclas Hedhman wrote:
If we are going to move away from extending Composite meta types, then
there is an interesting observation;
module.services( Executor.class ).withMixins(
ThreadPoolExecutor.class ).withConcerns( ExecutorProgressConcern.class
);
or
module.values( Map.class ).withMixins( HashMap.class
).withConcerns( PutCheckConcern.class );
and so on, that would actually work??
Uhm... yeah, it actually would.
If so, what are the positive consequences in terms of integration
across the open source world?
I don't have the answer, just a GutFeeling(tm) that this could be
really, really game changing...
Quite possibly so, yes.
One thing that I can think of is around enabling 'soft introduction'
of Qi4j into existing apps. A really low impact usage;
Module module = new SingletonQi4jApplication() { ..implement
assemble() }.module();
Map aopMap = module.newValue( Map.class );
module.service( Executor.class ).execute( new Runnable() { .... } );
Yes, and you can basically instantiate as many "Qi4j apps" as you want
in your "real app".
And perhaps even provide a suitable Spring application context
embedded in Qi4j Core so the above Module is available as a bean if
you put it into Spring.
Spring integration is already there. Haven't tested it myself, but looks
like it would do what you ask for quite easily.
Anybody have any thoughts?
Sounds good to me :-)
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
