You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dm...@apache.org> on 2002/12/17 00:51:00 UTC
[clazz] next step
Folks,
I believe [clazz] has reached a certain milestone. What we now have is the
following:
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:
MyInteface.class.isAssignableFrom(clazz.getInstanceClass())
Does this address the requirement or we need actual Interfaze metadata for
something?
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] next step
Posted by Dmitri Plotnikov <dm...@apache.org>.
Stephen,
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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
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.
> Time has constrained me from looking in detail, but this covers the basic
> goals for clazz properties well ;-)
Thanks.
> > 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
think
> > we need to better understand our relationship with the [attribute]
project
> > 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
layer
> 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
or
> .... Basically anywhere where there is processing. eg.
> clazzOp.invoke(object, params)
>
> An Operation is the delegate. It is the ClazzOperation, plus a reference
to
> 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
side?
> > 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:
> >
> > MyInteface.class.isAssignableFrom(clazz.getInstanceClass())
> >
> > Does this address the requirement or we need actual Interfaze metadata
for
> > something?
> I would avoid interfaces for the moment. We don't have a use case, and
they
> 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
not
> > 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
tools
> like XML readers to set values, but not ordinary program code. This
doesn't
> require that ClazzProperties and ClazzOperations themselves have
modifiers.
> 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
work,
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] next step
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> 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.
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 think
> we need to better understand our relationship with the [attribute] project
> 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 layer
of some kind is probably needed.
> 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 or
.... Basically anywhere where there is processing. eg.
clazzOp.invoke(object, params)
An Operation is the delegate. It is the ClazzOperation, plus a reference to
the bean itself. eg.
op.invoke(params)
> 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:
>
> MyInteface.class.isAssignableFrom(clazz.getInstanceClass())
>
> Does this address the requirement or we need actual Interfaze metadata for
> something?
I would avoid interfaces for the moment. We don't have a use case, and they
add complexity. If [clazz] succeeds then we can add them later.
> 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.
Agreed, extra metadata here is not useful.
> 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 tools
like XML readers to set values, but not ordinary program code. This doesn't
require that ClazzProperties and ClazzOperations themselves have modifiers.
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 work,
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 ;-)
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>