james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: Geronimo-JAMES integration
Date Sun, 22 Jun 2008 13:23:23 GMT
Am Sonntag, den 22.06.2008, 08:54 +0100 schrieb Robert Burrell Donkin:
> On Mon, Jun 16, 2008 at 8:24 PM, Stefano Bagnara <apache@bago.org> wrote:
> > David Jencks ha scritto:
> >>
> >> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
> >>>
> >>> David Jencks ha scritto:
> >>> At the moment the geronimo-james integration is simply a single gbean for
> >>> the whole james application: do you think it would be hard to support 1
> >>> gbean per function? JAMES is composed by api modules, library modules and
> >>> function modules. functions only depends on libraries and api, libraries
> >>> only on apis, and api have no internal dependencies.
> >>> deployments simply aggregate functions. Is it possible to create separate
> >>> GBean for functions only when functions depends on shared services or the
> >>> only solution is to publish 1 gbean for each of our services? I don't know
> >>> geronimo, but it would be a great deployment alternative if it allow us
to
> >>> undeploy 1 single function (e.g: the spoolmanager), alter its configuration
> >>> and redeploy it without stopping the smtp/pop3 servers.
> >>
> >> This was the original idea I had when I first looked into this integration
> >> several years ago.  However I don't think it will be practical until James
> >> adopts a more conventional IOC approach in which the components have their
> >> properties configured by the IOC container rather than through a
> >> initialize(configuration) method.  I could have seriously misjudged the
> >> situation however.
> >>
> >> I have basically no idea of the internal threading structure of James.  Is
> >> adding and removing components reasonably possible to do in a thread-safe
> >> way without a large synchronization overhead?
> >
> > e.g: no component depends on the spoolmanager component. so it can be
> > stopped and started as you like. The same is for servers (smtpserver,
> > pop3server, nntpserver, remotemanager) and for the fetchmail function. They
> > have dependencies on core services (e.g: the repositories) but they don't
> > depend on each other. Their interaction is mainly via the spool repository
> > or via the "James" component (implementing various core services).
> >
> > james block, smtpserver, spoolmanager receive the spoolrepository service
> > via IoC (ATM they receive the ServiceManager and they ask the spoolmanager
> > to the ServiceManager in their "service" method, but we already changed most
> > of them to be able to inject dependencies without a ServiceManager, if
> > needed).
> > the spoolrepository service is implemented by the MailStoreSpoolRepository
> > block that depends on the mailstore service. The mailstore service is
> > implemented by the AvalonMailStore component that in turn depends on the
> > cornerstone's DataSourceSelector and our FileSystem service)
> >
> > You can find the "runtime" service dependency graph in the
> > james-assembly.xml file.
> >
> > ATM you could remove only top level components or otherwise you would have
> > to remove every dependent component first.
> >
> > smtpserver, pop3server, spoolmanager, nntpserver, imapserver, fetchmail,
> >  and remotemanager are top level compoenents and they are the one
> > starting/stopping threads. Synchronization happens in lower/shared
> > components/services.
> 
> JAMES is too hard to understand and that's why i think we need to pull
> out the protocols (smtp, nntp, pop3, imap) into independent,
> embeddable libraries with no coupling to avalon (or to the JAMES
> socket handling layer). i think that this would be good for the JAMES
> application server since the application server build would be
> smaller, quicker and lighter. i discovered at apachecon that there are
> quite a number of projects that are interested in mail integration
> libraries providing it came without the burden of a heavyweight
> application server.
> 
> - robert

+1
Norman


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message