On Jan 31, 2010, at 2:27 AM, Adrian Crum wrote:
> --- On Sun, 1/31/10, David E Jones <d...@me.com> wrote:
>> Subject: Re: svn commit: r904921 - in
>> /ofbiz/trunk/framework/base/src/org/ofbiz/base: test/BaseUnitTests.java
>> util/string/UelUtil.java
>> To: dev@ofbiz.apache.org
>> Date: Sunday, January 31, 2010, 12:12 AM
>>
>> On Jan 31, 2010, at 2:00 AM, Adrian Crum wrote:
>>
>>> --- On Sat, 1/30/10, David E Jones <d...@me.com>
>> wrote:
>>>> On Jan 30, 2010, at 8:30 PM, Adrian Crum wrote:
>>>>> 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.
>>>>
>>>> That's kind of interesting.
>>>>
>>>> What got me thinking is that the normal practice
>> for Java
>>>> service is to create a local variable for pretty
>> much
>>>> everything in the context anyway (ie like: String
>> partyId =
>>>> (String) context.get("partyId");), and there are
>> things like
>>>> that all over the place.
>>>>
>>>> As far as not being to write to the context... why
>> not?
>>>> Sometimes it's handy to use the current context as
>> the basis
>>>> for calling another service. There are certainly
>> other ways
>>>> to go about that... but...
>>>
>>> Maybe it would help to step back a little and compare
>> OFBiz back in the day when it was just David and Andrew, and
>> what it is today. Back then using a Map for passing
>> parameters was a cool idea. I don't know what the motivation
>> was to use a Map to pass parameters when you designed the
>> service engine, but at the time I'm sure the two of you knew
>> that you weren't supposed to write to it.
>>>
>>> Today, things are different. We have a lot of
>> contributors. Many of those contributors might not know
>> everything they need to know about the framework. So, the
>> framework needs to protect itself from inexperienced or lazy
>> developers. That was the moral of the story.
>>
>> Have you ever considered running for public office?
>
> Getting paid at a higher rate than the private sector for doing less work has
> its appeal...
Yes, that does add a certain appeal. It's great when the people you work for
have a commonly accepted legitimacy that allows them to appropriate or print
whatever funds are needed. I guess it's even better when you ARE one of the
people you work for... ;)
Whatever the case, I think the current approach is sufficient for the framework
to protect itself from developers, ie pass in a cloned context that is not used
for anything else (of course, if anything mutable is in the context that could
be another issue, especially if developers are not thinking about services at
something isolated like something running on a different machine).
I guess if you really wanted to protect developers from themselves you would
run the services in a totally separate JVM, or as close to that as you can get
like running it from a different classpath branch with only limited resources
available and preferably no access to any static variables.
How much that would break in existing code is another question, especially Java
services where people can do (and frequently do) anything they want...
-David
