Re: ERPatcher Framework Proposal
Re: ERPatcher Framework Proposal
- Subject: Re: ERPatcher Framework Proposal
- From: Henrique Prange <email@hidden>
- Date: Sun, 15 Jul 2012 23:26:18 -0300
Hi Lachlan,
On 13/07/2012, at 19:05, Lachlan Deck wrote:
> Hey there,
>
> On 14/07/2012, at 6:22 AM, Henrique Prange wrote:
>
>> 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've been reading that thread... but it appears that the cart is leading the horse for the most part.
>
> I would suggest that in order to obtain any consensus moving forward people will need to do a better job of selling their proposal. To do so, it will require concrete examples of what exactly they will be fixing in the current stack via any said solution and not only why they think their approach to solving problems in the future is better.
>
> i.e., theoretical solutions to unknown problems won't sell, no matter how technically sound the solution may be. This is already a niche market.
>
> Additionally in order for people to make an informed decision, they'd need to know things like:
> - AOP is not straight forward: will it make my life harder in development / debugging / deployment?
> - will this make it easier for contributions to Wonder?
> - etc.
>
I've been looking into this problem for a long time. Sorry if I've thrown too much information at once. What really matters is: how can we patch WO core classes to fix bugs and make small improvements? How can we do this in a organized manner? How can we make those patches in a way that everybody using Wonder can take advantage? How can we make it requiring the minimum change in current projects?
A framework like ERPatcher could define a standard way of creating patches for core WO classes only. A patch is a small piece of code that change behavior adding code before, after or around method calls. It can be documented, reviewed and managed (via VCS). The patch could be applied without user's knowledge.
>> 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.
>
> Don't hear me wrong. WOInject is very cool, and I think should play an increasingly important role... but it seems to me waiting for the community to make a decision based on theoreticals just ain't gonna happen any time soon.
>
> This is especially the case if it won't solve the main perception of WO being a legacy tech.
I'm not trying to change the perception of WO being legacy. Also, I don't want to discourage people that want to change that perception. However, assuming WO as legacy tech, how can we keep living with it?
>
>> 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
>
> Does this mean rewriting lots of Wonder classes? i.e., classpath ordering will exist for the foreseeable future until they're eliminated, no? The cat's already out of the bag with licensing and has been for years.
>
I don't think we should change the past. Good or bad, there are important changes in the ERExtensions, ERFoundation and ERWebObjects. ERPatcher could pave the way for future small changes/fixes in the core WO libraries.
>> and doesn't scale (what happens if a number of frameworks need to change behavior in the same class?).
>
> Does that same question not apply to AOP?
>
AOP has a precedence mechanism, but forget about AOP for a minute. I'll give you an example:
WOInject must change two methods in the _NSUtilities class to work. I can decompile the source for this class from the ERFoundation.jar, make the required change and add the _NSUtilities class to the WOInject library. Now, anyone using the WOInject library must add it before the ERFoundation library in the classpath. Fair enough.
Later, someone need to change a different method in this class to fix a bug, for instance. He updates the ERFoundation library with the change. Of course, it is an undocumented change. There is no clear evidence of the change in the VCS. Now, you don't get this update if your project depends on WOInject. There is no conflict between the changes, but you have to choose between WOInject or the fix. It doesn't scale.
This is not much real as soon as I'll not decompile the _NSUtilites class, and nobody will fix a bug in the _NSUtilities class. Sadly, this is too complicated right now and we end up living with known bugs or workarounds. :(
IMHO, there are better ways to solve the problem of making small changes/fixes in the WO core than decompiling code and repackaging it in a "special" jar. I would like to standardize the way of doing it, with AOP or without it.
>> 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).
>
> Good example.
>
>> <...>
>>
>> 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.
>
> They're all good ideas, Henrique. They answer probably lies in insurance & assurances.
>
> i.e., insurance against tech debt, insurance on their skills, as well as assurances that whatever solution is used moving forward will rock!
>
> But first things first: in order to find a viable solution, there needs to be identification of technical problems that needs fixing and not just an improvement in terms of licensing.
>
Agree. The license aspect isn't the most relevant.
> Of course, take my conjecture as just that given that I am out of the loop these days (though I'm clearly still lurking around on the list) and as such will not be in a position to add any help in the form of code :)
>
Thanks for taking the time to share your opinion. It's really valuable.
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