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 protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
