Get running on CDI & JSF 2 in a jiffy using Maven archetypes

Awesome. Thanks for your work, guys!

Hi Dan,

great stuff. Absolutely fantastic, that things starts moving now. I used the weld-jsf-jee-Archetype out of Eclipse and deployed the demo to JBoss 6.0.0.M1 - it worked out of the box! Great Job!

Hm, obviously I need to learn which annotation come's from which API now. (-:

Inspite of beeing probably not yet qualified enough, I would like to give you a short feedback:

1) in general: the archetype is pretty simple an straightforward to use

2) the project structure looks nicely organized and quite common to a Seam-User

3) a deeper package structure would be nice (something like ejb, model, controller or so)

4) OK, the example is pretty simple - and Yes, I know, you didn't have to much time for that and I truly appreciate that you want the community to take part asap. What I do find a little bit misleading is that the example uses two domain objects: Widget for sample JPA usage (unfortunately, nothing new from JPA 2.0 included) and HelloWorld for sample CDI/JSF/303/el-access usage. I do not see where the WidgetRepositoryProducer-SLSB is used? Why not put things together to one simple CRUD-Widget-example? Well, there are lots of new changes, annotations so I personally would prefer to see one small All-in-One-example - OK, the Widgets could be accessed either with or without EJB's.

5) after 4) you hopefully could get rid of <h:outputText value=" All clear!" rendered="#{facesContext.postback and empty facesContext.messageList} (-:

I have just started to study the CDI-API, but maybe you can answer these probably simple questions? So I would be able to play around with the stuff by knowing what I am doing (-:

1) OK, I understand that #{widgets} from home.xhtml refers to WidgetListProducer.getWidgets() due to @Named. How would I change this after extending the Producer-Class with missing CRUD-methods? Can I annotate the class with @Named? Does it have a default scope? Do I still neet @Produces for the methods or is there a way to generalize this as well? The el-access to a method would be: #{widgetListProducer.widgets}?

2) I did not understand completely why do I need @Qualifier in @WidgetRepository. What would happen without this annotation?

3) Is there still a pages.xml construct or is that Seam3 stuff?

BTW, I really like the @Model-Sterotype thing!! Great to see this in action in your demo.

regards Michael

Great progress! :-)

But I didn't get it run in glassfish v3 embedded with your hints in readme.txt. Got it work after following glassfish embedded docu suggestions to add to pom.xml. (use target/test.war not test.war!) Maybe you can add this stuff to main pom until JBoss 6 embedded is flying or correct the readme for manual addition

Greets Benjamin

Benjamin wrote on Dec 19, 2009 10:14:
Great progress! :-) But I didn't get it run in glassfish v3 embedded with your hints in readme.txt. Got it work after following glassfish embedded docu suggestions to add to pom.xml. (use target/test.war not test.war!) Maybe you can add this stuff to main pom until JBoss 6 embedded is flying or correct the readme for manual addition Greets Benjamin

How did you got JavaDB started in embedded glassfish? I get a connection refused at port 1527 and I think that db service is not up. I tried with the glassish-embedded admin goal, but no luck!

Hi Alberto,

Yes I had the same problem and then started an external derby instance as workaround. Sorry, forgot to mention it in my last post! Well, but I'm not sure whether an internal db instance normally should be started together with glassfish embedded since the normal edition also does start it separately.

Greets Benjamin

Benjamin wrote on Dec 20, 2009 09:13:
Hi Alberto, Yes I had the same problem and then started an external derby instance as workaround. Sorry, forgot to mention it in my last post! Well, but I'm not sure whether an internal db instance normally should be started together with glassfish embedded since the normal edition also does start it separately. Greets Benjamin

You are right. Anyway I see an admin goal that should execute start-databse commands. I tried

<plugin>
  <groupId>org.glassfish</groupId>
    <artifactId>maven-embedded-glassfish-plugin</artifactId>
    <version>3.0-SNAPSHOT</version>
    <configuration>
      <goalPrefix>glassfish</goalPrefix>
      <app>${project.build.directory}/${build.finalName}.war</app>
      <port>8080</port>
      <contextRoot>/weld</contextRoot>
      <autoDelete>true</autoDelete>
      <command>start-database</command>
    </configuration>
    <executions>
      <execution>
      <phase>install</phase>
      <goals>
        <goal>start</goal>
        <goal>admin</goal>
        <goal>deploy</goal>
      </goals>
      </execution>
    </executions>
</plugin>

but I get Command start-database not found.

Another important feature we should enable is hot deployment. The last tutorial shown here by Gavin about CDI and Netbeans was amazing: Glassfish or Netbeans (I don't know if it's a IDE or AS feature) were able to hot deploy single beans (EJB and not EJB). If we can achieve a CDI, JSF2, EJB3.1m JPA2.0 mavenized application with bundled AS and Database and hot deployment for free, would be great!

I googled around this db problem and found that statement:

I do know that start-database and stop-database will not work because Embedded GlassFish does not bundle JavaDB.

Maybe the sun engineers will change their mind!

Michael Schuetz wrote on Dec 19, 2009 00:40:
3) a deeper package structure would be nice (something like ejb, model, controller or so) 4) OK, the example is pretty simple - and Yes, I know, you didn't have to much time for that and I truly appreciate that you want the community to take part asap.

Hello Michael,

Thank you for giving such detailed feedback. We greatly appreciate it. Regarding the package structure, we have a lot of debate interally about the size of the example. Archetypes are meant to be used by advanced users as well as beginners.

Generally an archetype consists of boilerplate code, which thankfully there is very little needed in CDI, as well as a POM an possibly a small hello world type application. Whatever example we put in has to be easy to delete so advanced users don't get annoyed and just clone our archetype and remove all the examples. Deleting 20 files is acceptable the first 10 or so times you use an archetype, but after you've built your 20th war, (as I can easily do in a year with prototypes), I fear our seasoned users would resent a rich example.

I don't believe the Maven community has come up with recommendations or best practices about the size of the starter application, so we can certainly make them richer if the community requests it. Do you have an opinion on the matter?

It is my opinion that our archetype example needs to be rich enough for you to confirm your POM works in your container. I always view the example applications as useful for QA more than teaching people best practices. The weld team has provided starter examples and are working on bringing the new Java EE 6 examples up to the high standard of quality that the Seam examples were. The examples are meant to teach you how to utilize the technology.

Of course, this project is done entirely for the benefit of the community, not the contributors. We make archetypes to make your job easier and you more productive. Community members such as yourself are doing us a huge favor by letting us know how we can make these archetypes more useful for you.

Thanks again for checking out our archetypes and helping us out with your feedback.

Steven Boscarine wrote on Dec 20, 2009 15:51:
...the archetype example needs to be rich enough for you to confirm your POM works in your container. I always view the example applications as useful for QA more than teaching people best practices.

Sorry, that sentence was poorly worded. I meant to say the example application generated by the archetype is meant more for QA-ing your POM and contianer whereas the weld examples are meant to teach you how to use CDI.

Deleting 20 files is acceptable the first 10 or so times you use an archetype, but after you've built your 20th war, (as I can easily do in a year with prototypes), I fear our seasoned users would resent a rich example.

Seasoned users would also take the project structure after they deleted those 20 files and make their own archetype out of it if they were that annoyed by it. ;)

Is there a way you can add like a clean flag, which will leave you without any stuff?

Drew Arrigoni wrote on Dec 20, 2009 19:04:
Is there a way you can add like a clean flag, which will leave you without any stuff?

...don't we wish!!! To my knowledge, there's no standard way to provide that sort of functionality. We've been contacting the folks at Maven to figure out just that sort of question. Obviously, if a reader has a good lead on that, please let us know and we'll do what we can. We'd love to be able to disable specific components like the examples, with flags. We'd also love to have flags for different platforms or container versions as well.

In an ideal world, we'd prefer to provide something that is useful to most of the developer community than encourage them to build their own. Ideally, developers should be solving business domain problems for their employers and not trying to figure out how to wire a POM to match their latest container point release. However, I fully understand that sometimes a developer can do a better job for their needs by writing their own archetype, but we're hoping they'll at least make a good faith effort to help us improve the archetype by providing suggestions.

This is great. I can't wait to see the Wicket archetype. It would be nice to have a more involved test. Maybe an integration test that involves the

WidgetListProducer.getWidgets()

method.

The WidgetRepositoryProducer has a comment saying weld will close the EntityManager? AFAIK Weld gives no special lifecycle management for the EntityManager. Are there any Docs about the relationship between weld and an EntityManager? In this example, since the EntityManager is retrieved using @PersistenceContext (not extended), isn't it going to close after a transaction completes, leaving you with a closed EntityManager stuck in the default (Conversation?) scope? Would a better example be to get the EntityManagerFactory and use a producer to retrieve the EM, and a disposer to close it?

Paul Mooney wrote on Dec 21, 2009 16:26:
It would be nice to have a more involved test.

I would like it too, but I don't see anything about integration test in Weld, actually. Maybe because we can use Weld-SE for our tests?

Hi Steven,

thanks for the reply.

The weld team has provided starter examples and are working on bringing the new Java EE 6 examples up to the high standard of quality that the Seam examples were. The examples are meant to teach you how to utilize the technology.

Sounds good. You're right. I was just excited about the new archetypes and the new possibility to see the big picture of Java EE 6 in Action. I know, it's a Weld archetype, no one for Seam 3.

I don't believe the Maven community has come up with recommendations or best practices about the size of the starter application, so we can certainly make them richer if the community requests it. Do you have an opinion on the matter?

A tiny starter app is absolutely fine. I think one Model in a simple CRUD-Context covers everything important to get started quickly: ejb,jpa,jsf (including navigation),cdi and the glue stuff

It is my opinion that our archetype example needs to be rich enough for you to confirm your POM works in your container.

I totally agree. And that's the reason I would like to see EJB3.1 in Action as well.

Keep up the good work!

Michael

The WidgetRepositoryProducer has a comment saying weld will close the EntityManager?

That's a reference to a bug in Weld. Weld isn't supposed to be doing that. I believe I put a reference to the bug report in the comment.

Alberto Gori wrote on Dec 21, 2009 18:36:

Paul Mooney wrote on Dec 21, 2009 16:26:
It would be nice to have a more involved test.

I would like it too, but I don't see anything about integration test in Weld, actually. Maybe because we can use Weld-SE for our tests?

There is no integration test because the integration test framework for Weld and Seam 3, Arquillian, is still a work in progress. It's possible to use it to write tests, but there is no release to Maven central, where the generated project is going to look for libraries. So you can be sure we will have integration tests coming in the archetypes soon!

But I didn't get it run in glassfish v3 embedded with your hints in readme.txt. Got it work after following glassfish embedded docu suggestions to add to pom.xml. (use target/test.war not test.war!) Maybe you can add this stuff to main pom until JBoss 6 embedded is flying or correct the readme for manual addition

Hmm, I'm a bit puzzled as to why the embedded GlassFish V3 setup doesn't work for you. The plugin should already be configured for you if you generate a jee-minimal or jee project. The configuration in the archetype is slightly different from the documentation you've cited, which I believe has errors in it.

Note that I have never gotten Maven to recognize the glassfish:run command. I have to use embedded-glassfish:run, which I think is the correct command for the plugin. I have yet to understand what the goalPrefix does, so I have omitted it from the configuration.

I did more research and I've determined that this goalPrefix configuration setting suggested in the Embedded GlassFish Documentation is a fallacy. The goal prefix for the maven-embedded-glassfish-plugin is embedded-glassfish (making the run command embedded-glassfish:run). The reason that goal prefix is selected is explained here.

Oh, I see. I had forgotten to add the maven-embedded-glassfish-plugin to the jee archetype. It is only in the jee-minimal archetype in 1.0.0-BETA1. I've added it to trunk.

Actually, we could probably put together a clean goal using the antrun plugin. It would clean out known resources that we added, probably just the Java classes. It would even be possible to pass this command in sequence with archetype:generate if you know ahead of time you want a clean project. Let's explore that, Steven. The antrun plugin could even remove itself after it finished (since Ant pretty much lets you do whatever you want, including regexp).

Having a clean target would all us to make the provided sample a little more fancy, just because it is a one step delete.

I don't think NetBeans is hot deploying individual beans. It's just copying the new class files into the in-place deployment archive and restarting the application when you save. This is really no different than a really streamlined, incremental builder (i.e., hot upgrade). Don't confuse that with hot swapping of classes at runtime, which is a much more complicated task.

As I said in my book, the term hot deploy is so overloaded that it's really hard know what behavior is really being referred to.

I try to run the project generated from the archetypes on embedded-glassfish.

This works fine with weld-jsf-jee-minimal.

But it does not work with weld-jsf-jee. First problem is that the maven-embedded-glassfish-plugin is not included in the pom (as stated by Dan above). But when I include the snippet from a pom generated by weld-jsf-jee-minimal, it still does not work. The error message is:

SEVERE: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener Has this something to do with the problem (discussed above) that the DB is not started?

Has anybody a some detailed instructions how to run the project generated with weld-jsf-jee in embedded-glassfish?

Thanks. jonas

Will the 1.0 version be released? The current archetype still uses JSF 2 RC dependencies..