Re: Heads-up - GBeanInfo via annotations
On Apr 1, 2008, at 1:18 AM, Gianny Damour wrote: On 01/04/2008, at 7:52 AM, David Blevins wrote: On Mar 31, 2008, at 5:37 AM, Gianny Damour wrote: From: David Jencks <[EMAIL PROTECTED]> 1. I think we should try harder to separate the identification of a constructor parameter as attribute or reference from identifying its name. So, I think we should use the java6 and xbean @ParameterName annotations for names and something else for references if necessary. It seems to me that xbean only defines a @ParameterNames annotation, which I think is quite efficient only when the number of parameters is small. The need of a @ParameterName annotation, targeting a parameter and not a constructor or method, really emerges when the number of parameters increases. If you want, I can add a @ParameterName annotation to xbean- reflect instead of adding it to geronimo-kernel. Annotation-wise an @ParameterName annotation would only be useful if there was an @ParameterNames annotation to act as a wrapper (can't have more than one annotation of the same name on a target). We already have an @ParameterNames which accepts String[] so that's sort of a dead end. I do not understand. @ParameterNames' target is either a constructor or a method. The @ParameterName I am referring to targets a parameter. It does not mandate another annotation acting as a wrapper to be useful. What is exactly the dead end you are hinting at? I completely forgot about the MyConstructor(@MyAnnotation String myString) possibility and was thinking about the "can't have more than one annotation on a target" limitation. The "extra metadata beyond a name" aspect of constructor and factory method injection is certainly a tricky one. If you can get by without needing anything beyond a string, that certainly makes it easier. In EJB3 we're sort of hosed in that regard as we have @Resource and @EJB, which is nearly identical to the proposed @Attribute/@Reference concept; having no polymorphism in annotations makes it impossible to support both in a list. If we could avoid needing the distinction, there are advantages. If we do feel the need to have the distinction, I'd strongly recommend "reference" being a boolean type on @Attribute or some similar convention so there's only one annotation type which could be used in a list. From there "rich" constructor or factory method support could be as simple as @Attributes(Attribute[]), which I'd recommend be supportable on a class, constructor or method. This idea of @Attributes(Attribute[]) or @ParameterNames may or may not be desirable. The more parameters, the less desirable it is (this is the point I tried to make). Let's consider how AppClientModuleBuilder would be annotated with @ParameterNames: The inlined approach is definitely the nicer approach. I totally forgot about the ability to annotate individual parameters in the method signature. There's a sneaky way to get the param names from the debug info in the class (code is in xbean). That should allow us to extend the annotation by exception approach to constructors and factory methods (if we support them some day). I'd hope we then use the same annotation for fields methods or constructor/factoryMethod params. The motivation for supporting it on a class is that there could be several constructors you might want usable, in which case you might be motivated to have all the metadata in one spot. Ideally, if you don't need to explicitly add an annotation for your plain attributes and only require the annotation when some extra metadata is required, you'd only need two or three @Attribute annotations on a class. The motivation to have all the metadata located at one spot may or may not be desirable. As per the previous example, I believe that putting annotations at the right place is more readable and maintainable. As a matter of fact, I am not a fan of the static block approach we are using to construct GBeanInfos as these blocks are too far from the code they are describing even if all the metadata is in one spot. I don't care for that approach myself either, just throwing it out there as something that'd be easy to support and give some style options. I can see it being a nice option in the configure by exception mindset where there might be just one annotation you need to supply and it possibly has some very long and detailed attributes that might be annoying to have in a constructor (or to repeat if there's more than one constructor). -David
Re: Heads-up - GBeanInfo via annotations
On 01/04/2008, at 7:52 AM, David Blevins wrote:
On Mar 31, 2008, at 5:37 AM, Gianny Damour wrote:
From: David Jencks <[EMAIL PROTECTED]>
1. I think we should try harder to separate the identification of
a constructor parameter as attribute or reference from
identifying its name. So, I think we should use the java6 and
xbean @ParameterName annotations for names and something else for
references if necessary.
It seems to me that xbean only defines a @ParameterNames
annotation, which I think is quite efficient only when the number
of parameters is small. The need of a @ParameterName annotation,
targeting a parameter and not a constructor or method, really
emerges when the number of parameters increases.
If you want, I can add a @ParameterName annotation to xbean-
reflect instead of adding it to geronimo-kernel.
Annotation-wise an @ParameterName annotation would only be useful
if there was an @ParameterNames annotation to act as a wrapper
(can't have more than one annotation of the same name on a
target). We already have an @ParameterNames which accepts String[]
so that's sort of a dead end.
I do not understand. @ParameterNames' target is either a constructor
or a method. The @ParameterName I am referring to targets a
parameter. It does not mandate another annotation acting as a wrapper
to be useful. What is exactly the dead end you are hinting at?
The "extra metadata beyond a name" aspect of constructor and
factory method injection is certainly a tricky one. If you can get
by without needing anything beyond a string, that certainly makes
it easier. In EJB3 we're sort of hosed in that regard as we have
@Resource and @EJB, which is nearly identical to the proposed
@Attribute/@Reference concept; having no polymorphism in
annotations makes it impossible to support both in a list. If we
could avoid needing the distinction, there are advantages.
If we do feel the need to have the distinction, I'd strongly
recommend "reference" being a boolean type on @Attribute or some
similar convention so there's only one annotation type which could
be used in a list. From there "rich" constructor or factory method
support could be as simple as @Attributes(Attribute[]), which I'd
recommend be supportable on a class, constructor or method.
This idea of @Attributes(Attribute[]) or @ParameterNames may or may
not be desirable. The more parameters, the less desirable it is (this
is the point I tried to make). Let's consider how
AppClientModuleBuilder would be annotated with @ParameterNames:
@ParameterNames(names={"transactionManagerObjectName",
"connectionTrackerObjectName",
"corbaGBeanObjectName",
"credentialStoreName",
"Repositories",
"ConnectorModuleBuilder",
"ServiceBuilders",
"NamingBuilders",
"ModuleBuilderExtensions",
"ClientArtifactResolver",
"defaultClientEnvironment",
"defaultServerEnvironment"})
public AppClientModuleBuilder(AbstractNameQuery
transactionManagerObjectName,
AbstractNameQuery
connectionTrackerObjectName,
AbstractNameQuery
corbaGBeanObjectName,
AbstractNameQuery
credentialStoreName,
Collection repositories,
Collection
connectorModuleBuilder,
Collection
serviceBuilder,
Collection
namingBuilders,
Collection
moduleBuilderExtensions,
ArtifactResolver
clientArtifactResolver,
Environment defaultClientEnvironment,
Environment
defaultServerEnvironment) {
Inlining a @ParameterName is more readable and maintainable:
public AppClientModuleBuilder(@ParameterName
(name="transactionManagerObjectName") AbstractNameQuery
transactionManagerObjectName,
@ParameterName
(name="connectionTrackerObjectName") AbstractNameQuery
connectionTrackerObjectName,
@ParameterName
(name="corbaGBeanObjectName") AbstractNameQuery corbaGBeanObjectName,
@ParameterName
(name="credentialStoreName") AbstractNameQuery credentialStoreName,
@ParameterName
(name="Repositories") Collection repositories,
@ParameterName
(name="ConnectorModuleBuilder") Collection
connectorModuleBuilder,
@ParameterName
(name="ServiceBuilders") Collection
serviceBuilder,
@ParameterName
(name="NamingBuilders") Collection namingBuilders,
Re: Heads-up - GBeanInfo via annotations
On Mar 31, 2008, at 5:37 AM, Gianny Damour wrote: From: David Jencks <[EMAIL PROTECTED]> 1. I think we should try harder to separate the identification of a constructor parameter as attribute or reference from identifying its name. So, I think we should use the java6 and xbean @ParameterName annotations for names and something else for references if necessary. It seems to me that xbean only defines a @ParameterNames annotation, which I think is quite efficient only when the number of parameters is small. The need of a @ParameterName annotation, targeting a parameter and not a constructor or method, really emerges when the number of parameters increases. If you want, I can add a @ParameterName annotation to xbean-reflect instead of adding it to geronimo-kernel. Annotation-wise an @ParameterName annotation would only be useful if there was an @ParameterNames annotation to act as a wrapper (can't have more than one annotation of the same name on a target). We already have an @ParameterNames which accepts String[] so that's sort of a dead end. The "extra metadata beyond a name" aspect of constructor and factory method injection is certainly a tricky one. If you can get by without needing anything beyond a string, that certainly makes it easier. In EJB3 we're sort of hosed in that regard as we have @Resource and @EJB, which is nearly identical to the proposed @Attribute/@Reference concept; having no polymorphism in annotations makes it impossible to support both in a list. If we could avoid needing the distinction, there are advantages. If we do feel the need to have the distinction, I'd strongly recommend "reference" being a boolean type on @Attribute or some similar convention so there's only one annotation type which could be used in a list. From there "rich" constructor or factory method support could be as simple as @Attributes(Attribute[]), which I'd recommend be supportable on a class, constructor or method. The motivation for supporting it on a class is that there could be several constructors you might want usable, in which case you might be motivated to have all the metadata in one spot. Ideally, if you don't need to explicitly add an annotation for your plain attributes and only require the annotation when some extra metadata is required, you'd only need two or three @Attribute annotations on a class. -David
Re: Heads-up - GBeanInfo via annotations
On Mar 30, 2008, at 9:40 AM, David Jencks wrote: 3. I think we should think long and hard if we really need to identify references specifically. Can we get by with deciding how to treat them based on what is in the plan? An additional possible way to identify a reference is by checking the attribute class type for the @GBean annotation. -David
Re: Heads-up - GBeanInfo via annotations
Hi,
Sorry for starting another thread (I deleted the initial thread and
had to start another one).
From: Jason Dillon <[EMAIL PROTECTED]>
Looks cool. Only question I have is why the "G" prefix on
annotations other than GBean?
I will drop the "G" prefix on annotations other than GBean; it is
indeed better.
From: David Jencks <[EMAIL PROTECTED]>
I have a couple of suggestions and questions.
1. I think we should try harder to separate the identification of a
constructor parameter as attribute or reference from identifying
its name. So, I think we should use the java6 and xbean
@ParameterName annotations for names and something else for
references if necessary.
It seems to me that xbean only defines a @ParameterNames annotation,
which I think is quite efficient only when the number of parameters
is small. The need of a @ParameterName annotation, targeting a
parameter and not a constructor or method, really emerges when the
number of parameters increases.
If you want, I can add a @ParameterName annotation to xbean-reflect
instead of adding it to geronimo-kernel.
2. I'm pretty sure identifying something as an attribute isn't
necessary.
I partially agree: out-of-the-box attributes are added based on the
getters and setters of the GBean class. These attributes are defined
as non-persistent and non-manageable. It should be possible to turn
them persistent and manageable via an annotation. This is the purpose
of @Attribute which looks like this:
@Documented
@Retention(value = RUNTIME)
@Target(value = {METHOD})
public @interface Attribute {
boolean manageable() default true;
}
It now appears to me that @Attribute is poorly chosen and that
@Persistent may be more appropriate.
3. I think we should think long and hard if we really need to
identify references specifically. Can we get by with deciding how
to treat them based on what is in the plan?
Based on the GBeanData passed in to GBeanInstance, we can tell if an
attribute should be set to a GBeanReference or a simple value. What
does not seem possible is a way to derive the j2eeType of the target
of a GBeanReference as there is no reliable way of retrieving the
GBeanInfo of a class. Without such a reliable mechanism, I am not
sure how to remove the explicit configuration of references having a
specific j2eeType.
4. Can the GBean annotation be optional? I hope so :-) (e.g.
default j2eeType=GBean, default name = class name)
It is now optional :)
While you are looking at this. I think we may want to move
towards considering the basic unit of geronimo assembly as the
module/plugin rather than the gbean. This may have repercussions
on some things the admin console can do that add or remove gbeans
from a module, but I've always looked at those actions rather
sceptically. Doing both changes at once may be too big a jump but
IMO if you see a way to progress more quickly by moving towards
this additional goal I'd support it.
Could you please explain a little bit more as I do not understand
what you have in mind?
Thanks for the feedback!
Gianny
Re: Heads-up - GBeanInfo via annotations
I have a couple of suggestions and questions.
1. I think we should try harder to separate the identification of a
constructor parameter as attribute or reference from identifying its
name. So, I think we should use the java6 and xbean @ParameterName
annotations for names and something else for references if necessary.
2. I'm pretty sure identifying something as an attribute isn't
necessary.
3. I think we should think long and hard if we really need to
identify references specifically. Can we get by with deciding how to
treat them based on what is in the plan?
4. Can the GBean annotation be optional? I hope so :-) (e.g. default
j2eeType=GBean, default name = class name)
While you are looking at this. I think we may want to move
towards considering the basic unit of geronimo assembly as the module/
plugin rather than the gbean. This may have repercussions on some
things the admin console can do that add or remove gbeans from a
module, but I've always looked at those actions rather sceptically.
Doing both changes at once may be too big a jump but IMO if you see a
way to progress more quickly by moving towards this additional goal
I'd support it.
This looks great!
Thanks!
david jencks
On Mar 30, 2008, at 12:55 AM, Gianny Damour wrote:
Hi,
I am working on the declaration of GBeanInfo via annotations.
This is an example GBean with all the possible annotations (note
that some annotation properties have default values so you do not
see all of them in the example):
@GBean(j2eeType="type", name="name")
@GPriority(priority=123)
public class MockGBean implements Runnable {
public MockGBean(@GParamAttribute(name = "name") String name,
@GParamReference(name = "Name") Runnable runnable) {
}
public void run() {
}
@GAttribute
public String getGetterAttribute() {
return null;
}
@GAttribute
public void setSetterAttribute(String value) {
}
@GReference
public void setSetterReference(Runnable value) {
}
}
Above annotations are in the package
org.apache.geronimo.gbean.annotations.
At the same time, I will add support for pluggable strategies to
get the GBeanInfo of a class. We will have two strategies: use
getGBeanInfo method, current approach; or introspect annotations,
the one I am working on. It will be possible to add additional
strategies, e.g. read a service descriptor file a la OpenEJB.
I will also replace the GBean instantiation code of GBeanInstance
by an ObjectRecipe (xbean-reflect class).
Let me know if you have any concerns about the above plan.
Thanks,
Gianny
Re: Heads-up - GBeanInfo via annotations
Looks cool. Only question I have is why the "G" prefix on annotations
other than GBean?
--jason
On Mar 30, 2008, at 2:55 PM, Gianny Damour <[EMAIL PROTECTED]
> wrote:
Hi,
I am working on the declaration of GBeanInfo via annotations.
This is an example GBean with all the possible annotations (note
that some annotation properties have default values so you do not
see all of them in the example):
@GBean(j2eeType="type", name="name")
@GPriority(priority=123)
public class MockGBean implements Runnable {
public MockGBean(@GParamAttribute(name = "name") String name,
@GParamReference(name = "Name") Runnable runnable) {
}
public void run() {
}
@GAttribute
public String getGetterAttribute() {
return null;
}
@GAttribute
public void setSetterAttribute(String value) {
}
@GReference
public void setSetterReference(Runnable value) {
}
}
Above annotations are in the package
org.apache.geronimo.gbean.annotations.
At the same time, I will add support for pluggable strategies to get
the GBeanInfo of a class. We will have two strategies: use
getGBeanInfo method, current approach; or introspect annotations,
the one I am working on. It will be possible to add additional
strategies, e.g. read a service descriptor file a la OpenEJB.
I will also replace the GBean instantiation code of GBeanInstance by
an ObjectRecipe (xbean-reflect class).
Let me know if you have any concerns about the above plan.
Thanks,
Gianny
