Weld Maven archetypes with JBoss 6.0.0 M1

[asookazian]

So I just finished reading these articles/blogs:

http://in.relation.to/Bloggers/GetRunningOnCDIJSF2InAJiffyUsingMavenArchetypes

http://seamframework.org/Documentation/WeldQuickstartForMavenUsers

And actually very quickly and successfully created two Maven projects in Eclipse (one for weld-jsf-jee-minimal and one for weld-jsf-jee), built them via mvn clean install and deployed the WARs to JBoss AS 6.0.0 M1 within 30 min's (including reading the instructions).  Of course I already had Eclipse, JBoss, m2eclipse and Maven installed but whatever.

Great job guys!

Now I have some sample code to generate some questions off of.

The code snippet below from home.xhtml looks similar to what I have done dozens of times in Seam using @Factory and @DataModel annotations (factory component pattern).

<h2>Widgets</h2>
      <h:dataTable var="_widget" value="#{widgets}">
         <h:column>
            <f:facet name="header">Id</f:facet>
            #{_widget.id}
         </h:column>
         <h:column>
            <f:facet name="header">Part Number</f:facet>
            #{_widget.partNumber}
         </h:column>
         <h:column>
            <f:facet name="header">Name</f:facet>
            #{_widget.name}
         </h:column>
         <h:column>
            <f:facet name="header">Description</f:facet>
            #{_widget.description}
         </h:column>
      </h:dataTable>

So the #{widgets} triggers a call to getWidgets()?

here:

public class WidgetListProducer
{
   @Inject @WidgetRepository EntityManager widgetRepository;
   
   @Produces
   @Named
   @RequestScoped
   @SuppressWarnings("unchecked")
   List<Widget> getWidgets() {
      return widgetRepository.createQuery("select w from Widget w order by w.name").getResultList();
   }
}

Thus, the @Produces is in effect similar to @Factory in Seam?  So essentially the Weld container looks to invoke getFoo() method in a managed bean whenever it encounters #{foo} in a facelet?  What if getFoo(...) is overloaded or does not exist with zero params?

Now we need an example which models a wizard use-case and demonstrates @ConversationScoped components...

The only thing I noticed is that after m2eclipse/Eclipse created my project, I did not have the same Java project structure as displayed in SBoscarine's step-by-step tutorial (properties shows as project and not Java project).  I think if I delete the project from my workspace and create a new Java project based on those generated folders and files, it may look the same...

Well, I just tried that and no changes.  I see myproject and directly inside that folder I see Deployment Descriptor: <web app>, Java Resources, src, target, pom.xml, readme.txt

[meetoblivion]

kind of, the key is that the method's annoated @Named, which tells CDI to bind the result to the javabeans field name widgets since it's named getWidgets. 

And just to point out, the difference is that seam only ever worked with the equivalent of @Named, so in a factory you had an overloaded annotation @Factory("widgets") which is the equivalent of @Produces @Named("widgets") or just @Produces @Named public List getWidgets() { }.  The reason for this change is the CDI is meant to work against custom qualifiers - not just name based designation.

[alin.heyoulin.qq.com]

You are right. But i don't like @Produces @Named(xx). So i'm struggling to do a portable extension to make @Produces @Named(xx) look like @Factory(xx)  and @Inject @Named(xx) look like @In(xx)

[nickarls]

Should be doable but I'm since the annotations are now standard I think you'll just confuse everybody else trying to read your code ;-)

[asookazian]

John Ament wrote on Dec 30, 2009 02:10:


kind of, the key is that the method's annoated @Named, which tells CDI to bind the result to the javabeans field name widgets since it's named getWidgets. 

And just to point out, the difference is that seam only ever worked with the equivalent of @Named, so in a factory you had an overloaded annotation @Factory("widgets") which is the equivalent of @Produces @Named("widgets") or just @Produces @Named public List getWidgets() { }.  The reason for this change is the CDI is meant to work against custom qualifiers - not just name based designation.

Thanks for the followup.

The following is from the JEE 6 tutorial:

To make a bean accessible through the unified expression language (EL), use the @Named
built-in qualifier.
import javax.inject.Inject;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
@Named
@RequestScoped
public class Printer {
@Inject @Informal Greeting greeting;
...
The @Named qualifier allows you to access the bean using the bean name, with the first letter in
lowercase. For example, a Facelets page would refer to the bean as printer.

Why must we explicitly use @Named?  Why can't the container default it to printer in this case?  Seems like extra unnecessary work in most (default) cases.

[meetoblivion]

in of itself, @Named isn't a good solution for a production level app.  It should only be used if you're looking to explicitly expose something for JSF UI consumption.