g tsuji

Ranch Hand
+ Follow
since Jan 18, 2011
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by g tsuji

@AnkitaS Singh
If you said using xsl, you mean the umbrella technology of w3c xslt->xsl-fo->pdf and its demonstration implementation fop or other commercial implementations, you have to take a deep look into the user-configuration file and also more importantly the generation of metric file(s) to use with the process. That's all I can tell you for a question phrased like that.
If we stick to method akin to dom childNodes() method where in JDom2 it would read as children() method, you have to successively go deeper in level. In this case, go twice in depth. This is how you can do that.

In a sense, you can do it more directly without explicitly spelling out the detail of traversing level-by-level... In dom there is getElementsByTagName() method and there is also xpath as a derivative technology. In JDom2, it takes form in Filter class and its sub-classes. This is how you can proceed with the ElementFilter.

Now you have two methods to do it.
2 weeks ago
Sorry, typing to carelessly! my apology Paul Clapham.
Upon re-reading the question posted, I think maybe the straight contiguity of tables after note may not be the essential condition for the processing... In that case, Paul Chapman's proposal is probably the simplest and neat solution to get by - bravo. The proper syntax is not far, it is written like this:
It is not exactly simple, no. The main thing is one should focus on doing the pertinent abstraction of what the structure actually is essential to the progression of the template flow that serves your needs, and then apply correctly the functionality available to xslt. Here is one of the ways of how you can do it. The mode attribute serves only as an indicator for regrouping some templates that is meant to work together for the purpose. It also involves a recursive match to the template for table... And I suppose the prefix fc is well declared.

The apply-templates part of your code is fine up to the select='note' which I add a mode to make it clear that some special processing design happens. You take out the line for select='table':

Then you set up the templates for "note" which in turn call the template for "table", all in the same mode "special".
I am not going to bring light to any of the doubt you may have along the study. I can't read because I think the presentation of the problem is fundamentally flawed. But I like to let you know that it is not the proper way to do an abstraction of an xml the way you show. Every element has its own indexing as to its positioning in the the node tree. That is generic, it is; but it is not its characteristic premier. Its characteristic premier is its name. Its position in the tree is taken care of by the parser such as our eyes as well as the software parsers. It is the called the documentary order. It would be unique. But the name, it is not at all unique. parent1child1, parent1child2 as names are rendering all names unique (in fact a way of saying the position in the documentary order is unique - it does not help to saying that twice and it is redundant). A schema's construction will be reflecting the same. If you do parent1child1, parent1child2, the schema would be radically different for pt->(x,y) as <pt><x>...</x><y>...</y></pt> from pt->(x,x) as <pt><x>...</x><x>...</x></pt>. In schema, they are radically different. In jaxb, the same generically different. Hence, if you want to investigate what jaxb will do for you and/or how to make a schema out of an instance of xml, you should change the way you make abstraction of it. It will confuse the machine as well as yourself because the information so abstracted out is not the right information one needs.

    nodeLst = doc.getElementsByTagName("cfdi:Traslado");

    for (int s = 0; s < nodeLst.getLength(); s++) {
      if (s == nodeLst.getLength() - 1) {
        Node fstNode = nodeLst.item(s);

        if (fstNode.getNodeType() == Node.ELEMENT_NODE) {
          Element fstElmnt = (Element) fstNode;
          if (doc.getElementsByTagName("cfdi:Traslado") != null) {
            System.out.println(fstElmnt.getAttribute("Importe") + "|"
                + fstElmnt.getAttribute("TasaOCuota") + "|"
                + fstElmnt.getAttribute("Impuesto"));

Look at this block of code where you want to find the data you said you want.


if (s == nodeLst.getLength() - 1) {
   // etc etc

That mean you don't want to get all but you want to get only the last element cfdi:Traslado. That is a contradition. Take the test out.


if (fstNode.getNodeType() == Node.ELEMENT_NODE) {
    //etc etc

This test is absolutely unnecessary. getElementsByTagName is getting "element", nothing else. The resultant node list contains only node, if any, of type Node.ELEMENT_NODE.  The conditional is alway true. Take out the if statement and keep the content. And that means also the casting (Element) will not pose any problem at all.


if (doc.getElementsByTagName("cfdi:Traslado") != null) {
    //etc etc

Again, this is absolutely unnecessay. You must get something already to get to that stage. Beside, even if getElementsByTagName gets nothing, it will return all the same a NodeList, only that it is empty, that's all. The return is not null in any case. So again take out the if statement and keep the content.

[4] Now the part of namespace mentioned several times already. This is the point: if you use getElementsByTagName() with tag name prefixed, hence containing a characteristic colon (:), that prefix must _exactly_ match what is used in the xml doc, hence, you make a rigidity out of non-generic and flexible part of the specificiation. You can do it once for a while, but that code would not be robust. As far as you code is concerned, you can keep it this time and get the results until further revision.

[4.1] But if you want to use the more proper approach as mentioned a couple of time, the line would look like this.

But... You cannot simple do this. You have to make the builder factory namespace aware beforehand in order to use it, otherwise, it won't do. That means you have to do this as well.

And then it is good to use the namespace aware version of getElementsByTagName(), that is getElementsByTagNameNS() method.

That is all you need to do.
If the schema is itself already incorrect, it would be misleading to speculate on the resultant of code generation by schema compilation. The schema on the element ABC could not be correct. How about you correct the schema first before considering anything else?
1 year ago
I notice you actually call the id serial, so you replace setId() and getId by setSerial() and getSerial(). That's all you need to accommodate modulo other possible details...
1 year ago
@Mart Zarate
For such kind of "auto" incremental data (or in a way "unique") identifier id, one of the natural source is acquiring from some db's indexing mechanism... if the data object at some stage of the business logic is fetching and persisting through some db. If the service does not keep track of data through some db, it can be done more naturally through the marshaller's listener, in particular, through its beforeMarshal method, so that the number will be adjusted before the object model actually marshalled to an xml. In this sense, the marshaller in question acquires some "state" and that state will in turn guide the specific data incremental following the marshaller's processing "history" during the same session.

It sounds abstract. Concretely you do it like this. Suppose "marshaller" is the instance created via the JAXBContext instance during a specific session, or simply put, your code block to be executed by the application. Suppose your object model's root is called Message.class whereas your incremental id is encapsulaed in the AWBNumber.class (certainly through some customization...) as what you posted suggests. Then you set up your marshaller's listener like this.

Then it is good to go to be used marshalling your object model with Message class exactly as you've coded thereafter.
1 year ago
If you look at the posted xml, you can discover id for the symptom-category appears exactly like this:
whereas if you copy-and-post it to a text editor, it would appear like this:

Now, the particle 8A (in the place of ?\) appears everywhere in the @id, more specifically at the beginning of 2nd component of it after the hyphen. For instance, the first symptom's id is read like this:
See the appearance of 8A?

You've to check what happens to the symptom-category's id, using any hex32 editor, to check at byte-level, how is it encoded?
Does it not matter if you happen to close symptom-category twice, as you can see what you posted yourself ?...
Your portType seems to be in namespace http://customer.services.ws.m2m.airtel.com which is defined in the wsdl:import part. You've only shown the xsd but not the wsdl... How does it look like? Also how do you code your client?
1 year ago
Very well, but what have you done for the purpose so far?
Mind the WAS versions, it could be different in "another server". More up-to-date may not necessarily be better, there could be errors due to regression such as this:
1 year ago