[Esapi-user] ESAPI development process
schallee at darkmist.net
Fri Sep 10 10:33:04 EDT 2010
> This has thread safety ramifications. I'd really like to see all of
> ESAPI move towards immutable objects because they are so much easier
> to prove thread safe.
Agreed on the immutable objects side. ESAPI has mondo issues with statics
that aren't immutable. It is such a problem that many of the unit tests
are not independent as one affects static settings that another uses.
Sorry. I'm getting ahead of myself. My original proposal (which I'll dig
up from the past and update a bit) for the codecs was to use a abstract
factory pattern with such setConfig type stuff on the factory class and
not on the codecs themselves. I got ahead of myself on this as I really
don't want to see the type of api pollution (for lack of a better term)
that is in the configuration object where every new config gets a new
method making any custom implementations or test proxies for it painful
to keep up. Having the configuration settings on the factories allows
the actual codec instances to be immutable which I would prefer.
(Incidentally, while on the threading subject, I committed a patch for
the HTMLEntityCodec which makes the lookup tables final, immutable and
assigned in the declaration for this very sort of reason. I put together a
unmodifiable version of the Trie to match Collections.unmodifiableMap(). I
need to port it to 1.4 but haven't had the chance yet.)
> The way I know of to make something like this configurable but
> immutable is to parse a configuration file and have the parser return
> a top-level immutable object (that transitively contains only
> immutable objects) from the configuration choices. Then if the
> configuration needs to change, you just parse again and assign the
> top-level object to wherever you need it.
Having the codecs exposed through the static Encoder completely configured
from the configuration and immutable makes perfect sense. Making the
configuration refreshable would be very nice at some point but is not
going to be a trivial undertaking and probably shouldn't get priority
at this point.
I'm not sure I'd like the codec configurations being unchangeable for
all code in a container though. I may want exceptions to be thrown
for invalid characters in some of my code but not in my JSPs. As such I
lean toward the factory route or something else where code that wants a
codec with certain options can get one without affecting thread safety
or codec options for other code.
This can certainly use more discussion though. Thoughts?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100910/aa67145d/attachment.bin
More information about the Esapi-user