Hi,
I use this
Configuration conf;
if (pathWithConfigurationFiles != null) {
conf = new FileConfiguration("cayenne.xml");
// Cayenne configuration files can be found at this location
((FileConfiguration) conf).addFilesystemPath(new
File(pathWithConfigurationFiles));
Configuration.initializeSharedConfiguration(conf);
} else {
conf = Configuration.getSharedConfiguration();
}
boolean failed =
Configuration.getSharedConfiguration().getLoadStatus().hasFailures();
if (failed) {
String message = "Error initializing Cayenne Configuration";
logger.fatal(message);
System.exit(1);
}
-borut
2008/5/20 Andrus Adamchik <andru..bjectstyle.org>:
> Wanted to check if anybody loads "cayenne.xml" and related Map and Node XML
> files from locations other than default two: CLASSPATH and WEB-INF/ ? More
> specifically:
>
> 1. anybody uses FileConfiguration?
> 2. anybody uses DefaultConfiguration (with 'addResourcePath' or without) to
> directly reference file in the filesystem (vs. referencing resources in
> classpath)?
> 3. anybody places DataMap / DataNode files in (jar) directories outside of
> the directory where "cayenne.xml" is located?
>
> I personally don't, as all these approaches lead to non-portable
> applications that make unwarranted assumptions about the environment. I
> think cases requiring to open cayenne.xml via the application UI are special
> enough to warrant a custom configuration.
>
> Some background. I am planning a rework of the config package to include
> support for merging of multiple Cayenne projects into a single "virtual
> project" in runtime (hence enabling multiple "persistent units" in the app).
> So I am looking to simplify this task and stop supporting edge cases that
> are not widely used, and also change the basic algorithm of resolving files
> relative to cayenne.xml to ensure they are actually relative to the URL
> within a JAR or class folder where cayenne.xml is found (so that we can have
> multiple cayenne.xml files and avoid conflicts when loading dependent XML
> files of those).
>
> I think there is a lot of benefit in keeping the built-in choices of file
> lookup down to just a few basic ones, and of course the users can still
> write their own Configuration extensions to address non-standard
> requirements.
>
> Andrus
>
>
>
This archive was generated by hypermail 2.0.0 : Fri May 23 2008 - 04:42:33 EDT