From: "David E Jones" <d...@me.com>
On Mar 11, 2010, at 10:20 AM, Adrian Crum wrote:
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.
Adrian, don't you dare. That is ridiculous, untrue, and unfair. You did it. Don't blame others. I was also against the changes you
were making and spoke up about it, but you ignored those comments.
You bring up my name in order to justify your actions? I completely disapprove and I now ask you out of respect to not refer to me
in this way, ever again. If it helps you may simply not refer to me at all.
Quite frankly, if I could undo everything you and certain others have done in the project without having to resolve innumerable
dependencies and invest an enormous amount of time... well that would be tempting. That's not an option though, and I don't think
it would be a good idea for the community either (community over code!), so I wouldn't pursue or even seriously propose such a
thing. There are always other ways to move forward...
-David
Beautiful answer, Adam's comment ;o) ?
Jacques
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.
