Re: Does ibatis 2.x OSGi ready?

2009-08-05 Thread Larry Meadors
You could do this pretty transparently:

1) try Thread.blah.blah.blah to get the resource

2) if the resource is null, use Resources.class.getClassLoader()

Make the change, write a test, and attach the source files to a JIRA issue.

Larry


On Wed, Aug 5, 2009 at 8:34 PM, Argan wrote:
>
> 1. find which the jar "com.ibatis.common.resources.Resources" is in
> 2. load the resource "xxx.dtd" from the jar use the ClassLoader which load
> the "com.ibatis.common.resources.Resources" class
>
> this maybe work, and is inspired by the yui compressor's JarClassLoader
>
>
> Clinton Begin wrote:
>>
>> And how do you propose to do that?
>>
>> On 2009-08-05, Argan  wrote:
>>>
>>> We found a problem when use ibatis 2.3.4 in spring dm,ibatis can't find
>>> sql-map2.dtd,and try to resolve it by network.
>>>
>>> By digging the source
>>> code(com.ibatis.sqlmap.engine.builder.xml.SqlMapClasspathEntityResolver
>>> and
>>> com.ibatis.common.resources.Resources),we found ibatis will always find
>>> the
>>> resources in the jar with
>>> Thread.currentThread().getContextClassLoader(),but
>>> in OSGi environment,this class loader will be the other bundler's cl,so
>>> the
>>> issue occurs.
>>>
>>> To resolve this , we can use Resources.setDefaultClassLoader before
>>> ibatis
>>> is initalized,but this is not a very clean way.
>>>
>>> So, we suggest ibatis always find the dtd in the "JAR" and not in the
>>> classpath .
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Does-ibatis-2.x-OSGi-ready--tp24821444p24821444.html
>>> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
>>> For additional commands, e-mail: dev-h...@ibatis.apache.org
>>>
>>>
>>
>> --
>> Sent from my mobile device
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
>> For additional commands, e-mail: dev-h...@ibatis.apache.org
>>
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Does-ibatis-2.x-OSGi-ready--tp24821444p24839438.html
> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
> For additional commands, e-mail: dev-h...@ibatis.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
For additional commands, e-mail: dev-h...@ibatis.apache.org



Re: Does ibatis 2.x OSGi ready?

2009-08-05 Thread Argan

1. find which the jar "com.ibatis.common.resources.Resources" is in
2. load the resource "xxx.dtd" from the jar use the ClassLoader which load
the "com.ibatis.common.resources.Resources" class

this maybe work, and is inspired by the yui compressor's JarClassLoader
 

Clinton Begin wrote:
> 
> And how do you propose to do that?
> 
> On 2009-08-05, Argan  wrote:
>>
>> We found a problem when use ibatis 2.3.4 in spring dm,ibatis can't find
>> sql-map2.dtd,and try to resolve it by network.
>>
>> By digging the source
>> code(com.ibatis.sqlmap.engine.builder.xml.SqlMapClasspathEntityResolver 
>> and
>> com.ibatis.common.resources.Resources),we found ibatis will always find
>> the
>> resources in the jar with
>> Thread.currentThread().getContextClassLoader(),but
>> in OSGi environment,this class loader will be the other bundler's cl,so
>> the
>> issue occurs.
>>
>> To resolve this , we can use Resources.setDefaultClassLoader before
>> ibatis
>> is initalized,but this is not a very clean way.
>>
>> So, we suggest ibatis always find the dtd in the "JAR" and not in the
>> classpath .
>> --
>> View this message in context:
>> http://www.nabble.com/Does-ibatis-2.x-OSGi-ready--tp24821444p24821444.html
>> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
>> For additional commands, e-mail: dev-h...@ibatis.apache.org
>>
>>
> 
> -- 
> Sent from my mobile device
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
> For additional commands, e-mail: dev-h...@ibatis.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Does-ibatis-2.x-OSGi-ready--tp24821444p24839438.html
Sent from the iBATIS - Dev mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
For additional commands, e-mail: dev-h...@ibatis.apache.org



Re: Does ibatis 2.x OSGi ready?

2009-08-05 Thread Clinton Begin
And how do you propose to do that?

On 2009-08-05, Argan  wrote:
>
> We found a problem when use ibatis 2.3.4 in spring dm,ibatis can't find
> sql-map2.dtd,and try to resolve it by network.
>
> By digging the source
> code(com.ibatis.sqlmap.engine.builder.xml.SqlMapClasspathEntityResolver  and
> com.ibatis.common.resources.Resources),we found ibatis will always find the
> resources in the jar with Thread.currentThread().getContextClassLoader(),but
> in OSGi environment,this class loader will be the other bundler's cl,so the
> issue occurs.
>
> To resolve this , we can use Resources.setDefaultClassLoader before ibatis
> is initalized,but this is not a very clean way.
>
> So, we suggest ibatis always find the dtd in the "JAR" and not in the
> classpath .
> --
> View this message in context:
> http://www.nabble.com/Does-ibatis-2.x-OSGi-ready--tp24821444p24821444.html
> Sent from the iBATIS - Dev mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
> For additional commands, e-mail: dev-h...@ibatis.apache.org
>
>

-- 
Sent from my mobile device

-
To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
For additional commands, e-mail: dev-h...@ibatis.apache.org



[jira] Created: (IBATIS-621) Improper cache create mechanism

2009-08-05 Thread Yuan Tao (JIRA)
Improper cache create mechanism
---

 Key: IBATIS-621
 URL: https://issues.apache.org/jira/browse/IBATIS-621
 Project: iBatis for Java
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Yuan Tao
 Fix For: 3.0.0


My sql map has some ${XXX} tag, no #{..} tag. When execute it with deferent 
patameterObject in the one session, It retrurn the same result.

In BaseExecutor :

  public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, 
int offset, int limit) {
BoundSql boundSql = ms.getBoundSql(parameterObject);
CacheKey cacheKey = new CacheKey();
cacheKey.update(ms.getId());  // *  Maybe use  
cacheKey.update(boundSql.getSql()) is better.
cacheKey.update(offset);
cacheKey.update(limit);
List parameterMappings = boundSql.getParameterMappings();
if (parameterMappings.size() > 0 && parameterObject != null) {
..



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
For additional commands, e-mail: dev-h...@ibatis.apache.org



[jira] Commented: (IBATIS-620) "select count(*) from table" return BigDecimal value in Oracle

2009-08-05 Thread Yuan Tao (JIRA)

[ 
https://issues.apache.org/jira/browse/IBATIS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739392#action_12739392
 ] 

Yuan Tao commented on IBATIS-620:
-

The fix solution imported other bugs. so now, I have no idea to solve it. 

Should I need convert the result SqlSession.selectOne to Integer manually.

> "select count(*) from table" return BigDecimal value in Oracle
> --
>
> Key: IBATIS-620
> URL: https://issues.apache.org/jira/browse/IBATIS-620
> Project: iBatis for Java
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Yuan Tao
>
> User SqlSession.selectOne for the sql "select count(*) from table" defined in 
> mapping file should return Integer, but return BigDecimal in Oracle.
> The bug seems happen int DefaultResultSetHandler.mapResults method. There are 
> codes below:
> ...
> for (int i = 1, n = rsmd.getColumnCount(); i <= n; i++) {
>   boolean useLabel = 
> mappedStatement.getConfiguration().isUseColumnLabel();
>   String columnLabel = (useLabel ? rsmd.getColumnLabel(i) : 
> rsmd.getColumnName(i));
>   columnLabel = columnLabel.toUpperCase();
>   String propName = metaResultObject.findProperty(columnLabel);
>   colSet.add(columnLabel);
>   if (propName != null) {
> propSet.add(propName);
> Class javaType = metaResultObject.getSetterType(propName);
>   // This line will return Object if the resultObject is 
> PlatformTypeHolder
>   
> TypeHandler typeHandler = 
> typeHandlerRegistry.getTypeHandler(javaType);
> ResultMapping resultMapping = new 
> ResultMapping.Builder(configuration, propName, columnLabel, typeHandler)
> .javaType(javaType).build();
> autoMappings.put(propName, resultMapping);
>   }
> }
> ...
> Maybe this bug can fixed by adding the code below after "Class javaType = 
> metaResultObject.getSetterType(propName);"
> if (javaType.isAssignableFrom(rm.getType()))
>   javaType = rm.getType();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
For additional commands, e-mail: dev-h...@ibatis.apache.org



[jira] Created: (IBATIS-620) "select count(*) from table" return BigDecimal value in Oracle

2009-08-05 Thread Yuan Tao (JIRA)
"select count(*) from table" return BigDecimal value in Oracle
--

 Key: IBATIS-620
 URL: https://issues.apache.org/jira/browse/IBATIS-620
 Project: iBatis for Java
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Yuan Tao


User SqlSession.selectOne for the sql "select count(*) from table" defined in 
mapping file should return Integer, but return BigDecimal in Oracle.

The bug seems happen int DefaultResultSetHandler.mapResults method. There are 
codes below:

...
for (int i = 1, n = rsmd.getColumnCount(); i <= n; i++) {
  boolean useLabel = mappedStatement.getConfiguration().isUseColumnLabel();
  String columnLabel = (useLabel ? rsmd.getColumnLabel(i) : 
rsmd.getColumnName(i));
  columnLabel = columnLabel.toUpperCase();
  String propName = metaResultObject.findProperty(columnLabel);
  colSet.add(columnLabel);
  if (propName != null) {
propSet.add(propName);

Class javaType = metaResultObject.getSetterType(propName);  
// This line will return Object if the resultObject is 
PlatformTypeHolder

TypeHandler typeHandler = typeHandlerRegistry.getTypeHandler(javaType);
ResultMapping resultMapping = new ResultMapping.Builder(configuration, 
propName, columnLabel, typeHandler)
.javaType(javaType).build();
autoMappings.put(propName, resultMapping);
  }
}
...

Maybe this bug can fixed by adding the code below after "Class javaType = 
metaResultObject.getSetterType(propName);"

if (javaType.isAssignableFrom(rm.getType()))
javaType = rm.getType();


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org
For additional commands, e-mail: dev-h...@ibatis.apache.org