commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <>
Subject [clazz] next step
Date Mon, 16 Dec 2002 23:51:00 GMT

I believe [clazz] has reached a certain milestone.  What we now have is the

1. Clazz APIs and three implementations of those:
   a) Standard JavaBeans clazz loader.  Recognizes properties the way
java.beans.Introspector does, including the indexed ones.
   b) Extended Bean clazz loader.  In addition to the functionality of the
Standard loader, also
        - recognizes plural form of a property (getCustomer,
getCustomerList, etc)
        - recognizes list (indexed) and mapped properties
        - for the list and mapped properties recognizes a number of
additional accessors a la "addCustomer", "removeCustomer",
"getCustomerCount" etc.
        - provides implementations of the List and Map interfaces that are
backed by accessor methods.
    c) Mutable BeanClazz, which allows you to create Clazzes and their
instances dynamically.

2. Clazz has a new kind of feature - InstanceFactory.  In the most basic
case an InstanceFactory is an reflected constructor.  In addition to the
basic case, we also recognize as a factory a static method returning an
instance of the target class.  I was thinking that this generalization would
play quite well with EJBs, which have separate factory methods on the Home.
All these variations would be transparent to the client.

3. There is a change notification mechanism.  Register a ClazzChangeListener
with a Clazz and you will get notifications when the clazz changes: a
property, operation or factory is added or removed.

The implementation of all this functionality is reasonably complete and
reasonably well (for a prototype) covered with test cases.  Please see those
test cases for examples of the API usage.

At this point I need your input. Here's what's not been addressed:

1. Attributes.  There is a placeholder method on ClazzElement:
getAttribute(String name), however it is currently unimplemented.  I think
we need to better understand our relationship with the [attribute] project
before we finalize these APIs.

2. Delegators.  If my understanding of Delegators is correct, we need a
method like this:

    clazz.addDeclaredOperation(ClazzOperation delegator)

These delegators will be seen as regular, method-based operations by the
client.  Is this correct?  Is there more to them?  Do they need to be
designated as "delegators"?

3. Interfaces.  I am not sure what the use case would be for interfaces in
the Clazz world (I guess they would have to be called "interfazes".  We can
always inquire like this:


Does this address the requirement or we need actual Interfaze metadata for

4. Exception declarations on operations.  Once again, I am not sure what the
purpose of that would be.  When you call  clazzOperation.invoke(...), it may
throw a RuntimeException, which can be examined dynamically, but I am not
convinced we need any metadata on it.

5. Modifiers.  Currently, everything introspected is based on public methods
of the target class.  What are some use cases for modifiers on
ClazzProperties and ClazzOperations?

Please comment.

Thanks in advance,

- Dmitri

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message