You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Peter M. Goldstein" <pe...@yahoo.com> on 2002/10/13 00:38:50 UTC
Followup: AbstractJamesService and Watchdog
All,
Since some of the participants in the current discussion have requested
complete source files for a service, rather than diffs. Attached are
the POP3 service sources. You will need the org.apache.james.watchdog.*
files and the AbstractJamesService.java file to complete a build with
this modified service.
--Peter
Re: Followup: AbstractJamesService and Watchdog
Posted by Stephen McConnell <mc...@apache.org>.
Peter M. Goldstein wrote:
>Stephen,
>
>
>
>>Just took a peek at the sources attached to your email - I was
>>
>>
>wondering
>
>
>>about the following defintion in the .xinfo file:
>>
>> <services>
>> <service name="org.apache.avalon.framework.component.Component"
>>version="1.0"/>
>> </services>
>>
>>This is basically saying the the POP3Server is providing a service
>>interface
>>corresponding to Component.
>>
>>That a little odd because:
>>
>> (a) it means that a container may proxy this component to
>> expose only Component (which is nothing)
>> (b) a container may complain because your exposing a internal
>> interfaces as opposed to a formal work interface
>> (c) if the real case is that this is a component that does
>> not provide a publically accessible services then the
>> better approach is to simply drop the <services> element
>> from the .xinfo file.
>>
>>I would have though that this component was actually providing a
>>services - but I'm not familiar with POP3 stuff so I'm not in a
>>position to say what that service interface would be.
>>
>>What do have in mind?
>>
>>
>
>Basically these lines are leftovers. I didn't add them, but I didn't
>want to muck with removing them. I agree with you - they probably
>shouldn't be there.
>
>
It's safe to remove the <services> declaration - in fact I recommend it
as the current declaration will probably generate warning in Phoenix
(that last time I check Phonenix there was a handler that was checking
from implementation classes but it was comented out probably because it
was breaking too much stuff).
>Realistically, I don't think we'll be able to run in a non-Phoenix
>container before some of the changes coming with the next revision.
>
Problems running in alternative containers are not linked to James. The
problem is related to Cornerstone (on which James in dependent).
Cornerstone resources depedent on the Phoenix platform include:
DefaultDataSourceSelector
AbstractFileRepository
SSLFactoryBuilder
(and a couple of the AltRMI classes)
From memory James in depedent on the AbstractFileRepository (when using
the default configuration). I have James running under the Merlin
container using a slightly patched version of Cornerstone (i.e. purged
of container depedencies).
The real benefit of the next James revision will be reduced dependency
on the framework (i.e. Avalon leverage instead of Avalon lock-in by
migrating to the ServiceManager package).
>So
>I haven't really worried about (b). But you're right - to generally
>support Avalon containers we need to modify the .xinfo file so we don't
>export internal interfaces.
>
Just drop the <services> element - things will work fine in Phoenix and
Merlin. It's perfectly OK to declare a compoent that does not export
services.
Cheers, Steve.
>
>--Peter
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Followup: AbstractJamesService and Watchdog
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Stephen,
> Just took a peek at the sources attached to your email - I was
wondering
> about the following defintion in the .xinfo file:
>
> <services>
> <service name="org.apache.avalon.framework.component.Component"
> version="1.0"/>
> </services>
>
> This is basically saying the the POP3Server is providing a service
> interface
> corresponding to Component.
>
> That a little odd because:
>
> (a) it means that a container may proxy this component to expose
only
> Component (which is nothing)
> (b) a container may complain because your exposing a internal
interfaces
> as opposed to a formal work interface
> (c) if the real case is that this is a component that does not
provide
> a publically accessible services then the better approach is to
> simply drop the <services> element from the .xinfo file.
>
> I would have though that this component was actually providing a
> services - but I'm not familiar with POP3 stuff so I'm not in a
position
> to say what that service interface would be.
>
> What do have in mind?
Basically these lines are leftovers. I didn't add them, but I didn't
want to muck with removing them. I agree with you - they probably
shouldn't be there.
Realistically, I don't think we'll be able to run in a non-Phoenix
container before some of the changes coming with the next revision. So
I haven't really worried about (b). But you're right - to generally
support Avalon containers we need to modify the .xinfo file so we don't
export internal interfaces.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Followup: AbstractJamesService and Watchdog
Posted by Stephen McConnell <mc...@apache.org>.
Peter M. Goldstein wrote:
>All,
>
>Since some of the participants in the current discussion have requested
>complete source files for a service, rather than diffs. Attached are
>the POP3 service sources. You will need the org.apache.james.watchdog.*
>files and the AbstractJamesService.java file to complete a build with
>this modified service.
>
Hi Pete:
Just took a peek at the sources attached to your email - I was wondering
about the following defintion in the .xinfo file:
<services>
<service name="org.apache.avalon.framework.component.Component"
version="1.0"/>
</services>
This is basically saying the the POP3Server is providing a service
interface
corresponding to Component.
That a little odd because:
(a) it means that a container may proxy this component to expose only
Component (which is nothing)
(b) a container may complain because your exposing a internal interfaces
as opposed to a formal work interface
(c) if the real case is that this is a component that does not provide
a publically accessible services then the better approach is to
simply drop the <services> element from the .xinfo file.
I would have though that this component was actually providing a
services - but I'm not familiar with POP3 stuff so I'm not in a position
to say what that service interface would be.
What do have in mind?
Cheers, Steve.
>
>
>--Peter
>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>