ERPatcher Framework Proposal
ERPatcher Framework Proposal
- Subject: ERPatcher Framework Proposal
- From: Henrique Prange <email@hidden>
- Date: Fri, 13 Jul 2012 17:22:47 -0300
Hi everybody,
The "Migrating to EOF to Cayenne" thread touched an import matter: how may we change WebObjects behavior that cannot be modified through OO constructs without violating the Apple's license?
I'm looking into solutions for this problem since it's an essential requirement for WOInject core functioning and to fix WO bugs that reflect in misbehavior of WOUnit.
The current solution applied in Wonder requires the decompilation of WebObjects code and the repackaging of changed code inside special libraries that must take precedence in the classpath ordering. This solution is not ideal as soon as it violates Apple's license and doesn't scale (what happens if a number of frameworks need to change behavior in the same class?).
I've been playing with a couple of alternative solutions lately including AOP, bytecode manipulation (Javassist and ASM), classloading manipulation and java-agents. I haven't tried anything at WOBootstrap level though. Every solution has advantages and drawbacks. IMHO, the ERPatcher framework should be ubiquitous and transparent to the user which is very challenging.
Some important WO classes are loaded during the static initialization of WOApplication and ERXApplication classes. Those classes are loaded even before the main method is executed. The ERPatcher framework should change or hook interceptors to the required classes/methods before the static initialization of the Application class. (We could do it afterwards with classloading manipulation. However it has too many drawbacks, so I won't take it into consideration). The ERPatcher should also provide means to patch classes outside the context of an entire application (we want bugfixes even when running a unit test, for instance).
We could create a special Runner or use java-agents (or a mix of both) to do the dirty work before the Application is initialized.
1) Special Runner: the application is started by a Runner class. The runner can patch WO classes before loading and starting the Application class. Users would have to add a new class to their projects and start the Application from it. Something as the following code:
public class MyRunner extends ERXRunner {
public static void main(String[] args) {
ERXRunner.run("my.company.Application", args);
}
}
2) Java-agents: Since Java 5, we can attach agents to the virtual machine to perform instrumentation of classes. That is how AspectJ does load-time weaving since version 5. Users would have to declare the java-agent parameter when running their Application.
3) Mix of both: Since Java 6, we can attach a java-agent to a running process. We could use a Runner to attach a java-agent in runtime for instrumentation and then start the Applicaiton. With this solution, users would run the application without any special parameter, but they have to implement the runner. Additionally, Java 6 becomes a requirement.
Aspect oriented programming already provides a common idiom that can be used to change the behavior of methods. We can use AspectJ as the base for ERPatcher. The integration with AspectJ should be as transparent as possible, so most users won't have to deal with it directly.
I'm willing to implement this framework in Wonder, but I would like to hear your opinion about the requirements and consequences of each solution. Every solution requires some kind of effort to adequate the current applications. If the community doesn't approve the solution, then it is waste of time to implement it.
Cheers,
Henrique
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden