Printable View
See the pitchfork project - it offers EJB3 semantics on top of Spring. Also, JPA is fully supported by Spring (both through annotations and XML).
However, as Colin pointed out, and depending on your requirements I would advice against tyeing your objects to particular frameworks (including Spring). With EJB3/JPA this comes down to the annotation vs XML argument in the end :).
So any object that uses Spring annotations (like @Transactional) aren't POJOs? Even if they are never interpretted? I guess it depends on what you mean by depends. Certainly classes with EJB3 annotations require those annotations to be present to load that class. But if they are executed in an environment where those annotations have no meaning (like a vanilla Spring container) aren't they still POJOs?Quote:
Originally Posted by yatesco
I don't think annotations specify functionality. Much like a marker interface doesn't. They are just there. They need an execution environment to interpret them. The fact you can port a EJB3 annotated object to Spring-based Pitchfork sort of highlights this. Also you could port such an object using XML and the presence of the annotations wouldn't mean anything. You could delete the annotations and merely limit the objects ability to properly execute in an EJB3 container, but would still execute in environments which didn't depend on them (like the mentioned XML and the unit test)
This is a whole other debate about annotations, but @Transactional is arguably providing meta data about the project, it is not instructing the container on how to execute it, merely what services it requires. The EJB annotations (@Stateless, for example) provide instructions on how to implement the object, and the POJO is incomplete without it. It is a subtle, but important difference. @Transactional does not belong to any framework....OK, it is defined by Spring, but it is not referring to Spring specifically, it is describing a characteristic of the bean. The EJB ones on the other hand are absolutely depending on a 3rd part framework; the ejb framework.
Another way of looking at it is that you are writing an EJB which can arguably be used outside an EJB container....POJOs are all about the POJOs.
Can you "new up" an EJB and provide all the dependencies via setter inject....yes. Does that make that EJB a POJO, absolutely not. Is it re-usable, encapsulated etc. Can that EJB be re-used in different environments, etc. Not at all, using annotations to specify runtime conditions/environment is just a fundamental mistake.
Also, bear in mind that an EJB3 bean assumes that all the annotations will be processed and honoured, you could re-use the bean outside of the container, but what would it's behaviour be? Proper use of annotations (I believe) do not add any extra functionality to the POJO, they merely describe meta data about the bean....loosing those annotations should not prevent the bean being used for it's original purpose.
Like I said, if people started writing POJOs and then decorated them into EJB3s that wouldn't be so bad, but people won't do that, they will write EJB3s and then consider them POJOs as a secondary (if at all) concern.
I should also put a big disclaimer on all of my thoughts....I really haven't thought these things through that much, they are at the level of "gut feelings" so feel free to shoot me down in flames ;)
Hi Collin,Quote:
Originally Posted by yatesco
I just see your argumentations about annotations in POJOs and I wanted to share my opinions with you and others Spring Team and users.:)
I am fully with what Bill (wpoitras) explain concerning annotation and marker interface: they dont specify functionnality. But you can use it to add or change POJO functionnalities, or ignore it.
The real debate is Annotation vs XML binding... I prefer Annotation and I am still waiting Spring team to put that in his top priority.
You said:
That is wrong from smart java developers. They give precedence to model design before looking at the persistence constraint/model. If you consider an EJB3 Entity bean, it is a POJO (with or without annotation). You add annotation, to give enough information, to do the crud operations behind the POJO, by the Persistence manager(PM). If there is no PM in your environment, your EJB3 entity POJO can still be used as any other POJO with no constraint on the environment. This is also true for the EJB3 sessions.Quote:
Like I said, if people started writing POJOs and then decorated them into EJB3s that wouldn't be so bad, but people won't do that, they will write EJB3s and then consider them POJOs as a secondary (if at all) concern.
So, what we developers need, is support for specialized operations on those POJOs:
- DI
- Persistence
- Transaction
- other specialized services
SpringFramework2.0 is potentially the best container, for those needs. But it lacked java oriented interface, at the beginning, and the new solutions Spring Team are taking out today (Pitchfork, spring-javaconfig packages) are the way to go, without a doubt. They are very timid in that offer and they are continuing to market the fact that XML binding is the best way to achieve the needs of java developers. I think XML binding is usefull and complementary for infrastructure configuration. But can't in my feeling be the preference of smart java developers.
Spring have demonstrated the way to simplify the JEE development process, but don't forget that before Spring, IOC was for long time handled by Apache offer named Avalon, and other IOC-like framework. But their environment was so tedious and difficult to implement and use until Spring offer. So many java developers sense what they want to benefit from those IOC containers.
If the Spring Team don't give quickly all the support for their actual java developers to integrate spring artifacts via annotation, they will loose the community interrest in favor of solutions like glassfish, geronimo, and JBoss.
There are many reasons for that :
1. For java developer, coding by XML is a constraint, and they are more confortable in java code.
2. They don't want to manage 2 sources of specification. Annotation is the way to centralize all the specs in on source
3. XML binding is more complex for java programmers than the Spring Team may think. There is a learning curve to master the spring xml config files
4. The springframework 2.0 is builted on a dying java 1.3 1.4 plateform, to support big corporations unable to switch quickly to java1.5+. That code can't be as optimal as a code written exclusivelly for java 1.5+.
5. Open source Developpers will prefer to select new containers to take avantage quickly of new technology.
In conclusion, It must be left to developers to say if annotated POJOs is POJOs or not. Their judgement will come from the expected runtime behavior of their favorite container.
Today My preferences have moved from:
- Hibernate, Spring, Tomcat
to
- glassfish, Toplink-essentials, [Spring]
but I hope to end with functionnal (in full EJB3 container)
- Spring(Pitchfork+JavaConfig) + Toplink-essentials
regards.