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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
> <[EMAIL PROTECTED]> 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
