On 21 May 2009, at 18:43, Gavin King wrote:
BTW, what exactly are the implications of adopting this rule for the
Do we still need to pass some sort Module object around, or can the
container figure it out based upon the Class objects?
This seems ugly, a Class does know where it comes from (but whether we
can get that info out, I need to try).
Does the container just call theClass.getClassLoader() and then cast
it to some internal ClassLoader subclass to determine exactly where
the class came from?
I think this should work, I will try to impl it sometime soon (for the
RI I will do this as a SPI call to the underlying container, and we
will use some concept of a Module internally).
We need to figure out how this works so I can update the SPI.
On Wed, May 20, 2009 at 9:37 PM, Gavin King <gavin.king(a)gmail.com>
> Folks, I spent a bunch of time with Bill Shannon and Roberto today.
> The results of these discussion were:
> Inter-module dependencies
> We shouldn't introduce any special module-level dependency mechanism
> or module-private dependencies (such as my proposal for @Exported
> beans). We should wait for the Java Module System for that kind of
> Instead we'll say that an injection point of a class X can resolve to
> a bean Y only when the Java EE spec requires that the bean class Y is
> visible to X (section 8.3 of the spec). So, for example, a bean in
> ejb-jar A is not available for injection into a bean in another
> ejb-jar B unless A declares a dependency to B in manifest.mf.
> This solution isn't quite as powerful as module-private dependencies,
> but it solves the cases I raised earlier today, and we'll get
> something more powerful when the Java Module System arrives.
webbeans-dev mailing list