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). -David > What kind of modifications do you need to do? Auto-vivification kinda > stuff?
