> From: Stephen McConnell [mailto:[EMAIL PROTECTED] > > I'm confident that Silvian would appreciate the implicit > magic in ECM, for all intensive purposes it requires the > obligatory usage of meta-info in component implementations > via the ROLE static member.
No. ROLE isn't obligatory. ECM doesn't know/care that it is there. > The mysterious ROLE static value is nothing more that > the declaration by a component of the public service interface it > provides No. It is a convenience value that clients can (but not must) use in the lookup() call. > We have a potential catch 22. There is vocal minority that is > expressing the opinion that we should not consolidate our efforts > on one platform without an equivalent feature/benefit matrix so > long as we have users of the another platform - and in the same > breath - why consolidate when we have a solution? The real catch > 22 here is that those who understand and appreciate the ECM/Fortress > model have not yet committed to the migration. You can only understand that against the background that *the container doesn't matter*. No, really, it doesn't. When Carsten says that "we use ECM, and that works fine", it isn't a reflexive "I can't be bothered to look at your magnificent container" but a reasonable position to take given business requirements. It is as if someone jumped up and said that we should dump Java and code in LISP/C#/Ruby instead, because it is just sooo much better - just look at all these features! Who would care if there was a migration strategy? Java works. Simply put, there's no business case to be made for the migration effort. Like you, I can only speak for myself - migrating to Merlin would not translate into a single $ for me. It would not translate into faster application development, not into easier deployment, not into anyhing except another dependency (that drags 30+ dependencies with it) and *a lot of effort* in migrating. It would translate into having a complete component model, but what do I *gain* from that? > Over to Hammett - and the religious conviction theme. Hammett and I > actually agree on most things - but on this particular issue > its black and white: > > Hammett's position: > > * don't abandon Fortress before equivalent functionality is in > place - in the meantime "may the force be with you" > > Steve's position > > * forget about the "force" - its just a movie - focus on > reality and deliver the final solution as a collaborative > effort - reality is that the "force" is the community and > the community needs to consolidate and as long as we have a > division - the end-game remains elusive > > So here is the dilemma. Follow the Hammett strategy and destroy the > dream. Follow the other strategy and take a risk. What to do? Follow Hammett's strategy and have working applications, follow the other strategy and risk a lot for nothing. I'm not quite sure what reality you want me to focus on. > How about the following: > > * create the one solution community > * maintain a fullback strategy > * deliver more than we promise > > In a somewhat related but independent thread Arron Far said > (and I'm not > implying anything but a good text-stream from Aaron): > > One container to rule them all > One container to find them > One Container to bring them all > And in the model bind them There is a gain in plugging holes in the Framework contracts - that much of the model I support. That should be enough to give us portable components. But I think that the "model" you talk about is the Merlin model - the parts of merlin that isn't Framework - and I really do have a problem with that part, because it is heavyweight and not that flexible. It's as big as J2EE, but without the industry support. > But maybe not. Chances are that I have this all wrong. Are there > additional points we should be taken into consideration > before closing this particular subject? Yes, what model? Niclas lists: + Component Type Specification + Component Instance Identification Specification + Component Dependency Specification + Component Packaging Specification + Component Requirements Extension Specification Now that's a *lot* of stuff. Take Component Packaging for example. Does this mean packaging as in ear/war/ejb-jar files? If so, can you guarantee that this will in fact work in many environments where Avalon is used? If not, does it make sense to exclude those and their developers? Avalon isn't an App Server. We have J2EE for that. Avalon is an IoC framework that currently excels at being used inside J2EE - inside servlets, inside MBeans, inside bizarre classloader hierarchies... you name it. And all this because of flexibility and a short and simple specification that only concerns itself with the very basics. I don't want to throw that part of Avalon away. As Niclas said, maybe I should take that ticket to Pico. An aside: Part of the reason I'm into this aspect-container (whatever I'll end up calling it), is to provide this type of scalability. You should be able to build an Avalon app server, but also build something much smaller. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
