hydralix / docbkx-tools

Automatically exported from code.google.com/p/docbkx-tools
0 stars 0 forks source link

Bug in ExpressionUtils for certain property definitions #20

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. In the POM that uses the docbkx plugin, add two properties of the form 
"a.b.c" and "a.b.c.d"
2. Run "mvn clean docbkx:generate-html" to process a DocBook file

What is the expected output? What do you see instead?

Instead of transforming the DocBook as usual, I get an exception:

java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map
    at com.agilejava.docbkx.maven.ExpressionUtils.splitToTree(ExpressionUtils.java:40)
    at com.agilejava.docbkx.maven.ExpressionUtils.splitToTree(ExpressionUtils.java:43)
    at com.agilejava.docbkx.maven.ExpressionUtils.createTree(ExpressionUtils.java:31)
    at 
com.agilejava.docbkx.maven.AbstractTransformerMojo$1.<init>(AbstractTransformerM
ojo.java:
165)
    at 
com.agilejava.docbkx.maven.AbstractTransformerMojo.execute(AbstractTransformerMo
jo.java:1
62)
    at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.ja
va:451)
    at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycl
eExecutor.java:
558)
    at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(Defaul
tLifecycleExec
utor.java:512)
    at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycle
Executor.java:4
82)
    at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecy
cleExecutor.java:330)
    at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultL
ifecycleExecu
tor.java:291)
    at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExec
utor.java:142)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

What version of the product are you using? On what operating system?

docbkx-maven-plugin 2.0.8

Please provide any additional information below.

This problem is caused by a bug in ExpressionUtils. The following code 
reproduces the error:

        Properties properties = new Properties();
        properties.setProperty("a.b.c", "foo");
        properties.setProperty("a.b.c.d", "bar");
        Map tree = ExpressionUtils.createTree(properties);

Original issue reported on code.google.com by goo...@vocaro.com on 18 Dec 2008 at 7:47

GoogleCodeExporter commented 9 years ago
This is probably the same bug described in Issue 12.

Original comment by goo...@vocaro.com on 18 Dec 2008 at 8:03

GoogleCodeExporter commented 9 years ago
Another problem with ExpressionUtils is that if you have properties like this:

a.b = foo
a.b.c = bar

Then the tree that is created will look like this:

{a={b=foo}}

No exception is thrown, but the "a.b.c" property is not there!

Original comment by goo...@vocaro.com on 18 Dec 2008 at 8:34

GoogleCodeExporter commented 9 years ago
I spent a lot of time trying to fix this bug, and I finally realized that it's 
unfixable. Let me illustrate with an 
example.

Consider this property and its corresponding expression tree:

a.b = "foo"  -->  {a = {b = "foo"} }

And this one:

a.c = "bar"  -->  {a = {c = "bar"} }

Now, if both of these properties are defined, the two trees will merge into one:

{a = {b = "foo", c = "bar"} }

That's all well and good.

But now consider this property and its corresponding tree:

a.b.c = "baz"  -->  {a = {b = {c = "baz"} } }

How would you merge this into the previous tree? You can't! That's because both 
trees have different values 
for "b". The former defines it as the string "bar" while the latter defines it 
as the map {c="baz"}. It can't be 
both.

So the problem here is that the expression tree data structure, as defined by 
ExpressionUtils, is invalid. It 
requires a single key to map to more than one value, but of course this is 
impossible.  Fixing the problem will 
require changing the very definition of the expression tree data structure.

Original comment by goo...@vocaro.com on 18 Dec 2008 at 9:10

GoogleCodeExporter commented 9 years ago
Hi,

Thank you for all this debug!
I will try to have a look where we use this ExpressionUtil class and maybe we 
can use
something else to avoid this problem.

Regards,
Cédric,

Original comment by MimilO...@gmail.com on 13 Jan 2009 at 10:45

GoogleCodeExporter commented 9 years ago
Hello,

I removed the use of the ExpressionUtil.createTree() and fall back on the
properties.get(key) and it sounds to work as expected on my tests:

Test:
 <properties>
  <a.b.c>JavaHelp example</a.b.c>
  <a.b.c.d>article.xml</a.b.c.d>
 </properties>

 <echo message="postprocess ${a.b.c} ${basedir}" />
 <echo>${a.b.c.d}</echo>

Result:
 [echo] postprocess JavaHelp example C:\projets\docbkx\docbkx-samples
 [echo] article.xml

Wilfred, any objection to remove the use of ExpressionUtil on this part of
AbstractTransformerMojo?

Cedric,

                                    }

Original comment by MimilO...@gmail.com on 5 Mar 2009 at 10:20

GoogleCodeExporter commented 9 years ago
remove of ExpressionUtils use

Original comment by MimilO...@gmail.com on 18 Mar 2009 at 9:23

GoogleCodeExporter commented 9 years ago

Original comment by MimilO...@gmail.com on 18 Mar 2009 at 9:30

GoogleCodeExporter commented 9 years ago
Issue 12 has been merged into this issue.

Original comment by MimilO...@gmail.com on 18 Mar 2009 at 9:33