The Official FAQ for the Pitchfork Project
Q. What is Pitchfork?
Pitchfork is an add-on for the Spring Framework performing JSR-250 (Common Annotations) dependency injection and EJB 3.0 style interception. It was developed by Interface21 and BEA under the Apache 2.0 open source license.
This project is currently used within the WebLogic Server Tech Preview released at JavaOne, 2006. It will be used in the production version of Web Logic Server (WLS) to implement Java Enterprise Edition (JEE) 5. It is also usable outside an application server as an add-on to the Spring Framework.
Q. Where is this project hosted?
Pitchfork is currently available from SpringSource. It is published under the Apache 2.0 License.
Q. How will Pitchfork benefit end users?
WebLogic users will be able to mix the JEE5 and Spring programming models in their applications. As the code is open and published under the Apache license, it is possible that other application servers may follow BEA's lead in offering such interoperability. It will also be possible to use components with JEE5 annotations in Spring applications running in any environment, and have those annotations recognized by the Spring container.
The prime motivations for this project are:
Q. Is SpringSource and the Spring team endorsing the EJB 3 programming model?
No. We are doing exactly what we have always done: enabling developer choice. We are endorsing Spring as a means to support EJB 3.0.
Since its inception Spring has supported EJB development for the cases where EJB adds value. This project provides developers the ability to mix the EJB 3.0 and Spring programming model, by deploying JEE-annotated classes in a Spring environment, or using Spring to provide more powerful injection and AOP functionality to EJB 3.0 components running inside an EJB container. We still believe EJB does not add value for the majority of cases and that a pure JEE + Spring solution is generally the better choice.
You can expect SpringSource to continue to innovate and lead with the Spring Framework 2.0, which raises the bar for true POJO programming while retaining compatibility with the Spring 1.x series. With Spring, developers are able to tap into a wealth of integration power inside and outside of a managed JEE5 environment, seamlessly. From test, to web, to desktop, EJB 2.x, and now to EJB 3.0, Spring works everywhere.
Q. How does SpringSource and the Spring community benefit from this?
BEA chose Spring as a foundation for their JEE5 implementation--a strong endorsement of the Spring model and implementation. WebLogic Server is an important, high performing, respected product with a very large user base and history. Many consider it to be the best application server available. We are proud to play this key role in its next generation.
We believe this project proves the power of Spring. The Spring core was usable by BEA as is to implement the necessary EJB3 functionality. Given this we believe Spring will also be used to implement other annotation-based injection models, such as that in Service Component Architecture (SCA).
Q. So what is the best programming model?
We believe experience has proven that the best programming model is one in which true POJOs are able to interact with any container in a transparent, non-invasive fashion.
In this respect, EJB 3 is generally invasive and limited in granularity where Spring is not, to the extent that it is reasonable to say there is a distinct EJB 3 programming model while there no need for a distinct Spring programming model. EJB 3.0's dependency injection and interception capabilities are limited in comparison to existing Spring 1.x capabilities while being less transparent. The EJB 3 interception model fails to achieve the goals of a general AOP solution and is both invasive and weak.
Using Spring allows writing clean, POJO based, object-oriented code across a range of environments, with dependency injection and other value-added services provided by the container transparently. Fundamentally, these are the things that IoC and AOP enable when implemented properly.
We believe that any statements to the effect that "EJB 3 can substitute for Spring" are a false play. There is evidence a great deal of people agree, some with significant investment in EJB. Consider Oracle as an example, which is basing its Service Fabric on Spring 2.0.
The existence of other models such as SCA is proof enough that EJB is not considered sufficient by many as the only model for programming in the J2EE space. Therefore we feel that any statements from those who promote such a "black and white" approach should be taken with a grain of salt, and scrutinized for hidden agenda, as they may not be made by those whose main concern is the most appropriate solution for the actual end users.
Q. Is this part of the Spring core?
No. Full JPA container support is part of the Spring Core. This includes the @PersistenceContext and @PersistenceUnit injection annotations that are specific to JPA rather than generic injection from the JNDI environment. Pitchfork comprises support for JSR-250 Common Annotations as well as portions of the JSR-220 EJB 3 spec such as JSR-220 Interceptors.
Q. Who is the project team?
The project lead is Rod Johnson. The other developers are Michael Chen (a member of the WebLogic EJB team since 1999) and Costin Leau (SpringSource).
Q. How is this used by WebLogic?
This is a library used to deliver part of WLS 9.x functionality. This project is used in the core of WebLogic (wherever injection and interception is now required -- not just in the EJB container), but is separate from the WebLogic codebase proper.
Q. Is Spring becoming increasingly tied to BEA/WebLogic?
No. This code works in any environment, and we hope it will be used as the basis of other EJB 3 implementations. BEA have been happy to co-develop these in Apache License, showing that they want this to be open.
Q. Can I use this outside WebLogic?
You can use the core annotation processing support in any environment. If you run it in a WebLogic environment it can work together with all the proven elements of the WebLogic platform. There is a clean interface between this code and any potential hosting platform, such as WebLogic or a pure Spring environment.
Q. What about portability? Is this project's code tied to Web Logic Server?
BEA has chosen an open extension technology. They are not looking to build lock-in. Other JEE5 vendors/implementers are encouraged to reuse this code and at least one has expressed interest.
Q. Will Spring become an EJB container?
No. This is an add-on project for Spring which implements many of the constructs of Java EE 5 (many of which are split from the EJB specification proper). Those constructs are implemented to follow the semantics laid down by the specification. WebLogic provides a full EJB container, building on the Pitchfork project. Other EJB container vendors/implementers are welcome to use this same codebase for their EJB 3 implementations.
Q. What about EJB 3.0 persistence?
JPA (Java Persistence API) is the object-relational mapping specification created as a product of the EJB 3 (JSR-220) working group. It is effectively a separate spec from the container portion of the EJB 3 specification, with JPA usage possible from both JSE and JEE applications and no requirement on use from within EJBs.
The Spring Framework embraces JPA. We believe a standard for O/R mapping offers the very important choice of persistence provider implementation. In Spring 2.0 RC1 and above we believe that Spring will be the best environment to run JPA data access code in any environment. We provide ways to access functionality implemented by all providers yet not defined by the specification.
Spring can provide a full managed environment for a JPA persistence provider in any environment: web container, application server, standalone application, or test case.
Spring does not do O/R mapping itself, nor does it try to abstract fundamental O/R mapper APIs. What it offers is consistent abstractions for accessing most O/R mapping frameworks, eliminating boilerplate and error-prone code related to resource handling and exceptions.