On Thu, 6 Dec 2001, Lucas Gonze wrote:
> A nice n easy solution which allows me to use whatever repository is best,
> including mbox files, but...
>
> public void setComponentManager(ComponentManager comp) {
> this.comp = new SimpleComponentManager(comp);
> }
>
> public void init() throws Exception {
>
> logger = (Logger) comp.getComponent(Interfaces.LOGGER);
> logger.log("JamesSpoolManager init...", "Processor", logger.INFO);
> spool = (SpoolRepository) comp.getComponent(Constants.SPOOL_REPOSITORY);
> mailetcontext = (MailetContext)
> comp.getComponent(Interfaces.MAIL_SERVER);
>
> ..I still need a way to get a handle to comp.
Which version of James do you currently use? I use 1.3-dev:
public void initialize() throws Exception {
getLogger().info("JamesSpoolManager init...");
workerPool = blockContext.getThreadPool( "default" );
MailStore mailstore
= (MailStore)
compMgr.lookup("org.apache.james.services.MailStore");
spool = mailstore.getInboundSpool();
if (DEEP_DEBUG) getLogger().debug("Got spool: " +
spool.getRepositoryName());
You can get the component compMgr there; which was initialized (by Avalon)
in the JamesSpoolManager.compose():
public void compose(ComponentManager comp) {
compMgr = new DefaultComponentManager(comp);
}
Once you get it, then you can get access to other blocks defined in James
(including your other own blocks, of course).
> A really easy way to get a handle to the James.comp object is to subclass the
> James class, have the conf file instantiate my subclass, and use my derived
> class when I need to see the handle. In James.java the comp variable is
> private, so is there an objection to either making it protected or adding an
> accessor method getComponentManager()?
I've done it once (for some other reason); it provided nothing but
headaches (when you are upgrading your James to the latest one, then your
code might work or might not work). You may just forget it.
> The JDBC solution is not bad at all, but a solution that lets me use non-JDBC
> repositories is better. This solution lets me use any kind of repository.
Yes, the JDBC solution would make you tied to the db repository.
> (n.b.: it's ok if my code is in the same JVM as James.)
Then writing an Avalon block would be the right way. Writing ones would be
quite challenging, but it would be really worthwhile.
Oki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
