GeoServer JDBC DataStore should be able to use external J2EE/JNDI Connection pools

I made some tests to check if GeoServer could be able to use external J2EE/JNDI connection pools instead of its internal one (ConnectionPool class in gt2-main).

This issue is linked with GEOT-489 I also filled/completed with the following text (resulting of some mails).
Working on this issue will imply to create a specific issue about Oracle to resolve some Oracle specific difficulties listed below.

########################
Ok, so here is the code we wrote for our tests (5 joined files) :

• OracleJNDIDataStore.java : an extention of OracleDataStore with specific createConnection and getSqlBuilder methods.
• OracleJNDIDataStoreFactory : an extention of OracleOCIDataStoreFactory with specific canProcess and createDataStore methods.
• WithSchemaSQLBuilder : an extention of DefaultSQLBuilder (used by Oracle
• SDOAttributeIO [oraclespatial] : a file modified to "extract from JBoss connection pool" the underlying OracleConnection (look for WrappedConnection word)
• OracleFeatureWriter [oraclespatial] : a file modified to "extract from JBoss connection pool" the underlying OracleConnection (look for WrappedConnection word)

Explanations :

• JNDI is "just" a directory that handles objects identified by textual keys. JBoss like other J2EE app-servers provides some javax.sql.DataSource trought JNDI.
  Look for InitialContext word in OracleJNDIDataStoreFactory to see how it is used (that is really simple)
• The parameter of OracleJNDIDataStore are identical (in number and types) to the parameters of OracleDataStore with 2 differences :
• the dbtype value is 'oracleJ' and not 'oracle'
• the alias key must be understand like the "JNDI textual id" and not the DB name.
• WithSchemaSQLBuilder is an other stuff that I wanted to provide later but that already work : the table names (in the FROM part of SQL queries) are prefixed with the user (aka schema) name so tables and data can be accessed in a specific schema (schema key of the datastore) through a "super user" (user key of the datastore) [see also GEOT-1005]
• SDOAttributeIO and OracleFeatureWriter are the 2 files that I modified to acces the underlying OracleConnection. Here is the bad work because it references some JBoss classes.
  Just take note that the underlying connection can not be used instead of the pool connection : the pool connection (WrappedConnection) is needed to handled some specific methods (like 'close') that helps to manage the pool.