Hhmm... ok, let me see if I understand this, using ECM as an example. I currently have a roles.xml file and a config.xml file. If I read the merlin site correctly, the role (no pun intended) of the roles.xml file is replaced with the <component-class>.xinfo files? And the container definition has the equivelant of my config.xml file is handled by the container definition for Merlin.
Did I get that all right? I know there are a few other things that merlin has/needs, but is that crossover correct? As for dependencies, you are right that they are a complex thing and I've seen threads on this list about them in the past. From my usage, I don't really need 'startup' dependencies, i.e. during the config process, but after all the config/init has happened and it all starts 'running'. Maybe if I could have a component tell its container "hey, I'm good to go", and be able to config the container so that unless all components are good, don't service anybody, that would be good enough for me. Right now I know something isn't right because I have a ton of logging going on, but from the top, or user level, they error/exception doesn't say a whole lot because it is really nested down. Make sense? I know Merlin doesn't do what I'm suggesting, but do you have any thoughts on where/how I could maybe subclass DefaultContainer to provide such functionality in the future (like 4 - 6 months down the road). Thanks a bunch, Robert -----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 1:45 PM To: Avalon Developers List Subject: Re: Migrating from ECM Robert wrote: >Thanks for the info about Merlin. I'm looking through the docs now and >will download and play with the demo as well. I'm not using the context >lifecycle, but I think I could really use the dependencies that you >mention. > Great! Some things to me careful of! 1. make sure you include new component definitions in your jar maniest (see execalibu/assembly/demo/src/etc/demo.mf for an example) 2. make sure you include the <component-class>.xinfo file in your jar file 3. make sure you inlcude your jar file in a classpath declaration in either the kernel or container level (see excalibur/assembly/src/etc/kenel.xml for examples). Exception reporting on the above cases needs more user friendly messages (its in the plan). > >One problem I have right now is that if one of my components does not >configure properly, I have no real way of 'knowing' this from other >components or the container. I'm using 4 components right now and they >are all interdependent at some level. In a nutshell what would be nice >is that if a component does not configure the container/service manager, >etc would know about and not allow it to be active. This might break a >few rules and from what I know right now, there is no callback from the >component to say "I'm not ready/configured". > > Interdependecies between a family components generally means circular dependecies which will result in a failure. The solution to this is to handle the components "as a family" where the container knows about the inter-relationships the the lifecycle sequencing that will work. The Merlin architecture has this in mind - I want to provide pluggable containers implementations and pluggable kernels that hide "family" issues like your describing. Currently the Merlin implemenmtation supports a DefaultKernel and a DefaultContainer - these assume non-circulare dependency conditions - however, I also need solutions for "family"based lifecycle management and as such will be introducting support for this as soon as the core framework is completed. One of the nice things about the framework is that the seperation of kernel and container hierachy allowing for the inclusion of a kernel in a container. This means that a kernel can container a kernel which means that a one kernel can act as a resource/facilities publisher to a parent when the parent is preparing and building another set of components. I.e. you get to control phasing of sub-sets of component assembly which is really nice in a complex compoent model. Cheers, Steve. >- Robert > > >-----Original Message----- >From: Stephen McConnell [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, July 17, 2002 12:17 PM >To: Avalon Developers List >Subject: Re: Migrating from ECM > > > >Robert wrote: > > > >>I have been planning on moving our product off of ECM since it isn't >> >> >the > > >>preferred container anymore (?), and was wondering which one should I >> >> >go > > >>to. I don't think I need phoenix as the container needs to lightweight >>enough to run in a single, fat-client environment, so I think either >>Fortress or Merlin would be my choices. So, with that in mind: >> >>- Which one is closer to production ready >> >> >> > >Merlin is under active development - but its already running compoenents > >really nicely, providing: > > (a) the component is thred-safe > (b) the component does not declare a context dependecy (that still >in progress) > (c) the component does not declare a default configfuration (that's >also in progess) > >My guess is that the real question concerns point (a) because ECM >compoents don;t know about default configuration or dependecies. The >excalibur/assembly package contains several example compoents with >Merlin doing the automated dependency resolution and lifecycle >management - take a look at the demo and see if this fits with your >needs. After a couple of other priority items I would like to focus on >Fortress/ECM style handler integration for pooled components but thats >at least three bullet points down the list. > > > >>- I need configuration as easy as, or close to as easy, as ECM was >> >> >> > >I'm confident you will find Merlin configuration easier than enything >else in Avalon. > > > >>- I am currently using the connection pooling from Excalibur and would >>like to continue using it. >> >>Any thoughts? >> >> >> >> > >If you want to trial Merlin 2.0 (excalibur/assembly) post me an emil >off-line and I'll try to help you with the job of getting things >running. In the meantime, the javadoc for Merlin 2 is really solid - it > >will giove you a reasonably good picture of what is possible today and >what is in the pipeline. > >Cheers, Steve. > > > >>Thanks, >>Robert >>- >> >> >>-- >>To unsubscribe, e-mail: >> >> ><mailto:[EMAIL PROTECTED]> > > >>For additional commands, e-mail: >> >> ><mailto:[EMAIL PROTECTED]> > > >> >> >> >> > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
