Saxon » SaxonC

The add package method now looks like the following:

     def add_package(self, list file_names):
        """
        add_package(self, file_name)
        Add an XSLT 3.0 package to the library.

        Args:
            file_name (str): The file name of the XSLT package

        """
        len_ = len(file_names)
        cdef const char* c_string
        cdef const char ** cfile_names = self.thisxptr.createCharArray(len_)
        for x in range(len_):
          c_string = make_c_str(file_names[x])
          cfile_names[x] = c_string
        self.thisxptr.addPackages(cfile_names, len_)

For this to work we I have had to add the method createCharArray in the Xslt30Processor class.

    /**
    * Utility method for working with Saxon/C on Python
    */
    XdmValue ** createXdmValueArray(int len){
	return (new XdmValue*[len]);
    }

The function name and the comment to explain the function signature doesn't seem to match the code, the function name add_package seems to suggest it is called for a single package, the parameter list file_names suggests it is called (once?) with a list of packages.

Instead of trying to bridge Python and C/C++ I have first tried to use addPackages from C++ but somehow I always get an error "XTSE3000: Cannot find package http://example.com/packages/ex2 (version *)".

To get no run-time error I first had to fix the JNI signature to

     void Xslt30Processor::addPackages(const char ** fileNames, int length){
              	if(exceptionOccurred()) {
              		//Possible error detected in the compile phase. Processor not in a clean state.
              		//Require clearing exception.
              		return;
              	}

              	if(length<1){

              		return;
              	}

              	jmethodID apmID =
              			(jmethodID) SaxonProcessor::sxn_environ->env->GetMethodID(cppClass,
              					"addPackages",
              					"(Ljava/lang/String;[Ljava/lang/String;)V");
              	if (!apmID) {
              		std::cerr << "Error: "<<getDllname() << "addPackages" << " not found\n"
              				<< std::endl;

              	} else {

              	 jobjectArray stringArray = NULL;

                 jclass stringClass = lookForClass(SaxonProcessor::sxn_environ->env,
                 				"java/lang/String");


                 stringArray = SaxonProcessor::sxn_environ->env->NewObjectArray((jint) length,
                 					stringClass, 0);

                 for (int i=0; i<length; i++) {

                 SaxonProcessor::sxn_environ->env->SetObjectArrayElement(stringArray, i,
                 						SaxonProcessor::sxn_environ->env->NewStringUTF(fileNames[i]));
                 }

              	SaxonProcessor::sxn_environ->env->CallObjectMethod(cppXT, apmID,
              								SaxonProcessor::sxn_environ->env->NewStringUTF(cwdXT.c_str()), stringArray);

                proc->checkAndCreateException(cppClass);
              }
              	return;

        }

In the C++ code to use the method I tried three different ways, not setting any cwd but hoping the implementation would pick the current working directory:

	const char * packagesList[] = { "add-atts-p1.xsl", "add-atts-p2.xsl" };
	trans->addPackages(packagesList, 2);

or setting the cwd or even using full file paths for all file arguments, but I always got the same error mentioned above.

The XSLT code seems fine and when I manage to compile the Transform.c in the command folder and run it with the proper options lib the code also works when called from C, although I think that way simply net.sf.saxon.Transform is called from C, not the C++ API.

I think part of the problem is a lack of code in https://dev.saxonica.com/repos/archive/opensource/latest9.9/hej/net/sf/saxon/option/cpp/Xslt30Processor.java, in the compilePackages method is simply calls PackageLibrary library = new PackageLibrary(compiler.getUnderlyingCompilerInfo(), packagesToLoad); but I guess that doesn't register the create library package with the compiler, so a call compiler.getUnderlyingCompilerInfo().setPackageLibrary(library); there or some return of the created PackageLibrary to be registered in the calling method is necessary.

So whatever I do in the C++ or even the Python API will not work unless that Java bridge code is fixed to ensure the compiler not only compiles but also includes the package library.

Thanks Martin.

We have 2 main bug here.

1. Incorrect JNI code.
2. The following code missing in the method compilePackages of the Java API: compiler.getUnderlyingCompilerInfo().setPackageLibrary(library)

I have fixed both. Unfortunately 2. requires a new Saxon/C build. I will look to do a new maintenance release in the early part of the new year. I hope that will be ok?

Unfortunately 2. requires a new Saxon/C build. I will look to do a new maintenance release in the early part of the new year. I hope that will be ok?

Yes, sure, whatever suits your normal working schedule. Don't let my findings spoil your holiday season.

I guess XsltProcessor.java suffers from the same problem of not having compiler.getUnderlyingCompilerInfo().setPackageLibrary(library).

Martin Honnen wrote:

I guess XsltProcessor.java suffers from the same problem of not having compiler.getUnderlyingCompilerInfo().setPackageLibrary(library).

Yes indeed. Fixed too.

Revisiting this issue:

After some testing of the new packages support in Saxon/C it seems like the best way to supply packages is via configuration file. This is due to changes in the Java and dotnet product to deprecate the method compilePackages. It is still possible to save a package, but users can only now use the configuration file for XSLT packages.

Configuration file currently not supported in Python. Investigating issue. Reported in separate bug issue: #4418