Re: [aspectj-dev] FW: [metadata-jsr] Reflection API: which classloa

["Alex" <aspectj@xxxxxxxxxx>]

Hi

I don't know if it clashes with the following but here are my ideas as
regards metadata and AOP.

1/ MetaData can be seen as a pointcut at weave time.

At weave time we have bytecode byte[] and not yet a Class instance, so the
"getAnnotation" API cannot help.
We can probably have some handling of that thru bytecode magic, and thus
accessing the metadata should not really be an issue tight to the
classloader (basically the bytecode kit - e.g. bcel - will have to provide
an API to have the metadata "Annotation" of class + runtime retention from
the class bytecode).
(in fact we probably need the defining class loader and we have this one
in JSR 163)

I have no idea if I can do some usefull things for package level
Annotation (package-info.java special file) at weave time, especially if
it is class load time weaving.

2/ Metadata can be used at runtime to adapt an advice behavior given the
metadata, with a runtime retention policy

Use-case could be some @transaction type="required" on aMethod of myPojo.
I need to access it at weave time to hook advice behavior, and at runtime
from within the advice thru runtime type information on the advised class
/ instance.

In such a scenario, If I have an app server with 2 versions of myPojo.java
deployed in two different apps, I have 2 parallel class loader hierarchies
[X see below]. Those 2 versions have different transaction level for
"aMethod" (ok it might be bad practice to deploy things twice differently
in the same app server but why not ?). We could even have the @transaction
annotation differs in the 2 version, and those annotations be packaged
twice in each application (e.g EAR).

AppServer
  App 1
    MyPojo.aMethod   @Transaction type="required"
    Transaction annotation is v1
  App 2
    MyPojo.aMethod   @Transaction type="requiresNew"
    Transaction annotation is v2 (supports requiresNew since v2 only)

In such a case, I assume that I will be able from within my advice code to
access at runtime thru "getAnnotation" the correct annotated element for
each one. And note that the Annotation itself can be specific to each app
if the annotation is packaged in each application.

When reading at the spec it seems obvious since the "getAnnotation" method
is at Class level and so on, and thus in this scenario I have 2 "Class"
instances for my 2 myPojo deployed class files.
I probably missed something with what this issue relates too, but i
explained the way I assume it will work.

Will it work that way ?
Alex - AspectWerkz

[X] applies to weblogic, websphere (.. others ..) and can apply to JBoss
if you explictly avoid the JBoss default flat classloader from what I
know.



>
> Does someone here want to send me a comment on this that I
> can forward to jsr-175?
>
> -----Original Message-----
> From: metadata-jsr-admin@xxxxxxxxxxxxx
> [mailto:metadata-jsr-admin@xxxxxxxxxxxxx] On Behalf Of Doug Lea
> Sent: Saturday, February 28, 2004 5:23 PM
> To: metadata-jsr@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [metadata-jsr] Reflection API: which classloader?
>
>
> I had a conversation with Neal Gafter about the class loader issue in
> which he rubbed off just enough of his paranoia fear of the unknown
> :-) to make me want to bring it up again.
>
> Recall that the issue is that you could have an AnnotatedElement e
> (i.e., some Class, Constructor, Field, Method, or Package), for which
>   e.getAnnotations();
> might not return some or all annotations because they were loaded
> using some other class loader than the one the caller is using.
>
> I suspect this discussion didn't get too far because most of us think
> that the less said here or anywhere about class loaders the better.
> But I also know that some frameworks out there use different class
> loaders for all sorts of odd purposes. And so have a lingering worry
> that Neal's main use-case ...
>
>>  For example, one might wish to have a single annotation processing
>> facility present in its own class loader but supporting processing
>> of that annotation for a number of subsystems, each in its own class
>> loader.
>
> ... might actually be needed somewhere in AOP or J2EE frameworks.
>
> Cedric, Simon, and Gregor: Could you possibly ask around and see what
> people building WebLogic, Websphere, AspectJ frameworks think about
> this?  Ted already asked at Oracle, and they are happy not to have the
> ability to do this.  My guess is that others will say either that they
> don't need it either, or that it might be nice to have but not
> essential.
>
> If this is so, I think we can safely drop the issue in JSR175, because
> there is a pretty good story about how to add support if it ever
> becomes necessary: Just add overloaded method
>     AnnotatedElement.getAnnotations(ClassLoader cl)
> that returns all annotations available from the given class loader.
> This would be a simple addition API-wise, although not
> implementation-wise, because big chunks of the current implementation
> would need changing to lazily resolve an AnnotatedElement with respect
> to the class loader that it carries around.
>
> Further, while I think it is important to find out now if anyone
> believes that this IS essential, we in JSR175 probably can't in good
> conscience demand that it be added now.  If we did, it would be at
> most incompletely implemented (i.e., buggy) in JDK1.5, which would not
> do anyone a favor. However, the knowledge that there will be an RFE
> for adding the method might enable some short-term adjustments to make
> it easier to put in later.
>
> -Doug
>
> _______________________________________________
> metadata-jsr mailing list
> metadata-jsr@xxxxxxxxxxxxxxxxxxxx
> http://altair.cs.oswego.edu/mailman/listinfo/metadata-jsr
>
>
> _______________________________________________
> metadata-jsr mailing list
> metadata-jsr@xxxxxxxxxxxxxxxxxxxx
> http://altair.cs.oswego.edu/mailman/listinfo/metadata-jsr
>
>
>
>
>