Adam Heath wrote:
Adrian Crum wrote:
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.
Oh, heh, funny you should say that.
Your DelegatorFactory change gave me many problems. It's not
backwards compatible.
Please keep in mind that was your design. Also keep in mind that David
has been warning the community for some time that even more
backwards-incompatible changes are on the way.
When making changes to ofbiz, it's not just the internal project code
that has to be made consistent. Ofbiz doesn't exist by itself. It
has to deal with external addons, that aren't even known. As such,
much care needs to be taken any time you change the abi(not api).
This was not done with the DelegatorFactory change. I even mentioned
this briefly during it's inception. But I never spoke up in detail
about it at the time.
You're preaching to the choir here. I tried to keep things backwards
compatible, but you and David argued against it.
Also, any time a class changes(I'm saying this again, but it bears
repeating), you need to consider the use cases of it. This paragraph
is talking about the moving of some classes from util to lang, with no
attention paid to backwards compatiblity, nor deprecation. If an end
developer has to maintain multiple versions of their product against
multiple versions of ofbiz, then changing abi like this causes *more*
work for end developers.
The only classes that were moved were new ones that shouldn't cause any
compatibility issues. You don't see me complaining about all of the
converter classes you moved around.
Any time you change something, and someone finds a problem with it,
don't take the defensive, and say "How dare you find faults with my
work; I'm not going to fix this, as it's just more work for me to do."
In actuallity, you have caused more work for the person who found the
problem. You have broken their own software; you have made them
dislike the project as a whole.
Are you speaking rhetorically? As far as I know I have been receptive to
comments about my code. I'm always willing to revert any of my changes
that cause problems.
