> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > This is the framework reference implementation of release. > Yes - it is > easy to understand, yes - its easy to use. Could we come up with > something that is better? Yes - remove it and delivery > something better > in the right level of abstraction. But the big point is that > your email > is making assertions that are only rational if your understanding of > Avalon Framework is Avalon Framework + ECM conventions and > implementation.
+ Fortress. The ECM is used by a great many of our users. There is a smooth (or relatively smooth) migration from ECM to Fortress. There are also benefits that Fortress provides which ECM doen't such as higher scalability due to offloading management functions into asynchronous functions. However, I haven't *removed* existing functionality. If we ignore our existing users we will piss them off royally. We need to think of them. Another important thing is that assumptions held by a large number of people (which include many of our users) in themselves become contracts. To ignore that fact because we didn't explicitly state the contract is really bad. I have been working at the possibility of removing pooled support for a while now. There are simply some ways that the ECM/Fortress is used that doesn't permit that yet. We are getting closer, but you can't remove expected functionality without providing a better substitute--which is what we are doing if we remove the release() method at this time. The fact is, ECM, Fortress, Merlin, and Phoenix all implement the contracts as they are laid out for containers at this moment. However, they are only *partially* compatible. We need you and Peter to finish the meta-data so that they can be even more compatible. Fortress will follow suite, and ECM will die. There are things that I need to explore with Fortress that may provide a better solution to explicit pooling, making it impossibly easy to create threadsafe components. Until they exist, the release() method needs to stay. Which is why I am suggesting to temporarily table A5. > >> It is > >>simply > >>the ratraction of an abstact operation that cannot be > >>supported at the framework's level. Nothing more - nothing > >>less. I'm not promoting or > >>opposing > >>that position here - what I am doing is directly challenging > >>the the assumptions you are implying about A4 and its > >>evolution. In reality, this email is a fake parade that > >>argues for the value of something we don't have. > >> > > > >I don't get the fake parade thing at all. > > > > Too much implied in beteen the lines. Positioning the containerkit as > overly complex - why - have you used it - have your tried to develop > something with it? I have - it is simple to use - took no > more that a > couple of days to get something operation in place. Containerkit is > simple - what's not simple is what containerkit implies. But > the iussue > here is that containkit is implying the defintion of what a component > really is - and that is much more of a concrete issue. My > fake-parade > comment is specifically addressing the issue of "lets ignore whats > really happenning" - "lets imagine that what we have is > perfect" - what > we have today is really great - but when we are discussing > evolution and > forward looking development - we cannot - must not - ignore our > functional limitations (e.g. the amazingly complex release > operation imp > described above - or the responsibilities we have when > defining what a > component really is). Restating my *intended* message: Let's not hide a complex problem with software if there is a simpler approach. I assert that J2EE's ServiceManager concept is flawed because it is an additional layer overtop a monster that Sun has created. Instead of fixing the underlying problems associated with resolving EJBs and other J2EE components, they add another software layer overtop. Even more specious is the fact that they expect every company to develop the same fundamental solution themselves instead of providing the abstraction. Let's simplify as much as possible, and then use the software to make it dirt easy. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
