Field signature usage

[alesj]

When doing annotation lookup on fields in AbstractBeanAnnotationAdapter there are two ways of doing that.

1) The same way as I'm doing it now via propertys
This is possible since fields are now 'propertys'.
But would require Signature abstraction on PropertyInfo.

2) Doing normal fields inspection
This would require a change to AnnotatedElementMetaDataLoader, since currently only public fields are supported.
Dealing with possible duplicates, e.g. existing only setter + FIELDS|ALL mode

The first one looks cleaner, and we should be 'fixing' the signature issue anyway for the instance annotations: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131947
But it's a bit of magic, since I doubt users/devs will expect fields as part of propertys.

The second one is more natural, handling fields is what you expect.
But would require more changes, e.g. MDL change, duplicates handling, ...

[adrian.brock]

"alesj" wrote:
When doing annotation lookup on fields in AbstractBeanAnnotationAdapter there are two ways of doing that.

1) The same way as I'm doing it now via propertys
This is possible since fields are now 'propertys'.
But would require Signature abstraction on PropertyInfo.

Why? What are you talking about?
BeanInfo/Reflection is not based on the metadata repository. It is the other way around.

2) Doing normal fields inspection
This would require a change to AnnotatedElementMetaDataLoader, since currently only public fields are supported.
Dealing with possible duplicates, e.g. existing only setter + FIELDS|ALL mode

If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"

[alesj]

Why? What are you talking about?
BeanInfo/Reflection is not based on the metadata repository. It is the other way around.

Sure.
But have a look at AbstractBeanAnnotationAdapter.
It needs Signature to get the MetaData.

If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"

That's all done. ;-)

[alesj]

"alesj" wrote:

Why? What are you talking about?
BeanInfo/Reflection is not based on the metadata repository. It is the other way around.

Sure.
But have a look at AbstractBeanAnnotationAdapter.
It needs Signature to get the MetaData.

If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"

That's all done. ;-)

OK, PI.getFieldInfo solves the problem.

I'll remove the fields check in AbstractBeanAnnotationAdapter, since they are already included in the propertys if the beaninfo has the right mode.

[alesj]

If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"

I'll still need that AnnotatedElementMetaDataLoader field change, for non-public fields.
It's the way I do annotation lookup in AbstractBeanAnnotationAdapter, going over MetaData to do the lookup:

 FieldInfo field = pi.getFieldInfo();
 if (field != null)
 {
 Signature sis = new FieldSignature(field);
 MetaData cmdr = retrieval.getComponentMetaData(sis);
 if (cmdr != null)
 {
 for(AnnotationPlugin plugin : fieldAnnotationPlugins)
 {
 if (isApplyPhase)
 plugin.applyAnnotation(field, cmdr, visitor);
 else
 plugin.cleanAnnotation(field, cmdr, visitor);
 }
 }
 else if (trace)
 log.trace("No annotations for field " + field.getName());
 }

If the field is non-public and the mode is non-standard, this field will be a part of propertys, but I don't want to distinct between underlying annotations and instance annotations (which are only in metadata, right).

[adrian.brock]

"alesj" wrote:

If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"

I'll still need that AnnotatedElementMetaDataLoader field change, for non-public fields.
It's the way I do annotation lookup in AbstractBeanAnnotationAdapter, going over MetaData to do the lookup:

 FieldInfo field = pi.getFieldInfo();
 if (field != null)
 {
 Signature sis = new FieldSignature(field);
 MetaData cmdr = retrieval.getComponentMetaData(sis);
 if (cmdr != null)
 {
 for(AnnotationPlugin plugin : fieldAnnotationPlugins)
 {
 if (isApplyPhase)
 plugin.applyAnnotation(field, cmdr, visitor);
 else
 plugin.cleanAnnotation(field, cmdr, visitor);
 }
 }
 else if (trace)
 log.trace("No annotations for field " + field.getName());
 }

If the field is non-public and the mode is non-standard, this field will be a part of propertys, but I don't want to distinct between underlying annotations and instance annotations (which are only in metadata, right).

You really need to learn to explain things from first princples.

I don't even understand if there is a question in your post
let alone what it is or what problem you are considering.

Assume I know nothing about AnnotatedElementMetaDataLoader
(which I don't, other than it exists - you wrote it and I've never reviewed this code :-)
or how it fits into the MC deployment protocol.

[adrian.brock]

By way of example, let me take your post apart.... ;-)

"alesj" wrote:

If you've done the field properties correctly, then this should just be
a case of using propertyInfo.get(Underlying)Annotations()
i.e. no getters/setters means use the field to get the annotations, but this
is all hidden from the caller - they are "property annotations"

I'll still need that AnnotatedElementMetaDataLoader field change, for non-public fields.

Why? Is that your implementation choice, it is a fundamental requirement
for this to work? etc. State the problem not the solution.

It's the way I do annotation lookup in AbstractBeanAnnotationAdapter, going over MetaData to do the lookup:

 FieldInfo field = pi.getFieldInfo();
 if (field != null)
 {
 Signature sis = new FieldSignature(field);
 MetaData cmdr = retrieval.getComponentMetaData(sis);
 if (cmdr != null)
 {
 for(AnnotationPlugin plugin : fieldAnnotationPlugins)
 {
 if (isApplyPhase)
 plugin.applyAnnotation(field, cmdr, visitor);
 else
 plugin.cleanAnnotation(field, cmdr, visitor);
 }
 }
 else if (trace)
 log.trace("No annotations for field " + field.getName());
 }
[/code

This shows you using the MetaData Repository (MDR)
not the field annotations. So if there's an issue, it is with the population
of the repository not this code.

I don't understand how the code you show has any relation
to field annotaions, since it doesn't use that api (at least directly).

And as I said above, I don't know this code and certainly can't assertain
how it works from a partial code snippet.

If the field is non-public and the mode is non-standard, this field will be a part of propertys, but I don't want to distinct between underlying annotations and instance annotations (which are only in metadata, right).

The conclusion is true, but what relevance that fact has to the rest of the sentence
is unclear to me. You need to "join the dots" :-)

[alesj]

You really need to learn to explain things from first principles.

Yup, known old problem. :-)

I don't even understand if there is a question in your post
let alone what it is or what problem you are considering.

The problem that I have is that non-public fields are not part of MetaData.
The AEMDL only handles public fields:

 public MetaDataRetrieval getComponentMetaDataRetrieval(Signature signature)
 {
 ...
 else if (signature instanceof FieldSignature)
 {
 try
 {
 Field field = clazz.getField(signature.getName());
 return new AnnotatedElementMetaDataLoader(field);
 }
 catch (NoSuchFieldException e)
 {
 return null;
 }
 }
 }

Which means I cannot use the MetaData to get the underlying annotations for non-public fields, like I do it in my AbstractBeanAnnotationAdapter.

The question is, should/can I change the impl of AEMDL to handle non-public fields as well?

Better? :-)

Assume I know nothing about AnnotatedElementMetaDataLoader
(which I don't, other than it exists - you wrote it and I've never reviewed this code :-)
or how it fits into the MC deployment protocol.

Nope, you wrote it, I just filled some of the missing pieces. ;-)

/**
 * AnnotatedElementMetaDataLoader.
 *
 * @author <a href="[e-mail]">Adrian Brock</a>
 * @version $Revision: 67291 $
 */
public class AnnotatedElementMetaDataLoader extends BasicMetaDataLoader

[adrian.brock]

"alesj" wrote:

Assume I know nothing about AnnotatedElementMetaDataLoader
(which I don't, other than it exists - you wrote it and I've never reviewed this code :-)
or how it fits into the MC deployment protocol.

Nope, you wrote it, I just filled some of the missing pieces. ;-)

Ok. I actually thought this was your annotation processing inside the MC. :-)

The problem that I have is that non-public fields are not part of MetaData.

...

Better? :-)

Yes. If this doesn't handle private "joinpoints" then its obviously a
bug that should be fixed.

Now I understand why there was no question in your original post
you were just stating the obvious in a not very obvious way. :-)

[alesj]

Now I understand why there was no question in your original post
you were just stating the obvious in a not very obvious way. :-)

Prehaps a big BUG text with AEMDL would explain it better than my ramblings. :-)

[adrian.brock]

Can you raise JIRA issues for these please, so I know when they are done
and users know what changed.

[alesj]

Can you raise JIRA issues for these please, so I know when they are done
and users know what changed.

http://jira.jboss.com/jira/browse/JBMDR-14