Group items tagged

Weld is the reference implementation (RI) for JSR-299: Java Contexts and Dependency Injection for the Java EE platform (CDI). CDI is the Java standard for dependency injection and contextual lifecycle management, led by Gavin King for Red Hat, Inc. and is a Java Community Process (JCP) specification that integrates cleanly with the Java EE platform. Any Java EE 6-compliant application server provides support for JSR-299 (even the web profile). Weld and the JSR-299 TCK (Technology Compatibility Kit) are developed here at seamframework.org. Both are licensed under the Apache License, Version 2.0.

"Stop using Tomcat and wondering why JEE "doesn't work." You're doing yourself a big disservice. Start thinking about JBoss AS 6, or GlassFish v3 - Yes, I know, it's a "Full JEE Container," - it's "Heavy," but with JEE6, that's not a bad thing: It all "Just works" and it works really well. Trust me, the reason people have thought Java EE sucks, is because they try to do this stuff on Tomcat, and say "Why doesn't (JPA, JMS, JTA, EJB, JSF, CDI) work?" Well… that's because Tomcat only gives you Servlet - the Request/Response lifecycle. So people install all these things manually, or try to, and then say, "Wow, Java EE is really hard to use, shit, I'm gonna use Spring or Grails instead.""

A library of Generally Useful Stuff (tm) for developing applications, extensions or frameworks based on CDI (JSR-299: Java Contexts and Dependency Injection). A swiss army knife for CDI extension writers.

Special thanks to Piero Sartini who came up with this alternative. It is basically the same as the previous alternative, but it uses the new JEE6 Context and Dependency Injection (CDI) and session scoped beans instead of EJBs. This alternative should have better performance than using EJBs. Instead of annotating the Vaadin application as a stateful session bean, it should be annotated using the @SessionScoped annotation, like so:

" Brings transactions and persistence to managed beans, provides a simplified transaction API and hooks transaction propagation events to the CDI event bus."

"Seam 3 is collection of modules and developer tools based on the Java EE platform. The modules are portable extensions to CDI that integrate with other technologies to extend the core Java EE functionality. These modules bring you many of the beloved features and integrations from Seam 2 (security, internationalization, JSF, rules, business process management) and also branch out into new areas. IDE support is provided by the JBoss Tools Eclipse plugins. Before diving in, get up to speed with the status and direction of Seam 3. Also be sure to check out the latest news at the bottom of the page. "

Does it all make sense now? Do you know how to solve every problem? Probably not, but when it comes right down to it, using Java EE can be even simpler than using Spring, and take much less time. You just have to find the right guides and the right documentation (which is admittedly a severe sore-spot of Java EE; the documentation is still a work in progress, but is getting much better, save blogs like this one.) You have to turn to a vendor like JBoss, or IBM in order to get the use-case driven documentation you need, and they do have documentation, it's just a matter of finding it. Seam 3 in particular strives to give extensive user-documentation, hopefully making things much simpler to adopt, and easier to extend. The main purpose of this article was not to bash Spring, although I may have taken that tone on occasion just for contrast and a little bit of fun. Both Spring and Java EE are strongly engineered and have strong foundations in practical use, but if you want a clean programming experience right out of the box - use Java EE 6 on JBoss Application Server 6 - JBoss Tools - and Eclipse. I will say, though, that the feeling I've gotten from the Spring forums vs the Java EE forums, is that there are far many more people willing to help you work through Java EE issues, and more available developers of the frameworks themselves to actually help you than there are on the Spring side. The community for Java EE is much larger, and much more supportive (from my personal experience.) In the end, I did get my application migrated successfully, and despite these issues (from which I learned a great deal,) I am still happy with Java EE, and would not go back to Spring! But I do look forward to further enhancements from the JBoss Seam project, which continue to make developing for Java EE simpler and more fun. Don't believe me? Try it out. Find something wrong? Tell me. Want more? Let me know what you want to hear.

Arquillian enables you to test your business logic in a remote or embedded container. Alternatively, it can deploy an archive to the container so the test can interact as a remote client. The mission of the Arquillian project is to provide a simple test harness that abstracts away all container lifecycle and deployment from the test logic so developers can easily produce a broad range of integration tests for their enterprise Java applications. Arquillian is part of the JBoss Testing initiative, an umbrella project focused on providing a comprehensive testing tool set for application developers. Arquillian can either execute a test case inside the container, in which case the test class is deployed by Arquillian along with the code under test, or hold back the test class so it can act as a remote client to the deployed code. All the developer has to do is write the test logic. In short... Arquillian makes integration testing a breeze!