[
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
https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk/geronimo-james/src/main/java/org/apache/geronimo/plugins/james/GeronimoAvalonApplicationContext.java
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
