Hi Eric,
I like your idea about loading every config from classpath. I think
you are right, we should change it. About the proposed fallback
strategy I'm not sure. I think we should not try to mix up things to
much. Just let use add two different ConfigurationRegistry
implementations. One for classpath and one for file, so if someone
needs to load things from files he could just swap them out.
Bye,
Norman
2010/5/5 Eric Charles <eric.char...@u-mangate.com>:
> Hi,
>
> To run james in my ide (eclipse), I copied config files from
> server/spring-deployment/src/main/config/james to a directory called conf a
> level upon the root of my project.
> The resource loading via the file://conf was ok.
>
> After, I wanted to load via classpath to have smoother intergration in my
> ide and also thinking to later integration with 3rd parties (simply using
> james jars with embedded resources).
>
> I changed all needed file://conf/ to classpath: in the xml files
> (spring-beans,...).
> I also had to change in SpringConfigurationRegistry.getForComponent line 56
> from
> Resource r = loader.getResource("file://conf/" + name + ".xml");
> to
> Resource r = loader.getResource("classpath:" + name + ".xml");
>
> I looked for a system-wide configuration (in James.xml or whatever) that
> would allow to define the way resources are loaded (file or classpath) but
> didn't find anything.
>
> One way to tackle this would be first try on file://conf and rather than
> throwing directly the RegistryException, still give a try to classpath.
> In case of duplicate config present (file + classpath), the file would take
> the precedence, discarding the classpath.
> You could have a default classpath config, and simply override some via
> file.
>
> On pom.xml, we could also add the following (direct ide setup after mvn
> eclipse:eclipse).
>
> <build>
> <resources>
> <resource>
> <directory>src/main/resources</directory>
> </resource>
> </resources>
> ....
>
> In a first instance, for mvn package, everything could remain as such (all
> files copied to conf).
>
> Any comment?
> Tks,
>
> Eric
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
