Hi Farrukh, 

Thanks for the summary!

Chuck


On 2012-07-13, at 5:06 AM, Farrukh Ijaz wrote:

> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

-- 
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

Reply via email to