[aspectwerkz-dev] [jira] Deleted: (AW-192) Enhanced inner class matching support (needed for Hibernate)

     [ http://jira.codehaus.org/browse/AW-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

[email protected] deleted AW-192:
---------------------------------


> Enhanced inner class matching support (needed for Hibernate)
> ------------------------------------------------------------
>
>                 Key: AW-192
>                 URL: http://jira.codehaus.org/browse/AW-192
>             Project: AspectWerkz
>          Issue Type: Improvement
>            Reporter: Jonas Boner
>
> In addtion to this, it is better to improve inner class method point cut specification.
> let Cof a.A.B.C is an instance class of B which is an instance class of A, then when we define pointcut for a method m of C by a.A.B.C.m(int), this is actually corresponding to a.A$B$C.m(a.A, a.A.B, int), it would fail to capture this mathod. So AspectWerkz should recognize the inner class, and whether the declaring class are instance class or static class, and automatically add necessary signatures(e.g, a.A, a.A.B) to the pointcut specification.
> It will be quite convenient and natural.
> There are a little bit more issue how much AspectWerkz should expose these innternal parameter information at runtime through Rtti. One rigorous way may be to hide these paramters at runtime too...
> The bottom line is to avoid specific inner class representation of Sun JDK(I think how inner class are generated as A$B would not be part of specification, maybe it is almost de fact standard...). Conceptually, it is better not to handle these inner class as sort of syntax sugar.
> nn
> ----- Original Message -----
> From: "nn" <[email protected]>
> To: <[email protected]>
> Sent: Thursday, June 10, 2004 8:51 AM
> Subject: Re: [aspectwerkz-user] AspectWerkz and Hibernate collections
> > Using reflection library, it is possible recognize whether A of a.A is
> class
> > or packagenage name.
> > So technically this should be feasible.
> > These ambiguity is a part of Java spec, so we can not change it.
> > nn
> >
> >
> > ----- Original Message ----- 
> > From: "Steve Caswell" <scaswell-rjMgWMNrobOBUy7/[email protected]>
> > To: <[email protected]>
> > Sent: Thursday, June 10, 2004 8:36 AM
> > Subject: RE: [aspectwerkz-user] AspectWerkz and Hibernate collections
> >
> >
> > a.A.*.m(..) seems a bit ambiguous. Since there is no JLS prohibition on
> > using uppercase naming for packages, how do you tell whether this pattern
> > means "all inner classes of class A in package a" or "all classes in
> package
> > a.A"?
> >
> > > -----Original Message-----
> > > From: nn [mailto:[email protected]]
> > > Sent: Thursday, June 10, 2004 11:24 AM
> > > To: [email protected]
> > > Subject: Re: [aspectwerkz-user] AspectWerkz and Hibernate collections
> > >
> > >
> > > >> I'm trying to apply a logging aspect to all classes. Fortunately,
> > > >> most of the classes that matter follow a naming convention (i.e.,
> > > >> SomethingBaseImpl). So
> > > >>
> > > >> execute(com.termnetinc.domain..*BaseImpl.*(..))
> > > >>
> > > >> seems to work. There are a few others scattered about that don't
> > > >> follow that convention, but I can specify those individually as
> > > >> necessary. So this does seem to be a short-term workaround.
> > > >>
> > >
> > > >Yeah, we need to find a good solution to this. Anyone has any ideas?
> > >
> > > One obvious solution and quite natural to do is to avoid
> > > capturing inner
> > > classs by *.
> > > Java compiler generate inner class as something like A$B and
> > > A$B is treated
> > > as a normal class name.
> > > But this is internal implementation matter.
> > > It is more natural to handle inner class as real class, so
> > > a.*.m(..) should
> > > capture only a.A.m(), not a.A$B.m().
> > > If we want to capture B.m, we should write a.A.*.m(..).
> > > This will be cleanner approach.
> > >
> > > And (most of) CGLIB related porblems can be avoided if you do
> > > this way.
> > >
> > > nn
> > >
> > >
> >

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email