XTSE1650: net.sf.saxon.trans.LicenseException: Requested feature (xsl:import-schema) requires Saxon-EE - saxon

I use java and saxonee-9.5.1.6.jar included build path , when run, getting these errors at different times.
Error at xsl:import-schema on line 6 column 169 of stylesheet.xslt:
XTSE1650: net.sf.saxon.trans.LicenseException: Requested feature (xsl:import-schema)
requires Saxon-EE
Error on line 1 column 1
SXXP0003: Error reported by XML parser: Content is not allowed in prolog.
javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
I open .xslt file in hex editor and dont see any different character at the beginning AND
I use transformerfactory in a different project but any error I get.

Check what the implementation class of tFactory is. My guess is it is probably net.sf.saxon.TransformerFactoryImpl - which is basically the Saxon-HE version.
When you use JAXP like this, you're very exposed to configuration problems, because it loads whatever it finds sitting around on the classpath, or is affected by system property settings which could be set in parts of the application you know nothing about.
If your application depends on particular features, it's best to load a specific TransformerFactory, e.g. tFactory = new com.saxonica.config.EnterpriseTransformerFactory().
I don't know whether your stylesheet expects the source document to be validated against the schema, but it it does, note that this isn't automatic: you can set properties on the factory to make it happen.
I would recommend using Saxon's s9api interface rather than JAXP for this kind of thing. The JAXP interface was designed for XSLT 1.0, and it's a real stretch to use it for some of the new 2.0 features like schema-awareness: it can be done, but you keep running into limitations.

Related

zOS: MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT BE SAVED IN LOAD MODULE FORMAT

I'm trying to do the linkage of a hello world in cobol, as in this tutorial, I can compile the program and get the new member in project.group.OBJ successfully, but when I link it with
LINK project.group.OBJ(Member) lib('cee.sceelked')
I get the following:
IEW2278I B352 INVOCATION PARAMETERS - TERM
IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT
BE SAVED IN LOAD MODULE FORMAT.
IEW2008I 0F03 PROCESSING COMPLETED. RETURN CODE = 12.
I realized that in 4 (foreground) option, the link editor appears with an asterisk at the left: "7 *Binder/Link editor" which indicates "No packed data support".
Is the error because of that? What does it mean "No packed data support"? I can access that option with no problem.
Searching I found a link which indicates "An attempt is being made to save a module in a format that is incompatible with the features being used" But I don't know what they mean by the features being used. Is it related to the type of the dataset load in which is supposed to be put when linked? I am lost.
The load module format is very old. The last COBOL compiler from IBM that would generate code that could be bound as a load module is IBM Enterprise COBOL 4.2.x, which is scheduled for end of service on 30-Apr-2022. Even that compiler would generate code that could not be stored as a load module if you used certain compile options, i.e. DLL.
More recent versions of IBM Enterprise COBOL generate code which must be bound as a program object. A program object, while executable like a load module, is very different from a load module.
Load modules are stored in PDSs (Partitioned Data Sets). Program objects must be stored in PDSEs (Partitioned Data Sets Extended).
Ensure the SYSLMOD DD of your bind step (the project.group.LOAD dataset) is pointing to a PDSE. When you allocate it with ISPF 3.2 set the Data set name type to LIBRARY.

Machine parseable error messages

(From https://groups.google.com/d/msg/bazel-discuss/cIBIP-Oyzzw/caesbhdEAAAJ)
What is the recommended way for rules to export information about failures such that downstream tools can include them in UIs.
Example use case:
I ran bazel test //my:target, and one of the actions for //my:target fails because there is an unknown variable "usrname" in my/target.foo at line 7 column 10. It would also like to report that "username" is a valid variable and this is a possible misspelling. And thus wants to suggest an addition of an "e" character.
One way I have thought to do this is to have a separate file that my action produces //my:target.errors that is in a separate output group and have it write machine parseable data there in addition to human readable data on stdout.
I can then find all of these files and parse the data in them in downstream tools.
Is there any prior work on this, or does everything just try to parse the human readable output?
I recommend running the error checkers as extra actions.
I don't think Bazel currently has hooks for custom error handlers like you describe. Please consider opening a feature request: https://github.com/bazelbuild/bazel/issues/new

Cache XMLProvider generated model(s)

Using XMLProvider from the FSharp.Data package like:
type internal MyProvider = XmlProvider<Sample = "C:\test.xml">
The test.xml file contains a total of 151,838 lines which makes up 15 types.
Working in the same project as the type declaration MyProvider is a pain, as it seems the XmlProvider is triggered everytime I hit CTRL+SPACE (Edit.CompleteWord) - and therefore regenerates all the models, which can take up to 10sec.
Is there any known work around, or setting to cache the generated models from XmlProvider?
I'm afraid F# Data does not currently have any caching mechanism for the inferred schema. It sounds like something that should not be too hard to add - if anyone is interested in contributing, please open an issue on GitHub to start the discussion!
My recommendation for the time being would be to try to simplify the sample XML, so that it is shorter and contains just a few representative records of all the different kinds.

How to define and use precompiled variable in delphi directives

I want to define a precompile string variable and use it in {$include} directive in delphi, for example:
{$define FILE_NAME "lockfile"}
{$include FILE_NAME'.txt.1'}
{$include FILE_NAME'.txt.2'}
...
For security reasons (this is part of our licensing system), we don't want to use normal strings and file reading functions. Is there any capability for this purpose in Delphi?
The $INCLUDE directive does not support indirection on the file name. So, the following code:
const
someconst = 'foo';
{$INCLUDE someconst}
leads to the following error:
F1026 File not found: 'someconst.pas'
If you must use an include file, you must apply the indirection by some other means. One way could be to use the fact that the compiler will search for the included file by looking on the search path. So, if you place each client specific include file in a different directory, then you can add the client specific directory to the search path as part of your build process.
FWIW, I find it hard to believe that this will make your program more immune to hacking. I think that a more likely outcome is that your program will be just as susceptible to hacking, but that it will become much more difficult and error prone for you to build and distribute the program.
You requirement may be better satisfied by the proper use of a VCS system. You need "branches" for every customer where customer-specific files contains customer-specific data. This will avoid to litter your code with complex directive to manage each customer - file names stays the same, just their content is different in each branch. Adding a new customer just requires to create a new branch and update files there.
Then you just need get each branch and compile it for each customer to get the final executable(s) with customer specific data built in.

How do I fix 'Setup project with custom action file not found' exception?

I am trying to create a setup project for a Windows Service. I've followed the directions at http://support.microsoft.com/kb/816169 to create the setup project with no trouble.
I want to be able to get a value during the installation in order to update the app.config with the user's desired settings. I added a Textboxes (A) dialog to retrieve the values. I set the Edit1Property property to "TIMETORUN", and in my Primary Output action's CustomActionData property I put in the following: /TimeToRun="[TIMETORUN]\". So far so good. Running the setup I can retrieve the TimeToRun value from the Context.Parameters collection without issue.
In order to locate the app.config I need to also pass in the value of the TARGETDIR Windows Installer Property to my custom action. This is where things begin to fall apart. In order to achieve this, the above CustomActionData must be altered like so: /TimeToRun="[TIMETORUN]\" /TargetDir="[TARGETDIR]\". Now when I run the setup I get the following error message:
Error 1001. Exception occurred while initializing the installation.
System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Windows\SysWOW64\Files' or one of its dependencies. The system cannot
find the file specified.
If you google this problem you will inevitably find people having tremendous success by simply adding the trailing slash to the /TargetDir="[TARGETDIR]\" portion of the CustomActionData. This unfortunately does not solve my issue.
I tried so many different variations of the CustomActionData string and none of them worked. I tried logging to a file from my overridden Install method to determine where the breakage was, but no log file is created because it's not even getting that far. As the error indicates, the failure is during the Initialization step.
I have a hunch that it could be one of the dependencies that the setup project is trying to load. Perhaps somehow something is being appended to the CustomActionData string and isn't playing well with the TARGETDIR value (which contains spaces, i.e. "C:\Program Files\My Company\Project Name"). Again, this is another hunch that I cannot seem to confirm due to my inability to debug the setup process.
One further thing to mention, and yes it's another hunch, could this be an issue with Setup Projects on 64-bit version of Windows? I'm running Windows 7 Professional.
I'll provide names of the dependencies in case it helps:
Microsoft .NET Framework
Microsoft.SqlServer.DtsMsg.dll
Microsoft.SqlServer.DTSPipelineWrap.dll
Microsoft.SqlServer.DTSRuntimeWrap.dll
Microsoft.SQLServer.ManagedDTS.dll
Microsoft.SqlServer.msxml6_interop.dll
Microsoft.SqlServer.PipelineHost.dll
Microsoft.SqlServer.SqlTDiagM.dll
As you may glean from the dependencies, the Windows Service is scheduling a call to a DTSX package.
Sorry for the long rant. Thanks for any help you can provide.
The answer is so maddeningly simple. If the last argument in the CustomActionData is going to contain spaces and thus you have to surround it with quotes and a trailing slash, you must also have a space following the trailing slash, like this:
/TimeToRun="[TIMETORUN]\" /TargetDir="[TARGETDIR]\ "
The solution and explanation can be found here.
Had a similar issue. In my case, it was odd because my installer had ran successfully once, then I uninstalled my app via Add/Remove Programs successfully, did some coding (did NOT touch my CustomActionData string), and rebuilt my project and setup project. It was when I re-ran my MSI that I got this error.
The coding I had done was to bring in more values of more parameters I had been specifying in my CustomActionData string. That syntax for getting the parameter values (i.e. string filepath = Context.Paramenters["filepath"]), which was in my Installer class, was actually fine, but as I found out, the syntax of the later parameters I was now trying to get from my CustomActionData string had not been correct, from the very beginning. I had failed to add a second quote around one of those parameters, so nothing else could be obtained.
I was using the "Textboxes (A)" and "Textboxes (B)" windows in the User Interface section. A has 1 box, EDITA1, where I get the path to a file, and B has 2 boxes, EDITB1 and EDITB2, for some database parameters. My CustomActionData string looked like this:
/filepath="[EDITA1]" /host="[EDITB1] /port="[EDITB2]"
It should have been:
/filepath="[EDITA1]" /host="[EDITB1]" /port="[EDITB2]"
(closing quote on [EDITB1])

Resources