--- On Sat, 1/30/10, David E Jones <[email protected]> wrote: > From: David E Jones <[email protected]> > Subject: Re: svn commit: r904921 - in > /ofbiz/trunk/framework/base/src/org/ofbiz/base: test/BaseUnitTests.java > util/string/UelUtil.java > To: [email protected] > Date: Saturday, January 30, 2010, 5:37 PM > > On Jan 30, 2010, at 7:28 PM, Adam Heath wrote: > > > Adrian Crum wrote: > >> --- On Sat, 1/30/10, Adam Heath <[email protected]> > wrote: > >>> From: Adam Heath <[email protected]> > >>> Subject: Re: svn commit: r904921 - in > /ofbiz/trunk/framework/base/src/org/ofbiz/base: > test/BaseUnitTests.java util/string/UelUtil.java > >>> To: [email protected] > >>> Date: Saturday, January 30, 2010, 4:57 PM > >>> Adrian Crum wrote: > >>>>> If you really need to modify variable, > then change > >>> the > >>>>> generics markup > >>>>> on context. > >>>> I appreciate the review and comments, but > I think > >>> you're not understanding the integration. I > can't change the > >>> method signature because it is part of the JSR > 245 > >>> specification, and yes, I really need to write > to the > >>> context because that is the whole point of the > integration. > >>> > >>> Well, then, the integration is wrong. If > that method > >>> signature is > >>> part of the spec, then you can't just go and > do an end run > >>> around it > >>> because you feel like it. > >> > >> The context Map that is passed around the > framework (in services, mini-lang, and screen widgets) is > referred to as Map<String, ? extends Object>. Yet some > portions of the framework need to write to that Map - it's > their job to do so. So, what do you suggest? > > > > Dig further. You'll find that this supposed > read-only map is actually > > already a copy in places, so if you really do write to > it, the changes > > will just be thrown away anyways. > > > > In other cases, the original map that enters the > system is already a > > throw-away. > > > > When I originally came up with the read-only generics > for service > > engine calls, I tried to make the maps writable. > But upon modifying > > the entire stack, I discovered it wasn't > possible. The service engine > > made copies in some cases, so the underlying service > implementations > > weren't able to send data back at all to the original > caller. To > > encapsulate this, I made the map read only, by using > the ? extends syntax. > > Maybe this is not the best way to look at it. The point is > not that you can't change the context, it is just that any > changes to the context are local to the service itself. > > If I had the service engine to design again I'd consider > having it be more like the screen widget with the > hierarchical context, and with the context as the local > variable space (for all services except those written in > plain Java where you can't inject into the variable space on > the stack (not that I know of anyway... maybe there is a way > and that would be cool).
When I first got involved with OFBiz, I would write to the service context Map because I didn't know any better. Then when I got to know OFBiz better, I still wrote to the service context Map because I was lazy. Now I always copy the service context Map into a local Map if I want to change things. The moral of the story is: developers shouldn't be allowed to write to the service context Map. If a service needs a Map for local storage, then it should create one.
