Request to change access modifiers

[Jeff Roberts <je...@yahoo.com>]

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
for lists in iBatis.  The extension does not require
anything special in the SELECT statement declaration. 
You can use any select statement for queryForObject,
queryForList or queryForXml (my extension method).  It
works within the context of the iBatis transaction
model.

I can attach the source code I've changed in iBatis if
that helps.  I can also provide additional examples or
explanation of the extension if that would help.

As I just joined the mailing list, I'm not sure what
my next step should be.  I assume someone will respond
to this request.

Thank you,
Jeff Roberts

P.S.  If Jeff Butler reads this, I'm the Jeff Roberts
you know from St. Louis.


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Request to change access modifiers

[Jeff Roberts <je...@yahoo.com>]

Clinton,
I'm not sure it matters, however, I am not simply
returning a string of XML.  The extension I've written
is a subclass of java.io.InputStream.  This stream can
be consumed by anything that would normally use it
(i.e. an XML parser, an XSLT transformation, or simply
streaming it to a requestor like a browser, etc.). 
The contents of the stream are produced on demand, as
the consumer reads from it.  It does not spin through
the result set and build up an XML string or
StringBuffer or anything of the sort.  The XML content
is produced as the consumer reads from the
InputStream.  As I mentioned, I'm aware that iBatis
already supports an XML document/XML string return
type, however this is different from what I was trying
to accomplish.  I'm only lobbying to have the access
modifiers changed so that my extension will work
without having to have a custom version of the iBatis
.jar file.

Nonetheless, I understand your point that you do not
support extensions to your classes in the .engine
package.  Unfortunately, without a complete
implementation of the iBatis interfaces on my part,
the easiest route for me was to subclass your code. 
Of course, I'd much rather reuse your code by
subclassing :).  I understand that you may change it,
but changing the access modifiers at least allows me
(and potentially others) a somewhat simpler process
for creating extensions with a minimal impact on the
iBatis code.

Given that the requested changes are minor (in my
view) and mostly non-intrusive, my hopes are that I
can convince you to include those changes.  If not, I
respect the decision and will try and address it
another way.

Thank you,
Jeff

--- Clinton Begin <cl...@gmail.com> wrote:

> 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
> <je...@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 <lm...@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 <je...@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
> > > <je...@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.
> 
=== message truncated ===



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

Re: Request to change access modifiers

[Clinton Begin <cl...@gmail.com>]

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 <je...@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 <lm...@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 <je...@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
> > <je...@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
>

Re: Request to change access modifiers

[Jeff Roberts <je...@yahoo.com>]

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 <lm...@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 <je...@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
> <je...@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

Re: Request to change access modifiers

[Larry Meadors <lm...@apache.org>]

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 <je...@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 <je...@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
> > for lists in iBatis.  The extension does not require
> > anything special in the SELECT statement declaration.
> > You can use any select statement for queryForObject,
> > queryForList or queryForXml (my extension method).  It
> > works within the context of the iBatis transaction
> > model.
> >
> > I can attach the source code I've changed in iBatis if
> > that helps.  I can also provide additional examples or
> > explanation of the extension if that would help.
> >
> > As I just joined the mailing list, I'm not sure what
> > my next step should be.  I assume someone will respond
> > to this request.
> >
> > Thank you,
> > Jeff Roberts
> >
> > P.S.  If Jeff Butler reads this, I'm the Jeff Roberts
> > you know from St. Louis.
> >
> >
> >
> >
> > __________________________________
> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > http://mail.yahoo.com
> >
>
>

Re: Request to change access modifiers

[Jeff Butler <je...@gmail.com>]

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 <je...@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
> for lists in iBatis. The extension does not require
> anything special in the SELECT statement declaration.
> You can use any select statement for queryForObject,
> queryForList or queryForXml (my extension method). It
> works within the context of the iBatis transaction
> model.
>
> I can attach the source code I've changed in iBatis if
> that helps. I can also provide additional examples or
> explanation of the extension if that would help.
>
> As I just joined the mailing list, I'm not sure what
> my next step should be. I assume someone will respond
> to this request.
>
> Thank you,
> Jeff Roberts
>
> P.S. If Jeff Butler reads this, I'm the Jeff Roberts
> you know from St. Louis.
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>