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.
HTH,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
