⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 repository.dtd

📁 一个Struts写的网上购物系统,是一个不错的实例.
💻 DTD
📖 第 1 页 / 共 3 页
字号:
<!-- @version $Id: $ -->
<!--
	ObJectRelationalBridge - Bridging Java objects and relational dabatases
	This DTD describes the grammar of the Descriptor repository
	Author: Thomas Mahler, (c) 2000, 2001, 2002, 2003
  -->

<!--
	The descriptor-repository is the root element of a
    repository.xml file.
	It consists of one jdbc-connection-descriptor and at least one
	class-descriptor element.

	The attribute element allows to add custom attributes.

    The jdbc-connection-descriptor element specifies the default jdbc
	connection for the repository.

	class-descriptor elements specify o/r mapping information for
	persistent classes.
  -->
<!ELEMENT descriptor-repository (documentation?, attribute*, jdbc-connection-descriptor*, class-descriptor*)>

<!--
	The version attribute is used to bind a repository.xml
    file to a given version of this dtd. This will help to
    avoid versions conflicts.

    The isolation attribute defines the default isolation level for
    class-descriptor on ODMG api level that do not define a
    specific isolation level (this does NOT touch the jdbc-level
    of the connection).
  -->
<!ATTLIST descriptor-repository
	version (1.0) #REQUIRED
	isolation-level (read-uncommitted | read-committed | repeatable-read |
	                 serializable | optimistic) "read-uncommitted"
	proxy-prefetching-limit CDATA "50"
>

<!--
	The documentation element can be used to store arbitrary
	information on all repository entries.
-->
<!ELEMENT documentation (#PCDATA)>

<!--
	The attribute element allows to add custom attributes.

    The jdbc-connection-descriptor element specifies the a jdbc
	connection for the repository.

	A connection-pool element may be used to define connection pool
	properties for the specified JDBC connection.

    A sequence-manager element may be used to
    define which sequence manager implementation should be used within
    the defined connection.
  -->
<!ELEMENT jdbc-connection-descriptor (documentation?, attribute*, object-cache?, connection-pool?, sequence-manager?)>

<!--
    The jcdAlias attribute is a shortcut name for the defined connection
    descriptor. OJB use jcdAlias as key for the defined connections.

    The default-connection attribute used to define if this connection
    should used as default connection with OJB. You could define only
    one connection as default connection. It is also possible to set
    the default connection at runtime using
    PersistenceBrokerFactory#setDefaultKey(...) method.
    If set 'true' you could use on PB-api a shortcut-method of the
    PersistenceBrokerFactory to lookup PersistenceBroker instances.

    The platform attribute is used to define the specific RDBMS
    Platform. This attribute corresponds to a
	org.apache.ojb.broker.platforms.PlatformXXXImpl class.

	The jdbc-level attribute is used to specify the Jdbc compliance
	level of the used Jdbc driver.

    The eager-release attribute was adopt to solve a problem occured when
    using OJB within JBoss (>=3.0). Only use within JBoss.

    The batch-mode attribute allow to set batch mode modus global
    from the used connection. It is also possible to change
    batch mode at runtime, using the
    PB.serviceConnectionManager.setBatchMode(...) method.

    The useAutoCommit attribute allow to set how OJB uses
    the autoCommit state of the used connections. The default mode
    was 1. When using mode 0 or 2 with the PB-api, you must use PB
    transaction demarcation.
    0 - OJB ignores the autoCommit setting of the connection and do not
        try to change it. This mode could be helpfully if the
        connection don't let you set the autoCommit state
        (e.g. using datasources from application server).
    1 - set autoCommit explicit 'true' when connection was created
        and temporary set to 'false' when necessary (default mode).
    2 - set autoCommit explicit 'false' when connection was created.

    If the ignoreAutoCommitExceptions attribute is set 'true', all
    exceptions caused by setting autocommit state, will be ignored.
    Default mode 'false'.

	If a jndi-datasource-name for JNDI based lookup of Jdbc
    connections is specified, the four attributes driver, protocol,
    subprotocol, dbalias used for Jdbc DriverManager based construction
    of Jdbc Connections must not be declared.

    The username and password attributes are used as credentials
    for obtaining a jdbc connections.
    If users don't want to keep this information the
    repository.xml file, they could pass user/password
    using PBKey.java to obtain a PersistenceBroker
  -->
<!ATTLIST jdbc-connection-descriptor
	jcd-alias CDATA #REQUIRED
    default-connection (true | false) "false"
    platform (Db2 | Hsqldb | Informix | MsAccess | MsSQLServer |
	          MySQL | Oracle | PostgreSQL | Sybase | SybaseASE |
              SybaseASA | Sapdb | Firebird | Axion | NonstopSql |
              Oracle9i ) "Hsqldb"
	jdbc-level (1.0 | 2.0 | 3.0) "1.0"
	eager-release (true | false) "false"
    batch-mode (true | false) "false"
    useAutoCommit (0 | 1 | 2) "1"
    ignoreAutoCommitExceptions (true | false) "false"

	jndi-datasource-name CDATA #IMPLIED

	driver CDATA #IMPLIED
	protocol CDATA #IMPLIED
	subprotocol CDATA #IMPLIED
	dbalias CDATA #IMPLIED

	username CDATA #IMPLIED
	password CDATA #IMPLIED
>


<!--
    The object-cache element can be used to specify the ObjectCache
    implementation used by OJB. There are three levels of
    declaration:
        1. in OJB.properties file, to declare the standard (default)
        ObjectCache implementation.
        2. on jdbc-connection-descriptor level, to declare ObjectCache implementation
        on a per connection/user level
        3. on class-descriptor level, to declare ObjectCache implementation
        on a per class level

    The priority of the declared object-cache elements are:
    per class > per jdbc descriptor > standard

    E.g. if you declare ObjectCache 'cacheDef' as standard, set
    ObjectCache 'cacheA' in class-descriptor for class A and class B
    does not declare an object-cache element. Then OJB use cacheA as ObjectCache
    for class A and cacheDef for class B
-->
<!ELEMENT object-cache (documentation?, attribute*)>

<!--
    Attribute 'class' specifies the full qualified class name of
    the used ObjectCache implementation.
-->
<!ATTLIST object-cache
    class                          CDATA #REQUIRED
>


<!--
	The connection-pool element specifies the connection pooling
	parameter.
-->
<!ELEMENT connection-pool (documentation?)>


<!--
	maxActive
	maximum number of connections that can be borrowed from the
	pool at one time. When non-positive, there is no limit.

	maxIdle
	controls the maximum number of connections that can sit idle in the
	pool at any time. When non-positive, there is no limit

	maxWait
	max time block to get connection instance from pool, after that exception is thrown.
	When non-positive, block till last judgement

	whenExhaustedAction
	0 - fail when pool is exhausted
	1 - block when pool is exhausted
	2 - grow when pool is exhausted

	testOnBorrow
	The pool will attempt to validate each object before it is returned from the pool

	testOnReturn
	The pool will attempt to validate each object before it is returned to the pool

	testWhileIdle
	Indicates whether or not idle objects should be validated.
	Objects that fail to validate will be dropped from the pool

	timeBetweenEvictionRunsMillis
	indicates how long the eviction thread should sleep before "runs" of examining
	idle objects. When non-positive, no eviction thread will be launched.

	minEvictableIdleTimeMillis
	specifies the minimum amount of time that a connection may sit idle
	in the pool before it is eligable for eviction due to idle time.
	When non-positive, no connection will be dropped from the pool due
	to idle time alone (depends on timeBetweenEvictionRunsMillis > 0)

	numTestsPerEvictionRun
	The number of connections to examine during each run of the
	idle object evictor thread (if any)

    validationQuery
    Here you could specify a validation query used by pool to test a
    obtained connection (e.g. "select 1 from dual"), else a default query was
    used - if defined in the platform class for your database.

    logAbandoned
    Only supported when using
    org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
    ConnectionFactory implementation.
    Flag to log stack traces for application code which abandoned
    a Statement or Connection. Defaults to false. Logging of
    abandoned Statements and Connections adds overhead for
    every Connection open or new Statement because a
    stack trace has to be generated.

    removeAbandoned/removeAbandonedTimeout
    Only supported when using
    org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
    ConnectionFactory implementation.
    Flag to remove abandoned connections if they exceed the
    removeAbandonedTimeout. Set to true or false, default false.
    If set to true a connection is considered abandoned and
    eligible for removal if it has been idle longer than the
    removeAbandonedTimeout. Setting this to true can recover
    db connections from poorly written applications which
    fail to close a connection.

-->
<!ATTLIST connection-pool
    maxActive                       CDATA #IMPLIED
    maxIdle                         CDATA #IMPLIED
    maxWait                         CDATA #IMPLIED
    minEvictableIdleTimeMillis      CDATA #IMPLIED
    numTestsPerEvictionRun          CDATA #IMPLIED
    testOnBorrow                    (true|false) #IMPLIED
    testOnReturn                    (true|false) #IMPLIED
    testWhileIdle                   (true|false) #IMPLIED
    timeBetweenEvictionRunsMillis   CDATA #IMPLIED
    whenExhaustedAction             (0|1|2) #IMPLIED
    validationQuery                 CDATA #IMPLIED

    logAbandoned                    (true|false) #IMPLIED
    removeAbandoned                 (true|false) #IMPLIED
    removeAbandonedTimeout          CDATA #IMPLIED
>



<!--
	The sequence-manager element specifies the sequence
    manager implementation used for key generation. All
    sequence manager implementations shipped with OJB
    you will find under org.apache.ojb.broker.util.sequence
    If no sequence-manager is defined, OJB use a default one.
    For configuration examples please consult documentation.

    Use the attribute element to pass implementation specific
    properties. This depends on the used implementation class.
-->
<!ELEMENT sequence-manager (documentation?, attribute*)>

<!--
    The className attribute represents the full qualified class name
    of the desired sequence manager implementation - it is mandatory
    when using the sequence-manager element.
    All sequence manager implementations you find will under
    org.apache.ojb.broker.util.sequence package named as SequenceManagerXXXImpl.
    For configuration examples please consult documentation.
-->
<!ATTLIST sequence-manager
    className                       CDATA #REQUIRED
>



<!--
	For interfaces or abstract classes a class-descriptor holds a sequence of
	extent-class elements.

	For concrete classes it must have field-descriptors that describe primitive
	typed instance variables.
	References to other persistent entity classes are specified by
	reference-descriptor elements.
	Collections or arrays attributes that contain other persistent entity
	classes are specified by collection-descriptor elements

	Concrete base classes, may specify a sequence of extent-class elements,
	naming the derived classes.

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -