Proposal of a Patch for Scala

[phkoester]

Using the AspectJ weaver in Scala programs might result in exceptions
like these (long paste ahead):

*

Oct 7, 2009 8:56:55 PM org.aspectj.weaver.tools.Jdk14Trace error
SEVERE: scala/collection/Iterator$$anon$3
org.aspectj.weaver.BCException: Whilst processing type
'Lscala/collection/Iterator$$anon$3;' - cannot cast the outer type to a
reference type.  Signature=Lscala/collection/Iterator$$anon;
toString()=scala.collection.Iterator$$anon
when processing type mungers
when weaving

         at
org.aspectj.weaver.AbstractReferenceTypeDelegate.getFormalTypeParametersFromOuterClass(AbstractReferenceTypeDelegate.java:108)
         at
org.aspectj.weaver.bcel.BcelObjectType.ensureGenericSignatureUnpacked(BcelObjectType.java:728)
         at
org.aspectj.weaver.bcel.BcelObjectType.getSuperclass(BcelObjectType.java:209)
         at
org.aspectj.weaver.ReferenceType.getSuperclass(ReferenceType.java:855)
         at
org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:1433)
         at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1257)
         at
org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:423)
         at
org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:286)
         at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:96)
         at
org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:52)
         at
org.springframework.context.weaving.AspectJWeavingEnabler$AspectJClassBypassingClassFileTransformer.transform(AspectJWeavingEnabler.java:97)
         at
org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver$FilteringClassFileTransformer.transform(InstrumentationLoadTimeWeaver.java:181)
         at sun.instrument.TransformerManager.transform(Unknown Source)
         at sun.instrument.InstrumentationImpl.transform(Unknown Source)
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(Unknown Source)
         at java.security.SecureClassLoader.defineClass(Unknown Source)
         at java.net.URLClassLoader.defineClass(Unknown Source)
         at java.net.URLClassLoader.access$000(Unknown Source)
         at java.net.URLClassLoader$1.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(Unknown Source)
         at java.lang.ClassLoader.loadClass(Unknown Source)
         at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
         at java.lang.ClassLoader.loadClass(Unknown Source)
         at java.lang.ClassLoader.loadClassInternal(Unknown Source)
         at scala.collection.Iterator$.<init>(Iterator.scala:26)
         at scala.collection.Iterator$.<clinit>(Iterator.scala)
         at scala.package$.<init>(package.scala:15)
         at scala.package$.<clinit>(package.scala)
         at scala.Predef$.<init>(Predef.scala:65)
         at scala.Predef$.<clinit>(Predef.scala)
         at com.phrood.sack.Apple.<init>(Apple.scala:10)
         at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
         at
sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
         at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
         at java.lang.reflect.Constructor.newInstance(Unknown Source)
         at
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:126)
         at
org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:72)
         at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:932)
         at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:884)
         at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:479)
         at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:450)
         at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:289)
         at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
         at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:286)
         at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:188)
         at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:543)
         at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:730)
         at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:387)
         at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
         at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
         at com.phrood.sack.Sack.run(Sack.scala:35)
Oct 7, 2009 8:56:55 PM org.aspectj.weaver.tools.Jdk14Trace info
INFO: Dumping to
c:\Users\phkoester\Data\phrood\sack\target\sack-1.0-beta-1-bin\.\ajcore.20091007.205655.878.txt

*

The problem is that `BcelObjectType.getOuterClass' will transform the
string `scala/collection/Iterator$$anon$3' to
`scala/collection/Iterator$$anon', which---in
`AbstractReferenceTypeDelegate.getFormalTypeParametersFromOuterClass'---does
not  result in an instance of `ReferenceType'.

In order to solve this problem and avoid this exception, I added three
lines to `BcelObjectType.getOuterClass' like so:

*

String superClassName = className.substring(0, lastDollar);
final String anon = "$$anon"; // Scala
if (superClassName.endsWith(anon)) {
        superClassName = superClassName.substring(0, superClassName.length() -
anon.length());
}
UnresolvedType outer = UnresolvedType.forName(superClassName);

*

I'm not certain whether this is the definitive fix---all I can say is
that it works for me: no exceptions any more, and working load-time
weaving for Scala classes.

What would be the usual procedure to validate this code and possibly
incorporate it into future versions of the weaver?

Regards
---Philip
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

Is this the problem already raised as:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=288064 ?

That includes a possibly more general patch than the one you propose?

Andy

2009/10/7 Philip Köster <philip.koester@...>:

> Using the AspectJ weaver in Scala programs might result in exceptions like
> these (long paste ahead):
>
> *
>
> Oct 7, 2009 8:56:55 PM org.aspectj.weaver.tools.Jdk14Trace error
> SEVERE: scala/collection/Iterator$$anon$3
> org.aspectj.weaver.BCException: Whilst processing type
> 'Lscala/collection/Iterator$$anon$3;' - cannot cast the outer type to a
> reference type.  Signature=Lscala/collection/Iterator$$anon;
> toString()=scala.collection.Iterator$$anon
> when processing type mungers
> when weaving
>
>        at
> org.aspectj.weaver.AbstractReferenceTypeDelegate.getFormalTypeParametersFromOuterClass(AbstractReferenceTypeDelegate.java:108)
>        at
> org.aspectj.weaver.bcel.BcelObjectType.ensureGenericSignatureUnpacked(BcelObjectType.java:728)
>        at
> org.aspectj.weaver.bcel.BcelObjectType.getSuperclass(BcelObjectType.java:209)
>        at
> org.aspectj.weaver.ReferenceType.getSuperclass(ReferenceType.java:855)
>        at
> org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:1433)
>        at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1257)
>        at
> org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:423)
>        at
> org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:286)
>        at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:96)
>        at
> org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:52)
>        at
> org.springframework.context.weaving.AspectJWeavingEnabler$AspectJClassBypassingClassFileTransformer.transform(AspectJWeavingEnabler.java:97)
>        at
> org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver$FilteringClassFileTransformer.transform(InstrumentationLoadTimeWeaver.java:181)
>        at sun.instrument.TransformerManager.transform(Unknown Source)
>        at sun.instrument.InstrumentationImpl.transform(Unknown Source)
>        at java.lang.ClassLoader.defineClass1(Native Method)
>        at java.lang.ClassLoader.defineClass(Unknown Source)
>        at java.security.SecureClassLoader.defineClass(Unknown Source)
>        at java.net.URLClassLoader.defineClass(Unknown Source)
>        at java.net.URLClassLoader.access$000(Unknown Source)
>        at java.net.URLClassLoader$1.run(Unknown Source)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at java.net.URLClassLoader.findClass(Unknown Source)
>        at java.lang.ClassLoader.loadClass(Unknown Source)
>        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>        at java.lang.ClassLoader.loadClass(Unknown Source)
>        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
>        at scala.collection.Iterator$.<init>(Iterator.scala:26)
>        at scala.collection.Iterator$.<clinit>(Iterator.scala)
>        at scala.package$.<init>(package.scala:15)
>        at scala.package$.<clinit>(package.scala)
>        at scala.Predef$.<init>(Predef.scala:65)
>        at scala.Predef$.<clinit>(Predef.scala)
>        at com.phrood.sack.Apple.<init>(Apple.scala:10)
>        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>        at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source)
>        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source)
>        at java.lang.reflect.Constructor.newInstance(Unknown Source)
>        at
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:126)
>        at
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:72)
>        at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:932)
>        at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:884)
>        at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:479)
>        at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:450)
>        at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:289)
>        at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
>        at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:286)
>        at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:188)
>        at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:543)
>        at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:730)
>        at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:387)
>        at
> org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
>        at
> org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
>        at com.phrood.sack.Sack.run(Sack.scala:35)
> Oct 7, 2009 8:56:55 PM org.aspectj.weaver.tools.Jdk14Trace info
> INFO: Dumping to
> c:\Users\phkoester\Data\phrood\sack\target\sack-1.0-beta-1-bin\.\ajcore.20091007.205655.878.txt
>
> *
>
> The problem is that `BcelObjectType.getOuterClass' will transform the string
> `scala/collection/Iterator$$anon$3' to `scala/collection/Iterator$$anon',
> which---in
> `AbstractReferenceTypeDelegate.getFormalTypeParametersFromOuterClass'---does
> not  result in an instance of `ReferenceType'.
>
> In order to solve this problem and avoid this exception, I added three lines
> to `BcelObjectType.getOuterClass' like so:
>
> *
>
> String superClassName = className.substring(0, lastDollar);
> final String anon = "$$anon"; // Scala
> if (superClassName.endsWith(anon)) {
>        superClassName = superClassName.substring(0, superClassName.length()
> - anon.length());
> }
> UnresolvedType outer = UnresolvedType.forName(superClassName);
>
> *
>
> I'm not certain whether this is the definitive fix---all I can say is that
> it works for me: no exceptions any more, and working load-time weaving for
> Scala classes.
>
> What would be the usual procedure to validate this code and possibly
> incorporate it into future versions of the weaver?
>
> Regards
> ---Philip
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[phkoester]

> Is this the problem already raised as:

I think it is the very same problem, yes.

> That includes a possibly more general patch than the one you propose?

Possibly. I don't know what this fix does, exactly. Linas and I already
talked on the scala-tools list about this matter and now we come up with
two different approaches. I just noticed yesterday that there was a new
weaver version around (1.6.6) which still has this Scala problem.

So I simply got impatient to have a working fix.

As far as I can see it's not the dollar signs that pose the problem but
only that the synthesized `anon' class does not result in a `ReferenceType'.

But I'm not an expert in this field---I only seeked for a working solution.

Cheers
---Phil
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

If you can build a simple testcase that shows the problem (which ought
to be possible without using scalac as it is just a naming problem), I
will work to put the patch from the bug in.
As I just commented in the bug, I don't have enough there to create a
regression test.  For example, this works:

> Outer.java
public class Outer {
  public class Inner$1 {
  }
  public class Inner$$$1$$2 {
  }
}

> X.java
aspect X {
  before(): within(*) {}
}

ajc X.java Outer.java

I suspect the pointcut needs changing to drive appropriate analysis
that leads to the failure.

cheers,
Andy

2009/10/7 Philip Köster <philip.koester@...>:

>> Is this the problem already raised as:
>
> I think it is the very same problem, yes.
>
>> That includes a possibly more general patch than the one you propose?
>
> Possibly. I don't know what this fix does, exactly. Linas and I already
> talked on the scala-tools list about this matter and now we come up with two
> different approaches. I just noticed yesterday that there was a new weaver
> version around (1.6.6) which still has this Scala problem.
>
> So I simply got impatient to have a working fix.
>
> As far as I can see it's not the dollar signs that pose the problem but only
> that the synthesized `anon' class does not result in a `ReferenceType'.
>
> But I'm not an expert in this field---I only seeked for a working solution.
>
> Cheers
> ---Phil
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[phkoester]

Andy Clement wrote:

> If you can build a simple testcase that shows the problem (which ought
> to be possible without using scalac as it is just a naming problem), I
> will work to put the patch from the bug in.

I'm not sure if this is really only a naming problem. Currently, for a
class name like `Outer$$anon$1', the weaver will look for an outer class
named `Outer$$anon', which is straight-forward and perfectly sensible
from the weaver's point of view.

I'd need more knowledge about the Scala-generated bytecode here---my
suspection is that there is no inner class named `anon' but that the
name of the inner class is actually `$anon$1', hence `Outer' would be
the next possible outer class.

>> Outer.java
> public class Outer {
>   public class Inner$1 {
>   }
>   public class Inner$$$1$$2 {
>   }
> }

What happens if you insert an inner class named `$anon$1' there?

---Ph.
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

> What happens if you insert an inner class named `$anon$1' there?

It compiles fine.  However, as I said, the problem may be my pointcut
is not driving the necessary analysis.  Are you able to tell me what
pointcuts you are using to trigger the failure?

Based on your note and that bug report, there is a problem that
AspectJ is a bit dumb about looking for the outer class and if you use
names containing dollars (which are valid), it needs to be smarter.
What I'm after here is a demo piece of java code that surfaces the
dumbness so I can apply the patch and fix it.  As the patch in the bug
suggests, there are attributes around in the class file that give you
proper information about inner classes, and they could be used to make
the weaver do the right thing.

When I have time, I will work on the pointcut that surfaces the
failure, but I'm a bit snowed under right now to look at exploring the
possible variations - hence if you have a particular pointcut that
already causes the problem, that would be very helpful.

cheers
Andy


2009/10/7 Philip Köster <philip.koester@...>:

> Andy Clement wrote:
>
>> If you can build a simple testcase that shows the problem (which ought
>> to be possible without using scalac as it is just a naming problem), I
>> will work to put the patch from the bug in.
>
> I'm not sure if this is really only a naming problem. Currently, for a class
> name like `Outer$$anon$1', the weaver will look for an outer class named
> `Outer$$anon', which is straight-forward and perfectly sensible from the
> weaver's point of view.
>
> I'd need more knowledge about the Scala-generated bytecode here---my
> suspection is that there is no inner class named `anon' but that the name of
> the inner class is actually `$anon$1', hence `Outer' would be the next
> possible outer class.
>
>>> Outer.java
>>
>> public class Outer {
>>  public class Inner$1 {
>>  }
>>  public class Inner$$$1$$2 {
>>  }
>> }
>
> What happens if you insert an inner class named `$anon$1' there?
>
> ---Ph.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[phkoester]

> It compiles fine.  However, as I said, the problem may be my pointcut
> is not driving the necessary analysis.  Are you able to tell me what
> pointcuts you are using to trigger the failure?

As a matter of fact, I don't use any AspectJ pointcuts directly. The
reason why I use AspectJ's LTW is that I have learned to love the
advantages of Spring's `Configurable' annotation, which I find ingenious
beacause it leads to less cluttered and more legible code.

> Based on your note and that bug report, there is a problem that
> AspectJ is a bit dumb about looking for the outer class and if you use
> names containing dollars (which are valid), it needs to be smarter.
> What I'm after here is a demo piece of java code that surfaces the
> dumbness so I can apply the patch and fix it.  As the patch in the bug
> suggests, there are attributes around in the class file that give you
> proper information about inner classes, and they could be used to make
> the weaver do the right thing.

I never claimed my "patch" was a decent one, in fact it is nothing more
than a quick and dirty hack I did last night to solve the most urgent
problems. Tonight I incorporated Linas's patch, and it works fine for
me. It looks like he did "the real thing" although from looking at the
source, I could not tell if he did everything alright.

How is "outer class" defined here? As a class's next outer class, or as
the outermost class of the compilation unit? (I reckon the first, else
it would be too trivial.) I was a bit confused by the identifier
`superClassName' because I don't think a superclass is meant
here---maybe `outerClassName' would be a better identifier (at the end
of `BcelObjectType.getOuterClass').

As for the regression tests, I don't think I could deliver some tangible
help, Andy, because I'm not at all familiar with the classes that Linas
is using.

---Phil
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

Thanks Phil, that is really helpful in fact - knowing that it is
Spring @Configurable support you are using, I can lookup the pointcut
involved :)

Andy

2009/10/8 Philip Köster <philip.koester@...>:

>> It compiles fine.  However, as I said, the problem may be my pointcut
>> is not driving the necessary analysis.  Are you able to tell me what
>> pointcuts you are using to trigger the failure?
>
> As a matter of fact, I don't use any AspectJ pointcuts directly. The reason
> why I use AspectJ's LTW is that I have learned to love the advantages of
> Spring's `Configurable' annotation, which I find ingenious beacause it leads
> to less cluttered and more legible code.
>
>> Based on your note and that bug report, there is a problem that
>> AspectJ is a bit dumb about looking for the outer class and if you use
>> names containing dollars (which are valid), it needs to be smarter.
>> What I'm after here is a demo piece of java code that surfaces the
>> dumbness so I can apply the patch and fix it.  As the patch in the bug
>> suggests, there are attributes around in the class file that give you
>> proper information about inner classes, and they could be used to make
>> the weaver do the right thing.
>
> I never claimed my "patch" was a decent one, in fact it is nothing more than
> a quick and dirty hack I did last night to solve the most urgent problems.
> Tonight I incorporated Linas's patch, and it works fine for me. It looks
> like he did "the real thing" although from looking at the source, I could
> not tell if he did everything alright.
>
> How is "outer class" defined here? As a class's next outer class, or as the
> outermost class of the compilation unit? (I reckon the first, else it would
> be too trivial.) I was a bit confused by the identifier `superClassName'
> because I don't think a superclass is meant here---maybe `outerClassName'
> would be a better identifier (at the end of `BcelObjectType.getOuterClass').
>
> As for the regression tests, I don't think I could deliver some tangible
> help, Andy, because I'm not at all familiar with the classes that Linas is
> using.
>
> ---Phil
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

On the bug report Linas provided a proper failing test, I've
integrated that and his patch - it will be in a dev build later today.

Andy

2009/10/8 Andy Clement <andrew.clement@...>:

> Thanks Phil, that is really helpful in fact - knowing that it is
> Spring @Configurable support you are using, I can lookup the pointcut
> involved :)
>
> Andy
>
> 2009/10/8 Philip Köster <philip.koester@...>:
>>> It compiles fine.  However, as I said, the problem may be my pointcut
>>> is not driving the necessary analysis.  Are you able to tell me what
>>> pointcuts you are using to trigger the failure?
>>
>> As a matter of fact, I don't use any AspectJ pointcuts directly. The reason
>> why I use AspectJ's LTW is that I have learned to love the advantages of
>> Spring's `Configurable' annotation, which I find ingenious beacause it leads
>> to less cluttered and more legible code.
>>
>>> Based on your note and that bug report, there is a problem that
>>> AspectJ is a bit dumb about looking for the outer class and if you use
>>> names containing dollars (which are valid), it needs to be smarter.
>>> What I'm after here is a demo piece of java code that surfaces the
>>> dumbness so I can apply the patch and fix it.  As the patch in the bug
>>> suggests, there are attributes around in the class file that give you
>>> proper information about inner classes, and they could be used to make
>>> the weaver do the right thing.
>>
>> I never claimed my "patch" was a decent one, in fact it is nothing more than
>> a quick and dirty hack I did last night to solve the most urgent problems.
>> Tonight I incorporated Linas's patch, and it works fine for me. It looks
>> like he did "the real thing" although from looking at the source, I could
>> not tell if he did everything alright.
>>
>> How is "outer class" defined here? As a class's next outer class, or as the
>> outermost class of the compilation unit? (I reckon the first, else it would
>> be too trivial.) I was a bit confused by the identifier `superClassName'
>> because I don't think a superclass is meant here---maybe `outerClassName'
>> would be a better identifier (at the end of `BcelObjectType.getOuterClass').
>>
>> As for the regression tests, I don't think I could deliver some tangible
>> help, Andy, because I'm not at all familiar with the classes that Linas is
>> using.
>>
>> ---Phil
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[phkoester]

> On the bug report Linas provided a proper failing test, I've
> integrated that and his patch - it will be in a dev build later today.

That's good news.

Two questions:

1.  Where and how do I get this dev build and corresponding sources,
possibly through Maven?

2. I activate load-time weaving in a Spring XML like so:

        <context:load-time-weaver/>
        <context:spring-configured/>

What would I have to do to use *compile-time* weaving for `@Configurable'?

Cheers
---Phil
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

> 1.  Where and how do I get this dev build and corresponding sources, possibly through Maven?

I spoke prematurely about the dev build - a bit of wierdness on the
build machine stopped it running the tests successfully. I've kicked
off another build which should appear shortly (I'll keep an eye on it
today).

I'm afraid the dev builds never make it into maven.  The next release
containing the fix will be AspectJ 1.6.7 in December - that will be in
maven.  Dev builds are here:

http://eclipse.org/aspectj/downloads.php

(but as I said, you will need one from today, not yesterdays)

I don't make sources available for the dev builds, just the releases -
that process isn't automated so it is a pain.  Although all the code
is in CVS of course.  Only a couple of source files are any different
to the 1.6.6 source attachment, the main one being the one changed by
the patch I applied to address your issue.

> 2. I activate load-time weaving in a Spring XML like so:

For compile time weaving.  install AJDT into your eclipse, convert
your project to an AspectJ project and put the spring aspects jar on
your aspectpath.  When it builds the aspects will be applied based on
your @Configurable annotation (I believe).  If on the command line,
use iajc instead of javac to compile your code and put the spring
aspects jar on the aspect path.  Or continue to use javac but add an
iajc step after that to binary weave the javac output (again with the
spring aspects jar on the aspect path for the iajc call).

Andy




2009/10/8 Philip Köster <philip.koester@...>:

>> On the bug report Linas provided a proper failing test, I've
>> integrated that and his patch - it will be in a dev build later today.
>
> That's good news.
>
> Two questions:
>
> 1.  Where and how do I get this dev build and corresponding sources,
> possibly through Maven?
>
> 2. I activate load-time weaving in a Spring XML like so:
>
>        <context:load-time-weaver/>
>        <context:spring-configured/>
>
> What would I have to do to use *compile-time* weaving for `@Configurable'?
>
> Cheers
> ---Phil
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users