cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <>
Subject Re: [POLL] loading XML configurations from filesystem
Date Tue, 20 May 2008 17:23:18 GMT
I thought for sure that I used both 1. and 2., but upon reviewing my
various applications, everything now uses or subclasses
DefaultConfiguration and calls config.addClassPath().

On 5/20/08, Andrus Adamchik <> wrote:
> 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

View raw message