On Jun 13, 2010, at 12:47 AM, Jacek Laskowski wrote: > On Sun, Jun 13, 2010 at 4:15 AM, David Blevins <[email protected]> wrote: > >> A much larger vision is that I'd really love to take EJB and break it up >> into tiny little pieces. It's difficult to describe without writing a big >> manifesto. I in fact have one that I started in July last year but never >> finished an never published. I went ahead and published it anyway: >> >> http://blog.dblevins.com/2010/06/if-software-is-pizza-ejb-is-house.html >> >> I don't think it adequately expresses the conecept, but it's a start. > > I've read the blog entry and it was a thought-provoking reading which > I loved. Following your metaphor(s), it was kind of having seen a > pizza without having been able to taste it :)
Hehe. I'm going to have to order some this weekend. > I'm too thought about > something similar and was wondering what the starting point would be - > there should be some kind of a DI container and the rest would be > injected at appropriate places. Is XBean what fullfils the > requirements? I don't know, but that's absolutely the right question to be asking. It's the big one in my mind as well. At some point I'm going to have to take a hard look at Guice. > I'd love if OSGi was somehow involved that could mean > OSGi+DI should be somehow merged and become THE starting place for the > rest. Better support for OSGi than we have now would be great. > Would you elaborate a bit more on the following: > > "All is fine until your bean throws a runtime exception and the > container decides to rollback the current transaction on your behalf." > > Why is it an issue? Why would I not want to have it? What's the scenario? The issue is that it isn't POJO behavior. It's a good feature, but should be one that is added. What I imagine is that a user starts with a POJO. It's simple and has no learning curve or "hidden" behavior. No specs to read. As they have need for a bit of functionality, they can add the related annotation. At that point they just need to learn and understand that annotation; what functionality it brings and what restrictions might come with that functionality. Development continues iteratively like this and the user adds annotations as they have need for them and time to learn them. You get what you want and use, no more and no less. EJB is somewhat like this already, but there are however many things that you get without asking and may not want. In some cases there are ways to disable functionality and in some cases not -- such as the whole "beans are destroyed if they throw an exception". Regardless, it does create a model where you have to learn everything up front so you know what parts you don't need and how to remove them. A very elegant way to disable something is to (big surprise) stop enabling it. It also creates code that is more self describing when you can see the annotations that affect it. It's great to have things turned on automatically for the people that are on the other side of the learning curve and don't want to have to go about explicitly enabling things every time they make a new object. But there are even more modern ways to do that as well. For example this should be possible: http://blog.dblevins.com/2010/06/ejb-annotations-and-stereotyping.html -David
