Bug 260342 - [plan] [LTW] improvements to load-time weaving tools
Summary: [plan] [LTW] improvements to load-time weaving tools
Status: NEW
Alias: None
Product: AJDT
Classification: Tools
Component: Core (show other bugs)
Version: 1.6.2   Edit
Hardware: PC Windows Vista
: P3 enhancement (vote)
Target Milestone: 2.1.2   Edit
Assignee: AJDT-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-07 19:59 EST by Andrew Clement CLA
Modified: 2010-12-08 19:59 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Clement CLA 2009-01-07 19:59:14 EST
This enhancement request will track the design of improvements to the LTW tooling.  The following questions represent our initial attempt at discovering requirements and use cases that need addressing.

--- 
1. How are you using LTW?
a) In OSGi / Plugin development
b) In a JEE / application server
c) In a regular J2SE application
d) With Spring-LTW
e) Other

2. Have you tried load-time weaving and given it up for some reason? Why?

3. Why use LTW instead of compile time weaving or binary weaving? What specific problems is LTW solving for you?

4. What are the biggest problems that you face when developing with LTW?

5. How can configuring your LTW environment and projects be made easier?

6. Do you use the LTW Run Configuration in the IDE?

7. Is your debugging/editing environment set up to do compile time weaving even if the runtime environment will be load time?

8. Is the aop.xml file automatically generated, or have you hand customized it? If so, then in what way? What else would you like to configure in the aop.xml that you cannot right now?

9. Would you like to use aop.xml to additionally configure compile time or binary weaving?

10. Do you consume other aspect libraries in your configuration? Does this cause you any problems?

11. Does your development environment contain all the code that you expect to be woven at runtime, or do you expect that there will be other binaries? Do you expect that these binaries will be other aspect libraries, code that consumes aspect libraries, or both?

12. If developing in an OSGi environment, are you aware of equinox aspects? Do you use it to perform your LTW? Do you have any problems with configuring LTW through equinox aspects?

13. What kinds of features would you like to see?
Comment 1 PASTUREL CLA 2009-01-08 02:54:21 EST
(b+c)Use LTW to profile Application/Was performances ( Duration of methods, Axis services, Tracking DBCP/JDBC JOLT connections when JMX is not available, Duration of PreparedStatement ... ) and  Mock Objects in Simulator

LTW permits not to modify code for temporary operation ( Tuning)

The major problem is with the Classpath and hierarchy of classpaths of the WAS. I have often to modify the classpath for weaving ( exemple add the axis.jar library)

aop.xml, i make a tool ( Swing tool not an eclipse pluggin)  that create automatically aop.xml regarding the aspects i want to weave with the application/WAS( I have 20 or 30 aspects concrete and abstract). The tool create also a custom agent packaging : all in one file .jar( aspectjweaver.jar, my aspects, aop.xml, file conf of my aspects). This kind of feature could be a candidate for the LTW tooling

13) Dynamic  attach/detach LTW agent ( perhaps with Attach API coming with Sun JDK 1.6)  as my request i wrote yesterday
Comment 2 PASTUREL CLA 2009-01-08 02:58:21 EST
The major problem is with the Classpath and hierarchy of classpaths of the WAS.
I have often to modify the classpath for weaving ( exemple add the axis.jar
library)

Sorry it must be read : "hierarchy of Classloaders" instead of "hierarchy of classpaths"
Comment 3 Simone Gianni CLA 2009-01-08 12:40:59 EST
1. How are you using LTW?

> b) In a JEE / application server
> c) In a regular J2SE application
> e) Other
> Running junit tests


2. Have you tried load-time weaving and given it up for some reason? Why?

> No, I haven't given it up, but it really takes so much time to bootstrap, and since the same time is taken during build for compile time weaving, I feel a bit like I'm loosing a lot of time every development cycle (10ths of times a day). I'm planning to move to compile time to take advantage of 1) progressive compile 2) automatic class reloading .. all to reduce the developement time. See https://issues.apache.org/jira/browse/LABS-201 to read some rants of mine about this subject.


3. Why use LTW instead of compile time weaving or binary weaving? What specific
problems is LTW solving for you?

> My target applications are "assembled" by maven, that means that a change in an xml file could make a new aspect library appear or disappear, or a new library that must be weaved. Using LTW simplifies the build part of it, but requires time at load time. 


4. What are the biggest problems that you face when developing with LTW?

> First of all the fact that time is taken BOTH durig build AND during LTW. This makes me feel like I'm loosing a lot of time. Also, there are a few bugs regarding reweaving and closures I see from time to time. Seems like if LTW "overwrites" an existing (build time generated) closure with another one (load time generated), causing a complete mess at runtime, but only happens in some specific situations I cannot reproduce ... it happened to me at least 3 times in last 6 months.


6. Do you use the LTW Run Configuration in the IDE?

>Nope


7. Is your debugging/editing environment set up to do compile time weaving even
if the runtime environment will be load time?

> Yes, yes and yes :) .. Eclipse is using AJDT, so it compiles and weaves, then maven compiles and weaves, then LTW reweaves :)


5. How can configuring your LTW environment and projects be made easier?
8. Is the aop.xml file automatically generated, or have you hand customized it?
If so, then in what way? What else would you like to configure in the aop.xml
that you cannot right now?

> Automatically generated for each package. I'd like to take advantage of the automatic generation while still being able to customize it. In fact actually either i get the automatically generated version, which is very handy but by default contains all aspects, or i do it manually, which is a pain. An alternative syntax to exclude/add aspects from the automatically generated one would be very nice, eventually embedded in the IDE (something like right-click, exclude this aspect). Something like this has been discussed recently on the mailing list.


9. Would you like to use aop.xml to additionally configure compile time or
binary weaving?

> YEEEEESSSS!!!! Since the weaving system should be transparent (this is an AspectJ definition :) ), the compile time weaver should read the aop.xml and behave accordingly. I think the fact that it does not is actually a bug.


10. Do you consume other aspect libraries in your configuration? Does this
cause you any problems?

> Yes i do, no it doesn't.


11. Does your development environment contain all the code that you expect to
be woven at runtime, or do you expect that there will be other binaries? Do you
expect that these binaries will be other aspect libraries, code that consumes
aspect libraries, or both?

> both, both and both. The final environment in which the package "A" containing this and that aspect is going to run could be popolated by anything, including other aspect libraries, and a lot of stuff downloaded directly from the maven repositories on which I don't have any kind of control.


12. If developing in an OSGi environment, are you aware of equinox aspects? Do
you use it to perform your LTW? Do you have any problems with configuring LTW
through equinox aspects?

> Yes, I'm aware of it ... but yet haven't had time to play with it :(


13. What kinds of features would you like to see?

> "Compile for LTW (or for later weaving)", that is do all the checks, but do not weave
> Ability to push classes (redefining and reweaving) during debug in an LTW environment :)

Comment 4 Andrew Eisenberg CLA 2009-01-14 13:17:50 EST
Thanks for your comments.  We expect to be exploring this in the coming weeks.
Comment 5 Andrew Eisenberg CLA 2009-09-30 14:36:56 EDT
Move to the 2.0.2 release.
Comment 6 Andrew Eisenberg CLA 2010-04-28 19:20:20 EDT
No longer slated for the next release.