We are maintaining an application that heavily relies on DOM4J and Xpath. Once in a while we see a strange behaviors with results of XPath execution via DOM4J: The text result would simply be truncated.
We tried applying the recommendation provided here: http://www.mail-archive.com/dom4j-user#lists.sourceforge.net/msg02688.html
It seems the problem occurs less frequently but it still manifests itsself. Last time we got it, it was after applying Xpath on a the clone of a document parsed as indicated by the previous link.
This also seems to be similar to the issue mentioned here: Use of text() function when using xPath in dom4j
Related
How to convert the below Relative path to TestCafe Selector?
//a[contains(#name,'indent')]/parent::div//span[contains(text(),'Follow')]
If I try the above one, it recognizes specific DOM Component which contains multiple elements and one of those is 'Follow'.
how to achieve this using TestCafe Selectors.
I did not succeeded with the below one :
Selector('a').withAttribute('#name','indent').parent('div').child('span').contains('Follow')
Selector('a').withAttribute('#name','indent').parent('div').child('span').withText('Follow')
I checked your code and found a couple of possible causes, which can lead to the issue.
TestCafe Selectors do not have the contains method so the first example is incorrect.
Though I don't know your html structure, I can currently assume that there is no need to pass the # char in the attribute argument.
Thus your second example looks valid excepting the # char.
If this recommendation does not help, please provide us with a working example that shows the issue and create a separate bug report in the TestCafe repository using the following form
When my scala-js code throws an error, I'd like to send a sensible stacktrace back to my server to put in the logs. By "sensible stacktrace" I mean something that gives the Scala methods, filenames, and line numbers rather than the transpiled javascript code.
I've made good progress by getting the source map and using the Javascript source-map library (https://github.com/mozilla/source-map) to translate each element of the stacktrace from javascript to the corresponding Scala code.
My issue: I need the column number of the javascript code that threw the error but don't see how to obtain it. Printing a StackTraceElement gives a result similar to
oat.browser.views.query.QueryRunView$.renderParamsTable$1(https://localhost:9443/assets/browser-fastopt.js:34787:188)
I need the "188" at the end of the line but don't see how to get it other than calling toString and parsing the result. Looking at the StackTraceElement code, the column number is a private variable with nothing in the API to access it.
Is there another approach to this that I'm completely overlooking? Anything built into scala-js that converts a javascript stacktrace to a Scala stacktrace?
I subsequently found the StackTraceJS library which does what I needed. I combined a ScalaJS facade for it with a facade for JSNlog to come up with a package that meets my needs pretty well. See jsnlog-facade. It logs to the browser console and/or the server, with Scala stack traces. Demo code included.
There is nothing in the public API to access the column number because this is a Java API, and Scala.js cannot add public members to Java APIs.
To work around this issue in the case of StackTraceElement, we export getColumnNumber(): Int to JavaScript. You can therefore use the following code to retrieve the column number:
def columnNumberOfStackTraceElement(ste: StackTraceElement): Int =
ste.asInstanceOf[js.Dynamic].getColumnNumber().asInstanceOf[Int]
Note that this "feature" is undocumented, and might change without notice in a future major version of Scala.js. If it disappears, it will be replaced by something reliable. In the meantime, the above should get you going.
I cannot work out where this doco might be - i'm assuming they do have something on it. I realise this is a dead simple question, but no amount of searching is bringing this up for me.
Bing/DuckDuck etc search cannot find anything particularly relevant, and the only w3c.org links I followed went to "functions", which apparently "select" isn't.
EDIT (Apologies for ambiguity) I am looking for the definition of something along the lines of :
<xsl:variable name="variableName" select="some/path/here" />
That is an XSLT variable. Like many other XSLT elements, it has a select attribute that takes an XPath expression as a value. The value of this attribute just typically happens to be an XPath expression, but the attribute itself isn't directly related to XPath, so you won't find it documented in the XPath spec.
You code fragment is in XSLT, so the specification you want is either "XSLT 1.0" or "XSLT 2.0", which you can find very easily by using these as Google search terms. The value of the select attribute is an XPath expression, so you may also want the XPath 1.0 or XPath 2.0 specification; these can be found the same way.
I've got a bunch of XML messages in a PostgreSQL 9.1.3 table, with a column content of type XML). They're not all the same "type", so I'm trying to extract the root type using a query like this:
SELECT xpath('name(/*)', content) FROM message;
as recommended by this answer to a similar SO question.
A sample message is:
<?xml version="1.0" encoding="UTF-8"?>
<WML version="6" xmlns="http://example.com/schemas/WML">...</WML>
For which case I'd hope to get the result '{WML}'. Unfortunately it just returns an empty array. Adding the namespaces parameter to xpath, or removing the namespace from the message, does not help.
A discussion on the PostgreSQL mailing lists seems to explain it as a bug in XPath handling in PostgreSQL. However that was in 2008, and a look at the PostgreSQL source shows that piece of code was changed in 2009. I'm not a PostgreSQL developer so I'm not confident that the bug is or is not a factor in my case.
But I'm wondering if there's a workaround, such as an alternative XPath expression that might work? I'd prefer not to have to resort to regular expressions to parse XML, though if you can suggest a short, punchy, robust RE then it would be better than nothing.
Clearly, this has not yet been solved as of June 2011.
I found this thread on pgsql-hackers that describes your problem exactly.
I don't know of a workaround for older versions, but this is fixed in PostgreSQL 9.2, so that's great.
(The likeliest workaround would likely to have been to write a function to parse the XML manually, but I'm glad I don't have to resort to that now!)
i have this Problem with my test ..the
driver.findElement(By.xpath("//html/body/div[2]/div/div/div[2]/div[2]/div/div[2]/div/div/div/div/div/div/div/ul/li[2]/a[2]/em/span/span/span")).click();
don't find the element.
the eclipse show this message of error
Cannot locate a node using
//html/body/div[2]/div/div/div[2]/div[2]/div/div[2]/div/div/div/div/div/div/div/ul/li[2]/a[2]/em/span/span/span
EDIT : Post edited to reflect answer to actual problem. Original answer follows.
Long XPath expressions are fragile, and tests are prone to fail when relying on them : a completely unrelated change somewhere else in the document can mess everything up, and even if you're aware of the problem, the tests' code is just harder to maintain.
In this particular case, since the site is generated by GWT, it's even worse - there is little control over the actual HTML changes. A good solution when using GWT is to use the ensureDebugId method (see link in comments).
Are you sure that this XPath expression is correct ? Does other tests work with this driver ?
I'd recommend avoiding the use of long XPath expressions like that - wouldn't it be safer in the long term to start the expression at an id-specified div somewhere in the page rather than at the root of the DOM ?