Sorry for not including this in my previous response.
I also noticed an issue when you have the following:
type1 {
save()
}
type2 extends type1 {
save()
}
If you hold a type1 reference to type2 and call type1.save (even though the
runtime type is type2) then iBATIS calls the mapping for type1.save()
instead of type2.save(). Is this expected behavior?
Thanks.
Soks86 wrote:
>
> I was going over the patch and it looks like it's out of date already,
> that is it's not compatible with Beta-6. Also, I'm not sure the
> implementation is as clean as it could be although when I tried to go in
> there myself I realized the issue does get a bit complicated.
>
> That is, the mappers and classes need to be completely mapped out in order
> to find the correct mapping to call from the method invocation. The
> current patch goes through the generated proxy looking for an interface
> that contains the method but this method actually uses exceptions as
> logic... now I'm not sure if this is workable or not but last time I had
> exceptions as part of normal logic my code ran very slowly...
>
> I'm going to poke around the code over the weekend and see if I can't come
> up with a solution but something tells me the information regarding which
> mapping to invoke may need to be stored elsewhere... unless I'm just
> crazy.
>
> Also, I ran into an issue when downloading the SVN code. One of the
> libraries from a test case comes from javax.nio.cs.US_ASCII (sorry if
> that's wrong don't have access to code ATM) and my IDE (Eclipse w/
> SpringSource) is complaining that this is a restricted .jar (the path is
> resolving to something/something/rt.jar) any ideas as to what could be
> causing this?
>
> Also my maven is refusing to find
> "org.apache.ibatis:ibatis-3:pom:3.0-SNAPSHOT" from
> "http://repo1.maven.org/maven2"; but I'm guessing that's likely an issue on
> my end.
>
> Thanks.
>
> (getMethod().execute() calls for each possibility)
>
> Clinton Begin wrote:
>>
>> The best thing you can do is try the patch. iBATIS is easy to check out
>> and
>> build (one-click build principle). So if you check out the source, apply
>> the patch and let us know if it works for you, that gives me a lot more
>> confidence.
>>
>> Cheers,
>> Clinton
>>
>> On Thu, Dec 10, 2009 at 1:50 PM, Soks86
>> <michael.chrostow...@gmail.com>wrote:
>>
>>>
>>> Is there anything I could do to help the patch along? Would trying the
>>> patch
>>> and vouching for it help... anything like that?
>>>
>>> The only fix without changes is to @Override the methods in all my
>>> interfaces and that will drive me nuts (wish I had interns...).
>>>
>>> Thank you for the quick reply.
>>>
>>>
>>> Clinton Begin wrote:
>>> >
>>> > Interface inheritance is not yet supported. There's a Jira ticket
>>> with a
>>> > patch submitted, here:
>>> >
>>> > http://issues.apache.org/jira/browse/IBATIS-655
>>> >
>>> > Clinton
>>> >
>>> > On Thu, Dec 10, 2009 at 11:23 AM, Soks86
>>> > <michael.chrostow...@gmail.com>wrote:
>>> >
>>> >>
>>> >> Hi,
>>> >>
>>> >> I've been switching my project over to iBATIS from a pretty complete
>>> >> Hibernate project. I've run into an issue with how the iBATIS
>>> >> configuration
>>> >> seems to look up mapped methods. I'm currently using Beta 5 since my
>>> >> Maven
>>> >> isn't seeing repo2.maven.org/org/... for some reason. I have an
>>> interface
>>> >> dao as such:
>>> >>
>>> >> public interface Dao<T> {
>>> >> void delete(T arg);
>>> >> void save(T arg);
>>> >> void update(T arg);
>>> >> T load(T arg);
>>> >> }
>>> >>
>>> >> then I have another interface which extends this
>>> >>
>>> >> public interface SomeTypeDao extends Dao<SomeType> {
>>> >> SomeType loadBySomething(String arg);
>>> >> }
>>> >>
>>> >> and finally my implementation:
>>> >>
>>> >> public class IbatisSomeTypeDao implements SomeTypeDao {
>>> >> void delete(SomeType arg) {
>>> >> SqlSession session = sessionFactory.openSession();
>>> >> try {
>>> >> SomeTypeDao dao = session.getMapper(SomeTypeDao.class);
>>> >> dao.delete(arg);
>>> >> session.commit();
>>> >> } finally {
>>> >> session.close();
>>> >> }
>>> >> //... other code omitted but present in actual code
>>> >> }
>>> >>
>>> >> My mapping file is for the namespace of SomeTypeDao and that is the
>>> only
>>> >> mapped interface or class from the three I posted above.
>>> >>
>>> >> Now when I call IbatisSomeTypeDao.delete(arg) instead of finding my
>>> >> mapped
>>> >> interface (SomeTypeDao.delete()) iBATIS seems to look for delete() in
>>> my
>>> >> Dao<T> class instead and thus it looks for a mapping for Dao<T>
>>> (which
>>> >> doesn't exist) and then I get this exception:
>>> >>
>>> >> java.lang.IllegalArgumentException: Mapped Statements collection does
>>> not
>>> >> contain value for com.icarus.common.dao.Dao.delete
>>> >> at
>>> >>
>>> >>
>>> org.apache.ibatis.session.Configuration$StrictMap.get(Configuration.java:366)
>>> >> at
>>> >>
>>> >>
>>> org.apache.ibatis.session.Configuration.getMappedStatement(Configuration.java:312)
>>> >> at
>>> >>
>>> >>
>>> org.apache.ibatis.binding.MapperMethod.setupCommandType(MapperMethod.java:131)
>>> >> at
>>> >> org.apache.ibatis.binding.MapperMethod.<init>(MapperMethod.java:41)
>>> >> at
>>> >> org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:18)
>>> >> at $Proxy1.delete(Unknown Source)
>>> >>
>>> >>
>>> >> Am I missing something here? It would seem to me that this is a
>>> >> limitation
>>> >> of iBATIS' configuration class. Shouldn't it first look for a mapping
>>> for
>>> >> SomeTypeDao and find my mapping? I do know for a fact that if I call
>>> >> SomeTypeDao.loadBySomething (method that isn't in Dao<T> generic
>>> type)
>>> >> then
>>> >> the Configuration seems to find the appropriate mapping and doesn't
>>> >> complain. However any method that was inherited by the interface is
>>> >> mapped
>>> >> to the parent interface it seems.
>>> >>
>>> >> Ideas? Help?
>>> >>
>>> >> Thanks.
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://old.nabble.com/Issue-with-Interface-Mapper-that-Extends-an-Interface-itself-tp26732131p26732131.html
>>> >> Sent from the iBATIS - User - Java mailing list archive at
>>> Nabble.com.
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>>> >> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Issue-with-Interface-Mapper-that-Extends-an-Interface-itself-tp26732131p26734289.html
>>> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/Issue-with-Interface-Mapper-that-Extends-an-Interface-itself-tp26732131p26752352.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
