[RT] Looking at standard Java technologies

[Berin Loritsch <bl...@citi-us.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [RT] Looking at standard Java technologies

[Berin Loritsch <bl...@citi-us.com>]

> From: Stephen McConnell [mailto:mcconnell@apache.org]
> 
> Seems that my ASCII art is being destroyed in the trip from 
> my desktop 
> to the list.  That prompted me to play around with the AvalonWiki and 
> the addition of an extended version of thoughts concerning lifecycle 
> strategies under AvalonFive.
> 
>   http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonFive
> 
> Cheers, Steve.

Our Wiki is set up?  Cool!

Now all I have to do is figure out how to use it....

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [RT] Looking at standard Java technologies

[Stephen McConnell <mc...@apache.org>]

Seems that my ASCII art is being destroyed in the trip from my desktop 
to the list.  That prompted me to play around with the AvalonWiki and 
the addition of an extended version of thoughts concerning lifecycle 
strategies under AvalonFive.

  http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonFive

Cheers, Steve.

<snip/>

---

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [RT] Looking at standard Java technologies

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

<snip-content-related-to-javax.sql.DataSources/>

>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?
>

Berin:

Your question concerning the balance between separation and
fragmentation of concerns got my attention. I've been thinking
about this as a result of the context discussions and have been
quietly thinking about what it is that makes Avalon attractive,
what it is that makes Avalon non-attractive, and how all of this
plays into the future of Avalon A4/A5/Ax.

After playing around with a bunch of diagrams, I came up with an
abstract model of what a container does in terms to a component at
a rather high level of abstraction - together with a mapping of this
abstraction down to the Avalon notion of component lifecycle and
container related concerns.


potential
|
| candidate
| |
| |
|--- creation --> | component
| | |
| |---- deployment ---->|
| | |
| |<-- decommissioning -|
| |
|<-- termination -|
|

The above diagram presents an abstract state machine from a
container's point-of-view. Potential components exist as a
result of a containment systems discovery process (classpath,
meta-info and meta-data scanning, etc.). The creation phase
is about the creation of a "candidate" component - involving
validation of meta-info and meta-data, assignment of a lifestyle
handler, assembly of dependencies, and finally, verification that
all logical dependencies are resolvable.

Moving from "candidate" to "component" is where we get into the
Avalon framework side of things. This involves object instantiation
application of a logging channel, contextualization, servicing,
initialization, and potential startup. I've referred to this as the
deployment phase. What is important to note is that that Avalon has
particular idea of what deployment means - but not formal notion of
deployment as a phase.

If we look into deployment in more detail (still maintaining an
abstraction above the Avalon framework model) there are a number of
particular stages that we can separate out as distinct and significant.

The deployment sub-stages include:

* logging strategy
* configuration strategy
* context strategy
* initialization strategy

In Avalon the "logging strategy" is based on the LogEnabled interface
And the assignment of a logging channel via that interface. What is
Important to note is that this is potentially one of may different
logging strategies providing we can abstract ourselves above the stage
implementation and into the notion of strategy definition.

The Avalon configuration strategy is basically the combination of
Configurable and Parameterizable. The Avalon context strategy is the
combination of the Contextualization and Service stages. An finally,
the Avalon initialization strategy is represented by the Initializable
interface and methods on the Startable interface or possibly the
Executable interface.

Something important in the above is the absence of references to things
Like recomposable, reconfigurable, etc. Instead, if we look at the
Individual artifacts that are supplied by a container to a component,
and given that these artifacts are supplied based on information #
declare in meta-info, than "re-" aspect can be qualified relative to
the artifact being applied. For example, if I declare that the
component needs a logging channel, the default declaration could be
that the logging channel is final - i.e. tyhe component does not
support re-assignment of the logging channel. The same concept can
be applied to configuration and context related information - is
contextualization final or not - are entries in a context object final
or not? Are service under a service manager final or not? Same
thinking in terms of entries in a service manager, etc. This allows us
to eliminate completely the "re-X" approach and instead - declare this
at the level of the meta-info that a component is declaring to its
container.

Second interesting aspect of the above is the folding of initializable
And startable under a single initialization phase. This is possible
because there is no longer a particular semantic difference between a
initialized and started (because the notion of re-X has been abstracted
out). Decommissioning of a component is equivalent to taking a
component back to its pre-initialized state where the volatile members
are all of the non-final artifacts that a component type has declared.

You may be wondering what the benefit of this abstraction is.

Basically, the key aspect is focussing on the containment abstraction
and considering the state model described above as the containment
management problem. It means that a container implementation can
handle objects that implement different component models - Avalon,
Servlet, etc.

Is it feasible?

Yes. I've recently introduced an abstraction to context management in
The avalon-sandbox/assembly package that enables a component to
implement any interface for the contextualization stage. This approach
can be applied to an abstract contextualization phase (covering both
Avalon contexualization and servicing). The same applies to the
abstract notions of logging, configuration and initialization.

I think the above is a rational approach to addressing some key issues:

(a) simplification for the component author
(b) applicability of Avalon to a wider audience

Both of the above seem to address the issues your raising.

Cheers, Steve.

-- 
mailto:mcconnell@apache.orghttp://www.osm.net
Stephen J. McConnell






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>