XSLT action fails

[Former Member]

We have an XSLT which has an include like below:

<xsl:include href="/CommonTemplates.xslt"/>

The main XSLT is used in XSLT action and specified as an URL. When XSLT action executed, xMII is not able to resolve the relative URL "/CommonTemplates.xml" and generates the following error:

[ERROR]: XSLTransform error: javax.xml.transform.TransformerConfigurationException: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: Had IO Exception with stylesheet file: /CommonTemplates.xslt

Is there any workaround on this issue?

Thanks,

Sara

[jcgood25]

Sara,

It would seem strange to have a stylesheet on the root even though the forward slash indicates that it is. To attempt to resolve the error have you tried putting the included xsl in the same directory as the main one and removing the forward slash?

You mention .xslt and then .xml - I assume this is just a typo?

Also, what version of xMII are you using?

Regards,

Jeremy Good

[Former Member]

Yes, it does not work either.

Thanks,

Sara

[jcgood25]

Sara,

Can you provide an explanation as to what the xsl does to the dataset? It is very possible that the transformation being done by the stylesheet(s) could be accomplished within the transaction itself.

Does the xsl work if you include the templates in the nested xsl within the base xsl and not have the include?

Regards,

Jeremy Good

[Former Member]

Yes, you are right. We could do what ever xslt is doing using xMII action blocks. But XSLT gives the flexiblity of the changing the mapping at runtime without changing any of the code.

Thanks,

Sara

[Former Member]

Removing the / and placing them in the same directory should definitely work.

[Former Member]

Rick,

Removing the / and placing include xslt in the same directory will work only if these xslt files are accessed using the file:// protocol. If these xslts are accessed using a URL, it does not work:

Here is the error:

[ERROR]: XSLTransform error: javax.xml.transform.TransformerConfigurationException: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: Had IO Exception with stylesheet file: CommonTemplates.xslt

[jcgood25]

What path are you using to call the xsl file in the BLS action block? You should use http:// and then like Rick said the relative pathing should be just fine.

Regards,

Jeremy

[Former Member]

Yes, I am using a valid URL path like http://server:8080/test.xslt. This test.xslt includes another xslt (test1.xslt) and this include xslt also in the same directory as test.xslt.

Thanks,

Sara

[jcgood25]

Sara,

I can recreate your issue (since you didn't answer my version question I am assuming you are using 11.5) and you will need to fully qualify your references within the action block and in the href include. I simply used the http://localhost/Illuminator/StyleSheets/Samples/TagExpander.xsl against a Current tag query and then added an include to the http://localhost/Illuminator/StyleSheets/IllumRowsetLibrary.

Use http://localhost/ for portability and migration purposes instead of embedding the server name and port in the string, but make sure to use the same reference in the include since 11.5 required fully qualified stylesheet references. Version 12.0 allows relative pathing.

Regards,

Jeremy

[Former Member]

Yes, I know that it supports an absolute URL path in the include. The problem is the support for a relative path.

Thanks,

Sara

[Former Member]

Yes, the xMII version is 11.5.

Thanks,

Sara

[jcgood25]

With 11.5 there is no workaround to use the nested stylesheet without fully qualifying the references. Use http://localhost referenced paths and then when you upgrade to 12 you can adjust accordingly.

Regards,

Jeremy

[Former Member]

The XSLTs are not served from localhost (xMII Server), but they are served from different servers.

Is the fix on one class "XSLTransform.class". If I just replace this class file with version 12 class file, will it work?

Thanks,

Sara

[jcgood25]

No, that will not work.

You want to use xsl, and not fully qualify them as needed, so as not to maintain BLS logic to transform your data but yet they live on another server? Yikes! What is special about the xsl - can you share more info to explain the reasons behind all this?

Regards,

Jeremy

[Former Member]

The reason could be as simple as why you have provided the XSLT action initially.

Okay, it is for the reason that we don't want to have the mapping logic anywhere in the code. If you want to change the mapping logic, it would be very easy to change the logic in XSLT without touching any of the current implementation.

Also, this XSLT mapping logic could be used by any integration framework, not only by xMII.

Thanks,

Sara