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-tp26732131p26752251.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

Reply via email to