Added serialization parameters to @JsonMBean annotation
Added security mechanism for trying to avoid side-effects during serialization.

Just happened (and it took me more than half a day to find it out): My JVM crashed
constantly during setting up some demo. For demonstration purposes I exposed a ServletContext
from Jetty via JMX. During the serialization the JVM crashed under various OS and various JVMs (6 & 7).
Debugging the mess (the JSON output from the ServletContext is over 15MB!) was a pain, but the
really freaking thing happened, when I tried to start up Jetty (via Maven plugin) again:
My .m2 repository was corrupted, as well as the web.xml, all files truncated to 0 bytes !!!!

I already opened an account at Jetty Bugzilla (although I wasn't sure, whether this isn't a JDK issue because
of the Heap crash), but then, at the end of the day, I got it: Jetty exposes FileResource object (indirectly)
over the ServletContext. These objects have methods like 'getInputStream()' and 'getOutputStream()' and
cover all sort of files, of which most are considered to be read only. But guess what happens when calling
'getOutputStream()' (even on descriptors like web.xml) ? Right a *new* OutputStream for this file is created,
deleting the old content !

Since FileResource are used for web.xml, jar-dependencies etc. traversing the ServletContext tree (which, in
fact has a reference to 'Server' and hence to everything ;-], nukes out your installation *and* source (web.xml)
if running from Maven.

The fix is, that OutputStream and Writer (+ subclasses) aren't considered for serialization. Since the
check is a bit expensive, its not yet done for InputStream and Reader but should probably.

The moral of the story: Take care of your side-effect ! "Getter" which are deleting files are not something
one would expect, or ? And yes, dont use automatic serialization blindly (and always consider "maxDepth", especially
when doing bulk read requests).