I am attempting to get the count of the //Root/Record elements using spring integrations int-xml:xpath-header-enricher. It comes back zero regardless of the document passed in.
You have to configure your XPath expression like this:
<int-xml:xpath-expression id="countExpression" expression="count(//ns:Ephemeris/ns:Record)"
ns-prefix="ns"
ns-uri="http://www.sandia.gov/pgmm/Ephemeris"/>
And have it as a reference from the <int-xml:header> instead.
The problem is that your root element in the XML comes with the xmlns="http://www.sandia.gov/pgmm/Ephemeris", so, there is no other way unless we honor namespaces in your source XML. For this purpose we introduce artificial prefix, even if your source XML does have then. We need that in XPath to properly distinguish elements based on some namespace.
I think default DocumentBuilderFactory just doesn't honor namespaces making your possible XPath expressions much horrible when it comes to several namespaces support.
Related
In the documentation, Gorilla/schema says that you must specify the schema reflection tag to unpack the struct. I've seen it unpack when I don't have the schema tag, for example when I just am using the json tag.
When the schema tag isn't specified what does Gorilla do under the covers? Does it look at other tags or does it do a case-insensitive match? Is there a huge performance hit as a result of not specifying the schema tag?
EDIT: Specified/linked package
For others searching for this answer -
This package has the ability to use any tag. The default is schema (which is initialized here). To change the tag it's searching for, use decoder.SetAliasTag("json"). While I think the fallback logic is around this function, I'm not totally certain what the performance hit really is from not explicitly setting a different tag.
So this may be a more general question, but I feel it needs to be asked.
Time and time again I come across examples on Camel's documentation pages where I say "that's exactly what I want!... but it's in Java not Spring. How the heck do I convert it properly?"
So my question is: What is the rule of thumb for converting things?
Is there some conversion guide out there?
For example, I wanted to append a \n to the end of each line as the data comes through a socket into a file using the Netty4 component.
I see an example such as .transform().body(append("\n"))
How would I interpret that as Spring, to put in my Spring-based route?
Maybe this is just a thing that a person new to Camel struggles with and once you get the hang of it you can see the obvious answer. But I feel like I can't be the only one who's thinking this about the examples out there.
It seems like a lot of Java -> Spring conversion can be done in a 1 to 1 ratio, but that's not all the time.
Well, the mapping isn't straightforward and there isn't a 1-to-1 mapping available - generally, a Java DSL method invocation will in most cases translate to a tag in Spring XML DSL but the position of that tag is not always the same - in some cases Java DSL method invocation chains translate to tags being placed on the same level, sometimes (e.g. idempotent consumer) the chain translates to child tags of the first invocation.
I guess that the mapping was done this way because XML and Java are two very different languages and making the mapping 1-1 would have crippled the expressiveness of at least one, if not both, DSLs.
My advice would be to always import the XML schema and rely on your IDE's auto-completion and the documentations from the schema itself and Camel's online documentation.
You can run your camel context via mvn camel:run goal and then use a JMX client to connect to that process. There is an mbean in camel which provides a method called dumpRoutesAsXML or similar. Invoking that one will give u the xml equivalent of your context. But keep in mind that it only prints the routes and all stuff out of routes is discarded.
Hope that helps,
Lars
I've been using Ruby Selenium-Webdriver for one of the automation scripts I'm developing and I'm being asked to use Page Objects, we use page objects a lot however for this application I am using CSV file instead, I have defined all the xpaths that I'm using in my application in a CSV file and I'm parsing that CSV file in my script to refer to those objects, I would like to know is there much of a difference in using a class for defining Page Objects or using a CSV file instead apart from performance concern? I believe using a CSV file will be an addon for us from configuration standpoint and will make it much easier to maintain, any suggestions on this?
Edit - In our use case, we're actually automating applications built on a cloud based tool, so basically all the applications share same design structure from HTML standpoint so we define xpath patterns in CSV and then we pass certain parameters to some custom methods that we've developed to generate xpath's automatically using the CSV instead of finding those manually as its overhead for us because we already know that all the applications will share similar xpath pattern for all elements.
Thanks
I think, POM is better than CSV approach. In POM, you put elements for a page in a separate class file. So, if any change is to make then it's easier to find where to change/maintain. Moreover, it won't get too messy as CSV file and you don't need to use extra utility function to parse those.
There is also a pageobjects gem that provides a set of libraries over and above webdriver/watir, simplifying the code.
Plus, why xpaths? Its one of the last recommended ways to identify an element.
As for the frameork aspect, csv should be more of a maintenance problem than PageObjects. Its the basic difference between text and code. You enforce Object oriented approach on your elements in PageObjects but that is not possible with csv.
In the best case scenario, you have created a column/separate sheets defining which page that element xpath belongs to. That sounds like an overhead. As your application / suite grows there can be thousands of elements. Imagine parsing/ manually updating a csv with that kind of data.
Instead in PageObjects, your elements will be restricted to the Page. Any changes to the app will also specify which elements may get impacted. Now, when define your element as an object in PageObject, rather than css, you also dont need to explicitly create your elements by reading the csv.
It completely depends on the application and the type of test you might perform.
Since it is an automated test script, you do not have to really worry about the performance of the script (it might take few more milli seconds to parse, which should be OK).
Maintaining all the elements identification properties & corresponding actions in a CSV file will make the maintenance easier and make the framework application independent which are nice. But maintaining your framework is bit difficult to make it more robust. Both approaches have its own pros and cons.
Refer to below posts [examples are in java - but you will get the idea]:
Keyword driven framework
Advanced Page Objects
Update:
If you like both, you can comeup with your implementation to easily integrate these too.
#ObjectRepository(src="/login.csv")
public class LoginPage{
private Map<String, WebElement> elements;
public void login(){
elements.get("username").sendKeys('');
elements.get("password").sendKeys('');
elements.get("signin").click();
}
}
Ie, define all the elements in a config file like csv/json etc. Let the page object refer to the class for the page elements. All the methods will be part of the page class.
My project was using Saxon 9.0.0.2. I am trying to upgrade to Saxon-HE 9.6.0-6.
XPathEvaluator#setBackwardsCompatible(boolean)
this method no longer exists in 9.6.0-6.
I commented that line in my code, but when running i am getting following error:
net.sf.saxon.trans.XPathException: A sequence of more than one item is not allowed as the first argument of name() (<xs:element/>, <xs:element/>, ...)
at net.sf.saxon.expr.Expression.typeError(Expression.java:1123)
at net.sf.saxon.expr.CardinalityChecker.evaluateItem(CardinalityChecker.java:295)
at net.sf.saxon.functions.NameFn.evaluateItem(NameFn.java:52)
at net.sf.saxon.functions.NameFn.evaluateItem(NameFn.java:23)
at net.sf.saxon.expr.Expression.iterate(Expression.java:448)
at net.sf.saxon.xpath.XPathExpressionImpl.evaluate(XPathExpressionImpl.java:192)
at net.sf.saxon.xpath.XPathEvaluator.evaluate(XPathEvaluator.java:239)
at jlibs.examples.xml.sax.dog.engines.SaxonEngine.evaluate(SaxonEngine.java:72)
at jlibs.examples.xml.sax.dog.TestCase.usingDOM(TestCase.java:71)
at jlibs.examples.xml.sax.dog.tests.XPathConformanceTest.run(XPathConformanceTest.java:44)
at jlibs.examples.xml.sax.dog.tests.XPathConformanceTest.main(XPathConformanceTest.java:73)
looks like, if name function throws this when the argument contains sequence of more than one element.
it used to work perfectly fine.
How to make it work without changing my xpaths.
Saxon now offers two APIs for XPath evaluation: the JAXP API and the s9api API. Saxon's implementation of the JAXP API has moved towards conforming as closely as possible with the JAXP specification, including dropping of extensions like the setBackwardsCompatible() method. However, XPathEvaluator allows you to access the StaticContext using getStaticContext(), and this has an option setBackwardsCompatibilityMode() which should restore the old behaviour.
Alternatively, there is also a method setBackwardsCompatible() on the s9api XPathCompiler class.
If you want to take advantage of XPath 2.0, you will probably want to move to the s9api interface, as JAXP has no support for the richer type system of XPath 2.0.
I'm writing a feature to produce CSV snapshots of screen data.
I need this to be data-driven. Thus I need to avoid hard-coding each snapshot in Java, but rather load it from a data source such as an XML file or a database. The data is contained in Java beans.
I'm using SuperCSV with the Dozer extension both at 2.1.0.
This combination seems perfect since I can code the mappings from the beans to the columns in Dozer XML mapping files.
This works well for the data, but I have not found a way to specify the strings to use for the CSV's column headers other than to hard-code them in Java as is done in all of the examples and test cases I've looked at. That is not data-driven.
Is there a way for me to code the column headers in the mapper file. Or even to extract them from the mapper file, construct a List and pass them to the writerHeader() method?
I think it would be OK to just use the bean property names as the headers, although ideal situation is that I am provided some additional meta-data notation in the XML's <Field> tag that specifies the header.
I'd have posted this on SourceForge, but I'm getting a 500 error there.
I'm a Super CSV developer. You're the first person I've heard of who's using CsvDozerBeanWriter with their own DozerBeanMapper - great to hear that feature is useful :)
So what's the goal of being 'data driven'? It sounds like you want your code to be really generic, so you can alter the CSV just by changing the XML. Is that right? Of course, you can't configure the cell processors dynamically...or are you trying to do that too!!??
I'd take a look at the MappingMetadata API of Dozer, which you can access by calling getMappingMetadata() on the DozerBeanMapper. I've never used it, but it looks like you could derive the column names this way (though you'd probably be limited to the field names).
Otherwise, you'll have to parse the XML file yourself (I'd probably use XPath). You'd have to do it this way if you want to use some other metadata in the XML for the column name.