FAQ
By the way, do we need this ConncetionProperties class in src/main/java?
Maybe move it to src/test/java?

2009/11/18 Olga Tkacheva (JIRA) <jira@apache.org>
rename 'cayenne.test.connection' to 'cayenneTestConnection' and add
configurations variables for tests

--------------------------------------------------------------------------------------------------------

Key: CAY-1311
URL: https://issues.apache.org/jira/browse/CAY-1311
Project: Cayenne
Issue Type: Task
Components: Cayenne Core Library
Affects Versions: 3.0 beta 1
Reporter: Olga Tkacheva


* rename 'cayenne.test.connection' to 'cayenneTestConnection' (Hudson
chokes on the variables with dots since it executes some of the relevant
scripts with Groovy).
* absorb the connection dictionary variables into the default config so
that we can run the tests against all Java dbs without needing any external
file. Even Derby can run with a completely in-memory database.



--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

--
Andrey

Search Discussions

  • Andrus Adamchik at Nov 18, 2009 at 9:59 am
    IIRC Ari also suggested the same thing. Now trying to remember why it
    was added to the core Cayenne in the first place. (did we use in the
    past in situations similar to the current JNDI hack??) Don't remember,
    and +1 on moving it out.

    Andrus
    On Nov 18, 2009, at 11:55 AM, Andrey Razumovsky wrote:

    By the way, do we need this ConncetionProperties class in src/main/
    java?
    Maybe move it to src/test/java?

    2009/11/18 Olga Tkacheva (JIRA) <jira@apache.org>
    rename 'cayenne.test.connection' to 'cayenneTestConnection' and add
    configurations variables for tests

    --------------------------------------------------------------------------------------------------------

    Key: CAY-1311
    URL: https://issues.apache.org/jira/browse/CAY-1311
    Project: Cayenne
    Issue Type: Task
    Components: Cayenne Core Library
    Affects Versions: 3.0 beta 1
    Reporter: Olga Tkacheva


    * rename 'cayenne.test.connection' to 'cayenneTestConnection' (Hudson
    chokes on the variables with dots since it executes some of the
    relevant
    scripts with Groovy).
    * absorb the connection dictionary variables into the default
    config so
    that we can run the tests against all Java dbs without needing any
    external
    file. Even Derby can run with a completely in-memory database.



    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.

    --
    Andrey
  • Andrey Razumovsky at Nov 18, 2009 at 10:22 am
    2009/11/18 Andrus Adamchik (did we use in the past in situations similar to the current JNDI hack??)
    >

    Andrus, could you describe more in detail this JNDI hack? I wish we could
    get rid of cayenne-modeler.jar
  • Andrus Adamchik at Nov 18, 2009 at 10:28 am

    On Nov 18, 2009, at 12:22 PM, Andrey Razumovsky wrote:

    2009/11/18 Andrus Adamchik <andrus@objectstyle.org>
    (did we use in the past in situations similar to the current JNDI
    hack??)
    Andrus, could you describe more in detail this JNDI hack? I wish we
    could
    get rid of cayenne-modeler.jar
    http://cayenne.apache.org/doc/using-jndi.html

    (see "Development with JNDI DataNodes")

    The reason why Modeler is need is to read the preferences DB. I am
    planning to replace custom Cayenne-driven Modeler preferences DB with
    standard Java Preferences API, and move all the preference read code
    to Cayenne core. Then we can get rid of Modeler dependency for JNDI
    hack.

    Andrus
  • Andrey Razumovsky at Nov 18, 2009 at 10:35 am
    I see. Actually here we use other approach. We have

    "cayenne.xml" - that is looking to DB via driver.xml and JDBC
    "cayenne.xml.web" - that is looking via JNDI.

    They both refer to same dataMap. In development we use cayenne.xml, during
    the build process we replace it with cayenne.xml.web (using Ant or Maven).
    No weird jars are required!

    2009/11/18 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 18, 2009, at 12:22 PM, Andrey Razumovsky wrote:

    2009/11/18 Andrus Adamchik <andrus@objectstyle.org>
    (did we use in the past in situations similar to the current JNDI hack??)
    Andrus, could you describe more in detail this JNDI hack? I wish we could
    get rid of cayenne-modeler.jar
    http://cayenne.apache.org/doc/using-jndi.html

    (see "Development with JNDI DataNodes")

    The reason why Modeler is need is to read the preferences DB. I am planning
    to replace custom Cayenne-driven Modeler preferences DB with standard Java
    Preferences API, and move all the preference read code to Cayenne core. Then
    we can get rid of Modeler dependency for JNDI hack.

    Andrus


    --
    Andrey
  • Andrus Adamchik at Nov 18, 2009 at 11:24 am
    Yeah, I tried to generalize this configuration a few times without
    much success. Swapping files is certainly one way to do it (see a
    recently removed "cdeploy" task). My issue with it is that connection
    info is stored with the project and is saved in SCM. I'd like to
    externalize it if possible.

    We'll see how the DI container work goes. Defining DataSourceFactories
    is certainly in scope for the container. Maybe we'll add something
    similar to what Olga just did for the unit tests - system property
    driven configuration.

    Andrus

    On Nov 18, 2009, at 12:34 PM, Andrey Razumovsky wrote:
    I see. Actually here we use other approach. We have

    "cayenne.xml" - that is looking to DB via driver.xml and JDBC
    "cayenne.xml.web" - that is looking via JNDI.

    They both refer to same dataMap. In development we use cayenne.xml,
    during
    the build process we replace it with cayenne.xml.web (using Ant or
    Maven).
    No weird jars are required!

    2009/11/18 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 18, 2009, at 12:22 PM, Andrey Razumovsky wrote:

    2009/11/18 Andrus Adamchik <andrus@objectstyle.org>
    (did we use in the past in situations similar to the current JNDI
    hack??)
    Andrus, could you describe more in detail this JNDI hack? I wish
    we could
    get rid of cayenne-modeler.jar
    http://cayenne.apache.org/doc/using-jndi.html

    (see "Development with JNDI DataNodes")

    The reason why Modeler is need is to read the preferences DB. I am
    planning
    to replace custom Cayenne-driven Modeler preferences DB with
    standard Java
    Preferences API, and move all the preference read code to Cayenne
    core. Then
    we can get rid of Modeler dependency for JNDI hack.

    Andrus


    --
    Andrey

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedNov 18, '09 at 9:56a
activeNov 18, '09 at 11:24a
posts6
users2
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase