> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > Simons, > > Berin and I were through this debate when we created Fortress. > I argued, just as you do, for marker interfaces. My rationale was that > the information about how a component should be handled should be > close to the component itself, and that it was one point where > java reflection really could shine.
Don't forget Peter in this too! He is not in favor of marker interfaces > > Berin, however, added a handler attribute to the container > configuration that specified how the component should be handled. > For example, you would have: > > <component role="some.Role" > class="some.Class" > handler="handlers.ThreadSafe"/> > > for ThreadSafe components. <snip/> Another issue arose from the Cocoon developers. Components were added, and the developers didn't realize that they should add marker interfaces for the ECM to treat the components as ThreadSafe, Poolable, etc. As a result, the overall Cocoon project had a feeling of being slow and heavy because a new component was created for every ECM request. People are forgetful about the marker interfaces because they do not have any methods to implement. I'm sure its sociological or something. However, most people don't forget to make the descriptor work for them properly. :/ I'm still scratching my head on that one--nevertheless, it's what I've observed. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
