Re: [jira] Closed: (IBATIS-580) SQLExecutor plug-ins for iBATIS2
Thanks. Regards, Abhigyan "Clinton Begin (JIRA)" 13/03/2009 09:48 To Abhigyan Agrawal1/India/i...@ibmin cc Subject [jira] Closed: (IBATIS-580) SQLExecutor plug-ins for iBATIS2 [ https://issues.apache.org/jira/browse/IBATIS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clinton Begin closed IBATIS-580. Resolution: Fixed Assignee: Clinton Begin Fixed. Mostly as described, with some refactorings to use naming conventions. Property to override SqlExecutor implementation is 'named sql_executor_class' > SQLExecutor plug-ins for iBATIS2 > > > Key: IBATIS-580 > URL: https://issues.apache.org/jira/browse/IBATIS-580 > Project: iBatis for Java > Issue Type: Improvement > Components: SQL Maps >Affects Versions: 2.3.4 > Environment: Platform independent >Reporter: Abhigyan Agrawal >Assignee: Clinton Begin > Fix For: 2.3.4 > > Attachments: junitResults.tar, plugin.patch, src.tar > > > The attached patch file provides the ability in to override the default 'SQLExecutor' if required in v2. > No new test cases need to be added for this functionality, since the existing test cases regress these changes. Attached are the ibatis test suites results executed with these changes. > __ > Attachments: > junitResults.tar - iBATIS test suite results with plug-in changes. > src.tar - Source for plug-in changes. > plugin.patch - patch file for plug-in changes. > __ > Usage Description > * User defines a property 'ibatis.sqlExecutor_class' in the iBatis properties file. The value is set to the name of the class (user developed) that implements the interface com.ibatis.sqlmap.engine.execution.ISqlExecutor > Description of code changes > 1. com.ibatis.sqlmap.engine.execution.ISqlExecutor >- new interface which consists of all the public methods of the the default SQLExecutor in iBATIS - com.ibatis.sqlmap.engine.execution.SqlExecutor > 2. com.ibatis.sqlmap.engine.execution.SqlExecutor >The default SQLExecutor now implements the ISqlExecutor interface > 3. com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate >- Changed the type of the member variable 'sqlExecutor' to the interface ISqlExectuor >- changed return type of method getSqlExecutor() to ISqlExecutor from SqlExecutor >- added method setCustomExecutor(string sqlExecutorClass). > **Instantiates user specified class that implements interface com.ibatis.sqlmap.engine.execution.SqlExecutor > >4. com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.java, ExtendedSqlMapClient.java, SqlMapClientImpl.java, com.ibatis.sqlmap.engine.mapping.statement.MappedStatement > - changed the return type of method getSqlExecutor() to ISqlExecutor from SqlExecutor >5. com.ibatis.sqlmap.engine.builder.xml.XmlParserState >setGlobalProperties() - If the 'ibatis.sqlExecutor_class' property is defined in the properties file, reads it and invokes SqlMapExecutorDelegate.setCustomExecutor(valueOfDefinedSqlExecutor) > ** The SqlMapExecutorDelegate instantiates the default SQLExecutor in its constructor. Initially had removed this and had the sqlExecutor always instantiated via a setter. With this XmlParserState.setGlobalProperties() always called the setter, to instantiate the Default or user-overridden sqlExecutor. The problem with this was that it is not mandatory to have a ibatis properties file, in which case the XmlParserState.setGlobalProperties() is not invoked. Given the parsing logic, couldn't find a appropriate place to invoke the getter to instantiate the default SQLExecutor and reverted to having it instantiated in the constructor > setCustomExecutor re-initializes the 'sqlExecutor'. Assumed this is OK, since it is always invoked during config setup and hence also the reinitialization doesn't need to be synchronized. > * It could have been possible to have this via a new property defined in the SqlMapConfig.xml. However given how many folks are probably going to use it, and the amount of changes, chose the property file approach. > 4 March 2009: Changed property name from 'sqlExecutor' to 'ibatis.sqlExecutor_class'. Updated patch and source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IBATIS-580) SQLExecutor plug-ins for iBATIS2
[ https://issues.apache.org/jira/browse/IBATIS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clinton Begin closed IBATIS-580. Resolution: Fixed Assignee: Clinton Begin Fixed. Mostly as described, with some refactorings to use naming conventions. Property to override SqlExecutor implementation is 'named sql_executor_class' > SQLExecutor plug-ins for iBATIS2 > > > Key: IBATIS-580 > URL: https://issues.apache.org/jira/browse/IBATIS-580 > Project: iBatis for Java > Issue Type: Improvement > Components: SQL Maps >Affects Versions: 2.3.4 > Environment: Platform independent >Reporter: Abhigyan Agrawal >Assignee: Clinton Begin > Fix For: 2.3.4 > > Attachments: junitResults.tar, plugin.patch, src.tar > > > The attached patch file provides the ability in to override the default > 'SQLExecutor' if required in v2. > No new test cases need to be added for this functionality, since the existing > test cases regress these changes. Attached are the ibatis test suites results > executed with these changes. > __ > Attachments: > junitResults.tar - iBATIS test suite results with plug-in changes. > src.tar - Source for plug-in changes. > plugin.patch - patch file for plug-in changes. > __ > Usage Description > * User defines a property 'ibatis.sqlExecutor_class' in the iBatis > properties file. The value is set to the name of the class (user developed) > that implements the interface com.ibatis.sqlmap.engine.execution.ISqlExecutor > Description of code changes > 1. com.ibatis.sqlmap.engine.execution.ISqlExecutor >- new interface which consists of all the public methods of the the > default SQLExecutor in iBATIS - com.ibatis.sqlmap.engine.execution.SqlExecutor > 2. com.ibatis.sqlmap.engine.execution.SqlExecutor >The default SQLExecutor now implements the ISqlExecutor interface > 3. com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate >- Changed the type of the member variable 'sqlExecutor' to the > interface ISqlExectuor >- changed return type of method getSqlExecutor() to ISqlExecutor from > SqlExecutor >- added method setCustomExecutor(string sqlExecutorClass). > **Instantiates user specified class that implements interface > com.ibatis.sqlmap.engine.execution.SqlExecutor > >4. com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.java, > ExtendedSqlMapClient.java, SqlMapClientImpl.java, > com.ibatis.sqlmap.engine.mapping.statement.MappedStatement > - changed the return type of method getSqlExecutor() to ISqlExecutor > from SqlExecutor >5. com.ibatis.sqlmap.engine.builder.xml.XmlParserState > setGlobalProperties() - If the 'ibatis.sqlExecutor_class' property is > defined in the properties file, reads it and invokes > SqlMapExecutorDelegate.setCustomExecutor(valueOfDefinedSqlExecutor) > ** The SqlMapExecutorDelegate instantiates the default SQLExecutor in its > constructor. Initially had removed this and had the sqlExecutor always > instantiated via a setter. With this XmlParserState.setGlobalProperties() > always called the setter, to instantiate the Default or user-overridden > sqlExecutor. The problem with this was that it is not mandatory to have a > ibatis properties file, in which case the > XmlParserState.setGlobalProperties() is not invoked. Given the parsing logic, > couldn't find a appropriate place to invoke the getter to instantiate the > default SQLExecutor and reverted to having it instantiated in the constructor > setCustomExecutor re-initializes the 'sqlExecutor'. Assumed this is OK, > since it is always invoked during config setup and hence also the > reinitialization doesn't need to be synchronized. > * It could have been possible to have this via a new property defined in the > SqlMapConfig.xml. However given how many folks are probably going to use it, > and the amount of changes, chose the property file approach. > 4 March 2009: Changed property name from 'sqlExecutor' to > 'ibatis.sqlExecutor_class'. Updated patch and source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
