and what about the org.osgi.service.event.Event class implementation?
Do you think a different implementation could be useful?
francesco
There are three issues with this. First, I don't think we can provide
a different implementation of org.osgi.service.event.Event; It's a
given and changing it is out of the question (unless I'm very much
mistaken).
Second, I'm not convinced that we need to do anything about it in the
first place. The spec clearly states that event properties must not be
mutable. For me that implies that they should not be mutated by event
receivers too. By this rationality, a receiver that mutates event
properties violates the contract and should be prevented from
receiving events to begin with. It follows that this is a case for
security. In other words, don't use mutable objects as event
properties, if you need to do it (as is it necessary due to the spec
in this case) make sure that untrustworthy bundles don't have the
required permissions to receive this kind of events. Granted, that
implies that security is present - but that is a different story :-)
Third, I don't see that we can come-up with a good solution at all.
Let's face it, Java has some flaws and one of it is arguably that you
can't just "freeze" an Object (as it is possible for example like in
ruby or smalltalk etc.). To make matters worse there is no (build-in)
way to create a proxy dynamically (except for Java Interfaces) and no
really acceptable workaround either (short of byte-code engineering
the heck out of the standard library - doable but questionable).
Furthermore, due to Cloneable not being part of the Object contract
and Serializable neither, a deep-copy is out of the question as well
(in case one could put-up with the semantically differences in the
first place - that is).
In short, I don't think this is the right place to tackle the problem.
Maybe you should raise the question in osgi-dev. The integration of
the EventAdmin with some parts of the spec does appear to be rather
fuzzy around the edges :o)
regards,
Karl
--
Karl Pauls
[EMAIL PROTECTED]
