Thanks Radu. I guess this option is ruled out for me. 
I will modify my request and response messages to take "req" and "resp"
prefixes. I will use XMLCursor ( or string match and replace ) to remove
"req" and "resp" prefixes when we talk to the server.

btw, the following line of code made no difference at all. It was still
putting namespace prefix. However if I change the second paramter to
something else, the new value is correctly reflected.

 cursor.setName(new QName("http://service..com/req/";,
"getEquityAccountDetail")) 
 cursor.xmlText();

Thanks,
Gopi



Radu Preotiuc-Pietro wrote:
> 
> If  xml.response.GetEquityAccountDetailDocument and
> xml.request.impl.GetEquityAccountDetailDocumentImpl both correspond to
> the same qualified element name, then the one created is going to be the
> first one found on the classpath, so again, you need to have two
> different QNames if you want two different implementation classes in the
> same classloader.
> 
> If you have two separate classloaders on the other hand, and load a
> different jar in each then it will work even if the same QName is used.
> So as long as the combination QName + CL is unique, you're fine.
> 
> Radu
> 
> -----Original Message-----
> From: gopi.rcr [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 27, 2006 6:54 PM
> To: user@xmlbeans.apache.org
> Subject: RE: blank namespace
> 
> 
> Radu,
> 
> I observed a strange behaviour.
> 
> I created two jar files. 
> 
> 1) getEquityDetailRequest.jar
> 2) getEquityDetailResponse.jar
> 
> I use the first jar file for creating a request message, which works
> fine.
> But when I try to parse the response message using classes from the
> second jar file, I am getting ClassCastException.
> 
> I tried with following two options.
> 
> 1)   XmlObject
> o=XmlBeans.getContextTypeLoader().parse(responseMsg,xml.response.GetEqui
> tyAccountDetailDocument.type,opts);
> 
> 2) XmlObject
> o=xml.response.GetEquityAccountDetailDocument.Factory.parse(responseMsg,
> opts);
> 
> 
> When I pass a response message to parse method, I expect it to return
> xml.response.GetEquityAccountDetailDocument but it is creating
> xml.request.impl.GetEquityAccountDetailDocumentImpl object.
> 
> Is this a bug ? or am I missing something ?
> 
> Thanks,
> Gopi
> 
> 
> 
> 
> Radu Preotiuc-Pietro wrote:
>> 
>> You should break it up of course, in fact you should use the standard 
>> SOAP Schema for the SOAP part (you can find it at the URI pointed to 
>> by the SOAP namespace). That part contains an <any> to represent the 
>> content of the Body element. The actual element inside the Body in the
> 
>> instance will be bound by XMLBeans to the correct type based on the 
>> _qualified_ name of the element.
>> 
>> Radu
>> 
>> -----Original Message-----
>> From: gopi.rcr [mailto:[EMAIL PROTECTED]
>> Sent: Monday, November 27, 2006 3:58 PM
>> To: user@xmlbeans.apache.org
>> Subject: RE: blank namespace
>> 
>> 
>> Radu,
>> Thanks for your suggestion.
>> I am just curious to know how XMLBeans are used to generate and parse 
>> SOAP messages. I guess in most of the cases only the Soap body is 
>> going to differ for all the messages. Is it advisable to break the 
>> schema into Soap template and soap body ? or Should schemas be 
>> generated for every soap message  ?
>> 
>> Thanks,
>> Gopi
>> 
>> 
>> 
>> Radu Preotiuc-Pietro wrote:
>>> 
>>> Does the answer from the server arrive in a SOAP message or as a 
>>> standalone XML document? If the latter, then 
>>> XmlOptions.setLoadReplaceDocumentElement(new
>>> QName("http://service..com/resp/";, "getEquityAccountDetail")) should 
>>> do the trick by changing the name of _only_ the root element, so at 
>>> that point the message will match the Schema and XMLBeans will be 
>>> able
>> 
>>> to access all the data in the message with the generated getters.
>>> 
>>> On the way out (to the server) it's more complicated, I don't think 
>>> that there is one option that will magically "fix" the name of just 
>>> the right element (given that it's inside a SOAP payload). The only 
>>> way I know to accomplish that is use an XmlCursor to navigate to the 
>>> "getEquityAccountDetail" element and then call cursor.setName(new 
>>> QName("http://service..com/req/";,
>>> "getEquityAccountDetail"))
>>> right before you call serialize your message to XML.
>>> 
>>> Hope this helps,
>>> Radu
>>> 
>>> -----Original Message-----
>>> From: gopi.rcr [mailto:[EMAIL PROTECTED]
>>> Sent: Monday, November 27, 2006 2:19 PM
>>> To: user@xmlbeans.apache.org
>>> Subject: RE: blank namespace
>>> 
>>> 
>>> Thanks David for your quick response. 
>>> Even if I introduce one more header, I guess I am still going to have
> 
>>> my basic problem of resolving name space collisions when I try to 
>>> compile schemas into java files since <soap-env:header>, 
>>> <soap-env:body>, <getEquityAcountDetails> etc tags will be present in
> 
>>> all my request and response messages.
>>> 
>>> Thanks,
>>> Gopi
>>> 
>>> 
>>> 
>>> Webber, David (NIH/OD) [C] wrote:
>>>> 
>>>> Gopi,
>>>> 
>>>> Yes - you need to modify your schema - make two choices for the 
>>>> elements
>>>> - and add a parent element above if necessary - so you can have two 
>>>> forms of the child elements - depending on the type of message you 
>>>> are
>>> 
>>>> sending.
>>>> 
>>>> This is what I was trying to tell you - add a type Hdr to YOUR MSG 
>>>> perhaps is one choice - not the SOAP HDR!!!
>>>> 
>>>> Then inside your own header you can have two or more forms of the 
>>>> elements you need.
>>>> 
>>>> DW
>>>> 
>>>> -----Original Message-----
>>>> From: gopi.rcr [mailto:[EMAIL PROTECTED]
>>>> Sent: Monday, November 27, 2006 1:51 PM
>>>> To: user@xmlbeans.apache.org
>>>> Subject: RE: blank namespace
>>>> 
>>>> 
>>>> Hi David,
>>>> I already have header info in my message. I didnt post the complete 
>>>> message.
>>>> My complete msg looks like this:
>>>> 
>>>> <soap-env:header>
>>>>      <action>getEquityAccountDetail</action>
>>>> </soap-env:header>
>>>> <soap-env-body>
>>>>        <getEquityAccountDetails>
>>>>                 -----
>>>>                     request information.
>>>>                 ----
>>>>        </getEquityAccountDetails>
>>>> </soap-env-body>
>>>> 
>>>> This is what our server expects for a request message. Header as 
>>>> such
>> 
>>>> doesnt contain any useful information related to query.  The 
>>>> response
>> 
>>>> msg also has a similar structure only difference being the contents 
>>>> of
>>> 
>>>> <getEquityAccountDetails> are different.
>>>> 
>>>> Response msg would look like this:
>>>> 
>>>> <soap-env:header>
>>>>      <action>getEquityAccountDetail</action>
>>>> </soap-env:header>
>>>> <soap-env-body>
>>>>        <getEquityAccountDetails>
>>>>                 -----
>>>>                     response msg (XML format)
>>>>                 ----
>>>>        </getEquityAccountDetails>
>>>> </soap-env-body>
>>>> 
>>>> 
>>>> 
>>>> I am open to modify my schema if it is going to solve the issue.
>>>> 
>>>> Thanks,
>>>> Gopi
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Webber, David (NIH/OD) [C] wrote:
>>>>> 
>>>>> Why don't you re-design your schema so its not so badly overloaded?
>>>>> 
>>>>> Seems simple to add a few parent elements to resolve all this - 
>>>>> such
>>>> as:
>>>>> 
>>>>> <Msg>
>>>>>   <Query>
>>>>>    <!- - Msg goes here -->
>>>>>   </Query>
>>>>>   <Response>
>>>>>    <!- - Msg goes here -->
>>>>>   </Response>
>>>>> </Msg>
>>>>> 
>>>>> Or if you don't like that - what about
>>>>> 
>>>>> <Msg>
>>>>>   <Hdr> my header stuff goes here for each Msg type </Hdr>
>>>>>   <Body>
>>>>>     <!- - Msg goes here -->
>>>>>   </Body>
>>>>> </Msg>
>>>>> 
>>>>> Seems like your original design for the xsd is what is giving you 
>>>>> all
>>> 
>>>>> the problems...
>>>>> 
>>>>> DW
>>>>> 
>>>>> -----Original Message-----
>>>>> From: gopi.rcr [mailto:[EMAIL PROTECTED]
>>>>> Sent: Wednesday, November 22, 2006 5:51 PM
>>>>> To: user@xmlbeans.apache.org
>>>>> Subject: RE: blank namespace
>>>>> 
>>>>> 
>>>>> Radu,
>>>>> Thanks for the detailed explanation.
>>>>> 
>>>>> Now I understand why it is behaving the way it is behaving. 
>>>>> 
>>>>> Let me explain the problem that I am facing. The request and 
>>>>> response
>>> 
>>>>> XML message formats for our server dont have any namespaces for the
> 
>>>>> XML elements. ie. they belong to a default namespace.
>>>>>  
>>>>> eg: <GetEquityAccountDetail> is used for both request as well as 
>>>>> response however the contents of this element are different for 
>>>>> both
>> 
>>>>> request
>>>> and
>>>>> response. 
>>>>> 
>>>>> If I run these two schemas through scomp tool, there will be 
>>>>> namespace collisions. So, to get around this problem, I associated 
>>>>> "req" and "resp"
>>>>> prefixes for request and response messages respectively. Now, I 
>>>>> have
>>>> two
>>>>> issues.
>>>>> 
>>>>> 1) When I generate a request message, it puts a "req" prefix which 
>>>>> is
>>> 
>>>>> perfect. BUt our server doesnt like the request message if there is
> 
>>>>> a
>>> 
>>>>> namespace prefix. So, I use saveImplicitNameSpaces to get rid of
>>> "req"
>>>>> prefix but it puts blank namespace references to other elements.
>>>> Though
>>>>> the
>>>>> message is semantically correct, our server fails to validate. 
>>>>> Looks
>> 
>>>>> like our server uses some kind of string matching program( not sure
>>>>> )
>>> 
>>>>> to validate the request message. Please let me know if there is a 
>>>>> better way of solving this.
>>>>> 
>>>>> <req:GetEquityAccountDetail xmlns:req="http://.....";>
>>>>>   <acccountNumber> </acccountNumber>
>>>>>   <productCode> </productCode>
>>>>>   <elementList> </elementList>
>>>>> </req:GetEquityAccoungDetail>
>>>>> 
>>>>> 
>>>>> 2) I hardcode the request message and get the following response 
>>>>> from
>>> 
>>>>> the server.
>>>>> 
>>>>> <getEquityAccountDetail>
>>>>>     <serviceName>ElpsService</serviceName>
>>>>>             <action>getEquityAccountDetail</action>
>>>>>     <processingTime>117</processingTime>
>>>>>             <info>
>>>>>             <accountNumber>65165104446500001</accountNumber>
>>>>>             <productCode>LCA</productCode>
>>>>>             <lineOfCredit> </lineofCredit>
>>>>>      </info>
>>>>> </getEquityAccountDetail>
>>>>> 
>>>>> 
>>>>> Now, my schema has "resp" name prefix for the response message. So,
> 
>>>>> parsing would obviously fail since the response I got from the 
>>>>> server
>>> 
>>>>> doesnt have any namespace. So, I use the following options.
>>>>> 
>>>>>                   HashMap m=new HashMap();
>>>>>                   m.put("","http://service.wellsfargo.com/resp/";);
>>>>>                   opts.setLoadSubstituteNamespaces(m);
>>>>> 
>>>>> When I try to print the values for ServiceName, ProcessingTime and
>>>> Info,
>>>>> it
>>>>> is printing null for all these values.
>>>>> 
>>>>>   
>>>>> xml.response.GetEquityAccountDetailDocument.GetEquityAccountDetail
>>>>> 
>>>>>                  gead=geadRespDoc.getGetEquityAccountDetail();
>>>>>                  System.out.println(" Service name in body 
>>>>> "+gead.getServiceName());
>>>>>                  System.out.println(" processing time in body
>>>>> "+gead.getProcessingTime())
>>>>> 
>>>>> Could you please tell me what I am missing? 
>>>>> Please let me know if there is a bettwer way of handling this.
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks in advance,
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Radu Preotiuc-Pietro wrote:
>>>>>> 
>>>>>> Gopi and David,
>>>>>> 
>>>>>> This is not about namespace declarations, this is about the names 
>>>>>> of
>>> 
>>>>>> elements in an XML document. In namespace-aware Schema processors
>>>>> (like
>>>>>> XMLBeans and mostly everyhing out there, except for some legacy
>>>> apps),
>>>>>> each element or attribute has a name (or QName, qualified name) 
>>>>>> that
>>>>> is
>>>>>> composed of a namespace uri (which can be empty) and a local name.
>>>>>> 
>>>>>> Now, in XMLSchema too, each time elements or attributes are 
>>>>>> declared,
>>>>> a
>>>>>> name is also part of the declaration. The names declared in the 
>>>>>> XMLSchema and the names present in the instance XML file have to
>>>> match
>>>>>> in order for the document to be valid, and this is what XMLBeans
>>>> tries
>>>>>> to ensure.
>>>>>> 
>>>>>> Now in gopi's example, that Schema declared an element with the 
>>>>>> name
>>> 
>>>>>> (local [EMAIL PROTECTED] uri)
>>>>>> 
>>>>>> [EMAIL PROTECTED]://service..com/req/ (local 
>>>>>> name=getEquityAccountDetail,
>>>>>> namespace-uri=http://service..com/req/)
>>>>>> 
>>>>>> This element in turn is supposed to contain the elements
>>>>>> 
>>>>>> accountNumber@
>>>>>> productCode@
>>>>>> elementList@
>>>>>> 
>>>>>> This is why the original document looks the way it does. It is
>>>>> correct.
>>>>>> By setting setSaveImplicitNamespaces(m), you tell XMLBeans that 
>>>>>> the
>> 
>>>>>> prefix "" (the default prefix) is already associated to the 
>>>>>> "http://service..com/req/";, so then XMLBeans, correctly again,
>>>> doesn't
>>>>>> redeclare it, but then when it comes to the "accountNumber", this 
>>>>>> element has to have an empty namespace-uri and the only way to
>>>> achieve
>>>>>> this is to use an xmlns="" declaration. This is correct and fully 
>>>>>> expected.
>>>>>> 
>>>>>> All I am trying to say is that we have to look at this is terms of
> 
>>>>>> changing names for elements, not in terms of manipulating prefix 
>>>>>> declarations. On the loading side, we have
>>>>>> .setLoadSubstituteNamespaces() which replaces a namespace uri with
> 
>>>>>> another for each name in the document. But this, again, does not 
>>>>>> have the ability to replace any namespace in the incoming document
> 
>>>>>> with something, you have to tell it in advance what namespaces to
>>> expect.
>>>>> On
>>>>>> the saving side, there is no option like that, I guess users have
>>>>> found
>>>>>> it useful only for loading.
>>>>>> 
>>>>>> I really want to do my best to help here, what part of what I 
>>>>>> wrote
>> 
>>>>>> din't make sense?
>>>>>> 
>>>>>> Radu
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Webber, David (NIH/OD) [C] [mailto:[EMAIL PROTECTED]
>>>>>> Sent: Wednesday, November 22, 2006 7:03 AM
>>>>>> To: user@xmlbeans.apache.org
>>>>>> Subject: RE: blank namespace
>>>>>> 
>>>>>> Yeah - this is related to what I've been complaining about for a
>>>> week!
>>>>>> 
>>>>>> Handling of default namespace is the reverse of what you would
>>>> expect.
>>>>>> 
>>>>>> What you try is putting a default namespace declaration on your 
>>>>>> root
>>> 
>>>>>> element - <req:getEquityAccountDetail
>>>>> xmlns="http://banktrans/default/";>
>>>>>> 
>>>>>> Which will at least prevent it having to generate ones for you 
>>>>>> inside your XML.
>>>>>> 
>>>>>> There should however be some way to tell XMLBeans to not require a
> 
>>>>>> default namespace declaration - but so far I've not been able to
>>>> track
>>>>>> down how...
>>>>>> 
>>>>>> DW
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: gopi.rcr [mailto:[EMAIL PROTECTED]
>>>>>> Sent: Tuesday, November 21, 2006 7:03 PM
>>>>>> To: user@xmlbeans.apache.org
>>>>>> Subject: Re: blank namespace
>>>>>> 
>>>>>> 
>>>>>> Forgot to include,
>>>>>> 
>>>>>> My schema file looks somthing like this.
>>>>>> 
>>>>>> <xs:schema targetNamespace="http://service..com/req/"; 
>>>>>>        xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>>>>>> 
>>>>>> <xs:import schemaLocation="Elps_GetEquityData_Request1.xsd"/>
>>>>>>  <xs:element name="getEquityAccountDetail">
>>>>>>          <xs:complexType>
>>>>>>                  <xs:sequence>
>>>>>>                          <xs:element ref="accountNumber"/>
>>>>>>                          <xs:element ref="productCode"/>
>>>>>>                          <xs:element ref="elementList"/>
>>>>>>                  </xs:sequence>
>>>>>>          </xs:complexType>
>>>>>>  </xs:element>
>>>>>> </xs:schema>
>>>>>> 
>>>>>> The elements accountNumber, productCode and elementList dont have 
>>>>>> a
>> 
>>>>>> namespace.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> gopi.rcr wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I have an XMLBeans based program for generating XML output. XML
>>>>> output
>>>>>> 
>>>>>>> looks as below:
>>>>>>> 
>>>>>>> <req:getEquityAccountDetail>
>>>>>>>       <accountNumber>
>>>>>>>         <bank>651</bank>
>>>>>>>         <branch>651</branch>
>>>>>>>         <customer>0444650</customer>
>>>>>>>         <loan>0001</loan>
>>>>>>>       </accountNumber>
>>>>>>>       <productCode>LCA</productCode>
>>>>>>> -----------
>>>>>>> 
>>>>>>> When I modify my code to filter out req namespace prefix by doing
>>>> the
>>>>>>> following.
>>>>>>> 
>>>>>>> XmlOptions op = new XmlOptions(); HashMap m=new HashMap(); 
>>>>>>> m.put("","http://service.wellsfargo.com/req/";);  //namespace uri 
>>>>>>> for
>>>>>> req
>>>>>>> opts.setSaveImplicitNamespaces(m);
>>>>>>> 
>>>>>>> -----------------------------------------------------------
>>>>>>> 
>>>>>>> I am getting output as follows, which has unwanted blank 
>>>>>>> namespace
>> 
>>>>>>> references for accountNumber and ProductCode. What should I do to
>>>> get
>>>>>> rid
>>>>>>> of these namespace references ? Why is it putting the blank
>>>> namespace
>>>>>>> references ?
>>>>>>> 
>>>>>>> <getEquityAccountDetail>
>>>>>>>       <accountNumber xmlns="">
>>>>>>>         <bank>651</bank>
>>>>>>>         <branch>651</branch>
>>>>>>>         <customer>0444650</customer>
>>>>>>>         <loan>0001</loan>
>>>>>>>       </accountNumber>
>>>>>>>       <productCode xmlns="">LCA</productCode>
>>>>>>> 
>>>>>>> 
>>>>>>> You help is highly appreicated.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/blank-namespace-tf2681769.html#a7482861
>>>>>> Sent from the Xml Beans - User mailing list archive at Nabble.com.
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>> 
>>>>>> ------------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>> 
>>>>>>
>>>>>
>>>> ____________________________________________________________________
>>>> _
>>>> _
>>>> _
>>>>>> Notice:  This email message, together with any attachments, may
>>>>> contain
>>>>>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>>>> affiliated
>>>>>> entities,  that may be confidential,  proprietary,  copyrighted
>>>>> and/or
>>>>>> legally privileged, and is intended solely for the use of the
>>>>> individual
>>>>>> or entity named in this message. If you are not the intended
>>>>> recipient,
>>>>>> and have received this message in error, please immediately return
>>>>> this
>>>>>> by email and then delete it.
>>>>>> 
>>>>>> ------------------------------------------------------------------
>>>>>> -
>>>>>> -
>>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/blank-namespace-tf2681769.html#a7497571
>>>>> Sent from the Xml Beans - User mailing list archive at Nabble.com.
>>>>> 
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/blank-namespace-tf2681769.html#a7565484
>>>> Sent from the Xml Beans - User mailing list archive at Nabble.com.
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>> 
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://www.nabble.com/blank-namespace-tf2681769.html#a7569291
>>> Sent from the Xml Beans - User mailing list archive at Nabble.com.
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>> 
>>> _____________________________________________________________________
>>> _
>>> _
>>> Notice:  This email message, together with any attachments, may 
>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
>>> affiliated entities,  that may be confidential,  proprietary, 
>>> copyrighted  and/or legally privileged, and is intended solely for 
>>> the
>> 
>>> use of the individual or entity named in this message. If you are not
> 
>>> the intended recipient, and have received this message in error, 
>>> please immediately return this by email and then delete it.
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>> 
>>> 
>>> 
>> 
>> --
>> View this message in context:
>> http://www.nabble.com/blank-namespace-tf2681769.html#a7570680
>> Sent from the Xml Beans - User mailing list archive at Nabble.com.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> ______________________________________________________________________
>> _
>> Notice:  This email message, together with any attachments, may 
>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
>> affiliated entities,  that may be confidential,  proprietary,  
>> copyrighted  and/or legally privileged, and is intended solely for the
> 
>> use of the individual or entity named in this message. If you are not 
>> the intended recipient, and have received this message in error, 
>> please immediately return this by email and then delete it.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
> 
> --
> View this message in context:
> http://www.nabble.com/blank-namespace-tf2681769.html#a7572406
> Sent from the Xml Beans - User mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/blank-namespace-tf2681769.html#a7572828
Sent from the Xml Beans - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to