Peter:
Based on the details you provided I finally hunted down the issue - doing a search through the James src directory for the phrase "AVALON_COMPONENT_MANAGER" reveals a lot of undeclared dependencies. As you say - irrespective of the "visual" cleanliness of the Mailet API, the James Mailets are "another kettle of fish". However - while the dependencies that are hard-coded are "rationale" - the problem (as far as I can se) is that the Mailet API does not provide a mechanism for a Mailet implementation to declare to its container the dependencies that is has. As such, any Mailet is dependent on the "James Mailet container implementation" - which seems contradictory to the prime objective of cross container Mailet deployment. If we take JDBCListserv as an example, it is assuming that the container will supply: * a set of init pareters * a mailet context containing: - a ComponentManager populated with a Cornerstone DataSourceSelector - plus "standard" James content Failure of the container to supply the above will result in a runtime failure of the Mailet. I've search through all of the configuration docs and I have not found anything that declares what a container is doing in order to prepare this state - therefore, the above state is implicitly part of the Mailet API. I think we would agree that this is a bad thing. Having build a couple of containers, here are the sort of things I would want to see in a Mailet container/Mailet API: 1. a meta-info model that enables developers to declare mailet depedencies, init params (context), configuration. logging categories, and extensions - i.e. something similar to a part of the content of a Servlet web.xml for a particular Servlet 2. a meta-data model that enables me to declare different arrangements for a particular mailet type (i.e. for a given type, I want a profile for friendly message generation and another profile for aggressive message generation) 3. the ability to validate my Mailet before I deploy it 4. the ability to declare a Mailet type and profile to the system without implying instantiation (i.e. I may want to declare an aggressive profile Mailet for message construction for overdue accounts - but I don't want it instantiated until I actually need to use it) 5. the ability to programmatically create and deploy a new Mailet 6. the ability to control class access at the container level (i.e. a classloader management strategy) 7. the ability to construct, deploy and declare a Mailet as a service to another business application 8. the ability to administer Mailets both within and external to James Beyond the above, I think it is desirable to see: a. no obligation for a Mailet developer to use Avalon b. a Mailet API that does not re-invent lifecycle interfaces that already existing in the Avalon Framework (the framework is a lightweight API - 62k - that 3x the size of the mySQL license document) c. re-use of existing Apache resources in the Mailet reference implementation (commons, excalibur) Unfortunately the last time that the Mailet API was discussed, it focussed somewhat strangely on the two things - (a) the parameter to use for logging, and (b) dependencies cleanliness. I think we have to go beyond Logger because that's not the issue - the issue is that the Mailet interface defines logging, configuration, initialization, (and to some degree services but its not clear), and disposal. If you abstract out the functionally equivalent content relative to the Avalon Framework model, you basically left with a context specialization for James (populated by James on Mailet deployment) and that's about it. With the above scenario - I already have (today - available - tested - validated) a James Mailet container that does everything listed above. But we haven't addressed dependency cleanliness - I'm not sure what the issue here is - if it's about packaging the minimum number of jar files then just put the Avalon framework classes into the Mailet jar and be done with it. If it's about a real technical issue concerning Avalon framework then that should be stated (the last thread on logging didn't provide anything towards that end). However - I must make a confession - if I were to define a new Mailet interface - I would be saying the same thing - keep the dependencies as small as possible. But after looking at the Mailet interface and seeing the very high level of redundancy relative to the Avalon framework lifecycle interfaces, your getting into really debatable territory. Bottom line - if I put in balance the benefits of "minimal dependencies on a new API" against "an API leveraging existing containers" - my pendulum swings over to the "leverage existing resources" side of the equation. Botom line - if the Mailet API was using Avalon lifecycle interfaces I'd be using Mailets today instead of just planning to use them. Cheers, Steve. Peter M. Goldstein wrote: >Stephen, > >The issue is very simple. James currently exports the ComponentManager, >which is an Avalon framework class. It just hides it in the >MailetContext, which is basically a glorified HashMap. Assorted mailets >(JDBCAlias, custom mailets, etc.) make use of this to grab Avalon >components. That means that this is a de facto part of the API. That >means that the Mailet implementations are tightly coupled to Avalon, >despite the fact that this is not evident in the Mailet API. Changes to >Avalon impact the mailets. This is the source of the current problem. > >Non-Avalon Mailet containers obviously will not be able to provide this >class. So the Mailets are not portable between (as of yet hypothetical) >containers. This has been a huge point of debate in the past. Some >want to keep the mailet API Avalon independent, for others it's not a >priority. Right now the API looks Mailet independent, but really isn't >for the reasons described above. See my earlier email for the relevant >rant. > >The suggestion in question is to replace the ComponentManager with >ServiceManager, which leaves us with the same problem. It doesn't fix >anything, but simply propagates the problem forward in time. Mailets >will now expect to have an Avalon ServiceManager instead of an Avalon >ComponentManager. The fact that they can use the ServiceManager to look >up non-Avalon items is basically irrelevant - we're still coupled to >this Avalon implementation for the ServiceManager. The mailet needs to >know what an Avalon ServiceManager looks like. > >An example of a non-Avalon dependent solution to this sub-problem would >be adding a lookup method to the Mailet API that hides the Avalon >ServiceManager. It would return an Object, and throw a subclass of a >MailetException. There are other viable solutions. The current one is >not, IMHO, acceptable. The point is that there are a few such problems, >and they need to be hashed out and resolved in Mailet v.2. > >On another note, because of the way mailets are loaded, they can't be >used as Avalon components. James code - not Avalon container code - >instantiates the mailets (see >org.apache.james.transport.MailetLoader.java). It doesn't check to see >if they implement any of the Avalon lifecycle interfaces. This is >related to the logging debate and the lesser discussion over >configuration. It would be possible to change this behavior, but that's >how it works today. > >--Peter > > > >>-----Original Message----- >>From: Stephen McConnell [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, September 24, 2002 5:10 PM >>To: James Developers List >>Subject: Re: [PATCH] Replace Components with Services >> >> >> >>Peter M. Goldstein wrote: >> >> >> >>>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? >>> >>> >>> >>> >>Peter: >> >>Can you provide me with summary of the issue here - if I look at the >>Mailet interface there are no Avalon Framework dependecies. As a >>container author there are a couple of lifecycle thigns I need to take >>care of which is complete within the scope of the lifecycle extension >>model used in a couple of Avalon containers (i.e. even if Mailet is >>independent of Avalon I can still treat a Mailet as a component - I >> >> >just > > >>need to know the lifecycle logic). I guess I'm confussed about the >>Avalon lock-in issue .. can you explain? >> >> >> >>>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 are some Avalon issues I would be jumping up and down about but >>the lifecycle ordering is not one one of them. Lifecycle orddering is >>very stong and is very reason why I can run james in Merlin. >> >> >> >>>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. >>> >>> >>> >>This is ignorance on my part - over on the left I have a bunch of >>windows open showing the Mailet sources - I'm not getting the issue - >>but (a) it's late and (b) I would really like to undertand the issue. >> >>:-) >> >> >> >>>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. >>> >>> >>> >>> >>Ok - I'm lost!! >> >> >> >>>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 >>> >>> >>> >>> >>It's a reasonable argument. >> >> >> >>>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 >>> >>> >>> >>> >>That's where things start to suck. >>But is this really a Mailet API issue - or just lots of fuss over the >>current mailet container implementation? >> >> >> >>>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 >>> >>> >>> >>> >>I'm using James because it's based on Avalon. >>Doing a roll-your-own means that I have to a lot of extra stuff to >>handle the same things - that sucks. >> >> >> >>>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. >>> >>> >>> >>> >>Summmary - I don't get the issue (and that's probably because I'm not >>deep enough into James). I do know that moving from ComponentManger >> >> >to > > >>ServiceManager reduces your depedence on Avalon. That's the reason it >>was introduced. I had way too many situations where I was forced to >>wrap other system just to fit into the "Avalon" way - and without any >>good reason. ServiceManager changed all of that - I can now have a >>CORAB ORB as a service, supplied to another component (the OMG spec >> >> >for > > >>the ORB does not include and will never include the Avalon Framework >>Component Interface). I have lots and lots of other examples where I'm >>using non-Avalon services within components, and exporting services >>without any Avalon baggage. >> >>Bottom line - moving from ComponentManager to ServiceManager means >>giving yourself more liberty. >> >>Anyway - If someone can bring me up to speed on the Mailet issue - I >>would be really happy. >> >>Cheers, Steve. >> >>p.s. Yes - I read lots of message in the thread about logging and to >> >> >be > > >>frank - I'm no better of than before. >> >>SJM >> >> >> >>>--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:james-dev- >>> >>> >>[EMAIL PROTECTED]> >> >> >>>For additional commands, e-mail: <mailto:james-dev- >>> >>> >>[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: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]> > > > > > -- 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]>
