Hi Simone,
I don't know what sort of environment you are developing in but I realized
myself that unless you really have the time to dedicate to editing the
Ibatis source (not really hard but of course it is work intensive) it seems
to be better to keep mapper's simple. I ended up making a private class
inside of each of my DAO classes that was the mapper and I stopped utilizing
inheritance for the mappers (though my DAO's still inherit from each other).
I think it's a small price to pay for everything else that Ibatis provides,
the dynamic SQL (for loops and such) is fantastic. Of course putting in the
code changes to the project would be great for everyone, but it is a VERY
high cost when you realize how well Ibatis works if you just design for it.
I figure so long as you can encapsulate the design changes they shouldn't
really effect your project negatively, aside from writing a bit more code.
Hope that helps,
Simone Tripodi wrote:
>
> 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
>
>
>
--
View this message in context:
http://old.nabble.com/Issue-with-Interface-Mapper-that-Extends-an-Interface-itself-tp26732131p26968735.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
