|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
LTW into javax.swingWhat I am trying to do: Swing has support for Tooltips, but that
functionality is very basic. There are two functions (SetToolTip() and
GetToolTip()) which either take a String argument or return one. I
would like to have different Tooltips, to be precise, different
verbosity levels, for all tooltips in my project. Of course I could
either overload all used JComponents (hah!) or use some other
nontrivial approach (manage my own listeners...) to set these values
anew every time the user changes the verbosity level.
But on the other hand, having an Aspect weave into GetToolTip() would instantly solve my issues, as I could then change the return parameter (read from a properties file). I have managed to figure out how to basically do this, and it works, as long as I am weaving into my own code (I suppose it would work at compile time even). But for some reason, weaving into Swing fails without error messages, it just does not happen. I assume the class loader has my classes prepared before the weaver kicks in, but I have absolutely no idea how to do that different. There is also not a lot of literature on the subject and I only assume this happens because I've read somewhere that writing a classloader might be necessary (without explanation as to why or how). I am settnig the option to the weaver to include javax, but it won't find JComponent. If I don't exclude the org.jdesktop package, it even tries to find the superclasses of some of the jdesktop parts at javax.jnlp.*, so it doesn't completely fail. As for the call I want to intercept: javax.swing.ToolTipManager is the class that calls my target function. It never gets woven. As for the code I use: aop.xml: <aspectj> <aspects> <aspect name="<something>.weaver. Wrangler"/>
<include within="<something>..*"/> <include within="javax.swing..*"/> <exclude within="org.jdesktop..*"/> </aspects> <weaver options="-verbose -Xset:weaveJavaxPackages=true -Xset:weaveJavaPackages=true -showWeaveInfo" > <include within="<something>..*"/> <include within="javax.swing..*"/> <exclude within="org.jdesktop..*"/> </weaver> </aspectj> public aspect Wrangler { before(JComponent component): call( public String JComponent.getToolTipText(MouseEvent) ) && target(component) { System.out.println("Intercepted!"); //target.setToolTip("My new thing"); } } The output I get: [AppClassLoader@19134f4] weaveinfo Join point 'method-call(java.lang.String javax.swing.JMenuItem.getToolTipText())' in Type <something>.gui.AppClientView' (AppClientView.java:596) advised by before advice from '<something>.weaver.Wrangler' (Wrangler.aj:33) And all other calls I make myself. Changing this to execution or anything like that does not help at all. No Javax.Swing classes are woven at all. _______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
RE: LTW into javax.swingI have made the same
error few months ago. You have to set only one Xset like : -Xset:weaveJavaxPackages=true,weaveJavaPackages=true Jean-Louis Pasturel De :
aspectj-users-bounces@... [mailto:aspectj-users-bounces@...] De la part de Kajetan Abt What I am trying to do: Swing has support for Tooltips, but that
functionality is very basic. There are two functions (SetToolTip() and
GetToolTip()) which either take a String argument or return one. I would like
to have different Tooltips, to be precise, different verbosity levels, for all
tooltips in my project. Of course I could either overload all used JComponents
(hah!) or use some other nontrivial approach (manage my own listeners...) to
set these values anew every time the user changes the verbosity level. Wrangler"/> ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** _______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingThat did not work, I get an identical behaviour. Still, thanks for finding a bug.
2009/9/25 <jeanlouis.pasturel@...>
_______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingHi,
Take a look at: http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html and try some of the debug/verbose options there - that will tell you whether the classloader is able to pass the types you are interested to a weaver. If they cannot be passed to a weaver they will never be woven, regardless of options or pointcuts. Can you use compile time weaving? That would definetly work. Andy 2009/9/25 Kajetan Abt <kdansky@...>: > That did not work, I get an identical behaviour. Still, thanks for finding a > bug. > > 2009/9/25 <jeanlouis.pasturel@...> >> >> I have made the same error few months ago. You have to set only one Xset >> like : >> >> -Xset:weaveJavaxPackages=true,weaveJavaPackages=true >> >> >> >> >> >> Jean-Louis Pasturel >> >> >> >> ________________________________ >> >> De : aspectj-users-bounces@... >> [mailto:aspectj-users-bounces@...] De la part de Kajetan Abt >> Envoyé : vendredi 25 septembre 2009 14:14 >> À : aspectj-users@... >> Objet : [aspectj-users] LTW into javax.swing >> >> >> >> What I am trying to do: Swing has support for Tooltips, but that >> functionality is very basic. There are two functions (SetToolTip() and >> GetToolTip()) which either take a String argument or return one. I would >> like to have different Tooltips, to be precise, different verbosity levels, >> for all tooltips in my project. Of course I could either overload all used >> JComponents (hah!) or use some other nontrivial approach (manage my own >> listeners...) to set these values anew every time the user changes the >> verbosity level. >> >> But on the other hand, having an Aspect weave into GetToolTip() would >> instantly solve my issues, as I could then change the return parameter (read >> from a properties file). I have managed to figure out how to basically do >> this, and it works, as long as I am weaving into my own code (I suppose it >> would work at compile time even). But for some reason, weaving into Swing >> fails without error messages, it just does not happen. I assume the class >> loader has my classes prepared before the weaver kicks in, but I have >> absolutely no idea how to do that different. There is also not a lot of >> literature on the subject and I only assume this happens because I've read >> somewhere that writing a classloader might be necessary (without explanation >> as to why or how). I am settnig the option to the weaver to include javax, >> but it won't find JComponent. If I don't exclude the org.jdesktop package, >> it even tries to find the superclasses of some of the jdesktop parts at >> javax.jnlp.*, so it doesn't completely fail. >> As for the call I want to intercept: javax.swing.ToolTipManager is the >> class that calls my target function. It never gets woven. >> >> As for the code I use: >> >> aop.xml: >> <aspectj> >> <aspects> >> <aspect name="<something>.weaver. >> >> Wrangler"/> >> <include within="<something>..*"/> >> <include within="javax.swing..*"/> >> <exclude within="org.jdesktop..*"/> >> </aspects> >> <weaver options="-verbose -Xset:weaveJavaxPackages=true >> -Xset:weaveJavaPackages=true -showWeaveInfo" > >> <include within="<something>..*"/> >> <include within="javax.swing..*"/> >> <exclude within="org.jdesktop..*"/> >> </weaver> >> </aspectj> >> >> public aspect Wrangler { >> before(JComponent component): >> call( public String JComponent.getToolTipText(MouseEvent) ) >> && target(component) >> { >> System.out.println("Intercepted!"); >> //target.setToolTip("My new thing"); >> } >> } >> >> The output I get: >> [AppClassLoader@19134f4] weaveinfo Join point >> 'method-call(java.lang.String javax.swing.JMenuItem.getToolTipText())' in >> Type <something>.gui.AppClientView' (AppClientView.java:596) advised by >> before advice from '<something>.weaver.Wrangler' (Wrangler.aj:33) >> >> And all other calls I make myself. Changing this to execution or anything >> like that does not help at all. No Javax.Swing classes are woven at all. >> >> ********************************* >> This message and any attachments (the "message") are confidential and >> intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if altered, >> changed or falsified. >> If you are not the intended addressee of this message, please cancel it >> immediately and inform the sender. >> ******************************** >> >> _______________________________________________ >> 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 > > aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingCompile Time weaving is out because I have to weave into Swing itself. I'm not about to recompile anything that's in javax or java. I have looked at that page and found the -debug option, which gives me what you see below. Now this tells me that my code gets woven (as it should), org.jdesktop is excluded (as it should) and javax.swing is never even passed to the weaver. Why? The -Xset:weaveJavaxPackages=true is there, and <include within="javax.swing..*"/> is there too.
[AppClassLoader@19134f4] debug weaving '<mystuff>.AppClientApp' //this is my main() class [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SingleFrameApplication' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Application' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.AbstractBean' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.AbstractBean$EDTPropertyChangeSupport' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Application$NotifyingEvent' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Application$NoApplication' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Application$1' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ApplicationContext' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceManager' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ActionManager' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ApplicationActionMap' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.LocalStorage' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.LocalStorage$LocalIO' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.LocalStorage$PersistenceServiceIO' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.LocalStorage$LocalFileIO' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.LocalStorage$LSException' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.LocalStorage$RectanglePD' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SessionStorage' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SessionStorage$WindowProperty' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SessionStorage$Property' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SessionStorage$TabbedPaneProperty' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SessionStorage$SplitPaneProperty' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.SessionStorage$TableProperty' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.TaskService' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.TaskService$TaskPCL' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$ResourceConverterException' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$InjectFieldException' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$PropertyInjectionException' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$LookupException' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$ColorStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$BooleanResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$IntegerResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$INumberResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$MessageFormatResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$FloatResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$NumberResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$DoubleResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$LongResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$ShortResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$ByteResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$URLResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceConverter$URIResourceConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$IconStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$ImageStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$FontStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$KeyStrokeStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$DimensionStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$PointStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$RectangleStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$InsetsStringConverter' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.ResourceMap$EmptyBorderStringConverter' Xlib: extension "RANDR" missing on display ":0.0". Sep 28, 2009 10:46:36 AM <mystuff>.AppClientApp setupLogger INFO: Logger started: Mon Sep 28 10:46:36 CEST 2009 [AppClassLoader@19134f4] debug weaving '<mystuff>.AppClientLoginFrame' [MethodUtil@1402eeb] info AspectJ Weaver Version 1.6.5 built on Thursday Jun 18, 2009 at 03:42:32 GMT [MethodUtil@1402eeb] info register classloader sun.reflect.misc.MethodUtil@1402eeb [MethodUtil@1402eeb] info using configuration file:/<mystuff>/workspace/Client/lib/tooltipWrangler.jar!/META-INF/aop.xml [MethodUtil@1402eeb] info register aspect <mystuff>.Wrangler [MethodUtil@1402eeb] debug cannot weave 'sun.reflect.misc.Trampoline' [AppClassLoader@19134f4] debug weaving '<mystuff>.AppClientLoginFrame$1' [AppClassLoader@19134f4] debug weaving '<mystuff>.AppClientApp$1' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.View' [AppClassLoader@19134f4] debug weaving '<mystuff>.AppClientView' [AppClassLoader@19134f4] weaveinfo Join point 'method-call(java.lang.String javax.swing.JMenuItem.getToolTipText())' in Type '<mystuff>.AppClientView' (AppClientView.java:596) advised by before advice from '<mystuff>.Wrangler' (Wrangler.aj:33) [AppClassLoader@19134f4] weaveinfo Join point 'method-call(java.lang.String javax.swing.JMenuItem.getToolTipText(java.awt.event.MouseEvent))' in Type '<mystuff>.AppClientView' (AppClientView.java:598) advised by before advice from '<mystuff>.Wrangler' (Wrangler.aj:12) [AppClassLoader@19134f4] weaveinfo Join point 'method-call(void <mystuff>.ToolTipSettings.omgAfunction())' in Type '<mystuff>.AppClientView' (AppClientView.java:599) advised by before advice from '<mystuff>.Wrangler' (Wrangler.aj:40) [AppClassLoader@19134f4] weaveinfo Join point 'method-call(void <mystuff>.ToolTipSettings.omganotherfunction())' in Type '<mystuff>.AppClientView' (AppClientView.java:601) advised by before advice from <mystuff>.Wrangler' (Wrangler.aj:46) [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.FrameView' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Application$DoWaitForEmptyEventQ' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Task' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.AccumulativeRunnable' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$4' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingPropertyChangeSupport' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$3' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$DoSubmitAccumulativeRunnable' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$2' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$1' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$StateValue' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Task$StatePCL' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$6' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$7' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingPropertyChangeSupport$1' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Task$1' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.Task$BlockingScope' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.application.TaskEvent' [AppClassLoader@19134f4] debug not weaving 'org.jdesktop.swingworker.SwingWorker$5' 2009/9/25 Andy Clement <andrew.clement@...> Hi, _______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingCompile time weaving doesn't mean you have to recompile swing - by
'compile time' I meant the aspects. At the time you compile the aspects just pass the swing jar in as binary input and ajc will weave the aspects into it, producing a new jar file. You don't need the source for swing. >From your trace it indicates that no weaver is being created for the classloader that loads the swing classes. If this doesn't happen then that loader will never weave anything. The -Xset flags are only useful if the weaver actually gets to see types with that prefix. I don't know the solution to making the more system'y classloaders associate a weaver instance - maybe someone else on the list does. However, it would be far easier to binary weave the jar containing the swing classes before you launch the app at all. cheers, Andy _______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingOk, I after a detour finally got on this and tried to make it work. You were right, I can actually go with compile-time weaving. For those who struggle:
1. Eclipse needs a lot more RAM if it has to go through rt.jar (located in the jre) 2. The setting to add -injars is in Properties/AspectJ Compiler/Other/non-standard compiler option, something like: -injars :/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar But now I'm a bit irritated by my result: First off, I get a 24 MB jar, which is rather big, considering I only weave this: before(JComponent component): execution( public String JComponent.getToolTipText(MouseEvent) ) && target(component) {...} It also spans into strange directories, such as com.sun.corba (do they really use swing's tooltips? I doubt it). I assumed I could just add the created jar as a library into my project, but that does not have any effect (but the non-aspect classes in that jar are visible and usable just fine). Any ideas? Thanks Kajetan 2009/9/28 Andy Clement <andrew.clement@...> Compile time weaving doesn't mean you have to recompile swing - by _______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingPlease add a within() clause to your pointcut if you can, to limit the
matching - that will speed things up. Strange that the jar grows significantly for a simple pointcut like that. If you turn on -showWeaveInfo or -verbose, do you see anything untoward? Anything you don't expect? If you modify the rt.jar you have to launch the VM specifying a different bootclasspath so it sees your jar and not the built in jar. Putting it on the classpath will mean it is seen too late. Andy 2009/9/30 Kajetan Abt <kdansky@...>: > Ok, I after a detour finally got on this and tried to make it work. You were > right, I can actually go with compile-time weaving. For those who struggle: > > 1. Eclipse needs a lot more RAM if it has to go through rt.jar (located in > the jre) > 2. The setting to add -injars is in Properties/AspectJ > Compiler/Other/non-standard compiler option, something like: > -injars :/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar > > But now I'm a bit irritated by my result: First off, I get a 24 MB jar, > which is rather big, considering I only weave this: > > before(JComponent component): > execution( public String JComponent.getToolTipText(MouseEvent) ) > && target(component) {...} > > It also spans into strange directories, such as com.sun.corba (do they > really use swing's tooltips? I doubt it). I assumed I could just add the > created jar as a library into my project, but that does not have any effect > (but the non-aspect classes in that jar are visible and usable just fine). > Any ideas? > > Thanks > Kajetan > > > 2009/9/28 Andy Clement <andrew.clement@...> >> >> Compile time weaving doesn't mean you have to recompile swing - by >> 'compile time' I meant the aspects. At the time you compile the >> aspects just pass the swing jar in as binary input and ajc will weave >> the aspects into it, producing a new jar file. You don't need the >> source for swing. >> >> >From your trace it indicates that no weaver is being created for the >> classloader that loads the swing classes. If this doesn't happen then >> that loader will never weave anything. The -Xset flags are only >> useful if the weaver actually gets to see types with that prefix. I >> don't know the solution to making the more system'y classloaders >> associate a weaver instance - maybe someone else on the list does. >> >> However, it would be far easier to binary weave the jar containing the >> swing classes before you launch the app at all. >> >> cheers, >> Andy >> _______________________________________________ >> 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 > > aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingWithin() helped significantly with compile time, though my jar is still 24MB. On the other hand, the rt.jar is twice as big. Either way, this can't be right. If I'm redeploying the whole runtime, I'm missing out on half of it (and as expected, I got "java/lang/NoClassDefFoundError: java/lang/Object" when I changed my bootclasspath to point into my own library folder (where the woven jar is). Is it not possible to only weave the one class I want to change but load the others from the jre/rt.jar? Do I have to write my own classloader to exchange JComponent?
:B: 10:40:50 =========================================================================================== :B: 10:40:50 Build kind = AUTOBUILD :B: 10:40:50 Project=TooltipWrangler, kind of build requested=Incremental AspectJ compilation :B: 10:40:50 Timer event: 0ms: Flush included source file cache :B: 10:40:50 Timer event: 1ms: Check delta :B: 10:40:50 File: <path>/Wrangler.aj has changed. :B: 10:40:50 build: Examined delta - 1 changed, 0 added, and 0 deleted source files in required project TooltipWrangler :B: 10:40:50 Timer event: 0ms: Looking for and marking configuration changes in TooltipWrangler :B: 10:40:50 Configuration changes found: true :B: 10:40:50 Timer event: 0ms: Look for source/resource changes :B: 10:40:50 Setting list of classpath elements with modified contents: :B: 10:40:50 [] :B: 10:40:50 Timer event: 3ms: Pre compile :B: 10:40:50 Sending the following configuration changes to the compiler: [] :B: 10:40:50 1 source file changes since last build :B: 10:40:50 Compiler configuration for project TooltipWrangler has been read by compiler. Resetting. :B: 10:40:50 Configuration was [] :B: 10:40:50 Resetting list of modified source files. :C: 10:40:50 Preparing for build: not going to be incremental because outjar being used :C: 10:40:50 Falling back to batch compilation :C: 10:40:50 Preparing for build: not going to be incremental because no successful previous full build :C: 10:40:54 Timer event: 4270ms: Time to first compiled message :C: 10:40:57 Timer event: 7289ms: Time to first woven message :C: 10:40:57 Processing progress message: Can't find eclipse resource for file with path woven class com.sun.accessibility.internal.resources.accessibility (from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar) <this is repeated for every single class encountered and takes forever> :C: 10:40:59 Processing progress message: Can't find eclipse resource for file with path woven class java.lang.Object (from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar) :C: 10:41:3 AspectJ reports build successful, build was: FULL :C: 10:41:3 AJDE Callback: finish. Was full build: true :B: 10:41:3 Timer event: 13305ms: Total time spent in AJDE :B: 10:41:3 Timer event: 0ms: Refresh after build :C: 10:41:3 Types affected during build = 2 //this seems fine to me :B: 10:41:3 Timer event: 13310ms: Total time spent in AJBuilder.build() :B: 10:41:3 Timer event: 1ms: Delete markers: TooltipWrangler (Finished deleting markers for TooltipWrangler) :B: 10:41:3 Timer event: 0ms: Create markers: TooltipWrangler (Finished creating markers for TooltipWrangler) :B: 10:41:3 Created 0 markers in 2 files :B: 10:43:49 Timer event: 0ms: Update visualizer, xref, advice listeners for (separate thread): TooltipWrangler 2009/9/30 Andy Clement <andrew.clement@...> Please add a within() clause to your pointcut if you can, to limit the _______________________________________________ aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
|
|
Re: LTW into javax.swingThere are other experts on the list who weave rt.jar, hopefully one of
them can chip in on this. If you absolutely know you only want to weave one class, just extract it from the jar, weave it and put it back in the original jar. > If I'm redeploying the whole runtime, I'm missing out on half of it I don't understand. Are you not getting all the input classes into the output jar? Size is perhaps not something to consider as rt.jar is specially packed (I believe) to optimize JVM startup time. That packing isn't respected when it is repacked by AspectJ (it just considers it an ordinary jar). I had imagined you'd be weaving outside of eclipse rather than inside - I'm not sure how AJDT handles things inside of eclipse for weaving a special jar like that. Outside of eclipse it is simply: ajc -inpath rt.jar -outjar new_rt.jar MyAspect.java (With appropriate Xmx set in the ajc.bat file) Andy 2009/10/1 Kajetan Abt <kdansky@...>: > Within() helped significantly with compile time, though my jar is still > 24MB. On the other hand, the rt.jar is twice as big. Either way, this can't > be right. If I'm redeploying the whole runtime, I'm missing out on half of > it (and as expected, I got "java/lang/NoClassDefFoundError: > java/lang/Object" when I changed my bootclasspath to point into my own > library folder (where the woven jar is). Is it not possible to only weave > the one class I want to change but load the others from the jre/rt.jar? Do I > have to write my own classloader to exchange JComponent? > > > :B: 10:40:50 > =========================================================================================== > :B: 10:40:50 Build kind = AUTOBUILD > :B: 10:40:50 Project=TooltipWrangler, kind of build requested=Incremental > AspectJ compilation > :B: 10:40:50 Timer event: 0ms: Flush included source file cache > :B: 10:40:50 Timer event: 1ms: Check delta > :B: 10:40:50 File: <path>/Wrangler.aj has changed. > :B: 10:40:50 build: Examined delta - 1 changed, 0 added, and 0 deleted > source files in required project TooltipWrangler > :B: 10:40:50 Timer event: 0ms: Looking for and marking configuration > changes in TooltipWrangler > :B: 10:40:50 Configuration changes found: true > :B: 10:40:50 Timer event: 0ms: Look for source/resource changes > :B: 10:40:50 Setting list of classpath elements with modified contents: > :B: 10:40:50 [] > :B: 10:40:50 Timer event: 3ms: Pre compile > :B: 10:40:50 Sending the following configuration changes to the compiler: > [] > :B: 10:40:50 1 source file changes since last build > :B: 10:40:50 Compiler configuration for project TooltipWrangler has been > read by compiler. Resetting. > :B: 10:40:50 Configuration was [] > :B: 10:40:50 Resetting list of modified source files. > :C: 10:40:50 Preparing for build: not going to be incremental because > outjar being used > :C: 10:40:50 Falling back to batch compilation > :C: 10:40:50 Preparing for build: not going to be incremental because no > successful previous full build > :C: 10:40:54 Timer event: 4270ms: Time to first compiled message > :C: 10:40:57 Timer event: 7289ms: Time to first woven message > :C: 10:40:57 Processing progress message: Can't find eclipse resource for > file with path woven class > com.sun.accessibility.internal.resources.accessibility (from > /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar) > > <this is repeated for every single class encountered and takes forever> > > :C: 10:40:59 Processing progress message: Can't find eclipse resource for > file with path woven class java.lang.Object (from > /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar) > :C: 10:41:3 AspectJ reports build successful, build was: FULL > :C: 10:41:3 AJDE Callback: finish. Was full build: true > :B: 10:41:3 Timer event: 13305ms: Total time spent in AJDE > :B: 10:41:3 Timer event: 0ms: Refresh after build > :C: 10:41:3 Types affected during build = 2 //this seems fine to me > :B: 10:41:3 Timer event: 13310ms: Total time spent in AJBuilder.build() > :B: 10:41:3 Timer event: 1ms: Delete markers: TooltipWrangler (Finished > deleting markers for TooltipWrangler) > :B: 10:41:3 Timer event: 0ms: Create markers: TooltipWrangler (Finished > creating markers for TooltipWrangler) > :B: 10:41:3 Created 0 markers in 2 files > :B: 10:43:49 Timer event: 0ms: Update visualizer, xref, advice listeners > for (separate thread): TooltipWrangler > > > > > 2009/9/30 Andy Clement <andrew.clement@...> >> >> Please add a within() clause to your pointcut if you can, to limit the >> matching - that will speed things up. >> >> Strange that the jar grows significantly for a simple pointcut like >> that. If you turn on -showWeaveInfo or -verbose, do you see anything >> untoward? Anything you don't expect? >> >> If you modify the rt.jar you have to launch the VM specifying a >> different bootclasspath so it sees your jar and not the built in jar. >> Putting it on the classpath will mean it is seen too late. >> >> Andy >> >> 2009/9/30 Kajetan Abt <kdansky@...>: >> > Ok, I after a detour finally got on this and tried to make it work. You >> > were >> > right, I can actually go with compile-time weaving. For those who >> > struggle: >> > >> > 1. Eclipse needs a lot more RAM if it has to go through rt.jar (located >> > in >> > the jre) >> > 2. The setting to add -injars is in Properties/AspectJ >> > Compiler/Other/non-standard compiler option, something like: >> > -injars :/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/rt.jar >> > >> > But now I'm a bit irritated by my result: First off, I get a 24 MB jar, >> > which is rather big, considering I only weave this: >> > >> > before(JComponent component): >> > execution( public String JComponent.getToolTipText(MouseEvent) ) >> > && target(component) {...} >> > >> > It also spans into strange directories, such as com.sun.corba (do they >> > really use swing's tooltips? I doubt it). I assumed I could just add the >> > created jar as a library into my project, but that does not have any >> > effect >> > (but the non-aspect classes in that jar are visible and usable just >> > fine). >> > Any ideas? >> > >> > Thanks >> > Kajetan >> > >> > >> > 2009/9/28 Andy Clement <andrew.clement@...> >> >> >> >> Compile time weaving doesn't mean you have to recompile swing - by >> >> 'compile time' I meant the aspects. At the time you compile the >> >> aspects just pass the swing jar in as binary input and ajc will weave >> >> the aspects into it, producing a new jar file. You don't need the >> >> source for swing. >> >> >> >> >From your trace it indicates that no weaver is being created for the >> >> classloader that loads the swing classes. If this doesn't happen then >> >> that loader will never weave anything. The -Xset flags are only >> >> useful if the weaver actually gets to see types with that prefix. I >> >> don't know the solution to making the more system'y classloaders >> >> associate a weaver instance - maybe someone else on the list does. >> >> >> >> However, it would be far easier to binary weave the jar containing the >> >> swing classes before you launch the app at all. >> >> >> >> cheers, >> >> Andy >> >> _______________________________________________ >> >> 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 >> > >> > >> _______________________________________________ >> 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 > > aspectj-users mailing list aspectj-users@... https://dev.eclipse.org/mailman/listinfo/aspectj-users |
| Free embeddable forum powered by Nabble | Forum Help |