I couldn't agree more. When I first started reading the code, It was hard to sperate the EJB sepecific stuff from the rest. I think this will help up out alot.
-dain > -----Original Message----- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 11:21 AM > To: Jboss-Development@Lists. Sourceforge. Net > Subject: [JBoss-dev] Separating JMX/EJB > > > 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
