Re: ERPatcher Framework Proposal
Re: ERPatcher Framework Proposal
- Subject: Re: ERPatcher Framework Proposal
- From: Lachlan Deck <email@hidden>
- Date: Sat, 14 Jul 2012 08:05:43 +1000
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'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.
> 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.
> 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?
> 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.
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 :)
with regards,
Lachlan Deck
_______________________________________________
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