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
