Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Test and Performance Tools Platform (TPTP) » Request for Comment: Defect #122770.
Request for Comment: Defect #122770. [message #49334] Thu, 05 January 2006 21:09 Go to next message
Paul Slauenwhite is currently offline Paul Slauenwhite
Messages: 970
Registered: July 2009
Senior Member
Hi Team,
Recently we discovered behavioral and inconsistency issues with how
the Common Base Event implementations (Java (EMF and non-EMF) and native
(C)) in TPTP (org.eclipse.hyades.logging.core plug-in
( http://dev.eclipse.org/viewcvs/index.cgi/platform/org.eclips e.hyades.loggin
g.core/?cvsroot=TPTP_Project))
handle null properties. For more information, see defect #122770
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=122770). Since the solution
for this defect involves a behavioral change in the Common Base Event
implementations, we are requesting feedback from the user community to
determine:

1) Are these behavioral and inconsistency issues required to be fixed in
TPTP v4.2? For example, are there concrete use cases where current users
or consuming products are negatively impacted by these behavioral and
inconsistency issues?

2) Are there current users or consuming products that would be negatively
impacted by introducing the necessary behavioral changes to resolve this
defect? If so, would a compatibility mode be required.

3) Is there any general feedback (opposition or agreement) from the user
community on this defect?

Please reply to this post or add a comment to defect #122770
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=122770) with any comments
related to the above questions.

Thank you.

Paul Slauenwhite
Re: Request for Comment: Defect #122770. [message #49399 is a reply to message #49334] Fri, 06 January 2006 07:29 Go to previous messageGo to next message
Brent A. Miller is currently offline Brent A. Miller
Messages: 1
Registered: July 2009
Junior Member
From an architecture perspective, I am in general agreement with the
direction of this proposal. Common Base Event implementations should
ultimately follow the XML schema rules rather than the specific (e.g.,
Java) implementation rendering rules.

One additional consideration: the Common Base Event specification notes
certain properties that should be treated as having "default" values when
they are null (unspecified) (for example, for the version property, the
specification states, "This field is OPTIONAL in that if it isn’t
specified, the version of the CBE is said to be 1.0."; for the
extensionName property, the specification states, "If the value specified
is null, then the value is assumed to be “CommonBaseEvent”.").
Implementations should, in addition to the treatment of null/unspecified
values noted in this defect, also respect these cases where the
specification notes special treatment for null/unspecified values.
Re: Request for Comment: Defect #122770. [message #49458 is a reply to message #49399] Fri, 06 January 2006 09:54 Go to previous messageGo to next message
Paul Slauenwhite is currently offline Paul Slauenwhite
Messages: 970
Registered: July 2009
Senior Member
Hi Brent,
Thank you for your reply and comments.

Regarding your point on default values for null or unspecified
properties, I would argue that since the Common Base Event V1.0.1
specification assume the XML convention, null or unspecified properties are
one in the same. As such, it is up to the consume of a Common Base Event
XML fragment to interpret a missing or empty version attribute as one in the
same, for example. Currently, Common Base Event properties, such as
version, are not serialized to XML if they have not been set (e.g. null in
the case of strings and complex objects or denoted by the unset flag in the
case of primitives) to control the size of Common Base Event XML fragments.
We are proposing converting null values explicitly set on a Common Base
Event property to an empty string, thereby serializing the property to an
empty XML attribute (or element in the case of a complex object other than a
string). The consumer of such an empty attribute would interpret it the
same as if the attribute were missing. Otherwise, to maintain consistency,
all null and unset properties would need to be serialized to XML as empty
attributes or elements resulting is artificially bloated Common Base Event
XML fragments.

Paul

"Brent A. Miller" <bamiller@us.ibm.com> wrote in message
news:6f518f1afc8703a096ef7414bf038c38$1@www.eclipse.org...
> From an architecture perspective, I am in general agreement with the
> direction of this proposal. Common Base Event implementations should
> ultimately follow the XML schema rules rather than the specific (e.g.,
> Java) implementation rendering rules.
>
> One additional consideration: the Common Base Event specification notes
> certain properties that should be treated as having "default" values when
> they are null (unspecified) (for example, for the version property, the
> specification states, "This field is OPTIONAL in that if it isn
Re: Request for Comment: Defect #122770. [message #49672 is a reply to message #49458] Mon, 09 January 2006 17:36 Go to previous message
Eclipse User
Originally posted by: tawinson.au1.ibm.com

Just to let everyone else know, the new SecurityEventFactory code has run
into problems with this bug. Put succintly, given perfectly valid
parameters, the cbe code is capable of creating an event that will then
fail its own validation. The problem arises in the ExtendedDataElement
code when addChild(name, type, value) is called and value==null. There is
no check for a null value, and the method calls
ede.getValues().add(value). This sets the "value" to an array of null
values, and a size of 1. Validate() later throws an exception when
"value" is not equal to null and has a size>0. I would suggest that
changing this particular occurence of how null values are handled would
not cause negative impact to existing consumers, as I doubt any existing
consumers are using this method this way, otherwise they would have
Exceptions thrown too.
Previous Topic:New Technology Agent Controller - Migration Sample
Next Topic:just want to test a plug-in
Goto Forum:
  


Current Time: Fri Apr 18 17:06:47 EDT 2014

Powered by FUDForum. Page generated in 0.02502 seconds