Programatically activating an Alternative...

[matt.corey]

Is it possible to programatically activate an Alternative, to integrate with JSF 2.0's Development Phase functionality, for example? 

M

[nickarls]

Write extension. Cast to impl. Get hold of BDA. Parse faces-cfg. Add beans.xml. Posted from mobile :-)

[nickarls]

I wouldn't mind having an event for each deployment archive that would have enableAlternative(Class<?>) and same for interceptors and decorators...

[matt.corey]

Holy cow -- translation needed, please! :)  What object am I casting into what other object?  What's a BDA, and what do I do with it?

If there were an 'enableAlternative' method, as you say, I would have figured it out by now, but I didn't find one :)

M

[nickarls]

Write an extension (see the refdoc) that listens to the

void afterBeanDiscovery(@Observes AfterBeanDiscovery abd) {
}

in Weld, this will be a AfterBeanDiscoveryImpl so you can cast to that. Use reflection to access the private beanDeployments and then use BeanDeploymentArchive.getBeansXml().add(my_own_beans_xml_with_correct_stereotype_enabled). The beans.xml will be merged to enable the correct stereotype.

Now, I don't think JSF has booted at this point so you don't have a FacesContext to work on (and can't mock one since the impl. itself is not there year) so you are better off getting the faces-config.xml yourself and parsing the production/devel mode from there.

This is so ugly, I'm not sure why I'm even telling you this ;-)

PS. Not tested, just looking at the code...

[matt.corey]

Ah, gotcha -- so it's basically a not-quite-portable extension... that's a bit disappointing, but potentially something I could work with...

And you're right, it's definitely ugly to manually parse the faces-config.xml... must be some other hook I can look for :)

Thanks,
M

[nickarls]

Well, I'm sure you might be able to bootstrap JSF yourself with mock objects and the faces-config.xml location (check out ConfigureListener() in JSF 2) but it might be a bit heavy...

[matt.corey]

Nicklas -- is this something that should work in Glassfish's CDI runtime (which uses Weld, as I'm sure you know)?  When I try to cast to AfterBeanDiscoveryImpl, I get a ClassNotFoundException, even if I include the weld-spi.jar in my webapp...

M

[matt.corey]

Hmm, got around the ClassNotFoundException when I realized that the AfterBeanDiscoveryImpl is in the weld-core jar file, but now I get

java.lang.ClassCastException: org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl cannot be cast to org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl

Usually this indicates a ClassLoader issue -- I'm presuming at this point that the Glassfish version is either a different version, or a slight variation...

M

[nickarls]

Don't include any weld-specific jar:s in your webapp

[gavin.king]

In the next rev of CDI, I want to add a Module interface and a ProcessModule event to let you mess with enabled alternatives, interceptors, decorators. For now there's no good portable way to mess with the module-level metadata.

This is a major item on the portable extension SPI wishlist.

[matt.corey]

Sounds good, Gavin -- is that something that's in the works, or are we going to have to wait a few years for JEE 7?

M

[gavin.king]

Matt Corey wrote on Dec 29, 2009 04:59:


Sounds good, Gavin -- is that something that's in the works, or are we going to have to wait a few years for JEE 7?

No, we plan a CDI 1.1 release way before EE 7.