Hy guys,
any news about this issue? I just met the case when a mapper needs to
extend an existing one, but mapper methods are not found :(
Thanks in advance!!!
Simone Tripodi
On Fri, Dec 11, 2009 at 11:27 PM, Soks86 <michael.chrostow...@gmail.com> wrote:
>
> 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
>
>
--
http://www.google.com/profiles/simone.tripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
