Carsten Ziegeler wrote:
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the configuration file that defines them is used to feed a ComponentSelector, which will try to load the class and the result is that you will get an Exception in the initialization phase of the TreeProcessor...
The only viable solution is for the declaration to be _not present_ in the treeprocessor configuration.
This is not the best solution, as it would required to change the treeprocessor conf for adding/removing flow.
Could the treeprocessor check the availability of a class before feeding
it into the selector? If the class is not available, a dummy implementation
could be perhaps added that could - when used - throw a meaningfull
exception.
Well, this would mean rewriting a ComponenentSelector specifically for this purpose, since the TreeProcessor does nothing more than delegating all this stuff to a CS : see DefaultTreeBuilder.createBuilderSelector().
Mmmh... A good solution may be to have a FakeFlowNodeBuilder that delegates to a RealFlowNodeBuilder if it's present in the classpath, and otherwise fails with a nice error message saying that the flow isn't installed.
That way, we don't have to open wide the sitemap language definition, which could lead to abuses : map:flow becomes an optional element that is however pre-configured in the sitemap definition. Just drop in the flow jar and it becomes available, without touching a single configuration file.
Thoughts ?
I personally don't like it. Adding fake facades for just one thing doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on the rhino jar. Please, Carsten, correct me if I'm wrong.
Now, if my sitemap doesn't use *any* flow elements, would the jar need to be in the classloader?
Stefano.