Yes, that would be best. Too bad that OSGi doesn't allow for the generally accepted best practice here... but Larry's suggestion would work well.
I look forward to the patch. Clinton On Wed, Aug 5, 2009 at 9:27 PM, Larry Meadors<larry.mead...@gmail.com> wrote: > 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<arga...@yahoo.com.cn> 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 <arga...@yahoo.com.cn> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ibatis.apache.org For additional commands, e-mail: dev-h...@ibatis.apache.org
