CDV ❯ bootjar succeeds with bad module xml
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
-
-
hhuynh
-
Reporter: tgautier
-
December 15, 2007
-
0
-
Watchers: 5
-
January 30, 2008
-
January 08, 2008
Description
I had a terracotta.xml in a module that was missing the the correct xml line, the first line was instead:
?xml version=”1.0” encoding=”UTF-8” ?>
Which should have been: <?xml version=”1.0” encoding=”UTF-8” ?>
When I tried to use this module, I got this:
[INFO] Starting bootjar tool
[INFO] [bootjar] 2007-12-15 16:46:16,029 INFO - Terracotta 2.5-rev6472, as of 20071211-121221 (Revision 6472 by cruise@rh4mo0 from 2.5)
[INFO] [bootjar] 2007-12-15 16:46:16,481 INFO - Configuration loaded from the file at ‘/Users/tgautier/src/forge/projects/labs/pattern-resourcepool/sample/target/classes/tc-config.xml’.
[INFO] [bootjar] 2007-12-15 16:46:17,497 WARN - Unable to parse configuration from bundle: org.terracotta.pattern.resourcepool
[INFO] [bootjar] org.apache.xmlbeans.XmlException: error: Unexpected element: CDATA
[INFO] [bootjar] at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3467)
[INFO] [bootjar] at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1270)
[INFO] [bootjar] at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1257)
[INFO] [bootjar] at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
[INFO] [bootjar] at com.terracottatech.config.DsoApplication$Factory.parse(DsoApplication.java:260)
[INFO] [bootjar] at com.tc.plugins.ModulesLoader.loadConfiguration(ModulesLoader.java:288)
[INFO] [bootjar] at com.tc.plugins.ModulesLoader.access$100(ModulesLoader.java:53)
[INFO] [bootjar] at com.tc.plugins.ModulesLoader$2.callback(ModulesLoader.java:137)
[INFO] [bootjar] at com.tc.bundles.KnopflerfishOSGi.startBundle(KnopflerfishOSGi.java:84)
[INFO] [bootjar] at com.tc.bundles.KnopflerfishOSGi.startBundles(KnopflerfishOSGi.java:64)
[INFO] [bootjar] at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:151)
[INFO] [bootjar] at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:95)
[INFO] [bootjar] at com.tc.object.tools.BootJarTool.
Comments
Alex Miller 2008-01-04
Steve Harris 2008-01-05
Don’t know if we need to tolerate bad modules but we do need to continue to think about how we deal with failures in general and boot jars in particular. Do we have a consistent response in all the places where we autogenerate bootjars so that if it fails they properly handle it?
Examples are: maven plugin dso-java eclipse tool configurator sample launcher others?
Alex Miller 2008-01-07
CDV-397 seems to be similar complaint. The change made in that case was to dump the error to the console in addition to the log (which was already happening).
Alex Miller 2008-01-08
There were 3 kinds of exceptions being caught and logged but not propagated in ModulesLoader. After some discussion, I modified these three catch blocks to also throw the exception, propagating the error. In the case above, this will result in the boot jar tool exiting. The message should exist in the log, on the console, and in the exception being thrown.
Added a test verifying this scenario and Tim reviewed. Also, I added a test for one of the other scenarios where the terracotta.xml is valid XML but is invalid (for example, root has neither field value or expression). In this case, we are getting good error messages from the next layer down, so I included that message as well and slightly improved the error messages there.
Hung Huynh 2008-01-25
Just a note: these errors are only caught during runtime not compile time.
So, the code in question here seems to be com.tc.plugins.ModulesLoader.loadConfiguration(ModulesLoader.java:288)
which catches IOException, XmlException (the one in question), and ConfigurationSetupException and logs but swallows all of them.
Anyone know why these conditions should not be treated as fatal errors? Seems like in all of them the module failed to load so presuming you wanted that module, this should be fatal. Is there a case where it’s important to be tolerant of bad modules?