Re: [aspectj-users] binary weaving and class dependency transitive closu

[Adrian Colyer <adrian.colyer@xxxxxxxxx>]

Let me give an example that might help clarify. Suppose the weaver
encounters a pointcut

pointcut foo() : execution(* SomeInterface+.*(..));

that is associated with a piece of advice. The weaver is weaving an
application class, MyApplicationClass. Does the pointcut match the
execution of methods defined in this class or not? The only way to
tell is to look at the direct supertypes - if SomeInterface is in the
set then we do match, otherwise we have to chase up the hierarchy
until we either hit Object in every branch, or we find a positive
match. To do this matching, the weaver will need to "find" all the
types in the hierarchy.

Consider the similar looking pointcut 

pointcut bar() : execution(* SomeClass.*(..));

also associated with a piece of advice. To determine whether or note
this pointcut matches we only need access to SomeClass, and no other
types will be pulled in.

On 29/07/05, Alexandre Vasseur <avasseur@xxxxxxxxx> wrote:
> Adam
> 
> The point around that is tied to the compilation phase. When you do
> binary weaving with ajc/iajc (that is post compile some jars to weave
> in some aspects from another jar f.e.) we need to resolve the
> pointcuts and see if we have a match.
> 
> In some case (depends on the pointcut as stated in the old post snip)
> this means that we need to know (in binary form) all the super class
> and interfaces that are parents of the class beeing weaved.
> This situation does not happen at all at deployment time but a weave
> time. The answer to the question " In effect, most (all?) concrete
> classes would need to be
> deployed.  Question is - is this true?" is thus NO.
> 
> This situation is one of the use case for load time weaving, where
> weaving happens (somehow) at "deployment" time. In that case we
> usually can resolve the types since as the JVM loads the classes, you
> should not have ClassNotFound and such exception from your own
> application since the environment in which you deploy does have all
> the required class in the hierarchy of this loaded class.
> 
> I hope this clarify a bit.
> Alex
> 
> 
> On 7/28/05, Adam Welch <adam.welch@xxxxxxxx> wrote:
> > Is this in the FAQ or docs somewhere?  The radio silence is deafening.
> >
> > ,Adam
> >
> > On Thu, 2005-07-21 at 12:00, Adam Welch wrote:
> > > I am a new user, so please forgive any mis-phrasings.  I am trying to
> > > use ajc to weave some aspects using -aspectpath and -inpath.  I have a
> > > conceptual question.  From googling, I saw this posted.
> > >
> > > http://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg00999.html
> > >
> > > >From which I snipped...
> > >
> > >         It is possible to use "within(my.class)",
> > >         "within(my.package..*)" or
> > >         "!within(exclude.pakage)" to scope a binary weave. However this technique
> > >         does not work if a class has a hierarchy dependency e.g. superclass on a
> > >         type that is not on the classpath You get a "can't find type ..." error. It
> > >         is not uncommon for applications to contain classes that cannot be resolved
> > >         due to external dependencies that were available during compile but not
> > >         during execution e.g. secure socket factories on AXIS (these can be
> > >         excluded as they have softer dependencies). AspectJ cannot binary weave
> > >         some of these applications. The question is:
> > >         1. Does the compiler need to resolve the class just to exclude it or is
> > >         this a bug?
> > >
> > > My question relates to this - I understand this to mean that all class
> > > dependencies must be present and supplied to ajc via one switch or
> > > another.  So, as the OP (snippet) states, this would seemingly present
> > > some problems for class factory situations, if not all concrete classes
> > > were deployed.  In effect, most (all?) concrete classes would need to be
> > > deployed.  Question is - is this true?
> > >
> > > Thanks in advance.
> > >
> > > ,Adam Welch
> > >
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 


-- 
-- Adrian
adrian.colyer@xxxxxxxxx