|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?
we agree on the metaprogramming, we are going to make it dynamic too, some other day I will publish a white paper :) Let Rickard fire first marcf | |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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
