Community
Participate
Working Groups
Behavioural and inconsistency issues with how the Java Common Base Event implementations handle null properties. There exists behavioural and consistency issues with how the Java (EMF and non-EMF) Common Base Event implementations handle null properties. First the behavioural issue. Since the Common Base Event V1.0.1 specification does not specify how to handle null properties, the Java Common Base Event implementations have adopted the Java conventions (e.g. adding a null element to a list results in a list of size 1 containing the null element). However, the Common Base Event V1.0.1 specification is tightly coupled to XML as defined in its schema. XML represents null or unset properties as empty attributes or elements. As for the consistency issue, the Java Common Base Event implementations treat null properties as both unset properties (e.g. setting a null msg property on a Common Base Event) and valid values (e.g. adding a null element to a list results in a list of size 1 containing the null element). Ultimately, the Java Common Base Event implementations should be following the XML conventions for representing null or unset properties. In other words, null strings would be represented as empty strings and serialized to XML as empty attributes. Also, null complex properties (objects) would flaged and serialized as empty elements.
*** Bug 122765 has been marked as a duplicate of this bug. ***
This defect applies to the native (C) Common Base Event implementation as well.
Since the solution for this defect involves a behavioral change in the Common Base Event implementations, a public request for comment has been issued on the TPTP public forums: Mailing List: http://dev.eclipse.org/mhonarc/lists/tptp-platform-dev/msg00462.html Newsgroup: http://www.eclipse.org/newsportal/article.php?id=1171&group=eclipse.tptp#1171
I think this could cause negative impact to existing consumers who are code-aware of the existing behavior and I would suggest not doing it pending your description of how a compatibiltiy mode would work. Can you describe that?
(In reply to comment #4) > I think this could cause negative impact to existing consumers who are > code-aware of the existing behavior and I would suggest not doing it pending > your description of how a compatibility mode would work. Can you describe that? Assuming that there are concrete examples where consuming products might be negatively impacted by such a behavioural change, the compatibility mode, on by default, would maintain the current behavior of how the Common Base Event implementations handle null properties. The user could turn off the compatibility mode to realize the behaviour proposed in the solution to this defect. That said, there would need to be concrete examples that merit the negative performance impact of such a compatibility mode. The proposed solution would only impact users or consuming products that explicitly set a null value as a Common Base Event property which is typically not the norm. We are investigating the potential for any negative impact to existing users or consuming products and if present, what measures are necessary to reduce or remove this negative impact.
The CBE representation is XML and hence from the architecture standpoint the native and Java implementation should follow the CBE XML schema spec.
Since no users/consuming products are requiring this defect and given the impact of the change, we will wait fix this defect in the the Common Base Event V2.x implementation (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=82676). As such, re-targeting to future and decreasing the severity to normal.
Transitioning to new component owner (Cindy Jin).
Cannot contain in TPTP V4.3(i3)
target to futrue, since this API is well used and changing it now would break a lot of users
This is required from AC perspective
No support for the Java CBE libraries will be provided post 4.5.
Closing.
