Details
-
Bug
-
Resolution: Done
-
Major
-
1.0.0.Beta4
-
None
-
Low
Description
It seems there is a bug that handle @AdministeredObject in Ironjacamar.
public @interface AdministeredObject
{
Class[] adminObjectInterfaces() default { };
}
public interface AdminObject extends IdDecoratedMetadata, CopyableMetaData
{
public abstract XsdString getAdminobjectInterface();
public abstract XsdString getAdminobjectClass();
....
}
The key line(611) in the AbstractResourceAdapterDeployer
if (aoMeta.getAdminobjectClass() != null &&
aoMeta.getAdminobjectClass().getValue() != null)
But for the annotation scan
for (Annotation annotation : values)
{
AdministeredObject a = (AdministeredObject)
annotation.getAnnotation();
if (trace)
log.trace("Processing: " + a);
String aoName = null;
if (a.adminObjectInterfaces().length > 0)
XsdString adminobjectInterface = new XsdString(aoName, null);
adminObjs.add(new AdminObjectImpl(adminobjectInterface,
null, null, null));
}
So it doesn't know AdminobjectClass any time.
In the JSR-311 document, it isn't clear about @AdministeredObject in the
annotation section.
regards
Jeff
The annotation scanning is not creating the right AdminObject since it puts always to null the Imple class in metadata.
Annotation scanning should take the scanned object and use its class as impl class. Use annotation.getClassNanme to obtain the annotated class.
Don't forget to implement a unit test proving the bug and documenting the solution.