avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject [RT] Looking at standard Java technologies
Date Tue, 24 Dec 2002 17:32:02 GMT

Lately, I have been taking a good hard look at how and why
the standard way Java does things work--and how it might
relate to Avalon.

The reason is that I want to be able to provide the best
cross-section of how to use existing software in an Avalon
context--without violating the spec of either.  To begin
my quest, I started toward a new and improved datasource
component.  I want to leverage the javax.sql.DataSource
interface, to allow Avalon apps to directly use vendor
specific connection pooling code.  I will also be looking
at creating an ApacheConnectionPoolDataSource that pools
connections, prepared statements, and whatever else needs
to be pooled.

I am not done with my "road to discovery", but here are
some observations I have:

* JavaBeans are slow if you have to use introspection
  - All javax.sql.DataSource implementations must conform
    to the JavaBeans specification.
  - You never know what properties are exposed from one
    implementation to the next.
  - There is a 900% to 1500% overhead paid for using
    introspection vs. directly calling the methods.
    However, since this is done during initialization it
    is not necessarily a big deal.  If we had 2000 JavaBeans
    all set using introspection at init time, we would
    encur ~500ms to set them all up.
* JavaBean introspection is ugly--common interfaces are much
  better.
  - I created a BeanUtil helper class to make it easier
    to work with introspection.
  - Sometimes it is a necessary evil--esp. when low coupling
    is a priority (like in server settings).  The Parameters
    and Configuration APIs rock compared to this.
  - By wrapping all properties with our Parameters object,
    it makes it a heck of a lot easier to save and read
    configurations.  I did this in my BeanUtils class, BTW.
* javax.sql.DataSources are well thought out for the
  server.  They have some specific ways of implementing things,
  but it is so that they can be embedded in a J2EE server.
  - I haven't started on a JDBC 2+ compliant DataSource
    implementation yet, but its infrastructure is better than
    what we currently have.
  - Its use of events help to push maintenance issues off of
    the critical path.
  - It is standard so that database manufacturers and J2EE
    manufacturers can really work together.
  - The JDBC compliant driver might not be in scope for Avalon,
    so it might need to be placed in Apache Commons.

In the process, I am looking for what things we can be doing
less of, and what we should focus our core strengths in.  For
example, what is the proper balance between developer ease of
use and conceptual purity?  What is the balance between separation
and fragmentation of concerns?  How do we encourage more
widespread adoption of Avalon?

I personally don't have all the answers, but I will let you
guys in on my observations as I discover them.  My recent experience
reinforced my dislike of JavaBeans as a mechanism--But they
have some conceptual promise in the asyncronous event process.

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message