commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <>
Subject Re: [clazz] next step
Date Tue, 17 Dec 2002 23:55:56 GMT

----- Original Message -----
From: "Stephen Colebourne" <>
To: "Jakarta Commons Developers List" <>
Sent: Tuesday, December 17, 2002 6:04 PM
Subject: Re: [clazz] next step

> > 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
> > 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
> > backed by accessor methods.
> >     c) Mutable BeanClazz, which allows you to create Clazzes and their
> > instances dynamically.
> Time has constrained me from looking in detail, but this covers the basic
> goals for clazz properties well ;-)

> > 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.
> +1
> > 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.
> +1
> > 1. Attributes.  There is a placeholder method on ClazzElement:
> > getAttribute(String name), however it is currently unimplemented.  I
> > we need to better understand our relationship with the [attribute]
> > before we finalize these APIs.
> I see [clazz] depending on [attributes] for the implementation of
> attributes. However, [clazz] users might also want to implement their own
> attribute mechanism independent of [attributes], so a light conversion
> of some kind is probably needed.
I got that.  The issue is really more organizational than technical.  I
would like our [clazz] attributes to be conceptually an functionally aligned
with those in [attribute].  I'll try to get somebody from the [attributes]
team engaged.

> > 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"?
> A ClazzOperation in reflection terms is a Method object, however it might
> alternatively be implemented as a Jelly script or Velocity transformation
> .... Basically anywhere where there is processing. eg.
>   clazzOp.invoke(object, params)
> An Operation is the delegate. It is the ClazzOperation, plus a reference
> the bean itself. eg.
>   op.invoke(params)

Ok.That's pretty much the way I wrote them.  However the questions remain
the same: is there anything special about delegators from the _client_'s

> > 3. Interfaces.  I am not sure what the use case would be for interfaces
> > the Clazz world (I guess they would have to be called "interfazes".  We
> can
> > always inquire like this:
> >
> >     MyInteface.class.isAssignableFrom(clazz.getInstanceClass())
> >
> > Does this address the requirement or we need actual Interfaze metadata
> > something?
> I would avoid interfaces for the moment. We don't have a use case, and
> add complexity. If [clazz] succeeds then we can add them later.
I am with you on this one.

> > 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
> > convinced we need any metadata on it.
> Agreed, extra metadata here is not useful.
So be 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?
> In the Joda system, private methods can be introspected as this allows
> like XML readers to set values, but not ordinary program code. This
> require that ClazzProperties and ClazzOperations themselves have
> We are trying to enable access to the properties/operations, not provide
> information on things that aren't accessible.
> One thing we need to be careful of is performance. As I have found at
> an object model that creates too many objects will scale badly. But we
> should optimise once the basic design is right and working. Premature
> optimisation is Bad ;-)
Exactly.  I am well aware of this performance consideration.  Sun claims
that in the new JDKs object allocation is virtually free.  I have trouble
believing that.

Thank you,
> Stephen

- Dmitri

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

View raw message