[OpenEMed-commits] OpenEMed/dist/servers/pids OJB.properties, 1.13, 1.14

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/openmed/OpenEMed/dist/servers/pids
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv27288

Modified Files:
	OJB.properties 
Log Message:
Updated for OJB 1.0.4


Index: OJB.properties
===================================================================
RCS file: /cvsroot/openmed/OpenEMed/dist/servers/pids/OJB.properties,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** OJB.properties	22 Apr 2005 05:30:08 -0000	1.13
--- OJB.properties	3 Nov 2006 23:53:23 -0000	1.14
***************
*** 27,31 ****
  # repository. The file is looked up from the classpath.
  #
- #repositoryFile=repository.xml
  repositoryFile=ojb//config//hsqldb_repository.xml
  #
--- 27,30 ----
***************
*** 65,68 ****
--- 64,76 ----
  #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
  #
+ #
+ # This setting can be helpful during development if the PersistenceBroker transaction
+ # demarcation was used (this is true in most cases). If set 'true' on PB#store(...)
+ # and PB#delete(...) methods calls OJB check for active PB-tx and if no active tx is
+ # found a error is logged. This can help to avoid store/delete calls without a running
+ # PB-tx while development. Default setting is 'false'. (Note: When using OJB in a managed
+ # environment *without* OJB-caching, it's valid to use store/delete calls without a running PB-tx)
+ TxCheck=false
+ #
  #----------------------------------------------------------------------------------------
  # PersistenceBroker pool
***************
*** 134,139 ****
  ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
  #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl
- #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
  #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
  #
  #
--- 142,149 ----
  ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
  #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl
  #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
+ # Only needed when using OJB 1.0.3 or earlier in managed environments. Since version
+ # 1.0.4 OJB detects datasources from managed environments automatically.
+ #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
  #
  #
***************
*** 153,162 ****
  #
  #----------------------------------------------------------------------------------------
! # IndirectionHandler
  #----------------------------------------------------------------------------------------
  # The IndirectionHandlerClass entry defines the class to be used by OJB's proxies to
  # handle method invocations
  #
! IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
  #
  #----------------------------------------------------------------------------------------
--- 163,189 ----
  #
  #----------------------------------------------------------------------------------------
! # ProxyFactory and IndirectionHandler
  #----------------------------------------------------------------------------------------
+ # The ProxyFactoryClass entry defines which ProxyFactory implementation is to be used.
+ # By default, a 1.0 compatiable, JDK-based version is used. However, a the CGLIB based entry 
+ # is available.
+ #
+ #	- ProxyFactoryCGLIBImpl: Refernece proxies are generated using bytecode manipulation
+ #			from the CGLIB library. Any class can become a dynamic proxy, and not just ones
+ #			that implement an interface.
+ #   - ProxyFactoryJDKImpl: OJB 1.0 compatiable Proxy implementation. Proxies in this method 
+ #			can only be generated from classes that implement an interface, and the generated
+ #			Proxy will implement all methods of that interface.
+ #
+ # NOTE: The appropriate cooresponding IndirectionHandler must be choosen as well
+ #
+ #ProxyFactoryClass=org.apache.ojb.broker.core.proxy.ProxyFactoryCGLIBImpl
+ ProxyFactoryClass=org.apache.ojb.broker.core.proxy.ProxyFactoryJDKImpl
+ #
  # The IndirectionHandlerClass entry defines the class to be used by OJB's proxies to
  # handle method invocations
  #
! #IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerCGLIBImpl
! IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerJDKImpl
  #
  #----------------------------------------------------------------------------------------
***************
*** 213,231 ****
  RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
  #
  #----------------------------------------------------------------------------------------
  # Object cache
  #----------------------------------------------------------------------------------------
! # The ObjectCacheClass entry tells OJB which concrete ObjectCache
! # implementation is to be used as standard cache.
! # Its also possible to override this entry adding object-cache elements
! # on jdbc-connection-descriptor level and
! # per class-descriptor in repository file. More info see documentation.
! #
! ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
! #
  #
  # This property is only relevant if the per class-descriptor object-cache
--- 240,250 ----
  RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
  #
+ #
  #----------------------------------------------------------------------------------------
  # Object cache
  #----------------------------------------------------------------------------------------
! # NOTE: ObjectCacheClass declaration in OJB.properties file was removed (since OJB 1.0.2).
! # The concrete ObjectCache implementation has to specified in the repository file using
! # the 'object-cache' element. See documentation for more detailed info.
  #
  # This property is only relevant if the per class-descriptor object-cache
***************
*** 238,266 ****
  descriptorBasedCaches=false
  #
! #
! # Use CacheFilters to do filter operations before caching methods were
! # called. Build your own filter class by implementing org.apache.ojb.cache.CacheFilter.
! # It is possible to use a arbitrary number of CacheFilters, but this slows
! # down the performance of the cache, thus handle with care.
! #
! # - org.apache.ojb.broker.cache.CacheFilterClassImpl
! # allows filtering of classes
! # - org.apache.ojb.broker.cache.CacheFilterPackageImpl
! # allows filtering of packages
! # More info see Javadoc of the according classes.
! # Set a comma separated list of CacheFilter.
! #ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
! #
  #----------------------------------------------------------------------------------------
  # Locking
  #----------------------------------------------------------------------------------------
! # The LockManagerClass entry tells OJB which concrete LockManager
! # implementation is to be used.
! LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
  #
  # The LockMapClass entry tells OJB which concrete LockMap
  # implementation is to be used.
  # If OJB is running on multiple concurrent clients it is recommended
! # to use the RemoteLockMapImpl. It guarantees to provide
  # Lockmanagement across multiple JVMs.
  # This Implemenation relies on a Servlet based Lockserver. To use it you have to
--- 257,294 ----
  descriptorBasedCaches=false
  #
! # NOTE: CacheFilters declaration was removed (since OJB 1.0.2). To exclude
! # object of whole packages from being cache use a specific property in
! # cache declaration - see caching guide in reference docs.
  #----------------------------------------------------------------------------------------
  # Locking
  #----------------------------------------------------------------------------------------
! # The 'LockManagerClass' specify the internal used LockManager implementation.
! # If OJB is running in distributed environment it is recommended to use the remote
! # lock manager. It guarantees to provide Lockmanagement across multiple JVM's.
  #
+ # The deprecated odmg locking implementation. Needs enabled 'LockMapClass' too.
+ #@deprecated LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
+ # A servlet based lock implementation for distributed environments, needs enabled
+ # property 'LockServletUrl' too.
+ #LockManagerClass=org.apache.ojb.broker.locking.LockManagerRemoteImpl
+ # Lock manager implementation using apache's commons-transaction locking api
+ #LockManagerClass=org.apache.ojb.broker.locking.LockManagerCommonsImpl
+ LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
+ #
+ # The LockServletUrl entry points to the Lockserver servlet.
+ # This Servlet is addressed by all distributed JVMs if the RemoteLockMapImpl
+ # is used.
+ #LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
+ #
+ # The LockTimeout entry defines the maximum time in milliseconds
+ # that a lock may be hold. Defaults to 60000 = 1 minute
+ LockTimeout=60000
+ #
+ #
+ # ------ deprecated ------
  # The LockMapClass entry tells OJB which concrete LockMap
  # implementation is to be used.
  # If OJB is running on multiple concurrent clients it is recommended
! # to use the LockMapRemoteImpl. It guarantees to provide
  # Lockmanagement across multiple JVMs.
  # This Implemenation relies on a Servlet based Lockserver. To use it you have to
***************
*** 269,306 ****
  # (see LockServletUrl section below).
  # If OJB is running in a single JVM (e.g. in a desktop app, or in a servlet
! # engine) it is save to use the InMemoryLockMapImpl. Using it will result
  # in a large performance gain.
! #LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl
! LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
! #
! # The LockTimeout entry defines the maximum time in milliseconds
! # that a lock may be hold. Defaults to 60000 = 1 minute
! LockTimeout=60000
! #
! # The ImplicitLocking entry defines if implicit lock acquisition is
! # to be used. If set to true OJB implicitely locks objects to ODMG
! # transactions after performing OQL queries.
! # If implicit locking is used locking objects is recursive, that is
! # associated objects are also locked.
! # If ImplicitLocking is set to false, no locks are obtained in OQL
! # queries and there is also no recursive locking.
! ImplicitLocking=true
! #ImplicitLocking=false
! #
! #
! # The LockServletUrl entry points to the Lockserver servlet.
! # This Servlet is addressed by all distributed JVMs if the RemoteLockMapImpl
! # is used.
! LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
! #
! #
! # The LockAssociations entry defines the behaviour for the OJB
! # implicit locking feature. If set to WRITE (default) acquiring a write-
! # lock on a given object x implies write locks on all objects associated
! # to x. If set to READ implicit read-locks are acquired.
! # Acquiring a read-lock on x thus allways results in implicit read-locks
! # on all associated objects.
! #LockAssociations=READ
! LockAssociations=WRITE
  #
  #
--- 297,305 ----
  # (see LockServletUrl section below).
  # If OJB is running in a single JVM (e.g. in a desktop app, or in a servlet
! # engine) it is save to use the LockMapInMemoryImpl. Using it will result
  # in a large performance gain.
! # These settings are deprecated, only needed in conjunction with the old odmg 'LockManagerClass'
! # @deprecated LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl
! # @deprecated LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
  #
  #
***************
*** 309,323 ****
  #----------------------------------------------------------------------------------------
  # The OqlCollectionClass entry defines the collection type returned
! # from OQL queries. By default this value is set to DListImpl.
! # This will be good for most situations as DList allows maximum flexibility
! # in a ODMG environment. See also section 'ODMG settings'.
  # Using DLists for large resultsets may be bad for application performance.
  # For these scenarios you can use ArrayLists or Vectors.
  # Important note: the collections class to be used MUST implement the
! # interface org.apache.ojb.broker.ManageableCollection.
  #
! OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl
! # OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
! # OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector
  #
  # The SqlInLimit entry limits the number of values in IN-sql statement,
--- 308,323 ----
  #----------------------------------------------------------------------------------------
  # The OqlCollectionClass entry defines the collection type returned
! # from OQL queries. By default this value is set to a List.
! # This will be good for most situations. If you need the additional features of
! # DList (DList itself is persistable, support of predicate) comment in the DList
! # implementation. See also section 'ODMG settings' (DListClass entry).
  # Using DLists for large resultsets may be bad for application performance.
  # For these scenarios you can use ArrayLists or Vectors.
  # Important note: the collections class to be used MUST implement the
! # interface 'org.apache.ojb.broker.ManageableCollection'.
  #
! OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
! # OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl
! # OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableVector
  #
  # The SqlInLimit entry limits the number of values in IN-sql statement,
***************
*** 327,331 ****
  #
  #----------------------------------------------------------------------------------------
! # ODMG settings
  #----------------------------------------------------------------------------------------
  # Specify the used base class for ODMG API
--- 327,331 ----
  #
  #----------------------------------------------------------------------------------------
! # ODMG-api settings
  #----------------------------------------------------------------------------------------
  # Specify the used base class for ODMG API
***************
*** 337,341 ****
  #ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl
  #
- #
  # Specify the used tx handling.
  # - LocalTxManager use if you want the transaction to be associated by a thread
--- 337,340 ----
***************
*** 347,350 ****
--- 346,379 ----
  #
  #
+ # The ImplicitLocking entry defines if implicit lock acquisition is
+ # to be used. If set to 'true' OJB implicitly locks objects to ODMG
+ # transactions after performing OQL queries.
+ # Also if implicit locking is used locking objects is recursive, that is
+ # associated objects are also locked.
+ # If ImplicitLocking is set to 'false', no locks are obtained in OQL
+ # queries, lookup objects and there is also no recursive locking.
+ # This setting can be changed at runtime using OJB's ODMG extensions.
+ ImplicitLocking=true
+ #ImplicitLocking=false
+ #
+ # The LockAssociations entry defines the behaviour for the OJB
+ # implicit locking feature. If set to WRITE (default) acquiring a write-
+ # lock on a given object x implies write locks on all objects associated
+ # to x. If set to READ implicit read-locks are acquired.
+ # Acquiring a read-lock on x allways results in implicit read-locks
+ # on all associated objects (if 'implicit locking' is enabled).
+ # This setting can be changed at runtime using OJB's ODMG extensions.
+ #LockAssociations=READ
+ LockAssociations=WRITE
+ #
+ # Enable/Disable OJB's persistent object ordering algorithm on commit
+ # of a transaction. If enabled OJB try to calculate a valid order for
+ # all new/modified objects (and referenced objects).
+ # If the used databases support 'deferred checks' it's recommended to use this
+ # feature and to disable OJB's object ordering.
+ # This setting can be changed at runtime using OJB's ODMG extensions.
+ Ordering=true
+ #
+ #
  # Used ODMG collection implementation classes
  # (e.g. when do a Implementation#newDlist() call)
***************
*** 366,369 ****
--- 395,407 ----
  #
  #
+ # @deprecated property for backward compatibility.
+ # If set 'true' the behavior of method
+ # ImplementationImpl#setImplicitLocking(...) will be the same as
+ # in OJB <=1.0.3 (set the implicit locking behavior of the current used transaction)
+ # and disable the new possibility of global 'implicit locking'
+ # setting at runtime with ImplementationExt#setImplicitLocking.
+ # This is only for backward compatibility and will
+ # be removed at a later date.
+ ImplicitLockingBackward=false
  #----------------------------------------------------------------------------------------
  # Meta data / mapping settings
***************
*** 394,411 ****
  #   (directly, as a bean, as a dyna bean) and then uses that strategy
  #
! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl
  #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl
  #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl
! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanAccessImpl
! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
! #
! # Here are the new upcoming PersistentField implementations. These classes will replace the
! # 'old' ones on next release. They pass the test-suite, but should be tested by community too.
! # The new implementations are about 50 times faster in handling nested fields.
! PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImplNew
! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImplNew
  #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
- #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanImplNew
  #(DynaBean implementation does not support nested fields)
  #
--- 432,440 ----
  #   (directly, as a bean, as a dyna bean) and then uses that strategy
  #
! PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectImpl
  #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl
  #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl
! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanImpl
  #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
  #(DynaBean implementation does not support nested fields)
  #