Grokbase Groups Cayenne user May 2008
FAQ
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

Search Discussions

  • Fixe106 at May 20, 2008 at 3:09 pm
    Hi
    Like you, I load only from classpath and WEB-INF
    best regards
    Julien
    Le Tue, 20 May 2008 16:38:48 +0200, Andrus Adamchik
    <andrus@objectstyle.org> a écrit:
    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
  • Philip Miller at May 20, 2008 at 4:23 pm
    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
    Sent: 20 May 2008 15:39
    To: user@cayenne.apache.org
    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.
  • Andrus Adamchik at May 20, 2008 at 5:46 pm
    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
    Sent: 20 May 2008 15:39
    To: user@cayenne.apache.org
    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.
  • Mike Kienenberger at May 20, 2008 at 5:23 pm
    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

  • Kevin Menard at May 20, 2008 at 5:33 pm
    I use #3.

    I have all of my Persistent objects in one module that bundles up the
    DataMap. Each app that uses them provides its own DataNode. It makes
    deployment to different environments really nice. It also lets me
    swap out test and production DataNodes really simply.

    I'm not married to that one way of doing things, but I would like to
    see that use case addressed somehow.

    --
    Kevin
    On May 20, 2008, at 10:38 AM, 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?
  • Andrus Adamchik at May 20, 2008 at 5:44 pm

    On May 20, 2008, at 8:33 PM, Kevin Menard wrote:

    I have all of my Persistent objects in one module that bundles up
    the DataMap. Each app that uses them provides its own DataNode. It
    makes deployment to different environments really nice. It also
    lets me swap out test and production DataNodes really simply.

    I'm not married to that one way of doing things, but I would like to
    see that use case addressed somehow.
    Addressing it in a Modeler-friendly fashion is the whole point here.
    The idea is to get rid of workarounds like yours (or cdeploy Ant
    task). Here is a Wiki link to the raw design description of this
    feature:

    http://cwiki.apache.org/CAY/runtime-metadata-merging.html

    So you'll simply have multiple full Cayenne projects (one per module
    that define DataMaps, and one in the application that defines
    DataNodes and links DataMaps to them). Each project can be opened and
    manipulated in the modeler independently from each other. So it makes
    possible environment-agnostic "Cayenne libraries" (or "persistence
    units" in JPA speak) that can be combined with other such libraries
    and shared between the projects.

    Andrus
  • Kevin Menard at May 21, 2008 at 3:01 am
    Then +1 from me. One shortcoming of my approach is that the Modeler
    auto-generates any missing DataNode, so if I want to manipulate my
    DataMap, I have to remember to delete the generated DataNode or risk a
    lot of confusion.

    --
    Kevin
    On May 20, 2008, at 1:44 PM, Andrus Adamchik wrote:

    On May 20, 2008, at 8:33 PM, Kevin Menard wrote:

    I have all of my Persistent objects in one module that bundles up
    the DataMap. Each app that uses them provides its own DataNode.
    It makes deployment to different environments really nice. It also
    lets me swap out test and production DataNodes really simply.

    I'm not married to that one way of doing things, but I would like
    to see that use case addressed somehow.
    Addressing it in a Modeler-friendly fashion is the whole point here.
    The idea is to get rid of workarounds like yours (or cdeploy Ant
    task). Here is a Wiki link to the raw design description of this
    feature:

    http://cwiki.apache.org/CAY/runtime-metadata-merging.html

    So you'll simply have multiple full Cayenne projects (one per module
    that define DataMaps, and one in the application that defines
    DataNodes and links DataMaps to them). Each project can be opened
    and manipulated in the modeler independently from each other. So it
    makes possible environment-agnostic "Cayenne libraries" (or
    "persistence units" in JPA speak) that can be combined with other
    such libraries and shared between the projects.

    Andrus
  • Borut Bolčina at May 23, 2008 at 8:42 am
    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 <andrus@objectstyle.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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupuser @
categoriescayenne
postedMay 20, '08 at 2:39p
activeMay 23, '08 at 8:42a
posts9
users6
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase