ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Roberts <jeff_roberts_iba...@yahoo.com>
Subject Re: Request to change access modifiers
Date Thu, 20 Oct 2005 14:55:00 GMT
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 <clinton.begin@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
> <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.
> 
=== message truncated ===



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

Mime
View raw message