Peter, Firstly dude, could you try to dofferentiate between Avalon-Framework, Avalon-Phoenix, and Avalon-Cornerstone when referring to classes. I know it's sightly rudeof me to raise this, and I mean no offence, it's just that I spent loads of effort explaining the difference before mid-August (your entry point to the mail-list), with some level of achivement :-))
I'd agree that the nascent Mailet API should not refer to Avanlo-Phoenix or Avalon-Cornerstone. I don't agree there is a problem with Avalon-Framework, but then I am subjective. As stephen says the lifecycle interfaces are very strong (arguably the best aspect of the avalon project). Like Stephen I am a two time container author, and would not consider a new hosted component design without them now. From other mails.... I dissagree that non-Avalon mail containers will be able to host Mailets if Avalon-Framework is used. It is really easy to roll your own container - the Turbine team is doing it. Re "tightly coupled to the Avalon lifecycle framework", not true. the current situation is because Avalon-Cornerstone (and Avalon-Cornerstone *only*) dropped Component references., and is not becuase of a prior change in Avalon-Framework. This problem is not to do with the fact that James impl incidentally uses Avalon-Excalibur interfaces. Nor is it to do with the fact that James Impl happens to run on Avalon-Phoenix as a containter. James impl is a container in a container, is is sweet apart from the lack of hot installable lifecyle-activated mailets and this Avalon-Cornerstone issue. From Noel's "One of the biggest items is that an interface to object repositories needs to be part of the mailet specification, and mapped to the platform, rather than having to break the veil." - Agree. And that should not expose Avalon-Cornerstone interfaces. It should expose Mailet interfaces (who's impl may use Avalon-Cornerstone things). Finaly, you guys should stick with the forked Cornerstone, if it is that big an issue. Maybe I should I get my act together and write a demo of the future mailet design (as promised). I'm sure stephen and I could write a tiny demo that could show how it should work. It would only use the Avalon-Framework classes for dependencies, so there would be no isses born of confusion on imports for the container versus for the mailet API. - Paul >Please consider this my -1 to replacing ComponentManager in the Mailet >API with ServiceManager as a long term approach. > >There have been extensive discussions on this list about the coupling >between the Mailet API and Avalon. How extensive should this coupling >be, what form should it take? > >For my part, I don't really have a tremendous objection to a tighter >coupling between Avalon and the Mailet API. I know that some do, >because they want to see the Mailet API become a server-independent >standard. I respect that opinion, but it's not the reason I'm voting >against this as a long term proposal. I'm interested in James as an >enterprise quality mail server, not in the Mailet API in the abstract. >If the mailet API were to incorporate some subset of the Avalon >lifecycle, I'd have no objection in principle. > >I do object however to an attempt to slip things in the back door. The >current situation is the worst of both worlds. We're tightly coupled to >the Avalon lifecycle framework (see the current situation), but gain >none of its benefits. There is no ordered lifecycle, no well defined >series of events. There isn't even a wrapper method for the >MailetContext to ensure that when we get the ComponentManager / >ServiceManager we're actually getting a ComponentManager / >ServiceManager object because that would introduce Avalon classes into >the Mailet API. That's supposedly a guarantee of the container, but it >can't be a real guarantee because not every Mailet container is >necessarily an Avalon container. So these mailets aren't really >portable even though their interfaces all say they are. Arrgh. But we >don't have any Avalon interfaces in our API, so we're Avalon independent >(wink, wink). Double arrgh. > >For a long term solution I see three possibilities: > >i) Incorporate the Avalon classes into the Mailet API - there is strong >objection to this and it ties us to Avalon > >ii) Incorporate some other set of classes that provide much of this >functionality (i.e. JDK 1.4 for logging) and write adaptors for the >relevant Avalon classes - probably incur strong objections, adaptors >might be tricky > >iii) Do it all ourselves, making a more rigorous lifecycle for the >mailet and write adaptors for the relevant Avalon classes - probably the >least objections from those who want the Mailet API to be independent, >adaptors might be tricky > >Anyway, that's why I'm voting -1 on simply replacing ComponentManager >with ServiceManager for the long haul. I understand we may need to do >it temporarily. If we do, I want us to commit to coming up with some >sort of acceptable solution by a given date/release. Otherwise I'll >vote against the change. > >--Peter > > > >>-----Original Message----- >>From: Steve Short [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, September 24, 2002 4:10 PM >>To: James Developers List >>Subject: RE: [PATCH] Replace Components with Services >> >>Yes - replace ComponentManager with SystemManager. I do not think is >> >> >as > > >>big a deal as you do. >> >>Steve >> >> >> >>>-----Original Message----- >>>From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] >>>Sent: Tuesday, September 24, 2002 4:05 PM >>>To: 'James Developers List' >>>Subject: RE: [PATCH] Replace Components with Services >>> >>> >>> >>>Steve, >>> >>> >>> >>>>It is an unfortunate situation, but I think the path that will >>>> >>>> >cause > > >>>the >>> >>> >>>>least pain now and in the future is to bite the bullet and do it. >>>> >>>> >>>There >>> >>> >>>>aren't too many mailets that use a ComponentManager / >>>> >>>> >ServiceManager > > >>>and >>> >>> >>>>for those the code change is trivial. >>>> >>>> >>>But that's exactly the question - do what? Replace >>>ComponentManager with ServiceManager? Is this our permanent >>>solution (very -1)? If not, how do we present it to our user >>>base? When do we expect to have a permanent solution? >>> >>> >>> >>>>Let's not get into forked Cornerstone or being tied to prehistoric >>>>releases of Avalon packages, both of which will just lead >>>> >>>> >>>to more and >>> >>> >>>>more compatibility problems. James needs to be able to move up to >>>> >>>> >>>newer >>> >>> >>>>releases of these packages as easily as possible. >>>> >>>> >>>Absolutely agree. >>> >>> >>> >>>>As far as backwards compatibility is concerned, this is partially >>>> >>>> >>>blown >>> >>> >>>>already with the enabled flag required in config files so >>>> >>>> >existing > > >>>>config files will no longer work. Admittedly this is much >>>> >>>> >>>easier to >>> >>> >>>>fix. >>>> >>>> >>>There is a huge difference here. Basically we can (and >>>should) write some simple XML transform code to change the >>>config file as necessary. Even if we don't do this, any >>>administrator can be instructed to do minor adjustments to >>>their config file. >>> >>>Changing APIs is an entirely different order of magnitude. >>> >>>--Peter >>> >>> >>> >>>-- >>>To unsubscribe, e-mail: >>><mailto:james-dev-> [EMAIL PROTECTED]> >>>For >>>additional commands, >>>e-mail: <mailto:[EMAIL PROTECTED]> >>> >>> >>> >>> >>-- >>To unsubscribe, e-mail: <mailto:james-dev- >>[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:james-dev- >>[EMAIL PROTECTED]> >> >> > > > >-- >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]>
