> From: Leif Mortenson [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > >>From: Leif Mortenson [mailto:[EMAIL PROTECTED]] > >> > >>I went ahead and committed a couple of tools which I have > >>been using for > >>some time to ease the use of the ECM. > >> > >>1) > >>The first is the ExcaliburComponentManagerCreator class. It > >>is used to > >>manage the entire lifecycle of the ECM, RoleManager, > >>LoggerManager and optionally the InstrumentManager. And it > >>can all be done with the following code. Much simpler than > >>having to everything manually each time it is used: > >> > >>Initialization: > >>--- > >>m_componentManagerCreator = new ExcaliburComponentManagerCreator( > >> null, // Optional Context > >> new File( "../conf/logkit.xml" ), > >> new File( "../conf/roles.xml" ), > >> new File( "../conf/components.xml"), > >> new File( "../conf/instrument.xml" ) ); > >>--- > >> > >> > > > >You mean you don't want to use Fortress? It has the same basic > >approach, and is just as easy to use. > > > Nothing wrong with Fortress. :-) I am playing around with it > some. But > I do have a bunch of > code which is written to use the ECM along with the Selectors. > Fortress doesn't support > selectors, so that code would have to be rewritten.
Nope, that's where your wrong. Fortress will give you a selector if you ask for the MyComponent.ROLE + "Selector" ending. If there are multiple components that implement the same interface, and you don't ask for a "Selector" it will return the default. The default is the first component read from the config file, unless you specify default="true" as an attribute of the component config element. > How stable is Fortress now? With all of the > Merlin/Fortress/ContainerKit arguments > going on right now. It seems like things are still in flux a bit. > Fortress is the only one I > have done anything with and so far I like it. But the ECM is > still the > current tried > and true CM. These tools do not add new functionality to them. They > simply make > the ECM easier to use. Code hasn't changed all that much. Right now, Fortress is pretty stable. Since Fortress supports multiple concrete Container types, I am experimenting with a Merlin compatible container. The main thing that is in contest is the meta model/meta data discussions. Fortress as it stands right now does not make use of it *yet*. I want to make sure that Fortress uses the correct meta model. > I had been trying to get into Fortress when all the childish > mudslinging > started. Tried > sifting through it for a while to get to the meat of the issues. But > ended up deciding to > wait a couple weeks for certain committers to maybe grow up a > bit. Then > see where > the dust settles. > > While all that is happening, the tried and true ECM is there. The soon-to-be-retired ECM. All of this "mudslinging" is to get the correct meta model so that all components are implemented and described the same way--regardless of the container that is using it. Fortress is very similar to ECM in the way components are described--with a few subtle differences. Merlin is more similar to the Phoenix way of doing things. Anytime we need to converge on standards things get heated. > >>2) > >>The second utility class is the > >>ExcaliburComponentManagerServlet. It is > >>located in the servlet subpackage and built into a seperate > jar file: > >>excalibur-component-servlet-1.0.jar > >>The ECMServlet allows users who wish to use the ECM in a Servlet > >>environment to do so painlessly. > >> > >> > >I would really like it if we started divorcing ourselves from ECM. > > > Sounds good, but it is not going to happen on the project I > am working on right now. Next project sure. It is going to > have to be around for a while. It is still the main CM > in the latest released > version of Avalon. Yep. We are nearing the place where that will no longer be true. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
