Peter M. Goldstein wrote:
It seems to me that you need to deeal with this ComponentManager export
sooner or later. Given that the mailet container implementation is not
providing Avalon lifecycle support, then there is not reason why the
mailet container could not just create a map of all of those "standard"
resourses - after all, your not managing mailet depedencies - you just
providing a lokup table - which means that there is zero value in
passing a component manager or service manager into the mailet context.
However - you need to deal with backward compatability, but that's
achievable - you know all of the entries that would in principal be
supplied under a ServiceManager - all you need to do is to construct a
ComponentManager inside James using a Map of those services, pass the CM
to the mailet context and you have compatibility - I.e. don't change the
implicit dependency to ComponentManger inside Mailet API - but bring
James up-to-date in terms of ServiceManager usage (and in the meantime
start the ball rolling on a better way of handling depedencies between
James and Mailet).
Doing this means that (a) James can move in sync with the rest of
Avalon, (b) better chance of establishing gump live builds against
Cornerstone, Excalibur and other Avalon content, which (c) is going to
increase general integrity between the two.
On the subject of the mailet container - I'm assuming (striongly
assuming) that the mailet container implemetation would be plugable. To
be more specific - I want to be able to plug in an embedded Merlin
container that will handle Mailets - the plugged-in container will get
the classic depedencies via a service manager - I'll be able to do
things like dynamic creation of mailets based on events, dynamic
assembly of mailets irrespective of the numer of depedencies that a
mailet has, etc. These characteristics are fundamental to the sort of
appplication environment I'm working in - which means I'll need to
declare my own mailet container.
Is this reasonable relative to the current architecture or is this out
in v3?
Cheers, Steve.
>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]>
