CDV ❯ defaults for element attributes defined in xml schema not returned by our config system
-
Bug
-
Status: Resolved
-
2 Major
-
Resolution: Won't Fix
-
Configuration
-
-
teck
-
Reporter: teck
-
January 14, 2008
-
0
-
Watchers: 0
-
September 06, 2013
-
September 06, 2013
Description
When this is fixed, the code in DistributedObjectServer.start() that deals with a null return value for l2DSOConfig.bind().getString() (line 294 in revision 6684) can be changed to an assertion.
Default values defined in our xml schema for tc-config are not returned by our config code. This should be fixed, who knows where we’re not getting the right defaults. These comments pretty much tell the story (from FromSchemaDefaultValueProvider.java)
// This is the single most incomprehensible piece of code in the entire system. I have absolutely no idea what this // XPath stuff is actually supposed to do; there is almost no documentation on it. I made this work by long // trial-and-error. You’re on your own here, mate.
and
// We don't yet support direct attribute grabs for defaults; this is because I can't figure out how to get
// XMLBeans to do them right.
Comments
Alex Miller 2008-01-15
Tim Eck 2008-01-15
true, this probably isn’t causing any real problems, but I has to debug it and workaround it, so I thought I’d at least create bug for it. The schema defined default is never returned through our stuff, it is getting short-circuited in FromSchemaDefaultValueProvider.
just seems like a little bit of time bomb
Fiona OShea 2010-03-16
did this ever get fixed? or is it just ticking away
I could take a look at this. I have a fair amount of experience with XML Beans, schema, xpath, and xquery. I’m not an expert but I could play one on TV.
It’s a little unclear here what the actual source problem is - seems like it is in getting the default value for bind?
I think the latter comment sounds a little more scary than it is. There is a unit test for this class that successfully grabs attribute default values at paths like “a/b/@foo”. The comment in question refers to directly reading an xpath like “@blah” in a type, I think, from walking through the debugger.
Seems like maybe this happens to be the case for bind, which is an attribute an the root of the server type. Given the relative scarcity of attributes in our schema (particularly those at the root of a type), I suspect this is not a wide-spread problem.