RE: iB3... It definitely will, as you can override the configuration class entirely.
On Fri, Jan 23, 2009 at 2:09 PM, Brandon Goodin <[email protected]> wrote: > -5 > > I appreciate the work that was put into providing this patch. However, it > would be best not to introduce this as a maintenance overhead for the iBatis > code base. SQLJ is not very popular at all. It also does not appear across > languages like SQL does. It would be nice if our architecture supported the > ability to add these type of extensions so that those who find it useful can > take advantage of it. Perhaps iB3 will provide the needed hooks to write a > SQLJ plugin/extension. > > Brandon Goodin > > > On Fri, Jan 23, 2009 at 1:05 PM, Clinton Begin <[email protected]> > wrote: >> >> Hi everyone, >> >> A group of developers have approached us with a contribution of code >> to patch iBATIS so that it supports SQLJ. >> >> If you've never heard of SQLJ, here are two links... >> >> http://en.wikipedia.org/wiki/SQLJ >> http://www.google.com/trends?q=sqlj >> >> The future of SQLJ is not clear to me, nor is its adoption rate over >> time. Certainly iBATIS has a broader user base than SQLJ does. >> >> So the question is: Should we support SQLJ as a feature of iBATIS? >> >> +5 == Absolutely... iBATIS will be better for it. >> +1 == Yes, support SQLJ. >> 0 == Doesn't matter to me. >> -1 == No, keep them separate. >> -5 == No way. iBATIS is better off without it. >> >> This vote will remain open for 72 hours. >> >> Cheers, >> Clinton > >
