Affects: Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes Complexity: High Date of First Response: 2008-12-22 11:50:01 project_key: SOA The jdbc driver needs to support jdk 1.5 on the client.
This is not requirement for the open source of the product. This should not be fixed.
Affects: Added: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes] Complexity: Added: High
I have added some language processing identifiers in the code like //## JDBC4.0-begin ## import java.sql.SQLXML; //## JDBC4.0-end ## /*## JDBC3.0-JDK1.5-begin ## import com.metamatrix.core.jdbc.SQLXML; ## JDBC3.0-JDK1.5-end ##*/ which by use of additional ant tasks during the build can turn ON or OFF certain portions of the code, that suits for the required 1.5 or 1.6 compilation of the code. The following projects have these processors teiid-common-core teiid-client teiid-client-jdbc A new project called teiid-client-jdbc30 has been added for purposes of building the JDK1.5 supported client jar file. This project copies the all the required java files from above projects and runs the language processors and builds 1.5 compatible code and builds the required jar file. I am not planning on putting any build related automation work, as they may be very time consuming right now, we will build it manually at release time and include in any kits. Testing is still pending.
Moving the testing until Teiid have stable Server build
Moving to 6.3, as there is no real requirement to finish this in 6.2
Pushing to 7.1 and reducing the priority on this to critical. There are new schools thought to use tools like http://retroweaver.sourceforge.net/ to achieve the similar effect. This needs to be investigated and tested if the above approach is not taken.
1.5 support is relatively easy to achieve with retrotranslator, but there are some issues. We need to add backports of NClob, Wrapper, and SQLXML. There is also a non-public method that needs exposed on ObjectStreamClass. The worst thing though is that PlanNode depends upon JAXB, which is not in older JREs by default. We would either need to provide a JAXB free backport, or require that the customer installs JAXB. With those changes though I was able to successfully query a 7.0 server using a 1.5 JRE client. Moving back to 1.4 would then not be that difficult, but would require a couple of changes to add support for a few missing JRE methods.
I should mention that the retro approach has the drawback that we do not get compile time safety as with the comment based approach. Errors are only noticeable when executing. The advantage though is that we won't have to mark up our code and we can make it to 1.4 support.
I am now inclined to remove the comment based approach. There are a couple of reasons for this. 1. with ODBC support there is another possible path of using a 1.5 (or older) client with the JDBC-ODBC bridge to call a Teiid 7.1. The limitations here would be JDBC extensions and transaction support, but at least for local transactions support could be added (there is already a JIRA on the ANSI syntax, but we could just reuse the set statement logic to allow SET AUTOCOMMIT OFF|ON). 2. The comment based approach will only allow us to get to 1.5, not 1.4 - which would probably be just as common of a legacy environment (just based upon our MetaMatrix customer experience). Our client server code is littered with 1.5 constructs and cannot through simple commenting be reverted to 1.4 support. So we'll need to revisit what we really intend to support here, are we requiring a distribution jar, or would instructions on using retro tooling, or a workaround based on ODBC be sufficient.
Dropping to major priority and pushing to 7.2.
Security: Added: Public
Link: Added: This issue Cloned to SOA-2958
Duplicate of SOA-2999