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
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by g tsuji

    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

this example from http://stackoverflow.com/questions/15948927/working-soap-client-example
is working good,...

I can only comment on the code shown: I am not so sure, and I don't think so. The SOAPAction would not and could not be set that way. It is not an ordinary MimeHeader. It can be set via the Dispatch object. Setting MimeHeader(s) via SOAPMessage won't help in that regard. So if it (or anything) works, it works probably because of some other code not shown.

..., BUT first 2 variant returned error

The error is what sends back from the server. They are by themselves not capable of that kind of "error". If eventually what is dispatched without the correct SOAPAction, and that in consequence the server does not know what operation to dispatch to, the server could send you back fault code as that. But all these are caused by the dispatching and invoking code, unrelated to the construction of the SOAPMessage as request, I think, as I don't see the whole picture.
1 year ago
The package javax.xml.soap provides extensions to org.w3c.dom to help control of many aspects of the message which are not considered generic or universally significant to an xml compliant to the recommendation. They help coders to simplify certain non-generic manipulation much easier than otherwise available directly to xml processing in general. For instance, the choice of prefix should not be a generic thing one may be concerned of, say a choice of default SOAP-ENV (for soap 1.1) or env (for soap 1.2) should be 100% comfortable for anyone than a choice of soap - but it does not mean the library necessarily intends to dictate and force these choices upon you...

The things you're asked can be done relatively easily with javax.xml.soap packages.

- how to addition this information in begin
<?xml version="1.0" encoding="UTF-8" ?>

The SOAPMessage class provisions two fields that you can set at your discretion. One of them is WRITE_XML_DECLARATION, defaulted to "false". You can add this line after establishing SOAPMessage object.

- deleted "-ENV"

You actually mean in general to change the default choice of "SOAP-ENV" to "SOAP", or, in fact, could mean to change to any other prefix for the matter.
You can do it by a method setPrefix() inherited from org.w3c.dom interface but you have to apply the method inherited from SOAPElement removeNamespaceDeclaration() to eliminate the original namespace declaration left over and rendered useless, hence a cleanup is probably more elegant rather than straightly necessary. You have to do on every wrapping element proper to SOAPMessage: Envelope, Header and Body. Like this.

and you're done. There are other ways to do this as well at different stages of the process of invocation but those may be way too complicated conceptually and code-wise to entangle the issue directly.

...and deleted "<SOAP-ENV:Header/>"

Here you sometimes have to be careful on dealing with Header. Within the package when an instance of SOAPMessage is created, an empty Header element is automatically created. This may not be the case for other libraries... Having said, soapHeader is never null in this approach and you can spare the control of it. To eliminate the optional Header, you simply do this.

That's it as simple as that and it is also documented in the documentation.
1 year ago
Also I just notice that you want request to be child to GetParameter, you have then to change this line.
1 year ago
Those are not properly speaking "attribute". An SOAPElement may live in certain namespace or in a null namespace... That is what happens for GetParameter, request, MonCode etc...

Note also that the re-use of bodyElement, paramsElement may cause confusion at times... I can't say it is absolutely discouraged, but certainly not encouraged, as long as you can keep them on track - it is up to you.
1 year ago
The previous pattern conceptually is to eliminate the last particule together with the separator colon... If you want alternative view point, namely, pro-actively keeping the first two particules, you can do this.

With these two perspectives, maybe most cases will be covered according to your need.
1 year ago
Simply this unless you really want to have some control or validating at the level of the input string.
1 year ago