Amen. FWIW, I think the major advantage of the EJB framework over e.g. using JDO is that, especially in the jboss environment, it is very simple to do (limited) meta-class programming. The EJB spec uses this for transactions and security, Scott uses it for Security Proxies, I have used it to apply rules to method invocations. The possibilities for this have barely begun to be scratched. On the other hand this is what you get with any interceptor based invocation architecture-- so why _are_ ejbs so good anyway?
david jencks On 2001.11.14 12:21:16 -0500 marc fleury wrote: > kids, > > we are hearing a lot of talk about EJB and not EJB and blabla bla. Well > I > will say that I am a big fan of the framework, for reasons that even our > favorite aliens are missing ;-) but that is another thread. > > The reason I want EJB to take a backseat in the "LAYOUT OF THE CODE" is > that > I believe we need to separate what is spec derived, spec dependent and > what > is "good software" in general. Most notably there are very large project > out there (Las Vegas IGT for example) that at first were using the JMX > base > and management of JBoss to build complex systems and the RH JBoss3.0 view > is > clearly targeted at these folks, large ISV shops using JBoss in high end > complex applications. The JMX view and what we do with it, needs to be > clearly expressed as independent of the EJB spec. Interceptors and the > packaging/distribution that we do, the microkernel view, all that is > knowledge that is not EJB specific. > > Right now everythign seems to be under org/jboss/ejb and > org/jboss/ejb/plugins when really we are largely BEYOND the ejb spec and > it > applies to a wider and more generic category of problems than just EJB. > In > fact I am starting to suspect that the EJB part of our code, the really > dependent part is <20% of the total code today. Which is really > negligeable. The smart ones in you will see where I am going with this. > If > not you will see. > > BOTTOM LINE: I want you guys to start wiring what is not EJB specific > into > more generic packages. Ex: the Invocation I just commited, the > MethodINvocation should be outside it is just dependent on the > EnterpriseContext and teh EC is just a wrapper for instances in Cache. > what > is really EJB dependent should at the end of the day be seen in the > imports > at once and it should be factored out. Meaning if it isn't dependent on > the > spec but derived from largely known computing practices (heck the state > machine view of JMX was first put forth by Alan Turing :) > > Again, this is not a reflexion on the value of EJB, I will start > seriously > evangelizing my love of EJB as system construct which is something I > cover > in the trainings already, JMX is just generic and independent of this, > the > microkernel view is generic and independent, the packaging we do is > generic > and independent... > > You get it. > > marcf > > xxxxxxxxxxxxxxxx > Marc Fleury > President > JBoss Group, LLC > xxxxxxxxxxxxxxxx > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
