RE: [JBoss-dev] Separating JMX/EJB
|I intend to write a whitey on it some day too, but basically it goes |something like this: |* Meta-programming is good, but not inherent to EJB true, but a sophism You are intelligent, but intelligence is not inherent to Rickard Oberg (I am intelligent as well), does that make Rickard Oberg dumb? |* The EJB programming model in general is flawed. (See EJB-INTEREST for |lots of conflicting answers to common questions. If experts can't figure |it out, how are mortals supposed to?!) could it be because experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses? I think so. Anyway when you really make your points, make sure to be specific about the model in general :) that's not going to cut it. |* In particular, dynamic (re)configuration of EJB is not possible, and |it should be (compare with JMX/Jini) false |* The EJB persistence model is flawed, compared with JDO. true boloney, sliced thick, with peanuts in the middle, will end up as chunky 2c toilet wisdom marcf | |/Rickard | |-- |Rickard Öberg | | |___ |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
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: |I intend to write a whitey on it some day too, but basically it goes |something like this: |* Meta-programming is good, but not inherent to EJB true, but a sophism You are intelligent, but intelligence is not inherent to Rickard Oberg (I am intelligent as well), does that make Rickard Oberg dumb? What an utterly stupid remark. What I meant was: MP is good, EJB has it, but it's not the only way to get MP. |* The EJB programming model in general is flawed. (See EJB-INTEREST for |lots of conflicting answers to common questions. If experts can't figure |it out, how are mortals supposed to?!) could it be because experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses? I think so. Anyway when you really make your points, make sure to be specific about the model in general :) that's not going to cut it. What utterly stupid remarks. Marc, Marc, time to return to reality, yoh, we're over hree |* In particular, dynamic (re)configuration of EJB is not possible, and |it should be (compare with JMX/Jini) false Because..? 1) Bean A uses bean B. B dies, but C that implements the same interface is still alive. Now what's A supposed to do? How will it be notified that B is dead, and how is it supposed to find C? (with hardcoding these dependencies in of course) 2) Bean A stores files in a particular directory. The name of the directory changes. A needs to be alerted of this. How? Change the XML file with environment settings and redeploy? Gee.. great... |* The EJB persistence model is flawed, compared with JDO. true boloney, sliced thick, with peanuts in the middle, will end up as chunky 2c toilet wisdom Thanks for your input, you really helped show why EJB is good, or rather, why my reasons to not use EJB are false. Thanks again. Now back to our regular programming. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
|What an utterly stupid remark. Laaa laa la laa laaa laa ! ( I am not listening ) |What I meant was: MP is good, EJB has it, but it's not the only way to |get MP. La! la ! la! la! la! la! | could it be because experts are donkey-dick-sucking-monkeys that don't | know their ass from their tinny winny pinuses? I think so. |What utterly stupid remarks. Marc, Marc, time to return to reality, |yoh, we're over hree Me gna! you gna! La La Laaa L! |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. |Thanks for your input, you really helped show why EJB is good, or |rather, why my reasons to not use EJB are false. Thanks again. | |Now back to our regular programming. Come to our trainings :) we really go down and dirty with the persistence, the finders, the metaprogramming and the semantics of EJB. It is all kosher. You should really come in London, snore marcf | |/Rickard | |-- |Rickard Öberg | | |___ |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
RE: [JBoss-dev] Separating JMX/EJB
|Hehe.. you're so screwed... awhh.. why do I even bother.. :-) As much as I really love to argue with you I really want to work on RH and put it out, but these discussions are down the road, really I extend the invitation again, I will try to get you to come to one of the trainings. |Alright, you may have a point, but it's not really valid until it gets |implemented *well*. sure. It is not there yet, if the point is valid (meaning people really ask for it) then it might see the light of day. |So you'd need to go outside EJB for such a common requirement as runtime |reconfiguration? Is that good? JMX isn't bad. We like it :) it might become a part of the J2EE spec (it should) so there you have it. |like EJB, is because it's overused. People use it for things they |shouldn't use it for, especially for web applications where the web |client and EJB's are in the same JVM. And you still need to go through |the remote interface, thus introducing a whole bunch of heavyweight |patterns such as Data Transfer Objects. The weight of the container is minimal, it is serialization that is heavy, but really that's enough for today we will take it again down the road kid, thanks for your attention marcf | | |/Rickard | | |-- |Rickard Öberg | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: |What an utterly stupid remark. Laaa laa la laa laaa laa ! ( I am not listening ) Hehe.. you're so screwed... awhh.. why do I even bother.. :-) |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. Well, EJB's can't use Jini (can't hold on to a ServiceDiscoveryManager for example). If you want the proxies to do the failover, which would be entirely possible, you need to be able to let them point to many various instances of possibly different implementations. I guess the EJB interface/spec in itself would allow for this, but it would require quite a lof of the EJB container, as opposed to a rather simple hack in JMX/Jini. Alright, you may have a point, but it's not really valid until it gets implemented *well*. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. So you'd need to go outside EJB for such a common requirement as runtime reconfiguration? Is that good? Sorry, but it's still bad. However, one of the key reasons why I don't like EJB, is because it's overused. People use it for things they shouldn't use it for, especially for web applications where the web client and EJB's are in the same JVM. And you still need to go through the remote interface, thus introducing a whole bunch of heavyweight patterns such as Data Transfer Objects. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
Sorry to chime in so late, but I have a few comments... Firstly, from Rickard. I intend to write a whitey on it some day too, but basically it goes something like this: * Meta-programming is good, but not inherent to EJB * The EJB programming model in general is flawed. (See EJB-INTEREST for lots of conflicting answers to common questions. If experts can't figure it out, how are mortals supposed to?!) Every programming model is flawed. The same thing is happening to EJB as did CORBA as it matures. These so-called experts you talk about get in there and beef up a rather simple specification to support all of their esoteric use cases. What these experts end up doing making these specifications more resitant to change and the industry ends up having to think of another programming model. I saw this crap when I was in the CORBA world. I agree with Marc. These experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses.(Thanks for the humor Marc, I really needed it.) Nextly |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. Well, EJB's can't use Jini (can't hold on to a ServiceDiscoveryManager for example). If you want the proxies to do the failover, which would be entirely possible, you need to be able to let them point to many various instances of possibly different implementations. I guess the EJB interface/spec in itself would allow for this, but it would require quite a lof of the EJB container, as opposed to a rather simple hack in JMX/Jini. Actually, it would not require a lot of the container. Sacha Labourey and I have developed a pretty simple framework to provide fail-over and load-balancing for EJBs. Basically, we've integrated JavaGroups into this framework and will eventually see if JINI/JavaSpaces can fit in as well. Alright, you may have a point, but it's not really valid until it gets implemented *well*. Well, it is implemented. Go check it out. It's probably flawed, but it will do the job for now. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. So you'd need to go outside EJB for such a common requirement as runtime reconfiguration? Is that good? Sorry, but it's still bad. However, one of the key reasons why I don't like EJB, is because it's overused. People use it for things they shouldn't use it for, especially for web applications where the web client and EJB's are in the same JVM. And you still need to go through the remote interface, thus introducing a whole bunch of heavyweight patterns such as Data Transfer Objects. Why do people think that EJB's only purpose is for remoting? I think its great for defining transaction and security boundaries between interfaces and hiding the implementation of this from the programmer. The real power of EJB is in the packaging and deployment. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
-Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 1:11 PM To: Bill Burke; Rickard Öberg Cc: Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Separating JMX/EJB can'tturn off the freaking email. |The real power |of EJB is in the packaging and deployment. you on dope? Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. Bill marcf | |Bill | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
Maybe I'll just shut up before I make (more of) a fool of myself. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, November 15, 2001 1:11 PM To: Bill Burke; Rickard Öberg Cc: Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Separating JMX/EJB can'tturn off the freaking email. |The real power |of EJB is in the packaging and deployment. you on dope? marcf | |Bill | | ___ 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
Re: [JBoss-dev] Separating JMX/EJB
Bill Burke wrote: Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. While the packaging is cool, IMHO it's more of a practical detail than a real advancement. To me, personally, it's all about the meta-programming and dynamicity of building large constructs from small blocks, which is enabled by having simple blocks that fit together like lego. JBoss is like lego. In many forms and different shapes, sizes and colors, but at the same time it's all the same. It's a nice illusion though. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
Rickard Oberg wrote: Bill Burke wrote: Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. While the packaging is cool, IMHO it's more of a practical detail than a real advancement. practical details are very important in the traditional IT world. Most developers are nowhere near as dedicated and talented as those who've been taking part in this conversation. To me, personally, it's all about the meta-programming and dynamicity of building large constructs from small blocks, which is enabled by having simple blocks that fit together like lego. JBoss is like lego. In many forms and different shapes, sizes and colors, but at the same time it's all the same. It's a nice illusion though. Very cool, indeed. But don't knock practicality 8^}) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[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 Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
Definitely. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Wednesday, November 14, 2001 9:21 AM 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 Marc Fleury President JBoss Group, LLC ___ 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
Re: [JBoss-dev] Separating JMX/EJB
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 Marc Fleury President JBoss Group, LLC ___ 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
RE: [JBoss-dev] Separating JMX/EJB
|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 | | | Marc Fleury | President | JBoss Group, LLC | | | | ___ | 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
RE: [JBoss-dev] Separating JMX/EJB
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 Marc Fleury President JBoss Group, LLC ___ 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
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: 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 I intend to write a whitey on it some day too, but basically it goes something like this: * Meta-programming is good, but not inherent to EJB * The EJB programming model in general is flawed. (See EJB-INTEREST for lots of conflicting answers to common questions. If experts can't figure it out, how are mortals supposed to?!) * In particular, dynamic (re)configuration of EJB is not possible, and it should be (compare with JMX/Jini) * The EJB persistence model is flawed, compared with JDO. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
