*** Bug 40674 has been marked as a duplicate of this bug. ***

I can confirm this problem.

Well, I don't think that can be fixed.

template-fallback:// doesn't look for the parent of the publication it is called
from (because it can't figure out from which location it has been called). It
just returns the second match. So if you include something with
template-fallback which in turn contains a template-fallback statement, the
latter file will try to include itself.

I'm afraid you have to address the stylesheet you want to include explicitely
(e.g., with a context:// URL).

I'm leaving this issue open, maybe we'll find a way to determine the calling
publication.

i think this is a major issue. it will specifically bite those users who are
trying something clever and elegant with lenya. we must not frighten them :)

still, a hard problem...

Apparently the template-fallback source factory doesn't get to resolve the URI
twice. I guess Xalan only looks at the URL and thinks that the stylesheet would
include itself ...

Yes, this is the problem:

Xalan/ProcessorImport.java:134

      if (handler.importStackContains(hrefUrl))
      {
        throw new org.xml.sax.SAXException(

Well, I hope we'll find a way around this :(

Jörn suggested to use a query string (e.g., ...?salt=1345243) to trick Xalan.
I'm trying this now.

Now the leaf can resolve its parent, but then the Lenya context resolving fails.
Maybe the only solution is to change the context like the cocoon:// protocol
does ...

The only simple way is to pass the publication ID in the URL:

template-fallback:pub://path

I'm reducing the severity because this workaround exists.