Community
Participate
Working Groups
Build Identifier: Java EE 6 provides an update JSF version (2.0) which Eclipse is starting to support, and CDI (JSR 299) which is an ideal companion for JSF applications (and more). CDI usage can make obsolete (deprecated) JSF ManagedBeans (CDI provides an equivalent ManagedBeans in a a different package). CDI makes it easy for EJBs to be used in JSF 2.0 application, and allows simple POJO annotated with @Named annotation to be used like regular managedbeans inside XHTML Facelets. As such these @Named Pojo inside a JSF 2.0 project should be available in the EL part of the editor (#{...}) if there is an empty beans.xml (or correct beans.xml content) which is the trigger to enable CDI in a Web App. CDI will need also a complete set of new wizards to create CDI pojos, but this bug is more related to JSF 2.0 tooling that needs to be aware of CDI beans in the xhtml editor for code completion and validation in EL areas. Equivalent features are now in NetBeans IDE. Look at http://wiki.netbeans.org/NewAndNoteworthy69m1#Contexts_and_Dependency_Injection and really help the adoption of Java EE 6 and JSF 2.0 Reproducible: Always
This is a feature we would like to see supported in the JSF Tools project and we do plan to address this in a release after Helios.
I didn't find other bugs in bugzilla on CDI so leaving my comment here: We got majority of CDI spec implemented in JBoss Tools 3.2 by now (http://jboss.org/tools). We probably cannot contribute this code directly because of other dependencies, but would like to contribute where we can in this area. Adding me to cc here to know - but do feel free to contact me directly if something comes up.
Under review.
btw. shouldn't this be somewhere else than JSF ?
(In reply to comment #5) > btw. shouldn't this be somewhere else than JSF ? We will use this bug to track consumption of CDI @Named beans in a JSF Tools project. We will add more info on the planned support.
We will support discovery of @Named and @Model CDI beans and associated CDI scopes. Support will include all features currently available to managed beans defined in a faces-config file or via JSF @ManagedBean annotations, which are: EL content-assist, validation, and hyperlinking to the managed bean class. New API in JSFAppConfigUtils will allow testing of a managed bean instance to determine how it was defined.
Fix committed to HEAD at 2012/01/31 11:34AM PST.
Is there an API for extenders to contribute valid named beans/validation ? i.e. jboss tools understand more annotations than what is possible via pure annotation scanning - i.e. to pick up programmatic defined CDI beans. Would be sad if WTP starts reporting wrongful errors thus great if we could contribute other names at least to validation and secondary for completion (completion we can extend already today so not so crucical)
(In reply to comment #10) > Is there an API for extenders to contribute valid named beans/validation ? Currently, there is not. If what you'd require is still JSF Tools-specific, then perhaps you would kick off further discussion by proposing the interface(s) that would support your needs? If this goes beyond JSF Tools, then we would need to open up a discussion with the broader (WTP) team. Thanks, - Ian
(In reply to comment #11) > (In reply to comment #10) > > Is there an API for extenders to contribute valid named beans/validation ? > Currently, there is not. I was thinking CDI-specifics when I first responded. There already exist a couple of extension points that have been used by adopters to provide app configuration. org.eclipse.jst.jsf.core.jsfAppConfigManagerFactory allows the user to implement org.eclipse.jst.jsf.core.jsfappconfig.internal.IJSFAppConfigManagerFactory, and so have complete control over the app config. org.eclipse.jst.jsf.core.jsfAppConfigLocatorProviderFactory allows the user to implement org.eclipse.jst.jsf.core.jsfappconfig.internal.IJSFAppConfigLocatorProvider, which allows manipulation of all "locators" of app config artifacts (and was successfully used by an adopter to add annotated beans before base tooling was doing so). As for validation warnings, validation of beans was relaxed a while back, so specifying a bean that is not known to the tooling will not generate a warning marker.
