Add support to register external CDI Extensions about cdi-unit HOT 11 CLOSED

You can just specify the extension class in @AdditionalClasses. Let me know if this doesn't work.

from cdi-unit.

No it didn't work. I'll pull a request for a working patch.

from cdi-unit.

Hi.
I'd be interested to know why the extension doesn't get registered on line 125 of WeldTestUrlDeployment.

from cdi-unit.

Hi
Extension.class.isAssignableFrom(c) is evaluated to false. Extension class is not in classesToProcess yet?

from cdi-unit.

Sorry, I don't really understand then, surely adding ValidationExtension to additional classes should work because it implements Extension?

Just trying to understand this fully before accepting the pull request.

from cdi-unit.

Did a little more debugging:
private boolean isCdiClass(Class<?> c) {
if (c.getProtectionDomain().getCodeSource() == null) {
return false;
}
URL location = c.getProtectionDomain().getCodeSource().getLocation();
boolean isCdi = cdiClasspathEntries.contains(location);
return isCdi;

}
Returns false for ValidationExtension in statement cdiClasspathEntries.contains(location);

Helps?

from cdi-unit.

Hmmm. The reason for that code is #14. It means that classes are not processed if they are not in an archive with beans.xml.

It looks like extensions are exempt from the beans.xml rule and hibernate validator doesn't have one.

I have just pushed a change to git can you give the version on head a go specifying the ValidationExtension in additional classes?

It's just I know that people are already doing this, so I'm reluctant to add another annotation type at this stage.

from cdi-unit.

Seams to work but for a cleaner separation doesn't it make sense to divide additional classes for "real" beans and extensions?

from cdi-unit.

I can see the attraction, and I've also never been a fan of 'AdditionalClasses' as a name.

I was thinking with the weld 2 support the next release could be a major version number which would enable some of this stuff.

Questions though:
As a cdi-unit user do you want to have to make the distinction between an extension and non-extension classes? At the moment if an extension gets added to the deployment then it is enabled, no distinction necessary. Then again is it more confusing for the user to do things the way?

Would changing the name of the @AdditionalClasses attribute to something else such as @CdiDeployment help?

If we add an @AdditionalExtensions should we disable extension discovery via @AdditionalClasses?

from cdi-unit.

Well, hard to answer your questions. Personally I like the idea to separate the concern I like to address with the meta information. An Extension is something different than an simple POJO for simple bean injection. That might help for a better testcase definition to separate that information. So for question three I would disable extension discovery via @AdditionalClasses. If changes to names are better? Corresponding to CDI spec. @PortableExtensions/@beans... ?

from cdi-unit.

Opened new issue to cover naming
#33

from cdi-unit.