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]>
