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: [email protected]
> 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: [email protected]
>> 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: [email protected]
>>> 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: [email protected]
>>>> 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: [email protected]
>>>>> 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: [email protected]
>>>>>> 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: [email protected]
>>>>>> 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]