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