Modules and CDI

[swd847]

I have been thinking about add a portable extension to implement Modules in CDI. Specifically if I have the following:

 interface A {};
 @Module1
 class B implements A{}

 @Module2
 class C implements A;

The active module information would be stored in a thread local, and could be controlled in a variety of ways, e.g through interceptors, a filter that looks at the current view id etc. Possible use cases include beans that are only availible on certain view ids, scoping beans to a WAR module without having to deploy them inside the module, and the 'Robot Legs' problem that Bob Lee was talking about that time modules were discussed .

Does this sound like it would be useful?

[swd847]

I just though I would clarify that these are run time modules that have nothing to do with the existing CDI concept of modules (I probably need a better name for them).

Basically these will just provide a dynamic way for you to vary the implementation of a bean at runtime.

[nickarls]

Don't let me stop you but what it the difference to keeping the logic in a @Produces? Fewer evaluations? Something else? Or am I missing the problem?

[gavin.king]

It sounds like the activities stuff that we used to have in older drafts of the CDI spec. I encourage you to take a look at that stuff and see what you think. Unfortunately, I'm not sure that there's a way to implement this stuff properly as a portable extension (which is why we thought we needed it in the spec).

I think Weld has some support for activities already, perhaps you could look into working on that stuff (if it still exists), since activities could definitely make a comeback in a future rev of CDI, if we have a working implementation to use as a starting point.

[swd847]

Do you know where I could find one? I had a look on the JSR site and could not seem to find the draft with activities in it.