On Mon, Jun 16, 2008 at 8:24 PM, Stefano Bagnara <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
