XSLT extension does not work with file: URIs

[ppalaga]

I just tried to extend the XsltTest with a file: use case and it fails. Let me try to fix it.

[lburgazzoli]

Not very sure if it make sense as the file need to be compiled at build time so it may be better to require the file to be available as classpath thing so it does not change between the build phase and the runtime execution of the app

[ppalaga]

I have a fix. It does not work for any URI that contains slashes. Has to do with how we produce the translet name.

Not very sure if it make sense as the file need to be compiled at build time

Yes, the limitation is there for any kind of URI. We state in the docs that the resources have to be available at build time, but we should perhaps make it even more explicit saying that they are compiled at build time and fully ignored at runtime.

If we document it properly, I see no reason why file:, http:, and other kinds of URIs should not be supported. WDYT?

[lburgazzoli]

As far as I remember the stack (camel or xslt engine) still try to access the file before determine if it needs to compile or reuse classes so having something served through http would still lead to some possible slow actions and errors.

[ppalaga]

the stack (camel or xslt engine) still try to access the file before determine if it needs to compile or reuse classes

Ah, indeed, I can see it now. My understanding is that runtime XSLT loading cannot work because it requires a class to get loaded. If this is really the case, accessing the XSLT source at runtime could be seen as a bug, shouldn't it? I mean that could be fixed easily by downloading and embedding the content of every source URI at build time.

[lburgazzoli]

Yes, what I think is that we should enhance the component to let us filter what protocols we support so in quarkus we'll support classpath only, then about compiling the source yes, it can be everywhere and embedded in the resulting image but I do not know if it is something that depends on us or is a developer task