Stefano Mazzocchi wrote:

Sylvain Wallez wrote:

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?


Nope, since the flow-related treeprocessor classes deal with flow interfaces rather than with the JS implementation. So we need the flow-related interfaces (only o.a.c.c.flow.Interpreter AFAICS) to be present in the core, but can perfectly live without the implementation jars.

Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }




Reply via email to