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
