ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Request to change access modifiers
Date Thu, 20 Oct 2005 14:12:48 GMT
For the record, iBATIS can return XML as a string as well, which you can
then simply pass to an StringReader or whatever you like. If that's
seriously all you're doing, then I'd be worried that the extension is too
complex for what it does.

Furthermore, please consider this advanced warning that any extensions that
require subclassing of classes in the .engine package, are not supported. We
reserve the right to make significant changes to the internals of the
framework that may break such extensions.

Also, (and I may be alone in this), I disagree with arbitrarily making
methods and fields protected. I believe that classes should be designed for
extension, and if they're not, then they should be privately protected.

Cheers,
Clinton

On 10/20/05, Jeff Roberts <jeff_roberts_ibatis@yahoo.com> wrote:
>
> Being new to this mailing list, I appreciate yours and
> Jeff Butler's advice on how to proceed. I will create
> a JIRA issue and hope that the enhancement is
> accepted.
>
> As a general rule of thumb, it is probably a good idea
> (as Jeff Butler points out) to address this across the
> entire code base instead of just where I needed it to
> be done for my specific enhancement.
>
> I appreciate your help.
>
> Thanks,
> Jeff
> --- Larry Meadors <lmeadors@apache.org> wrote:
>
> > Please attach the changed code to the JIRA issue. As
> > far as changing
> > the access modifiers, I am all for it - I have had
> > to do similar
> > things, and protected still provides an adequate
> > layer of
> > idiot-proofing while (as you said) not changing any
> > existing behavior.
> >
> > IMO, protected means "use at your own risk..." :-D
> >
> > As for the added functionality, it sounds like it
> > could be
> > useful...but I am not so sure that it is an area we
> > want to get into.
> > IMO, iBATIS is about mapping data from services to
> > and from domain
> > objects. This extension seems to be outside of that
> > scope. I guess you
> > could argue that a Stream is an object..but so is a
> > result set. The
> > key difference is that they are not domain objects
> > (employee,
> > customer, etc...).
> >
> > I think it is great that you built it though. That
> > is the kind of
> > thing that I think iBATIS in its current form could
> > exploit more -
> > providing more access to the data mapping process.
> > Your suggested
> > changes the the access modifiers IMO are something
> > that will make it
> > easier for others to extend.
> >
> > Larry
> >
> >
> > On 10/19/05, Jeff Butler <jeffgbutler@gmail.com>
> > wrote:
> > > Hi Jeff!
> > >
> > > The Cards forgot how to bat AGAIN in the post
> > series :-(
> > >
> > > Your request sounds reasonable to me. Please make
> > a JIRA enhancement
> > > request with the details of what should change
> > from private to protected,
> > > then we'll remember to get to it (maybe someone
> > should take a look at this
> > > in general?)
> > >
> > > As for the extension, I'm not sure what the proper
> > procedure is - maybe one
> > > of the other committers can comment. The list
> > does not allow attachments.
> > > If there is interest from the community, you could
> > attach the sample code to
> > > another JIRA issue - or distribute it informally.
> > >
> > > Jeff Butler
> > >
> > >
> > >
> > > On 10/19/05, Jeff Roberts
> > <jeff_roberts_ibatis@yahoo.com> wrote:
> > > > I have recently added and extension to the
> > iBatis
> > > > framework. In order for my extension to work
> > > > effectively, I had to subclass several of the
> > iBatis
> > > > classes. In doing so, I found that some of the
> > > > methods and variables in the iBatis classes were
> > > > declared as private, preventing me access to
> > them from
> > > > my subclasses.
> > > >
> > > > I changed the following access modifiers in the
> > > > following iBatis classes:
> > > >
> > > > - com.ibatis.sqlmap.client.SqlMapClient
> > > > I changed the default constructor from private
> > to
> > > > protected. This still prevents public
> > instantiation
> > > > of the class, but allows me to instantiate my
> > > > subclass.
> > > >
> > > > -
> > > >
> >
> com.ibatis.sqlmap.engine.builder.xml.SqlMapConfigParser
> > > > I changed the static variable "parser" from
> > private to
> > > > protected. This allows me to access the parser
> > from
> > > > my subclass.
> > > >
> > > > I also changed the addSqlMapNodelets() method
> > from
> > > > private to protected, allowing me to override it
> > in my
> > > > subclass and extend its behavior.
> > > >
> > > > -
> > com.ibatis.sqlmap.engine.builder.xml.SqlMapParser
> > > > I changed the static variable "parser" from
> > private to
> > > > protected. This allows me to access the parser
> > from
> > > > my subclass.
> > > >
> > > > I also changed the addStatementNodelets() method
> > from
> > > > private to protected, allowing me to override it
> > in my
> > > > subclass and extend its behavior.
> > > >
> > > > - com.ibatis.sqlmap.engine.impl.SqlMapClientImpl
> > > > I changed the variable "localSqlMapSession" from
> > > > private to protected, allowing my subclass to
> > access
> > > > it.
> > > >
> > > > I also changed the getLocalSqlMapSession() from
> > > > private to protected, allowing me to override it
> > in my
> > > > subclass and extend its behavior.
> > > >
> > > > -
> > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate
> > > > I changed the variable "sqlExecutor" from
> > private to
> > > > protected, allowing my subclass to access it.
> > > >
> > > > I also changed the autoEndTransaction(),
> > > > autoCommitTransaction() and
> > autoStartTransaction()
> > > > methods from private to protected, allowing my
> > > > subclass to invoke them.
> > > >
> > > > I would like to request that the iBatis
> > development
> > > > team make these same changes to the iBatis
> > source
> > > > code. In my view, it doesn't change any
> > behavior or
> > > > introduce any changes to the source code other
> > than to
> > > > make key pieces of the code accessible to
> > subclasses.
> > > > By making these changes, I can implement an
> > extension
> > > > to iBatis by subclassing the classes I've
> > mentioned
> > > > above and providing an additional feature.
> > > >
> > > > To help bolster my case, I would like to
> > describe my
> > > > extension. I would be happy to submit my
> > extension to
> > > > the iBatis development team for inclusion into
> > the
> > > > framework or as a third party extension. If
> > neither
> > > > is desired, I'm happy to use the extension for
> > my own
> > > > use.
> > > >
> > > > The extension that I have created is to provide
> > an
> > > > alternate mechanism for returning XML as a
> > result of a
> > > > query. While I realize iBatis already provides
> > > > support for XML, this extension is different.
> > My
> > > > understanding is that iBatis can return an XML
> > > > document (DOM) from a result set. This is
> > adequate if
> > > > you wish to use the DOM within the application.
> > My
> > > > extension returns a java.io.InputStream
> > subclass,
> > > > which is a stream of XML derived from a result
> > set.
> > > > The stream is dynamically produced as the
> > InputStream
> > > > is read. This allows you to simply stream it
> > out to a
> > > > caller or run it through an XSLT transformation
> > on the
> > > > server or on the client. It uses SAX callbacks
> > and
> > > > therefore minimizes the memory requirements and
> > can
> > > > handle a virtually unlimited size result set
> > since the
> > > > results are streamed. I've also included
> > support for
> > > > skipping and max results as is the case when
> > querying
> >
> === message truncated ===
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>

Mime
View raw message