Deepak Vohra has published an article on OTN that covers conversion of an EJB2 entity bean to an EJB3 equivalent, including a session facade for the entity, including a mechanism to generate the EJB3 bean via XSLT after adding some bits of data to the ejb-jar.xml.

It's an interesting idea (and a useful article!), and perhaps we J2EE developers should write a more generic tool that pulls relevant data from container-specific configuration files, too, just to eliminate the need to add data to ejb-jar.xml.

Interesting article; this will work fine for cases where uni-directional relationships are being used. However, the conversion appears to miss that under the Java Persistence API, bi-directional relationship management must be handled by the application itself. Therefore the remove() method on the session bean facade may need some additional code to update the relationship field in the "other" entity (or entities) that may be pointing to the entity being removed (so you don't end up with dangling pointers). The signature of the remove() method would need to take something like the primary key(s) of the other entity(ies) as an argument.

I should have mentioned that the relationship management thing I posted about earlier is not unique to EJB3/JPA, it's a characteristic that was inherited from Hibernate, etc. and is true if you're using basically any POJO-based persistence framework.

...under the Java Persistence API, bi-directional relationship management must be handled by the application itself.

1. Why to lock yourself in a ejb kind if technology which promises to be simpler going forward in every release and still doesnt seem to be.
2.Why do ejbs when spring and other simpler frameworks provide you transaction control, persistence etc etc.
3. Why spend days or months into ejb when things can be done in hours with other frameworks.
4. Why not use frameworks like spring which allo you to test any of your objects out of the container easily. Testing an EJB takes too long.

1. Why to lock yourself in a ejb kind if technology which promises to be simpler going forward in every release and still doesnt seem to be. 2.Why do ejbs when spring and other simpler frameworks provide you transaction control, persistence etc etc. 3. Why spend days or months into ejb when things can be done in hours with other frameworks.4. Why not use frameworks like spring which allo you to test any of your objects out of the container easily. Testing an EJB takes too long.

because EJB3 + JSF is going to be an industry standard

Hibernate 3 and some JDOs implement data persistence part of EJB3 interfaces. try to guest why ...

1. Why to lock yourself in a ejb kind if technology which promises to be simpler going forward in every release and still doesnt seem to be. 2.Why do ejbs when spring and other simpler frameworks provide you transaction control, persistence etc etc. 3. Why spend days or months into ejb when things can be done in hours with other frameworks.4. Why not use frameworks like spring which allo you to test any of your objects out of the container easily. Testing an EJB takes too long.

because EJB3 + JSF is going to be an industry standardHibernate 3 and some JDOs implement data persistence part of EJB3 interfaces. try to guest why ...

Is that joke of the day ? Who defines the standard to be jsf and ejbs ? and when is that gonna happen ?
whats jsf to do with ejb discussion anyway ?

1. Why to lock yourself in a ejb kind if technology which promises to be simpler going forward in every release and still doesnt seem to be. 2.Why do ejbs when spring and other simpler frameworks provide you transaction control, persistence etc etc. 3. Why spend days or months into ejb when things can be done in hours with other frameworks.4. Why not use frameworks like spring which allo you to test any of your objects out of the container easily. Testing an EJB takes too long.

because EJB3 + JSF is going to be an industry standardHibernate 3 and some JDOs implement data persistence part of EJB3 interfaces. try to guest why ...

I fell for that reasoning with ejb2. There is no reason to go with "industry standards". If the alternative tools are better and have a decent following (so they don't dissappear tomorrow) go with them. Spring and Hibernate meet this criteria.

I fell for that reasoning with ejb2. There is no reason to go with "industry standards". If the alternative tools are better and have a decent following (so they don't dissappear tomorrow) go with them. Spring and Hibernate meet this criteria.

I have fallen for that 'have a decent following so won't disappear torrow'. I have seen very widely accepted products disappear - sometimes so slowly that you don't realise the lack of support until it is too late. The nice thing about industry standards is that you get multiple vendors competing to provide quality implementations, which (in my view) can sometimes be healthier than having a single supplier for a popular product. This competition is happening with JSF and EJB 3.0.

Just because EJB 2.0 failed for some people does not mean there is any reason to reject other standards.

I fell for that reasoning with ejb2. There is no reason to go with "industry standards". If the alternative tools are better and have a decent following (so they don't dissappear tomorrow) go with them. Spring and Hibernate meet this criteria.

I have fallen for that 'have a decent following so won't disappear torrow'. I have seen very widely accepted products disappear - sometimes so slowly that you don't realise the lack of support until it is too late. The nice thing about industry standards is that you get multiple vendors competing to provide quality implementations, which (in my view) can sometimes be healthier than having a single supplier for a popular product. This competition is happening with JSF and EJB 3.0. Just because EJB 2.0 failed for some people does not mean there is any reason to reject other standards.

what good is the ejb "standard" if it is supported by multiple vendors , but it takes more than double the time and cost to build it.
We can build better sites in half the time even if we have to change the "open source" not so standard framework behind the scene.
I think a lot of people like you are stuck with "industry support " fashion bit too much that you ingore the learning curve, maintenance cost and complexity of ejbs.
   Also I m not advocating the millions of half baked ideas that show up on open source world every day. I m talking about Apache or Spring like initiatives coming from serious guys who have given much more to the community than SUN and IBM ever did. Fact that Xalan and Xerces have become defacto standard are from open source Apache is a very good example. Tomcat is used in most of SUN server now a days.
Same wiht spring - you read it, understand it and then you relaize that its a whole new world and not just new "spec" like EJB. All EJB has done after 1.0 version is to complicate it. ITs digging its own grave and I m glad its on the way to the cemetary.

what good is the ejb "standard" if it is supported by multiple vendors , but it takes more than double the time and cost to build it.

Have you tried EJB 3.0? Or a similar persistence standard that I prefer - JDO? Talk of 'double the time or cost' simply isn't true. EJB 3.0 is close to Hibernate - would you say "Hibernate takes more than double the time and cost"?

I think a lot of people like you are stuck with "industry support " fashion bit too much that you ingore the learning curve, maintenance cost and complexity of ejbs

On the contrary - I think my 'industry support' view seems to be rather unfashionable (and certainly not 'cool'!). There are many standards, and I would not advocate only using standards regardless of the cost or complexity. My view is that when there is a choice, go with the standards. This is in contrast to stating that there "is no reason to go with industry standards", as one of the ancestor posts did. Of course there are - good reasons - but not at any cost.

All EJB has done after 1.0 version is to complicate it. ITs digging its own grave and I m glad its on the way to the cemetary.

Oh come on! There is little or no evidence that EJB is seriously declining in use - just wishful thinking from those who don't like it. EJB 3.0 is a dramatic change and has most of the advantages of Hibernate and JDO - so it looks like EJB persistence has a very healthy future.

what good is the ejb "standard" if it is supported by multiple vendors , but it takes more than double the time and cost to build it.

Have you tried EJB 3.0? Or a similar persistence standard that I prefer - JDO? Talk of 'double the time or cost' simply isn't true. EJB 3.0 is close to Hibernate - would you say "Hibernate takes more than double the time and cost"?

I think a lot of people like you are stuck with "industry support " fashion bit too much that you ingore the learning curve, maintenance cost and complexity of ejbs

On the contrary - I think my 'industry support' view seems to be rather unfashionable (and certainly not 'cool'!). There are many standards, and I would not advocate only using standards regardless of the cost or complexity. My view is that when there is a choice, go with the standards. This is in contrast to stating that there "is no reason to go with industry standards", as one of the ancestor posts did. Of course there are - good reasons - but not at any cost.

All EJB has done after 1.0 version is to complicate it. ITs digging its own grave and I m glad its on the way to the cemetary.

Oh come on! There is little or no evidence that EJB is seriously declining in use - just wishful thinking from those who don't like it. EJB 3.0 is a dramatic change and has most of the advantages of Hibernate and JDO - so it looks like EJB persistence has a very healthy future.

If you still dont know that EJB use has gone down drastically in last 2 years, then there is no need for me to comment further any more.
Continue living in your own fantasy world and good luck with the ejb 3.0.

If you still dont know that EJB use has gone down drastically in last 2 years, then there is no need for me to comment further any more. Continue living in your own fantasy world and good luck with the ejb 3.0.

Where is your evidence that EJB use has gone down? Honestly - I am interested - all I see is a huge and continuing demand for these skills. I see new J2EE projects being released (Geronimo), and increasing use of J2EE application servers.

You still have not addressed the matter of the similarity of EJB 3.0 persistence and Hibernate, and how you are able to say that one is a major time-saver and not the other.

If you still dont know that EJB use has gone down drastically in last 2 years

Do you have documentation for such a claim? You responded to someone stating there was "little or no evidence" - if you have some evidence, spill it!

Just because the industry hype-machine has pushed other technologies doesn't mean EJB is dead among developers. Empty barrels rattle the most and all that.

I also think your claim that EJB3 takes longer time than the others is simply a reflection of your own unwillingness to learn something new, so you factor the learning "cost" into EJB3 without thinking over that learning Hibernate etc. represent costs as well. There isn't anything harder in adding @Table and @Id to a POJO than writing an XML mapping for a class when using Hibernate.

what good is the ejb "standard" if it is supported by multiple vendors , but it takes more than double the time and cost to build it.

Have you tried EJB 3.0? Or a similar persistence standard that I prefer - JDO? Talk of 'double the time or cost' simply isn't true. EJB 3.0 is close to Hibernate - would you say "Hibernate takes more than double the time and cost"?

I think a lot of people like you are stuck with "industry support " fashion bit too much that you ingore the learning curve, maintenance cost and complexity of ejbs

On the contrary - I think my 'industry support' view seems to be rather unfashionable (and certainly not 'cool'!). There are many standards, and I would not advocate only using standards regardless of the cost or complexity. My view is that when there is a choice, go with the standards. This is in contrast to stating that there "is no reason to go with industry standards", as one of the ancestor posts did. Of course there are - good reasons - but not at any cost.

All EJB has done after 1.0 version is to complicate it. ITs digging its own grave and I m glad its on the way to the cemetary.

Oh come on! There is little or no evidence that EJB is seriously declining in use - just wishful thinking from those who don't like it. EJB 3.0 is a dramatic change and has most of the advantages of Hibernate and JDO - so it looks like EJB persistence has a very healthy future.

If you still dont know that EJB use has gone down drastically in last 2 years, then there is no need for me to comment further any more. Continue living in your own fantasy world and good luck with the ejb 3.0.

Are you sure you're referring to EJBs in general or entity beans? You know SLSBs and MDBs are very much alive and have never really lost steam. In fact, a lot of the noise about how tedious/hard it is to do EJBs are really not true if you spend some time in setting up a framework for it. In our case, our framework is actually setup so all we have to do is annotate our interfaces and let xdoclet (with customization of course) do the rest like generating all the necessary interfaces, implementation (with skeletons) and deployment descriptors. In fact, once EJB3 rolls out, we dont even have to change our code, just the framework that does the generation and then <code>ant clean-build</code> and we're done.

OK, I'll take the bait :)

1. Why to lock yourself in a ejb kind if technology which promises to be simpler going forward in every release and still doesnt seem to be.

Because with EJB3 you aren't locking yourself into anything. EJB3 and Java Persistence API objects are POJOs so you can use and test them anywhere, inside or outside a container.

2.Why do ejbs when spring and other simpler frameworks provide you transaction control, persistence etc etc.

Because EJB3 with Java Persistence API is now just as simple to use (simpler once you add transaction control into the mix) as the other frameworks, and is available from more than a single vendor so you have a choice of implementations (in case something goes wrong).

3. Why spend days or months into ejb when things can be done in hours with other frameworks.

Because you can do the same thing on EJB3 and JPA in hours...and as a bonus you then don't need to spend any time installing the other frameworks.

4. Why not use frameworks like spring which allo you to test any of your objects out of the container easily. Testing an EJB takes too long.

Because EJB3 and JPA let you do all the same testing outside the container, and are already available without installing additional frameworks.

Moreover, you don't have any open source component dependency in your mission critical code. It is all J2EE compliant.

A big plus on evolution and maintainability perspective of any architecture.

Cheers

Gurvijay

I think the point of Spring and designing applications for IS that you design coherent and infrastructure-free Domain Object Model using POJOS. You are tied to Spring through interfaces (e.g. the DAO layer), and only the implementations of those use Spring templates and utilities. So the question: why choose Spring if it will probably die and EJB3.0 will be god is really of little importance. IF this would happen, then it will be very easy for you to migrate your DOM to another platform, be it EJB3.0 or something else.

So the question: why choose Spring if it will probably die and EJB3.0 will be god is really of little importance.

This is a very narrow point of view. Why do you assume that the only use of Spring, with all it's rich facilities, is for use with J2EE persistence? Dependency Injection, configuration, and other things that Spring can do are great for general development, in J2SE as well. EJB 3.0 is no threat to Spring.

I would like to learn more on Converting an EJB2 entity bean to EJB3

buffalo freelance web designer

the convertion is seamless i hope

 the stork club movie