james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <server-...@james.apache.org>
Subject [jira] Updated: (JAMES-842) Inconsistencies in spring integration
Date Mon, 07 Jul 2008 21:40:32 GMT

     [ https://issues.apache.org/jira/browse/JAMES-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

David Jencks updated JAMES-842:

    Attachment: JAMES-840-2.patch

While I think that the switch to ResourceLoader is a very good idea, based on my experience
in the geronimo plugin I don't think it is working as you expect.   I believe that the JamesResourceLoader
is rarely actually used, instead the AvalonApplicationContext implementation of ResourceLoader
is being installed by spring as the actual service at runtime.  The only way I could find
to work around this is to implement the ResourceLoader functionality directly in (my subclass
of) AvalonApplicationContext.

There's another problem in that the AvalonApplicationContext constructor is calling refresh().
 This effectively prevents remiplmenting   the ResourceLoader functionality in subclasses
since refresh() involves use of that ResourceLoader functionality.  (this is a classic example
of why calling (non static, non final) instance methods from a constructor is a bad idea)

I've proposed a patch that solves this latter problem by use of static factory methods.  It
also makes FileSystemBridge ResourceLoaderAware.  It might be possible to solve these problems
in another way by making AvalonConfigurationFileProvider no longer ResourceLoaderAware and
explicitly configuring the use of the JamesResourceLoader; as it is now (before this patch),
in the geronimo plugin the AvalonConfigurationFileProvider always got the resourceLoader set
to the AvalonApplicationContext even when explicitly configured to the JamesResourceLoader.

My implementation of an AvalonApplicationContext subclass that implements the ResourceLoader
functionality I need for geronimo is at


> Inconsistencies in spring integration
> -------------------------------------
>                 Key: JAMES-842
>                 URL: https://issues.apache.org/jira/browse/JAMES-842
>             Project: James
>          Issue Type: Bug
>    Affects Versions: 3.0
>            Reporter: David Jencks
>            Assignee: Stefano Bagnara
>             Fix For: 3.0
>         Attachments: JAMES-840-2.patch, JAMES-842.patch
> I've found a couple inconsistencies in the spring integration:
> in AvalonConfigurationFileProvider InputSource is supplied a systemId for the james config
files whereas in AvalonBeanDefinitionReader it is not.  In my scenario this means that the
entities in james-config.xml don't work because for AvalonConfigurationFileProvider the entities
are resolved relative to the james-config.xml file location whereas for AvalonBeanDefinitionReader
they are resolved relative to some base directory.
> There's a FileSystem bean supplied to spring to locate stuff in the file system but it
is not used in AvalonConfigurationFileProvider; AFAICT this means that configuration files
must be in the classpath.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message