Am Sonntag, den 22.06.2008, 08:54 +0100 schrieb Robert Burrell Donkin: > 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
+1 Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
