Sorry for late response, just landed last night.
The idea is very simple to understand and implement. E.g. I've a third party
library which has a method named with following signature:
String encode(String someString) {
// some crappy encoding performed on someString and saved as encoded...
return encoded;
}
Now this method can be private, public, protected, static, final, blah blah
etc. I find that encoding is buggy, how to fix it? There are two ways:
1. Get the source code, fix the method and submit patch. (This is sometimes not
possible and for sure not possible in case of WebObjects)
2. Use AOP
Forget about option 1. In Option 2 we have to use some AOP mechanism and the
one that I've tested with my Wonder apps is AspectJ. I'm not going into details
as it's a vast subject but providing links which are sufficient to experiment :)
http://www.eclipse.org/aspectj/
http://www.eclipse.org/aspectj/doc/released/progguide/starting-aspectj.html#the-dynamic-join-point-model
As far as weaving is concerned, I would suggest to use dynamic join point as
they can be used to intercept calls and invoke different code rather than
modifying the original classes.
The idea is we need to define join point for the method which is buggy or where
we want to provide our own implementation. When the code is executed, the class
loader reroutes the request for incoming method calls to our code. AOP is
different that OOP. In contrast with OOP where methods are associated with
Objects, AOP is used to classify those methods under common aspects and
normally we use regular expressions for that. Two very common aspects I can
explain here:
1. You may have lots of methods and you want to collect execution type for each
method call. (A logging aspect)
2. A developer like me who put all the code in try block and catch one super
Exception, someone would like to perform different operations on each
sub-exception can write an aspect to catch my exceptions and do whatever he
wants and then continue the original processing.
I'm not familiar with internals of the WebObjects but the code that's
responsible for single thread can be studied and multithreaded solution can be
provided using AOP. If someone is interested to work with me to on this, I'm
more than happy to help where I can :)
Farrukh
On 2012-07-11, at 10:25 PM, Chuck Hill <ch...@global-village.net> wrote:
> Hi Farrukh,
>
> I like the idea of using AOP to address bugs in WO. Can you give us any
> details on how you did that?
>
> As for making EOF multi-threaded.... that is a very fundamental part of the
> design. Fixing that with AOP would be challenging. :-)
>
>
> Chuck
>
>
>
> On 2012-07-11, at 11:12 AM, Farrukh Ijaz wrote:
>
>> Hi,
>>
>> In past I've used AOP to address issues of closed source. This I believe if
>> carefully used can help convert the EOF from single to multi threaded and/or
>> solve other bottleneck problems. Having said this doesn't mean I'm against
>> Cayane. However if the current EOF issues get fixed with AOP patched code
>> would be better for those who don't want to or for some reasons can't switch
>> to Cayane.
>>
>> Farrukh
>>
>> Chuck Hill <ch...@global-village.net> wrote:
>>
>>> I agree that we need to more closely examine Cayenne before jumping in with
>>> both feet. How mature are the tools? What is the functionality gap? How
>>> important is the missing functionality? How costly is adding any needed
>>> functionality? Will the missing functionality fit in with the Cayenne
>>> architecture? How stable is it? How well does it scale (scaling is more
>>> than multi-threaded EOF)? And Cayenne is only EOAccess/EOControl. What do
>>> we do about the presentation layer? Getting rid of 2/3 of WO still leaves
>>> you with WO.
>>>
>>>
>>> Chuck
>>>
>>> On 2012-07-11, at 11:29 AM, Theodore Petrosky wrote:
>>>
>>>>
>>>> Hurray someone actually started talking about this.
>>>>
>>>>
>>>> I want to add my two cents without starting a "this is better than that"
>>>> conversation.
>>>>
>>>> If Cayenne is to be utilized, someone in the know must look not only at
>>>> the current state of Cayenne, but at the developers. What is/was their
>>>> philosophy behind what they write/wrote? If we don't, it will be a very
>>>> short and costly marriage. Costly, because we either buck up and foot the
>>>> bill to rewrite Webobjects or continue in a bad relationship.
>>>>
>>>> I am writing this not as a diatribe but because I am concerned that in the
>>>> excitement of looking at Cayenne, the obvious impact of differing
>>>> philosophies of the original authors may be ignored. BTW, I say original
>>>> authors because the person that wrote the first line of code left his/her
>>>> imprint on the direction of all code that follows.
>>>>
>>>> JMHO (i mean that sincerely).
>>>>
>>>> Ted
>>>>
>>>>> Message: 4
>>>>> Date: Wed, 11 Jul 2012 10:09:08 -0500
>>>>> From: John Huss <johnth...@gmail.com>
>>>>> To: WebObjects-Dev Mailing List List <webobjects-dev@lists.apple.com>
>>>>> Subject: Migrating from EOF to Cayenne
>>>>> Message-ID:
>>>>>
>>>>> <CAOUwSGtOwEayxK4im97HucAUANo=cfnrkq9ej5z+679bcd7...@mail.gmail.com>
>>>>> Content-Type: text/plain; charset="windows-1252"
>>>>>
>>>>> At WOWODC there was a lot of interest in migrating from EOF
>>>>> to Cayenne, and
>>>>> even entirely rebasing Wonder to run on top of Cayenne
>>>>> instead of EOF.
>>>>>
>>>>> *Why would anyone want to do this? *
>>>>>
>>>>> 1. Cayenne is open-source and is actively
>>>>> being developed
>>>>> 2. Cayenne has great concurrency support
>>>>> which is in stark contrast to
>>>>> EOF single-threaded architecture
>>>>> 3. Cayenne is conceptually very similar to
>>>>> EOF so the transition is
>>>>> fairly straightforward
>>>>>
>>>>> For those reasons it is a much better long term solution
>>>>> than EOF, which is
>>>>> now frozen in time. Cayenne can be used inside a WO
>>>>> application as an EOF
>>>>> replacement while continuing to use the rest of WebObjects.
>>>>>
>>>>> *I'm interested. Now what?*
>>>>>
>>>>> - Learn about Cayenne. The best source of
>>>>> information for comparing EOF
>>>>> and Cayenne is on the
>>>>> wiki<http://wiki.wocommunity.org/display/WO/Alternative+Technologies-Cayenne>.
>>>>> In addition, you can look at the
>>>>> documentation<http://cayenne.apache.org/>for
>>>>> Cayenne.
>>>>> - Use Cayenne in your new projects.
>>>>> Cayenne runs just fine inside a
>>>>> WebObjects application. Wonder has
>>>>> the ERCayenne framework and
>>>>> ERCayenneExample to help you get started.
>>>>> I suggest working with the trunk
>>>>> of the Cayenne source (and Wonder too)
>>>>> since some things are just being
>>>>> added to make this easier.
>>>>> - Help work on easing and automating the
>>>>> migration from EOF to Cayenne.
>>>>> It is possible to automate a large part of
>>>>> the work involved in moving from
>>>>> EOF to Cayenne. But it requires effort.
>>>>> ERCayenne in Wonder has a class
>>>>> that will convert an EOModel to a Cayenne
>>>>> model (the class is
>>>>> CayenneConverter). This works well, but
>>>>> could be improved. I've started
>>>>> working on an Eclipse refactoring script
>>>>> that will convert from one API to
>>>>> the other. Yes, you may not have known (I
>>>>> didn't) that Eclipse can record a
>>>>> series of refactorings and save it as a
>>>>> script. The bulk of the migration
>>>>> work is creating refactoring scripts in
>>>>> Eclipse by performing refactorings
>>>>> on a stubbed out version of the EOF API to
>>>>> convert the API into the
>>>>> equivalent Cayenne API. After performing
>>>>> the refactorings, a script can be
>>>>> exported using Refactor->"Create
>>>>> Script". For EOF methods that do not have
>>>>> a direct Cayenne equivalent, helper
>>>>> methods (or classes) will need to be
>>>>> written that can serve as a direct
>>>>> replacement.
>>>>>
>>>>> *How can I help specifically with the migration effort?*
>>>>>
>>>>> - CayenneConverter in ERCayenne (for
>>>>> converting the model) does not
>>>>> convert the connection dictionaries in the
>>>>> EOModel yet.
>>>>> - CayenneConverter does a poor job
>>>>> converting fetch specs defined in the
>>>>> model currently.
>>>>> - We need to create new subclasses of
>>>>> Cayenne's DbAdapter that use the
>>>>> Wonder naming convention for primary key
>>>>> generators/sequences. This is done
>>>>> by subclassing classes like
>>>>> PostgresPkGenerator and overriding
>>>>> sequenceName. This is necessary to
>>>>> support existing databases created with
>>>>> EOF.
>>>>> - An Wonder-like entity template is
>>>>> already in ERCayenneExample. This
>>>>> needs to be examined and any missing
>>>>> functions from WonderEntity need to be
>>>>> added. For example, I know some the
>>>>> .deleteAllXXXXRelationships and
>>>>> .createXXXX(…) methods are missing.
>>>>> - More refactorings need to created. For
>>>>> example, a refactoring script
>>>>> should be made that changes NSArray and
>>>>> NSDictionary methods to the
>>>>> equivalent List or Map APIs (since Cayenne
>>>>> doesn't use these classes for
>>>>> relationships or fetch results you
>>>>> probably want to minimize the places you
>>>>> need them).
>>>>> - Submit code to Cayenne or create
>>>>> Jira<https://issues.apache.org/jira/browse/CAY>issues
>>>>>
>>>>> Any questions? :-)
>>>>>
>>>>> John
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>>
>>>> This email sent to ch...@global-village.net
>>>
>>> --
>>> Chuck Hill Senior Consultant / VP Development
>>>
>>> Practical WebObjects - for developers who want to increase their overall
>>> knowledge of WebObjects or who are trying to solve specific problems.
>>> http://www.global-village.net/gvc/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com
>>>
>>> This email sent to farrukh.i...@fuegodigitalmedia.com
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall
> knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/gvc/practical_webobjects
>
>
>
>
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
