robert burrell donkin wrote: > > > On 2/16/07, Steve Brewin <[EMAIL PROTECTED]> wrote: > > robert burrell donkin wrote: > > > > > > > > > On 2/15/07, David Woldrich <[EMAIL PROTECTED]> wrote: > > > > Robert, > > > > > > > > Ok, fair enough. Well, honestly for starters, I would love > > > to deploy > > > > James as a monolithic Enterprise App or Web App if we could > > > work out the > > > > lifecycle issues (meaning System.exit() isn't the only way > > > to achieve > > > > orderly server shutdown.) It's been awhile since I looked > > > deep enough > > > > at that code to say whether that problem has already > been solved or > > > > not. So, if I could get that, it would totally solve > my short term > > > > itch. If you think that that's a rabbit hole not worth > > > diving into, I > > > > will trust your judgement. But, if it is, I'd like to > > > tackle that first > > > > and get it overwith. > > > > > > i really think that the best approach would be to deploy > JAMES as a > > > service available to enterprise applications rather than as an > > > enterprise application. so, i prefer the idea of deployment as a > > > plugin but i'm not a geronimo guru. i think that the > first step should > > > be to ask the geronimo team whether this would be the > best approach. > > > this probably means posting something appropriate to the dev list. > > > > > > for connectivity to the JAMES service, this is where i think that > > > service bus and JCA ideas are powerful. rather than > thinking about an > > > EJB, multiple transport mechanisms would be powerful: > EJB, WS, JMS, > > > JCA and so on. adopting a bus might give a lot of > benefits for very > > > little effort. > > > > > > - robert > > > > I agree "that the best approach would be to deploy JAMES as > a service > > available to enterprise applications", particularly > connected via a JCA. > > This would allow James to be connected to any modern J2EE > server or a JCA > > aware service bus. In contrast, a Geronimo plug-in would > only be useful > > within Geronimo. > > > > The JCA approach is also a more realistic goal as it would > entail much less > > work! > > serving SMPT, news, IMAP and so on requires sockets serving, thread > pools and access to the file system. i'm not sure whether this breaks > the JCA contract but i worry that it wouldn't make JAMES a good JCA > citizen.
None of the above neccesarily breaks the JCA contract. When a JCA is connected to a remote application, the remote application can acquire and consume whatever resources it wishes. There is no problem as its running in another JVM to the appserver. When a JCA is connected to a local application it must obey the J2EE rules which is short means delegating acquisition of resources to the appserver and consuming them via the JCA management interfaces. This is why don't see a JCA connected remotely to James as being too much work. It would be a good first step. >this is why i suspect that a plugin would be the right way to > embed these components but i think that the best approach would be to > ask the geronimo team. any volunteers? > > but i definitely agree that the connector is important > > > I'd guess the next step would be to identify what could > usefully be exposed > > as James services. Top of my list would be injecting mail > into the spool, > > reading mail from the mail stores and exposing dynamically > configurable > > artifacts. > > sounds reasonable > > wonder whether it might be possible to use an optional remoting > architecture to allow the processing to happen in another process See above. Also, we already have interface level exposure of this stuff, which is how the services I listed would be interacted with via a JCA. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
