Re: too much problems with new functions was: Re: ofbiz twitter account was: Re: svn commit: r918926 - in /ofbiz/site: images/follow_us-b.png index.html

Posted by Adrian Crum on Mar 11, 2010; 4:02pm
URL: http://ofbiz.116.s1.nabble.com/Re-svn-commit-r918926-in-ofbiz-site-images-follow-us-b-png-index-html-tp1578166p1589185.html

Adam Heath wrote:

> Moving the caching higher implies that the constructed delegator won't
> be saved until it is completely done being constructed.  However,
> during construction, the delegator creates several helper entities.
> These include EntityCrypto, and the cache support classes.  These
> classes also still have the same problem of not storing delegator
> instances, instead just storing a name.  So, they try to load a
> delegator with the correct name, and don't find it, because the
> original delegator is not done being constructed.
>
> But, we still aren't done with this particular problem.
>
> When GenericPK and GenericValue get created, they try to set their
> fields.  Setting any field on a GenericEntity requires that it knows
> it's delegator.  However, creation doesn't actually set the delegator.
>  Even the delegator name is null.  So any GenericEntity created during
> delegator instantiation ends up trying to load a delegator named
> "default", *not* with whatever delegator is actually being created.

I ran into that circular logic problem in the ExecutionContext branch. I
agree - there are a lot of problems with the delegator implementation
and they should be fixed. Let me know if there is anything I can do to help.