[jboss-jira] [JBoss JIRA] Commented: (JBJCA-512) AdminObject annotation scanning is not creating correct metadata

[Stefano Maestri (JIRA)]

    [ https://issues.jboss.org/browse/JBJCA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586556#comment-12586556 ] 

Stefano Maestri commented on JBJCA-512:
---------------------------------------

<maeste> jpederse: first point: we are not considering implemented intefaces
<maeste> jpederse: but specs ask to
<maeste> jpederse: 2) we are not considering properties (annotated one). Here I've not yet found if spec require or not
<maeste> jpederse: 3) we had some resourceadapter annotated with @AdministerObject
<maeste> jpederse: in our test cases
<maeste> jpederse: that is valid, but these test cases was written considering @AdministeredObject as pointer to impl class
* smarlow (~smarlow at vpn-11-236.rdu.redhat.com) has joined #jca
<maeste> jpederse: while it should annotate the ResourceAdapter as AdminObject too
<jpederse> maeste: 1) that is more of a question what should be exposed - but we should record that
<maeste> jpederse: moreover multiple annotated object are not validated by a testcase, and I suspect we can have some merge problem there, even if I haven't analised very well
<jpederse> maeste: 2) Spec 18.5
<jpederse> maeste: 3) something that the validator should pick up
<jpederse> maeste: regarding coverage - yes, probably more tests should be added in this area
<maeste> jizhang: BTW I haven't stressed code generator on thhis points (mainly the first one), but we have to verufy that code generator avoid to create wrong annotations

> AdminObject annotation scanning is not creating correct metadata
> ----------------------------------------------------------------
>
>                 Key: JBJCA-512
>                 URL: https://issues.jboss.org/browse/JBJCA-512
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 1.0.0.Beta4
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 1.0.0.Beta5
>
>
> 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)
>              {
>                 aoName = ((Class) Array.get(a.adminObjectInterfaces(), 
> 0)).getName();
>              }
>              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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira