Fair enough... I may have intentionally exaggerated the portability
claim and may argue about changing your specific setup (e.g. deploying
a full war or a jar to that single shared point of the server farm),
but I agree with you calling this the "ideal world", with real world
being all made of exceptions and edge cases.
As a practical matter I think we can support (1) and (2) in a multi-
cayenne.xml runtime (after all, files can be identified via URL's just
as well as jar components). And support (3) as well, detecting
conflicts on the fly and throwing an exception (2 DataMaps with the
same name located outside of any project roots, how do we merge them?)
So the refactoring I mentioned is not strictly necessary for things to
move forward. Although leaving them the way they are adds to the
Configuration hair ball... So it is very tempting to just leave it up
to the users to handle at least #3 by extending Configuration (per my
reply to Kevin, many cases of #3 would actually become obsolete).
Andrus
On May 20, 2008, at 7:22 PM, Philip Miller wrote:
Portability means different things in different contexts.
For example I might write an application which reads its config from a
UNC file path (\\foo\bar\cayenne.xml). That application is portable to
any environment which can see that path. It allows me to administer
configuration of an indefinitely scalable server farm from a single
point. That might be a desirable design feature in the context of my
application.
To answer your question I've used 1,2 and 3 at various times when it
was
appropriate to compromise on the ideal world solution.
Phil
-----Original Message-----
From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Sent: 20 May 2008 15:39
To: [email protected]
Subject: [POLL] loading XML configurations from filesystem
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
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless
specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
