I've used the performance analysis tool in Saxon (https://www.saxonica.com/documentation11/index.html#!using-xsl/performanceanalysis) to analyze stylesheets, and it's quite useful. I'd like to do the analysis from within eXist-db rather than the command line. For one, the performance could be different. But mainly because some stylesheets open documents in exist-db, and I can't run these from the command line. Is there a way to configure Saxon to output the profile.html document when it's run via eXist-db?
I was hoping there would be an attribute in conf.xml , or attributes that could be sent via transform:transform(), but I don't see any options related to the performance analysis tool.
I can't be certain this will work, but it's worth a try.
The $attributes parameter of Exist-db's transform() method allows you to set Saxon configuration properties. The available properties are listed at https://www.saxonica.com/documentation11/index.html#!configuration/config-features . You could try setting the properties TRACE_LISTENER_CLASS (to "net.sf.saxon.trace.TimingTraceListener") and TRACE_LISTENER_OUTPUT_FILE (to the required "profile.html" output file).
Incidentally, note that the performance is going to be different when you run with a trace listener. The profile generated using -TP is useful because it tells you which templates and functions are accounting for the most time and therefore need attention; the absolute numbers are not important or accurate. The hot spots will almost certainly be the same whether you are running within eXist or from the command line.
I can confirm this did work. Here's the XQL I used:
let $params :=
<parameters>
</parameters>
let $attributes :=
<attributes>
<attr name="http://saxon.sf.net/feature/traceListenerClass" value="net.sf.saxon.trace.TimingTraceListener"/>
<attr name="http://saxon.sf.net/feature/traceListenerOutputFile" value="/tmp/profile.html"/>
</attributes>
let $serialization := 'method=html5 media-type=text/html indent=no'
return transform:transform($xml, $xsl, $params, $attributes, $serialization)
Related
I'm developing a SSIS Package that copies contents of specific files to a database. In this package I mak heavy use of the foreach container. Today I came across a strange behavior and have no clue whats wrong. In one of the containers I filter for "VBFA*.txt". But for some reason the container also gets triggered for a file called "VBAP.D2014211.T204008397.R000564.txt". When I change any part of that filename it doesn't trigger the container anymore. Additionally there are plenty of other files that start with "VBAP" and don't trigger the container. What could be the reason for this behavior?
Here is the enumerators implementation:
<DTS:ForEachEnumerator>
<DTS:Property DTS:Name="ObjectName">{6E07E755-700D-4D7D-9550-E08DA5B81264}
</DTS:Property>
<DTS:Property DTS:Name="DTSID">
{f0ceed84-f95c-404c-8794-2eec0155d1a6}</DTS:Property>
<DTS:Property DTS:Name="Description"></DTS:Property>
<DTS:Property DTS:Name="CreationName">DTS.ForEachFileEnumerator.2</DTS:Property>
<DTS:ObjectData>
<ForEachFileEnumeratorProperties>
<FEFEProperty Folder="\\desoswi0204vs\etldata\transfers\out\DP"/>
<FEFEProperty FileSpec="VBFA*.txt"/>
<FEFEProperty FileNameRetrievalType="0"/>
<FEFEProperty Recurse="0"/>
</ForEachFileEnumeratorProperties>
</DTS:ObjectData>
</DTS:ForEachEnumerator>
I've checked the paths contents with dir /x and the short name of my file is wrong. For the file "VBAP.D2014211.T204008397.R000564.txt" the shortname is "VBFA08~1.TXT". The full result is:
01.08.2014 11:02 1.067.169 VBFA08~1.TXT VBAP.D2014211.T204008397.R000564.txt
I have absolutely no clue, what is happening here and how to stop it. This violates every rule I've found regarding the short filename creation. I leave this as the answer for everybody else who is comming accross this beahvior, which is also the case for c# Directory.GetFiles
For some specific purpose, I need to install some fonts on the instances. It comes as no surprise when I choose StartUp Task to accomplish that goal. I've configured the Service Definitions as below:
<Startup>
<Task commandLine="Fonts\InstallFonts.vbs" executionContext="elevated" taskType="simple" />
</Startup>
Nothing special here. Click and run, it failed. However, if I changed the commandLine into a cmd file including just nonsense, namely "echo test", the instance would run without ado. So there must be some issue with my scripting:
Const FONTS = &H14&
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(CreateObject("Scripting.FileSystemObject").GetAbsolutePathName("."))
Set fontFolder = objShell.Namespace(FONTS)
Set rxTTF = New RegExp
rxTTF.IgnoreCase = True
rxTTF.Pattern = "\.ttf$"
Set fso = CreateObject("Scripting.FileSystemObject")
FOR EACH FontFile IN objFolder.Items()
IF rxTTF.Test(FontFile.Path) THEN
IF NOT fso.FileExists(fontFolder.Self.Path+"\\"+FontFile.Name) THEN
FontFile.InvokeVerb("Install")
END IF
END IF
NEXT
The script should come with no error because I've tested it either locally or on Azure via RDP.
Weirdly, when I put it in the startup, the role just won't start. The instance just keeps recycling and at last says "I'm unhealthy". Even if I deprecate the vbs into just one line of code - the first line Const FONTS = &H14&, it just won't start. Even if I wrap the invocation of the vbs into a cmd file, namely to put something like "cscript /B file.vbs", it won't run either.
So I'm concluding that there must be some issue regarding the communication between the script and the Windows Azure monitor. I'm not sure but I think the monitor might take the running script as a failed task. Besides, I'm wondering if there is any timeout for the startup task, which should be the problem though, because the script can guarantee that no UI interaction block the process.
Any idea would be greatly appreciated.
I am sure you must have but just for the sake of confirmation, have you checked that the InstallFonts.vbs file is exported with the package? I mean is the "Copy To Output Directory" is set to "Copy Always/Copy if newer"?
This is pretty much possible that it is not able to locate your file.
You need to write a cmd file as a start up task. In your cmd file, you can call the vbs file using the command line tool cscript.
Azure start up can compile only command line tools.
Oh god, I finally solved the problem.
Although the compiler does quite a good job usually, it allows to use subfolder as a source of command, I mean something like "Subfolder\command.cmd", which will not work always. I've seen examples in which people put whatever we do in cmd in commandLine property, such as "copy fileA fileB" and it really works. But as for vbs, you need to be cautious. Until now I still don't know what's under the cover, but there should be some problem with the path. And the solution is definitely simple, instead of doing the subfolder work for tidiness, just leave the command file in the root folder like most people do:
<Startup>
<Task commandLine="InstallFonts.vbs" executionContext="elevated" taskType="simple" />
</Startup>
And thank you all the same, Kunal. :)
My first question. Please bear with me!
I have an Ant task that need to get some input from the user before proceeding. I use the Input task to achieve this. The input message will contain Swedish characters (eg å, ä and ö) but I am unable to get Ant to output the message properly. I'm testing this using the command line on a machine running Windows 7 Pro English (but obviously using a Swedish keyboard). Example:
<input message="åäö"/>
will output:
[input] Õõ÷
The build.xml is saved in UTF-8 format. If I do 'chcp' on the command line I get "Active code page: 850".
The same result can be seen when doing an echo:
<echo message="åäö"/>
will output:
[echo] Õõ÷
But in the case of the echo task I'm able to do:
<echo encoding="850" message=åäö">
to get the expected output:
[echo] åäö
The input task does however not have an encoding attribute and I'd very much prefer to not have to define an encoding at all, especially not on a per-task level (since I can't tell for sure on what machine the Ant script will be run from).
PS I have additional problems with the received input if it contains åäö and I set the input as a property that is later used in a filter copy task, but I guess that's a whole other question
I can observe the issue on my Polish Windows.
<script language="javascript">
java.lang.System.out.println("default charset: "
+ java.nio.charset.Charset.defaultCharset());
</script>
reports default charset as "windows-1250" while the console operates at "iso-8859-2" (I guess so).
Looks like <input> task uses the default charset thinking it would match the console input. In case it does not, I managed to override the encoding this way:
set ANT_OPTS=-Dfile.encoding=iso-8859-2
ant
In your case I would try to force 850, as it looks like JRE defaults to something else.
This question helped me to find the property name.
It is also important where ant is run from. If I run it from my ide, jedit console plugin, I don't need to override encoding, because I configured it to operate in windows-1250. So it seems to be another workaround, using an IDE.
I am porting a C# program to Linux (using Mono). The only compatibility issues that MoMA has found were all related to printing: P/Invokes of functions from winspool.drv:
ClosePrinter
EndDocPrinter
EndPagePrinter
OpenPrinter
StartDocPrinter
StartPagePrinter
WritePrinter
These are all used in the same class, which prints files (which must be either PDF or PS) by wrapping them in PJL (to set the paper size/tray/orientation) and calling WritePrinter.
I'll need to rewrite this printing logic with non-Windows-specific code. A previous question refers to System.Drawing.Printing, but it seems to be way too low level. I don't want DrawString and DrawImage, I want "print this PostScript file". Is there functionality in Mono to do this?
I ended up using System.Diagnostics.Process to call the lp command.
I am completely new to web services, but not new to Delphi.
I am importing a WSDL file into Delphi 2010 with the "WSDL Importer" wizard. The WSDL file contains some "attributeGroup" tags which Delphi completely ignores, which is presumably a bug, although I haven't yet found an entry on Quality Central for this issue, only mentions in forums like here and here.
My question has several parts:
What is the best workaround?
I have written a Python script to format the WSDL file such that all references to attributeGroup tags are replaced with the declaration of the attributes defined in the attributeGroups; in other words, flattening the references. The output is successfully imported into Delphi via the "WSDL importer" wizard, and looks correct, but I have yet to test whether the messages constructed via this new WSDL file will work correctly. Is this strategy likely to be viable, or should I quit now and move onto something else more productive?
Update
Based on my experiences, and the answers in this question, I decided to go the wrapper route with a C# console application that eats JSON input data and outputs JSON reply data. A Delphi app drives the C# app. The SOAP part of the whole thing is now effortless, and "just works" in C#.NET, and the rest of the functionality is handled well by Delphi. I would recommend this route to anyone else with similar problems. I did try exporting a C# SOAP assembly as a COM library, and connecting to that from Delphi, but it became very complex, because the SOAP specification in my particular app is large and somewhat complex.
Ok, this one took a while.
According to this post, there are certain tags that the .NET wsdl.exe tool just won't recognize when importing a wsdl file. According to MSDN:
attributeGroup: Ignored. DataContractSerializer does not support use of xs:group, xs:attributeGroup, and xs:attribute. These declarations are ignored as children of xs:schema, but cannot be referenced from within complexType or other supported constructs.
This behaviour is also described (albeit in a very hard-to-understand manner) on one of the MSDN blogs. In my specific case, the particular part of the wsdl file causing the problem looks like this:
<xs:complexType name="PhonesType">
<xs:annotation>
<xs:documentation xml:lang="en">Provides detailed phone information.</ xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Phone">
<xs:annotation>
<xs:documentation xml:lang="en">Used to pass detailed phone information.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attributeGroup ref="TelephoneInfoGroup"/>
<xs:attributeGroup ref="ID_OptionalGroup">
<xs:annotation>
<xs:documentation xml:lang="en">The ID attribute in this group is a unique identifying value assigned by the creating system and may be used to reference a primary-key value within a database or in a particular implementation.</xs:documentation>
</xs:annotation>
</xs:attributeGroup>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
It seems that the <xs:attributeGroup ref="TelephoneInfoGroup"/> is being ignored by the .NET wsdl.exe tool, just like it was being ignored by the Delphi wsdl importer. In such a situation, where importing fails in both Delphi and .NET, the wsdl file probably has to be changed, and that means I will have to use my home-made python ref-flattener after all.
We had a similar problem with Delphi 2009 and a standard Soap service (CRM). It was not related to attributeGroup. We found so many incompatibilities that we finally decided to use a small C# application as a proxy for the real .Net based service.
I was the poster of the first reference you give. I think I found out that this bug has never been fixed.
I later posted another question on the Embarcadero Developer Network where Nick Hodges said that
We are concentrating on client development [...] if you are looking to build SOAP servers, then I'd suggest that you also give Delphi Prism a look.
We decided to switch to C# for development of our SOAP servers. I decided to let the service talk to a database, which is then accessed by our Delphi application.
Later I ran into problems with client development under Delphi as well, so we're doing that in C#, too. This time the C# class is com visible and can be accessed from Delphi. Seems to work fine.
Regards, Miel.
The Delphi WSDL importer can't handle <xsd:attributeGroup ref="..."> elements, but you can replace those with the actual attributes that are referenced, which the importer can deal with.
Below is a PowerShell script that does this replacement.
The script is unpolished. It's just what I created for my own needs. It may work for you too, or at least it should give you a starting point.
$xsdPath = "E:\scratch\InputFile.wsdl"
# Note: Must be full path.
$outPath = "E:\scratch\OutputFile.wsdl"
$xsd = [xml](gc $xsdPath)
$ns = #{xsd="http://www.w3.org/2001/XMLSchema"}
$attrGroupDefs = $xsd |
Select-Xml -Namespace $ns -XPath "//xsd:schema/xsd:attributeGroup" |
select -ExpandProperty Node
$attrGroupRefs = $xsd |
Select-Xml -Namespace $ns -XPath "//xsd:complexType/xsd:attributeGroup" |
select -ExpandProperty Node
$attrGroupRefs | % {
# the thing to be replaced
$ref = $_
$refParent = $ref.ParentNode
$namespace, $name = $_.ref -split ":"
$attrs = $attrGroupDefs | ? name -eq $name | select -ExpandProperty attribute
# remove the reference
$refParent.RemoveChild($ref)
# add the actual definitions
$attrs | % {
$newNode = $_.CloneNode($true)
$refParent.AppendChild($newNode)
}
}
$xsd.Save($outPath)