As Jake pointed out Xerces-J 1.2.0 is ancient. It was released over 12 
years ago. It's unlikely that you'll find anyone here who still uses it or 
remembers how it behaves. It is more likely that someone would respond to 
your questions if you were using a recent version.

Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org

karthikeyan...@polarisft.com wrote on 01/11/2012 11:53:37 AM:

> Hi jake,
> Thanks for the reply.
> But we want to know whether it is an issue in 1.2.0.
> Only if we make sure that is an issue in xerces 1.2.0 itself ,  only 
then
> we can take steps to move to the latest version.
> Thanks,
> karthik.
> 
> 
> 
> From:   "Jacob Kjome" <h...@visi.com>
> To:   <j-users@xerces.apache.org>
> Date:   11/01/2012 09:15 PM
> Subject:   Re: Xerces clone node issue in  production environment (Multi
>             threaded). Help needed ...
> 
> 
> 
> 
> If you are using Xerces 1.2.0, then you are using an ancient version... 
of
> Xerces1.  That hasn't been actively developed for many years.
> 
> You should upgrade and see if your issue exists in the latest release of
> Xerces2, which is version 2.11.0.
> 
> 
> Jake
> 
> On Thu, 1 Nov 2012 18:44:27 +0530
>  karthikeyan...@polarisft.com wrote:
> >
> > Hi Xerces users,
> >
> > Greetings!.
> >
> > We have an issue in the xerces parsers and specifically in cloning a
> > node.We browsed in apache's site and bugzilla to find if anyone had
> > reported any issues or bugs relevant to the one we are facing in our
> > production environment.
> >
> > We were able to find info about few issue that were reported already 
and
> > that is more or less similar to the one we are facing now.
> >
> > Let me brief out the environment wherein we are facing this issue.
> >
> > OS: Sun Solaris 10
> > Server: Websphere 6
> > JDK: 1.4
> > Xerces version: Xerces_Version_1_2_0
> > Number of Daemon threads per JVM: 3
> >
> > Scenario:
> >
> > In our Production environment when 3 daemon threads run under a JVM.
> >
> > When 3 similar type of XML messages gets parsed at same second
> > (concurrently) under a JVM, we notice some attribute gets missed.
> >
> > Here is sample XML that gets parsed.
> >
> > <?xml version="1.0"?>
> > <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
> > <InTemplate>
> >  <Header>
> >    <DataDictionary>
> >      <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
> > CFCType="TYPE_STRING"/>
> >      <element XMLName="ProcessingLoc" CFCName="PR_LOC"
> > CFCType="TYPE_STRING"/>
> >      <element XMLName="ServiceType" CFCName="FCO_TYP"
> > CFCType="TYPE_STRING"/>
> >    </DataDictionary>
> >  </Header>
> >  <Body>
> >    <DataDictionary>
> >      <element XMLName="TxnUID" CFCName="TRAN_NO" 
CFCType="TYPE_STRING"/>
> >      <collection XMLName="TxnIdentification"
> > CFCType="TYPE_FIELDCOLLECTION">
> >        <element XMLName="Sequence" CFCName="BSI_SEQ"
> > CFCType="TYPE_STRING"/>
> >        <element XMLName="TxnType" CFCName="PYMT_TYP"
> > CFCType="TYPE_STRING"/>
> >        <element XMLName="AcctNumber" CFCName="ACCT_NO"
> > CFCType="TYPE_STRING"/>
> >        <element XMLName="CCY" CFCName="ACCT_CCY_COD"
> > CFCType="TYPE_STRING"/>
> >      </collection>
> >      <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
> > CFCType="TYPE_STRING"/>
> >      <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
> >      <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
> > CFCType="TYPE_STRING"/> ( line no 20)
> >      <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
> > CFCType="TYPE_STRING"/>
> >
> >      <element XMLName="Reference" CFCName="MT942_REF_NO"
> > CFCType="TYPE_STRING"/>
> >    </DataDictionary>
> >  </Body>
> > </InTemplate>
> >
> > Intially, we faced something like the whole attribute in one of the 
child
> > nodes in XML itself gets missed .( like the one highlighted above in 
the
> > sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined 
gets
> > missed).The returned XML doc is with out the 'CFCName' attribute and 
it
> > looks  something like
> >
> >        <element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line
> no  20)
> >
> >
> >
> > To fix this we placed the following code
> >
> >
> >        *       Parameters:
> >        *               iNode - source
> >        *               deep - If true, recursively clone the subtree
> under
> > the specified node; if false, clone only the node itself (and its
> > attributes, if it is an Element).
> >        *       return:
> >        *               copy of source ( xml document that was parsed)
> >        */
> >        private Node cloneNode(Node inNode, boolean deep){
> >
> >                //      clone current input node
> >                Node outNode = inNode.cloneNode(deep);
> >                outNode = getRenderer().getOutDocument().importNode
> > (outNode,true);
> >
> >                // put back attr.
> >                if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
> > inNode.hasAttributes() ){
> >
> >                        NamedNodeMap attrMap = inNode.getAttributes();
> >                        Attr attr = null;
> >                        Attr outAttr = null ;
> >
> >                        for ( int i=0; i<attrMap.getLength(); i++ ){
> >                                attr = (Attr)attrMap.item(i);
> >                                // only append deleted attr.
> >                                if 
((((Element)outNode).getAttributeNode
> > (attr.getName())) == null ){
> >                                        outAttr = getRenderer
> > ().getOutDocument().createAttribute(attr.getName());
> >                                        outAttr.setValue( attr.getValue
> > () );
> 
>                                        ((Element)outNode).setAttributeNode
> 
> > (outAttr);
> >                                }
> >                        }
> >                }
> >                return outNode;
> >        }
> >
> > Even after that , we faced another issue ,but this time the value of 
the
> > attribute(CFCName) gets missed or it is empty like the one shown below
> and
> > not the whole attribute as we faced before.
> >
> >
> > The xml after the attribute value missed looks something like
> > <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> 
[Here u
> > can see the CFCName attribute value is empty (null)]
> >
> >
> > We are clueless about this and the most disheartening thing is that we
> are
> > not able to  reproduce this behavior consistently and this occurs
> probably
> > once in 5-6 months in our environment.We tried different ways with the
> > threads  in our IDE to reproduce but everything ended in vain.
> >
> > The below issue reported in the following link is more or less similar 
to
> > the one we are facing, but we are not able to see the whole mailing
> thread
> > conversation from the site and hence seeking xerces users who reported
> this
> > already to sort this out for us.
> >
> > Clone node issue
> >
> > Bug getOwnerElement for cloned attributes
> >
> >
> http://mail-archives.apache.org/mod_mbox/xerces-j-users/
> 200102.mbox/%3c3a843476.8a614...@us.ibm.com%3e
> 
> >
> >
> >
> > [Bug 937] Changed - cloneNode empties Attribute nodes
> >
> >
> http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%
> 3c200103121958.laa00...@nagoya-a.betaversion.org%3E
> 
> >
> >
> >
> >
> > We would like to know
> >
> > 1.Is this issue a valid one?
> > 2.Is this issue got fixed ,if so, in which xerces version ?.
> > 3.Why we are not able to reproduce it consistently and what had 
actually
> > gone wrong.
> >
> > sorry for the detailed explanation about issue but we have no other 
go.
> > Your help in this regard is very much appreciated.I am ready to give 
more
> > info regarding this if needed
> >
> >
> > Thanks,
> > karthik,
> >
> >
> >
> > This e-Mail may contain proprietary and confidential information and 
is
> sent
> >for the intended recipient(s) only.  If by an addressing or 
transmission
> >error this mail has been misdirected to you, you are requested to 
delete
> this
> >mail immediately. You are also hereby notified that any use, any form 
of
> >reproduction, dissemination, copying, disclosure, modification,
> distribution
> >and/or publication of this e-mail message, contents or its attachment
> other
> >than by its intended recipient/s is strictly prohibited.
> >
> > Visit us at http://www.polarisFT.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
> >For additional commands, e-mail: j-users-h...@xerces.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
> For additional commands, e-mail: j-users-h...@xerces.apache.org
> 
> 
> 
> 
> 
> This e-Mail may contain proprietary and confidential information and
> is sent for the intended recipient(s) only.  If by an addressing or 
> transmission error this mail has been misdirected to you, you are 
> requested to delete this mail immediately. You are also hereby 
> notified that any use, any form of reproduction, dissemination, 
> copying, disclosure, modification, distribution and/or publication 
> of this e-mail message, contents or its attachment other than by its
> intended recipient/s is strictly prohibited.
> 
> Visit us at http://www.polarisFT.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
> For additional commands, e-mail: j-users-h...@xerces.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org

Reply via email to