[ https://issues.apache.org/jira/browse/XMLBEANS-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hayo updated XMLBEANS-372:
--------------------------
Comment: was deleted
(was: <nachname>NES Elektro & Service GmbH</nachname>
is correct xml. Nonetheless parsing it shows exactly the same bug as the example above.
org.apache.xmlbeans.XmlException: error: Unexpected character encountered (lex state 3): 'a'
at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3486)
at org.apache.xmlbeans.impl.store.Locale.parse(Locale.java:712)
at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:696)
at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:683)
at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:208)
at de.telekom.wholesale.oss.v2.envelope.AnnehmenAuftragRequestDocument$Factory.parse(Unknown
Source)
at com.oneandone.consumer.freenet.talmigration.meldungen.wita.xmlhandler.WitaPass1.parseXmlString(WitaPass1.java:211)
at com.oneandone.consumer.freenet.talmigration.meldungen.wita.xmlhandler.WitaPass1.main(WitaPass1.java:139)
Caused by: org.xml.sax.SAXParseException: Unexpected character encountered (lex state 3):
'a'
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportFatalError(Piccolo.java:1038)
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:723)
at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3454)
... 7 more
If you have a look at http://www.w3.org/TR/xml/#dt-escape you will see, that the parser MUST
recognize this entity.
Probably the error is inside the parser called by piccolo, but the stack trace is not going
that far.
For this, XMLBeans does not comply XML 1.0.
My environment:
XMLBeans 2.4.0;
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
)
> XMLBean locale exception is thrown when element containing '&' is used
> ----------------------------------------------------------------------
>
> Key: XMLBEANS-372
> URL: https://issues.apache.org/jira/browse/XMLBEANS-372
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Solaris
> Reporter: Paul Gray
>
> I have an issue where if a special character is entered (example '&') the SAML authentication
breaks.
> An identical case was raised by another user, See url below) the issue was apparently
resolved and a new version was released, unfortunately this does not appear to have resolved
the issue!
> http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200512.mbox/%3C209085473.1134164174755.JavaMail.jira@ajax.apache.org%3E
> The error appears to be in: org.apache.xmlbeans.impl.store.Locale.java
>
> 13:38:47,913 INFO [STDOUT] org.apache.xmlbeans.XmlException: error: Unexpected character
encountered (lex state 3): ' '
> 13:38:47,945 INFO [STDOUT] at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3467)
> 13:38:47,960 INFO [STDOUT] at org.apache.xmlbeans.impl.store.Locale.parse(Locale.java:706)
> Kind Regards
> Paul
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785265#action_12785265
]
Hayo commented on XMLBEANS-372:
-------------------------------
<nachname>NES Elektro & Service GmbH</nachname>
is correct xml. Nonetheless parsing it shows exactly the same bug as the example above.
org.apache.xmlbeans.XmlException: error: Unexpected character encountered (lex state 3): 'a'
at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3486)
at org.apache.xmlbeans.impl.store.Locale.parse(Locale.java:712)
at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:696)
at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:683)
at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:208)
at de.telekom.wholesale.oss.v2.envelope.AnnehmenAuftragRequestDocument$Factory.parse(Unknown
Source)
at com.oneandone.consumer.freenet.talmigration.meldungen.wita.xmlhandler.WitaPass1.parseXmlString(WitaPass1.java:211)
at com.oneandone.consumer.freenet.talmigration.meldungen.wita.xmlhandler.WitaPass1.main(WitaPass1.java:139)
Caused by: org.xml.sax.SAXParseException: Unexpected character encountered (lex state 3):
'a'
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportFatalError(Piccolo.java:1038)
at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:723)
at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3454)
... 7 more
If you have a look at http://www.w3.org/TR/xml/#dt-escape you will see, that the parser MUST
recognize this entity.
Probably the error is inside the parser called by piccolo, but the stack trace is not going
that far.
For this, XMLBeans does not comply XML 1.0.
My environment:
XMLBeans 2.4.0;
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
> XMLBean locale exception is thrown when element containing '&' is used
> ----------------------------------------------------------------------
>
> Key: XMLBEANS-372
> URL: https://issues.apache.org/jira/browse/XMLBEANS-372
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Solaris
> Reporter: Paul Gray
>
> I have an issue where if a special character is entered (example '&') the SAML authentication
breaks.
> An identical case was raised by another user, See url below) the issue was apparently
resolved and a new version was released, unfortunately this does not appear to have resolved
the issue!
> http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200512.mbox/%3C209085473.1134164174755.JavaMail.jira@ajax.apache.org%3E
> The error appears to be in: org.apache.xmlbeans.impl.store.Locale.java
>
> 13:38:47,913 INFO [STDOUT] org.apache.xmlbeans.XmlException: error: Unexpected character
encountered (lex state 3): ' '
> 13:38:47,945 INFO [STDOUT] at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3467)
> 13:38:47,960 INFO [STDOUT] at org.apache.xmlbeans.impl.store.Locale.parse(Locale.java:706)
> Kind Regards
> Paul
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Hello everyone, The first release candidate for XMLBeans 2.5.0 is available at: http://xmlbeans.apache.org/dist/ Please give it a try and let us know if there are any problems with it. Thank you, Cezar Andrei
[ https://issues.apache.org/jira/browse/XMLBEANS-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zoheb patankar updated XMLBEANS-424:
------------------------------------
Description:
Hi,
Consider following schema example :-
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/"
xmlns:tns="http://www.example.org/">
<complexType name="Employee">
<sequence>
<element name="name" type="string"/>
<element name="country" type="string" default="India"/>
</sequence>
</complexType>
<element name="emp" type="tns:Employee"/>
</schema>
>From above schema i generated schema type jar and populated XMLBean object "EmpDocument"
setting only the name property of it.
The resultant xml that i got from above object contains only name element as given below:-
<emp xmlns="http://www.example.org/">
<name>zoheb</name>
</emp>
As can be seen from generated xml it only contains "name" element skipping the"country"
element.
Although i did not set the country element but xmlbean parser should honour the default attribute
value defined for the country element in schema instead it skips the element if code doesnt
sets it .
Same is the issue other way around as well i.e XML to XMLObject.
was:
Hi,
Consider following schema example :-
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/"
xmlns:tns="http://www.example.org/">
<complexType name="Employee">
<sequence>
<element name="name" type="string"/>
<element name="country" type="string" default="India"/>
</sequence>
</complexType>
<element name="emp" type="tns:Employee"/>
</schema>
>From above schema i generated schema type jar and populated XMLBean object "EmpDocument"
setting only the name property of it.
The resultant xml that i got from above contains only name element as given below:-
<emp xmlns="http://www.example.org/">
<name>zoheb</name>
</emp>
As can be seen from generated xml it only contains "name" element skipping the"country"
element.
Although i did not set the country element but xmlbean parser should honour the default attribute
value defined for the country element in schema instead it skips the element if code doesnt
sets it .
Same is the issue other way around as well i.e XML to XMLObject.
> XMLBeans fail to honour elements which has default attribute value as well as mandatory
in schema.
> --------------------------------------------------------------------------------------------------
>
> Key: XMLBEANS-424
> URL: https://issues.apache.org/jira/browse/XMLBEANS-424
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2
> Environment: Windows XP,Sun solaris 2.5.1, Weblogic 9.2
> Reporter: zoheb patankar
>
> Hi,
> Consider following schema example :-
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/"
xmlns:tns="http://www.example.org/">
> <complexType name="Employee">
> <sequence>
> <element name="name" type="string"/>
> <element name="country" type="string" default="India"/>
> </sequence>
> </complexType>
> <element name="emp" type="tns:Employee"/>
> </schema>
> From above schema i generated schema type jar and populated XMLBean object "EmpDocument"
setting only the name property of it.
> The resultant xml that i got from above object contains only name element as given below:-
> <emp xmlns="http://www.example.org/">
> <name>zoheb</name>
> </emp>
> As can be seen from generated xml it only contains "name" element skipping the"country"
> element.
> Although i did not set the country element but xmlbean parser should honour the default
attribute value defined for the country element in schema instead it skips the element if
code doesnt sets it .
> Same is the issue other way around as well i.e XML to XMLObject.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
XMLBeans fail to honour elements which has default attribute value as well as mandatory in
schema.
--------------------------------------------------------------------------------------------------
Key: XMLBEANS-424
URL: https://issues.apache.org/jira/browse/XMLBEANS-424
Project: XMLBeans
Issue Type: Bug
Components: XmlObject
Affects Versions: Version 2
Environment: Windows XP,Sun solaris 2.5.1, Weblogic 9.2
Reporter: zoheb patankar
Hi,
Consider following schema example :-
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/"
xmlns:tns="http://www.example.org/">
<complexType name="Employee">
<sequence>
<element name="name" type="string"/>
<element name="country" type="string" default="India"/>
</sequence>
</complexType>
<element name="emp" type="tns:Employee"/>
</schema>
>From above schema i generated schema type jar and populated XMLBean object "EmpDocument"
setting only the name property of it.
The resultant xml that i got from above contains only name element as given below:-
<emp xmlns="http://www.example.org/">
<name>zoheb</name>
</emp>
As can be seen from generated xml it only contains "name" element skipping the"country"
element.
Although i did not set the country element but xmlbean parser should honour the default attribute
value defined for the country element in schema instead it skips the element if code doesnt
sets it .
Same is the issue other way around as well i.e XML to XMLObject.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780542#action_12780542
]
Vladimir Shor edited comment on XMLBEANS-316 at 11/20/09 2:32 PM:
------------------------------------------------------------------
XMLBeans 2.4.0 also have this bug.
Looking at the source I would rather say that the bug occurs if complexType element has mixed=true
and it has only attributes. Then this line in (org.apache.xmlbeans.impl.schema.StscChecker:254
in the trunk currently@20.nov.2009):
if (!model.getType().getContentModel().isSkippable())
throws NPE. I Guess ContentModel is not set, if element has nothing besides attributes.
was (Author: vovencij):
XMLBeans 2.4.0 also have this bug.
> NPE on complex elements with default or fixed values
> ----------------------------------------------------
>
> Key: XMLBEANS-316
> URL: https://issues.apache.org/jira/browse/XMLBEANS-316
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2.1, Version 2.2, Version 2.2.1
> Environment: Sun Java 6 (build 1.6.0-b105), Linux
> Reporter: Benjamin Gufler
> Assignee: Radu Preotiuc-Pietro
>
> Compiling an XML schema which defines default or fixed values for elements with complex
types leads to a NPE in StscChecker:
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.xmlbeans.impl.schema.StscChecker.checkElementDefaults(StscChecker.java:206)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkFields(StscChecker.java:152)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkAll(StscChecker.java:67)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl(SchemaTypeSystemCompiler.java:310)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:181)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem(SchemaCompiler.java:952)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1072)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:368)
> (The line numbers in this stack trace refer to xmlbeans-2.2.0, but the same error arises
with 2.1.0).
> Here's a minimal subset of the schema I'd like to compile which reproduces the error:
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:element name="Segment" type="Spectrum" />
> <xs:complexType name="Spectrum">
> <xs:sequence>
> <xs:element minOccurs="0" maxOccurs="1" name="SegmentType" type="TextParam" default="Spectrum"
/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="TextParam" mixed="true">
> <xs:attribute name="name" type="xs:string">
> </xs:attribute>
> <xs:attribute name="ucd" type="xs:string">
> </xs:attribute>
> </xs:complexType>
> </xs:schema>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780542#action_12780542
]
Vladimir Shor edited comment on XMLBEANS-316 at 11/20/09 2:33 PM:
------------------------------------------------------------------
XMLBeans 2.4.0 also have this bug.
Looking at the source I would rather say that the bug occurs if complexType element has mixed=true
and it has only attributes. Then this line in (org.apache.xmlbeans.impl.schema.StscChecker:254
in the trunk currently, 20.nov.2009):
if (!model.getType().getContentModel().isSkippable())
throws NPE. I Guess ContentModel is not set, if element has nothing besides attributes.
was (Author: vovencij):
XMLBeans 2.4.0 also have this bug.
Looking at the source I would rather say that the bug occurs if complexType element has mixed=true
and it has only attributes. Then this line in (org.apache.xmlbeans.impl.schema.StscChecker:254
in the trunk currently@20.nov.2009):
if (!model.getType().getContentModel().isSkippable())
throws NPE. I Guess ContentModel is not set, if element has nothing besides attributes.
> NPE on complex elements with default or fixed values
> ----------------------------------------------------
>
> Key: XMLBEANS-316
> URL: https://issues.apache.org/jira/browse/XMLBEANS-316
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2.1, Version 2.2, Version 2.2.1
> Environment: Sun Java 6 (build 1.6.0-b105), Linux
> Reporter: Benjamin Gufler
> Assignee: Radu Preotiuc-Pietro
>
> Compiling an XML schema which defines default or fixed values for elements with complex
types leads to a NPE in StscChecker:
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.xmlbeans.impl.schema.StscChecker.checkElementDefaults(StscChecker.java:206)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkFields(StscChecker.java:152)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkAll(StscChecker.java:67)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl(SchemaTypeSystemCompiler.java:310)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:181)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem(SchemaCompiler.java:952)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1072)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:368)
> (The line numbers in this stack trace refer to xmlbeans-2.2.0, but the same error arises
with 2.1.0).
> Here's a minimal subset of the schema I'd like to compile which reproduces the error:
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:element name="Segment" type="Spectrum" />
> <xs:complexType name="Spectrum">
> <xs:sequence>
> <xs:element minOccurs="0" maxOccurs="1" name="SegmentType" type="TextParam" default="Spectrum"
/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="TextParam" mixed="true">
> <xs:attribute name="name" type="xs:string">
> </xs:attribute>
> <xs:attribute name="ucd" type="xs:string">
> </xs:attribute>
> </xs:complexType>
> </xs:schema>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780542#action_12780542
]
Vladimir Shor commented on XMLBEANS-316:
----------------------------------------
XMLBeans 2.4.0 also have this bug.
> NPE on complex elements with default or fixed values
> ----------------------------------------------------
>
> Key: XMLBEANS-316
> URL: https://issues.apache.org/jira/browse/XMLBEANS-316
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2.1, Version 2.2, Version 2.2.1
> Environment: Sun Java 6 (build 1.6.0-b105), Linux
> Reporter: Benjamin Gufler
> Assignee: Radu Preotiuc-Pietro
>
> Compiling an XML schema which defines default or fixed values for elements with complex
types leads to a NPE in StscChecker:
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.xmlbeans.impl.schema.StscChecker.checkElementDefaults(StscChecker.java:206)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkFields(StscChecker.java:152)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkAll(StscChecker.java:67)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl(SchemaTypeSystemCompiler.java:310)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:181)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem(SchemaCompiler.java:952)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1072)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:368)
> (The line numbers in this stack trace refer to xmlbeans-2.2.0, but the same error arises
with 2.1.0).
> Here's a minimal subset of the schema I'd like to compile which reproduces the error:
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:element name="Segment" type="Spectrum" />
> <xs:complexType name="Spectrum">
> <xs:sequence>
> <xs:element minOccurs="0" maxOccurs="1" name="SegmentType" type="TextParam" default="Spectrum"
/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="TextParam" mixed="true">
> <xs:attribute name="name" type="xs:string">
> </xs:attribute>
> <xs:attribute name="ucd" type="xs:string">
> </xs:attribute>
> </xs:complexType>
> </xs:schema>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon resolved XMLBEANS-260.
------------------------------------
Resolution: Fixed
Fix Version/s: (was: Version 2.1)
Version 2.4.1
Fix should go into the next release (expected to be 2.5).
> Calling SchemaType.isSkippedAnonymousType() can throw a NPE
> -----------------------------------------------------------
>
> Key: XMLBEANS-260
> URL: https://issues.apache.org/jira/browse/XMLBEANS-260
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Java 1.5, Windows XP
> Reporter: Luke Peters
> Assignee: Wing Yew Poon
> Fix For: Version 2.4.1
>
>
> If isSkippedAnonymousType() is called on a SchemaType instance that does not have _outerSchemaTypeRef
set, then a NPE will be thrown. Example:
> MyXmlBean myBean = MyXmlBean.Factory.newInstance();
> boolean isSkipped = myBean.schemaType().isSkippedAnonymousType(); <- throws a NPE
> It seems that it should return false in this instance, rather than throw an exception.
All this needs to fix is to add a null check. I'm not sure which versions exactly are effected,
but it is an issue in 2.1.
> Current code:
> public boolean isSkippedAnonymousType()
> { return _outerSchemaTypeRef.get().getBaseType() == this ||
> _outerSchemaTypeRef.get().getContentBasedOnType() == this; }
> Potential fix:
> public boolean isSkippedAnonymousType()
> { return _outerSchemaTypeRef == null ? false : _outerSchemaTypeRef.get().getBaseType()
== this ||
> _outerSchemaTypeRef.get().getContentBasedOnType() == this; }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon resolved XMLBEANS-298.
------------------------------------
Resolution: Fixed
Fix Version/s: Version 2.4.1
The fix will go into the next release (expected to be 2.5).
The character escaping now applies to attributes as well. Namespace declarations are not escaped.
> Saver.entitizeAttrValue() doesn't honor SAVE_SUBSTITUTE_CHARACTERS setting
> --------------------------------------------------------------------------
>
> Key: XMLBEANS-298
> URL: https://issues.apache.org/jira/browse/XMLBEANS-298
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2.2
> Reporter: Niklas Mehner
> Assignee: Wing Yew Poon
> Fix For: Version 2.4.1
>
>
> I'm formatting a XML Document using the following XMLOptions:
> XmlOptions options = new XmlOptions();
> options.setSavePrettyPrint();
> XmlOptionCharEscapeMap escapes = new XmlOptionCharEscapeMap();
> escapes.addMapping('<', XmlOptionCharEscapeMap.PREDEF_ENTITY);
> escapes.addMapping('>', XmlOptionCharEscapeMap.PREDEF_ENTITY);
> escapes.addMapping('&', XmlOptionCharEscapeMap.PREDEF_ENTITY);
> escapes.addMapping('\'', XmlOptionCharEscapeMap.PREDEF_ENTITY);
> escapes.addMapping('"', XmlOptionCharEscapeMap.PREDEF_ENTITY);
> options.setSaveSubstituteCharacters(escapes);
> This works when using content containing the escaped chars, but attribut values are not
escaped:
> <inventory>
> <customer name1=">"/>
> </inventory>
> This should be:
> <inventory>
> <customer name1=">"/>
> </inventory>
> The reason for this is, that Saver.entitizeAttrValue() does not contain:
> [....]
> else if (isEscapedChar( ch ))
> i = replace( i, _replaceChar.getEscapedString( ch ) );
> [....]
> This is only done in Saver.entitizeContent().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Preotiuc-Pietro resolved XMLBEANS-162.
-------------------------------------------
Resolution: Fixed
Fix Version/s: Version 2.4
> NPE during schema compilation with extension
> --------------------------------------------
>
> Key: XMLBEANS-162
> URL: https://issues.apache.org/jira/browse/XMLBEANS-162
> Project: XMLBeans
> Issue Type: Bug
> Components: Compiler
> Affects Versions: Version 2 Beta 1
> Reporter: Harald Meyer
> Assignee: Jacob Danner
> Fix For: Version 2.4
>
>
> When no extensions are used, everything works fine. Stack trace:
> [java] Exception in thread "main" java.lang.NullPointerException
> [java] at org.apache.xmlbeans.impl.config.BindingConfigImpl.error(BindingConfigImpl.java:289)
> [java] at org.apache.xmlbeans.impl.config.InterfaceExtensionImpl.validateJava(InterfaceExtensionImpl.java:91)
> [java] at org.apache.xmlbeans.impl.config.InterfaceExtensionImpl.validateInterface(InterfaceExtensionImpl.java:66)
> [java] at org.apache.xmlbeans.impl.config.InterfaceExtensionImpl.newInstance(InterfaceExtensionImpl.java:38)
> [java] at org.apache.xmlbeans.impl.config.BindingConfigImpl.recordExtensionSetting(BindingConfigImpl.java:234)
> [java] at org.apache.xmlbeans.impl.config.BindingConfigImpl.<init>(BindingConfigImpl.java:109)
> [java] at org.apache.xmlbeans.impl.config.BindingConfigImpl.forConfigDocuments(BindingConfigImpl.java:69)
> [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem(SchemaCompiler.java:939)
> [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1067)
> [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:367)
> From my understanding, XMLBeans tries to report an error message, but the StscStack (what
ever it is) is empty.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Preotiuc-Pietro resolved XMLBEANS-310.
-------------------------------------------
Resolution: Won't Fix
Fix Version/s: unspecified
> XmlObject.substitute() does not work when XMLBeans are used in conujunction with AXIS2
and run in a servlet container. Other operations might be affected by this as well.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XMLBEANS-310
> URL: https://issues.apache.org/jira/browse/XMLBEANS-310
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Environment: AXIS2 version 1.1
> Tomcat version 5.5
> Reporter: Severin Ecker
> Priority: Minor
> Fix For: unspecified
>
>
> In situations where, at runtime, a compiled schema for an XML element (XML type name)
is being looked for (this happens e.g. when the XmlObject.substitute() operation is invoked)
a resource is loaded via Classloader.getResourceAsStream() (see SchemaTypeLoaderImpl.java)
> The problem is, that the Classloader of the current thread ('Thread.currentThread.getContextClassLoader();)
is used instead the Classloader of an already loaded class (e.g.: classname.class.getClassLoader()).
> This implementation works as long as it is not used within an AXIS2 service. In this
case all classes and resources are located in an .aar archive. At load time this file is in
the classpath and the XML-schemas and compiled classes are found. But, later when a service
operation is invoked, the classloader retrieved with 'Thread.currentThread().getContextClassLoader()
is of type WebappClassLoader instead of org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl.
And this WebappClassLoader does NOT look within the .aar file for the schema, therefore substitude
does not have the correct types available at runtime.
> Oh and, there is also no error message in this case stating that a class couldn't be
found/loaded!
> Our workaround to this problem ATM is, setting the thread's contextClassLoader to be
the class loader of a class contained in our web application, first thing each time an operation
of our webservice is invoked. But a fix to this problem would of course be highly appreciated!
> ps.: I will also crosspost this bugreport in AXIS2 since this problem is closely related
to AXIS2, which probobably should hand down a better suited class loader.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Preotiuc-Pietro resolved XMLBEANS-334.
-------------------------------------------
Resolution: Invalid
Fix Version/s: unspecified
> No access to content for mixed complexType containing an empty choice only
> --------------------------------------------------------------------------
>
> Key: XMLBEANS-334
> URL: https://issues.apache.org/jira/browse/XMLBEANS-334
> Project: XMLBeans
> Issue Type: Bug
> Components: Compiler
> Affects Versions: Version 2.2, Version 2.3
> Reporter: Johannes Stamminger
> Priority: Trivial
> Fix For: unspecified
>
>
> Within a small example that I will attach in a minute there is defined an element Title:
> <xs:element name="Title">
> <xs:complexType mixed="true">
> <xs:choice minOccurs="0" maxOccurs="unbounded"/>
> </xs:complexType>
> </xs:element>
> The generated sourcecode for interface Title within XBTitleDocument (all xmlbeans generated
classes were created with XB prefix by way of xsdconfig) does extend from org.apache.xmlbeans.XmlObject
and contain nothing else than the static org.apache.xmlbeans.SchemaType member. Especially
it does not provide access to the string content of the element.
> Though the generated implementation TitleImpl in XBTitleDocumentImpl does provide access
as it
> -> derives from org.apache.xmlbeans.impl.values.XmlComplexContentImpl
> -> deriving from XmlObjectBase
> -> granting access to that value by way of method getStringValue()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777337#action_12777337
]
Radu Preotiuc-Pietro commented on XMLBEANS-334:
-----------------------------------------------
Well, the thing is that, since you can have many children elements under the "Title" element
and text interspersed with them, you would need a way to see what is the relative position
of all the text fragments with respect to each child element. You would use XmlCursor for
that.
See the MixedContent sample.
> No access to content for mixed complexType containing an empty choice only
> --------------------------------------------------------------------------
>
> Key: XMLBEANS-334
> URL: https://issues.apache.org/jira/browse/XMLBEANS-334
> Project: XMLBeans
> Issue Type: Bug
> Components: Compiler
> Affects Versions: Version 2.2, Version 2.3
> Reporter: Johannes Stamminger
> Priority: Trivial
>
> Within a small example that I will attach in a minute there is defined an element Title:
> <xs:element name="Title">
> <xs:complexType mixed="true">
> <xs:choice minOccurs="0" maxOccurs="unbounded"/>
> </xs:complexType>
> </xs:element>
> The generated sourcecode for interface Title within XBTitleDocument (all xmlbeans generated
classes were created with XB prefix by way of xsdconfig) does extend from org.apache.xmlbeans.XmlObject
and contain nothing else than the static org.apache.xmlbeans.SchemaType member. Especially
it does not provide access to the string content of the element.
> Though the generated implementation TitleImpl in XBTitleDocumentImpl does provide access
as it
> -> derives from org.apache.xmlbeans.impl.values.XmlComplexContentImpl
> -> deriving from XmlObjectBase
> -> granting access to that value by way of method getStringValue()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776185#action_12776185
]
Radu Preotiuc-Pietro commented on XMLBEANS-423:
-----------------------------------------------
That does make a lot of sense, to remove the semicolon.
> Extra semi-colon in SchemaTypeCodePrinter changes apparent semantics of 'if' statement
> --------------------------------------------------------------------------------------
>
> Key: XMLBEANS-423
> URL: https://issues.apache.org/jira/browse/XMLBEANS-423
> Project: XMLBeans
> Issue Type: Bug
> Components: Compiler
> Affects Versions: Version 2.4
> Reporter: Josh Micich
> Priority: Minor
>
> See line 807:
> http://svn.apache.org/viewvc/xmlbeans/trunk/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeCodePrinter.java?annotate=799073
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Extra semi-colon in SchemaTypeCodePrinter changes apparent semantics of 'if' statement
--------------------------------------------------------------------------------------
Key: XMLBEANS-423
URL: https://issues.apache.org/jira/browse/XMLBEANS-423
Project: XMLBeans
Issue Type: Bug
Components: Compiler
Affects Versions: Version 2.4
Reporter: Josh Micich
Priority: Minor
See line 807:
http://svn.apache.org/viewvc/xmlbeans/trunk/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeCodePrinter.java?annotate=799073
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
org.apache.xmlbeans.XmlException: error: Unexpected end of file while parsing xml-document
------------------------------------------------------------------------------------------
Key: XMLBEANS-422
URL: https://issues.apache.org/jira/browse/XMLBEANS-422
Project: XMLBeans
Issue Type: Bug
Affects Versions: Version 2.4
Environment: OS UNIX - AIX
Reporter: Matthias Weidinger
The random error occurs during parsing a xml -document. It first occured while using version
2.2.0 and after changing to 2.4 there is still the same problem.
ByteArrayInputStream inputStream = new ByteArrayInputStream(content);
xmlObject = XmlObject.Factory.parse(inputStream);
Is there a version available that is not affected by this problem?
thx in advance
Matthias Weidinger
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773598#action_12773598
]
Wing Yew Poon commented on XMLBEANS-421:
----------------------------------------
I think we can change the link to http://xmlbeans.apache.org/samples/index.html then.
> Link to XMLBeans Samples on Getting Started is dead
> ---------------------------------------------------
>
> Key: XMLBEANS-421
> URL: https://issues.apache.org/jira/browse/XMLBEANS-421
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: unspecified
> Reporter: Hayo
> Priority: Minor
>
> See
> http://xmlbeans.apache.org/docs/2.0.0/guide/conGettingStartedwithXMLBeans.html
> http://xmlbeans.apache.org/docs/samples/navXMLBeansSamples.html does not exist:
> "Not Found
> The requested URL /docs/samples/navXMLBeansSamples.html was not found on this server.
> Apache/2.2.12 (Unix) mod_fcgid/2.3.2-dev Server at xmlbeans.apache.org Port 80"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Link to XMLBeans Samples on Getting Started is dead
---------------------------------------------------
Key: XMLBEANS-421
URL: https://issues.apache.org/jira/browse/XMLBEANS-421
Project: XMLBeans
Issue Type: Bug
Affects Versions: unspecified
Reporter: Hayo
Priority: Minor
See
http://xmlbeans.apache.org/docs/2.0.0/guide/conGettingStartedwithXMLBeans.html
http://xmlbeans.apache.org/docs/samples/navXMLBeansSamples.html does not exist:
"Not Found
The requested URL /docs/samples/navXMLBeansSamples.html was not found on this server.
Apache/2.2.12 (Unix) mod_fcgid/2.3.2-dev Server at xmlbeans.apache.org Port 80"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Hi Friends,
I need to parse JavaBean to XML and XML to JavaBean, kindly
suggest me the best API to parse
Thanks in Advance
----------------
Siva
--
View this message in context: http://old.nabble.com/Parsing-JavaBean-to-XML-and-Viceversa-tp26190789p26190789.html
Sent from the Xml Beans - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773135#action_12773135
]
Raman Gupta commented on XMLBEANS-262:
--------------------------------------
Good point about option #1. Option #3 it is then.
For the enhancement, I how about two new XmlOption's:
setEolStyle(String eolStyle)
setEolStyleDeclaration(String eolStyle)
with the following constants as possible values:
EOLSTYLE_LF = "LF";
EOLSTYLE_CRLF = "CRLF";
EOLSTYLE_SYS = "SYS";
To maintain backwards compatibility, the option eolStyle would be set by the user to EOLSTYLE_LF
and eolStyleDeclaration would be EOLSTYLE_SYS. However, the defaults provided by XmlBeans
should probably be EOLSTYLE_LF or EOLSTYLE_SYS for both. My personal preference would be _LF
but I suspect most people would expect _SYS to be the default.
> Line ending behavior inconsistent when using save(OutputStream)
> ---------------------------------------------------------------
>
> Key: XMLBEANS-262
> URL: https://issues.apache.org/jira/browse/XMLBEANS-262
> Project: XMLBeans
> Issue Type: Improvement
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Windows, JDK 1.5.0_06
> Reporter: Raman Gupta
> Assignee: Radu Preotiuc-Pietro
> Priority: Minor
>
> When executing an XmlObject.save(OutputStream) call, the output's line endings do not
conform to any consistent and expected behavior. Even though this should not be a problem
for any conformant XML processor due to http://www.w3.org/TR/REC-xml/#sec-line-ends, this
sometimes causes problems with other tools or code.
> Here is a code snippet to reproduce:
> XmlObject x = XmlObject.Factory.parse("<root>\r\n<test/>\r\n</root>");
> OutputStream o = new FileOutputStream("out.xml");
> x.save(o);
> o.close();
> Viewing out.xml in a hex editor will show that the line ending after the XML declaration
is determined by the System property line.separator (on windows, default is \r\n, or 0x0D,
0x0A) but the line endings after all the other elements is always a single \n (0x0A), regardless
of line.separator and the input XML. In other words, line endings do not match either the
line endings provided in the input XML, or the platform default value on Windows.
> I suppose there are several options for fixing this:
> 1) The XML declaration continues to use the System property, but for other line endings,
the input XML's line endings should be respected when output (\r\n on the input is output
as is), OR
> 2) That the output XML uses the System property and makes all line endings consistent.
> 3) Some combination of the above with new XmlOption's settings.
> My preference would be #3 so that the line ending behavior can be controlled by the user.
For the default, I have no preference except to have some known documented behavior. Option
#1 will sometimes result in a file with inconsistent line endings, but it could be argued
that the user requested it so it is ok.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon updated XMLBEANS-262:
-----------------------------------
Issue Type: Improvement (was: Bug)
This is not a bug. The behavior is by design.
As the reporter found, the behavior is in fact predictable and known, although perhaps not
documented. The xml declaration ends with the system line separator, while lines within the
xml body end with \n (line feed).
I personally would prefer the xml declaration to always end with \n as well, to be consistent
with the rest of the document, regardless of the system.
As an enhancement, we could provide an option to output all lines to end with the system line
separator.
Option 1 stated by the reporter is not possible, and conflicts with the xml spec. As the section
cited by the reporter states, "the XML processor MUST behave as if it normalized all line
breaks in external parsed entities (including the document entity) on input, before parsing,
by translating both the two-character sequence #xD #xA and any #xD that is not followed by
#xA to a single #xA character." Note the clause, "before parsing". Thus all the line endings
in the input are normalized away before parsing, so there is no way for XMLBeans to get them
back from the XmlObject.
> Line ending behavior inconsistent when using save(OutputStream)
> ---------------------------------------------------------------
>
> Key: XMLBEANS-262
> URL: https://issues.apache.org/jira/browse/XMLBEANS-262
> Project: XMLBeans
> Issue Type: Improvement
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Windows, JDK 1.5.0_06
> Reporter: Raman Gupta
> Assignee: Radu Preotiuc-Pietro
> Priority: Minor
>
> When executing an XmlObject.save(OutputStream) call, the output's line endings do not
conform to any consistent and expected behavior. Even though this should not be a problem
for any conformant XML processor due to http://www.w3.org/TR/REC-xml/#sec-line-ends, this
sometimes causes problems with other tools or code.
> Here is a code snippet to reproduce:
> XmlObject x = XmlObject.Factory.parse("<root>\r\n<test/>\r\n</root>");
> OutputStream o = new FileOutputStream("out.xml");
> x.save(o);
> o.close();
> Viewing out.xml in a hex editor will show that the line ending after the XML declaration
is determined by the System property line.separator (on windows, default is \r\n, or 0x0D,
0x0A) but the line endings after all the other elements is always a single \n (0x0A), regardless
of line.separator and the input XML. In other words, line endings do not match either the
line endings provided in the input XML, or the platform default value on Windows.
> I suppose there are several options for fixing this:
> 1) The XML declaration continues to use the System property, but for other line endings,
the input XML's line endings should be respected when output (\r\n on the input is output
as is), OR
> 2) That the output XML uses the System property and makes all line endings consistent.
> 3) Some combination of the above with new XmlOption's settings.
> My preference would be #3 so that the line ending behavior can be controlled by the user.
For the default, I have no preference except to have some known documented behavior. Option
#1 will sometimes result in a file with inconsistent line endings, but it could be argued
that the user requested it so it is ok.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon closed XMLBEANS-365.
----------------------------------
The link to the external validation tool has also been removed from the Apache XMLBeans resources
web page.
> XMLBeans Schema Validation V2 from web does not work - http://www.xmlbeans.org/schemaToolsV2/validate.do
> --------------------------------------------------------------------------------------------------------
>
> Key: XMLBEANS-365
> URL: https://issues.apache.org/jira/browse/XMLBEANS-365
> Project: XMLBeans
> Issue Type: Bug
> Components: Tools
> Reporter: Jakub Příkazský
> Priority: Blocker
>
> When I tried to use schema validation tool i got following error:
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it from fulfilling
this request.
> exception
> javax.servlet.ServletException: Servlet execution threw an exception
> root cause
> java.lang.NoClassDefFoundError: org/w3/x2001/xmlSchema/SchemaDocument$Schema
> validation.ValidateRequestAction.validateSchema(ValidateRequestAction.java:80)
> validation.ValidateRequestAction.execute(ValidateRequestAction.java:49)
> org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17
logs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon resolved XMLBEANS-365.
------------------------------------
Resolution: Won't Fix
The website is no longer maintained due to lack of funding. See XMLBEANS-411. This bug is
essentially a duplicate of that.
> XMLBeans Schema Validation V2 from web does not work - http://www.xmlbeans.org/schemaToolsV2/validate.do
> --------------------------------------------------------------------------------------------------------
>
> Key: XMLBEANS-365
> URL: https://issues.apache.org/jira/browse/XMLBEANS-365
> Project: XMLBeans
> Issue Type: Bug
> Components: Tools
> Reporter: Jakub Příkazský
> Priority: Blocker
>
> When I tried to use schema validation tool i got following error:
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it from fulfilling
this request.
> exception
> javax.servlet.ServletException: Servlet execution threw an exception
> root cause
> java.lang.NoClassDefFoundError: org/w3/x2001/xmlSchema/SchemaDocument$Schema
> validation.ValidateRequestAction.validateSchema(ValidateRequestAction.java:80)
> validation.ValidateRequestAction.execute(ValidateRequestAction.java:49)
> org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17
logs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772804#action_12772804
]
Wing Yew Poon commented on XMLBEANS-366:
----------------------------------------
I submitted an enhancement in XMLBeans 2.4.0 to make the XPath/XQuery engine pluggable (see
XMLBEANS-373). This is a more general solution to implement the functionality Robert seeks
(using JXPath instead of Saxon).
We could add a sample demonstrating this pluggability, using JXPath as the XPath engine. That
could be nice.
> Apache JXPath support
> ---------------------
>
> Key: XMLBEANS-366
> URL: https://issues.apache.org/jira/browse/XMLBEANS-366
> Project: XMLBeans
> Issue Type: New Feature
> Components: XPath
> Affects Versions: Version 2.3.1
> Reporter: Robert Marcano
> Priority: Minor
> Attachments: jxpath-support.patch
>
>
> I have patched the version 2.3 to support Apache JXPath when no saxon is found (default
behavior), I sent this to the dev mailing list without answer, so I an adding it here to see
if it gets a little more attention (I can update it to trunk and make the necessary changes):
> Greeting everyone, I have been a long time user of XMlBeans but it is
> the first time I needed to use the XPath support. Using an old Saxon
> release (8.6.1 as documented because is the version that is API
> compatible) everything is working perfectly.
> My application is Webstart based so I try to reduce the amount of
> external dependencies in order to have a small download size, I am
> currently using JXPath for some Beans trees searches, so I decided to
> patch XMLBeans to try to use JXPath after it fails to find Saxon. I am
> attaching the patch so anyone can use it and to know if the changes are
> accepted so I can port it to the trunk release instead of 2.3.0.
> In the process of developing this patch I found one problem with the
> XPath function "id()". The JXPath implementation of this functions when
> it is traversing a DOM tree is to find the document owner and call
> getElementById(). the current DOM implementation of XMLBeans only
> recognize ID attributes when they are defined on a DTD and does not use
> the XML schema information. Even when my XMLBeans model parses a DOM
> tree obtained from a XML Schema validating DOM parser, the ID attributes
> information is lost because it recreated an internal tree that discards
> the "isId" information added by the DOM parser. I tried to use the
> schema type information in the method Cur>>isAttrOfTypeId but still do
> not find a way, any helps with this is appreciated
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772777#action_12772777
]
Cezar Andrei commented on XMLBEANS-268:
---------------------------------------
Just to be clear: there are 2 problems here:
1. if target namespace differs only in caps, on Windows the generated resources will collide
and there is no workaround for this at this point.
- a potential fix should change the encoding algorithm from uri to dir name, which will
break backwards compatibility so the code should be enabled only through a system property
2. and the generation of the same class/interface name, which is by design and the user should
use a .xsdconfig file to change the package name or the class/interface name
I reopened the issue only for tracking problem 1.
> Collision detected while generating classnames for (except-case) identical schema names
> ---------------------------------------------------------------------------------------
>
> Key: XMLBEANS-268
> URL: https://issues.apache.org/jira/browse/XMLBEANS-268
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2
> Environment: unix
> Reporter: Mike Barrett
> Priority: Minor
>
> We have two schemas:
> slideshow.xsd and slideShow.xsd
> Which have identical names, except case. The issue is that it seems that this causes
a name collision, and causes the generated class name to have a number inserted:
> slideshow.xsd --> SlideshowDocumentImpl
> slideShow.xsd --> SlideShowDocument2Impl
> now if you remove the '2' from the slideShow class, you still have two unique java class
names. Therefore, I don't see the need to append a number to the generated name.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon reassigned XMLBEANS-328:
--------------------------------------
Assignee: Radu Preotiuc-Pietro
> Problems in multi-processor environment
> ---------------------------------------
>
> Key: XMLBEANS-328
> URL: https://issues.apache.org/jira/browse/XMLBEANS-328
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2.2, Version 2.2.1
> Environment: At least Win XP and Linux 2.6 with Sun JRE. Intel multi-core processor.
> Reporter: Pasi Lehtimaki
> Assignee: Radu Preotiuc-Pietro
> Priority: Critical
> Attachments: patch-xmlbeans-2.2.0, patch-XMLBEANS328-2.4.0.patch, xbean.jar
>
>
> Running a strongly threadded Eclipse application using xmlbeans in multi-processor (/multi-core)
computer causes frequent crashes in xmlbeans code.
> Most of the crases happen in Cur.java in form of a NPE:
> ***************************************************
> java.lang.NullPointerException
> at org.apache.xmlbeans.impl.store.Cur.listRemove(Cur.java:2783)
> at org.apache.xmlbeans.impl.store.Locale.getCur(Locale.java:2775)
> at org.apache.xmlbeans.impl.store.Locale.tempCur(Locale.java:2736)
> at org.apache.xmlbeans.impl.store.Locale.tempCur(Locale.java:2731)
> at org.apache.xmlbeans.impl.store.Xobj.tempCur(Xobj.java:348)
> at org.apache.xmlbeans.impl.store.Xobj.new_cursor(Xobj.java:1810)
> at org.apache.xmlbeans.impl.values.XmlObjectBase.newCursor(XmlObjectBase.java:250)
> at org.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:424)
> at org.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:415)
> ***************************************************
> In some cases the crash happens in Locale.exit():
> ***************************************************
> Exception occurred: java.lang.ArrayIndexOutOfBoundsException: -1
> at org.apache.xmlbeans.impl.store.Locale.exit(Locale.java:2840)
> ***************************************************
> This problem problem occurs in xmlbeans 2.2. and in the latest version in SVN. The problem
disappears when I turn the multi-core support off from BIOS and reappears again immediently
when I turn it back on. So I believe that this has something to do with threading. Only classes
Locale.java and Cur.java seem to be affected. I haven't encountered any exceptions from other
classes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cezar Andrei reopened XMLBEANS-268:
-----------------------------------
I would leave this bug open, because this is really a problem on windows.
> Collision detected while generating classnames for (except-case) identical schema names
> ---------------------------------------------------------------------------------------
>
> Key: XMLBEANS-268
> URL: https://issues.apache.org/jira/browse/XMLBEANS-268
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2
> Environment: unix
> Reporter: Mike Barrett
> Priority: Minor
>
> We have two schemas:
> slideshow.xsd and slideShow.xsd
> Which have identical names, except case. The issue is that it seems that this causes
a name collision, and causes the generated class name to have a number inserted:
> slideshow.xsd --> SlideshowDocumentImpl
> slideShow.xsd --> SlideShowDocument2Impl
> now if you remove the '2' from the slideShow class, you still have two unique java class
names. Therefore, I don't see the need to append a number to the generated name.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772751#action_12772751
]
Wing Yew Poon commented on XMLBEANS-260:
----------------------------------------
The isSkippedAnonymousType method should only be called on a SchemaType instance that *is*
in fact an anonymous type.
> Calling SchemaType.isSkippedAnonymousType() can throw a NPE
> -----------------------------------------------------------
>
> Key: XMLBEANS-260
> URL: https://issues.apache.org/jira/browse/XMLBEANS-260
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Java 1.5, Windows XP
> Reporter: Luke Peters
> Assignee: Wing Yew Poon
> Fix For: Version 2.1
>
>
> If isSkippedAnonymousType() is called on a SchemaType instance that does not have _outerSchemaTypeRef
set, then a NPE will be thrown. Example:
> MyXmlBean myBean = MyXmlBean.Factory.newInstance();
> boolean isSkipped = myBean.schemaType().isSkippedAnonymousType(); <- throws a NPE
> It seems that it should return false in this instance, rather than throw an exception.
All this needs to fix is to add a null check. I'm not sure which versions exactly are effected,
but it is an issue in 2.1.
> Current code:
> public boolean isSkippedAnonymousType()
> { return _outerSchemaTypeRef.get().getBaseType() == this ||
> _outerSchemaTypeRef.get().getContentBasedOnType() == this; }
> Potential fix:
> public boolean isSkippedAnonymousType()
> { return _outerSchemaTypeRef == null ? false : _outerSchemaTypeRef.get().getBaseType()
== this ||
> _outerSchemaTypeRef.get().getContentBasedOnType() == this; }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cezar Andrei reassigned XMLBEANS-316:
-------------------------------------
Assignee: Radu Preotiuc-Pietro
Exception in thread "main" java.lang.NullPointerException
at org.apache.xmlbeans.impl.schema.StscChecker.checkElementDefaults(StscChecker.java:255)
at org.apache.xmlbeans.impl.schema.StscChecker.checkFields(StscChecker.java:192)
at org.apache.xmlbeans.impl.schema.StscChecker.checkAll(StscChecker.java:68)
at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl(SchemaTypeSystemCompiler.java:311)
at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:181)
at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem(SchemaCompiler.java:979)
at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1100)
at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:373)
> NPE on complex elements with default or fixed values
> ----------------------------------------------------
>
> Key: XMLBEANS-316
> URL: https://issues.apache.org/jira/browse/XMLBEANS-316
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2.1, Version 2.2, Version 2.2.1
> Environment: Sun Java 6 (build 1.6.0-b105), Linux
> Reporter: Benjamin Gufler
> Assignee: Radu Preotiuc-Pietro
>
> Compiling an XML schema which defines default or fixed values for elements with complex
types leads to a NPE in StscChecker:
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.xmlbeans.impl.schema.StscChecker.checkElementDefaults(StscChecker.java:206)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkFields(StscChecker.java:152)
> at org.apache.xmlbeans.impl.schema.StscChecker.checkAll(StscChecker.java:67)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl(SchemaTypeSystemCompiler.java:310)
> at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:181)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem(SchemaCompiler.java:952)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1072)
> at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:368)
> (The line numbers in this stack trace refer to xmlbeans-2.2.0, but the same error arises
with 2.1.0).
> Here's a minimal subset of the schema I'd like to compile which reproduces the error:
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:element name="Segment" type="Spectrum" />
> <xs:complexType name="Spectrum">
> <xs:sequence>
> <xs:element minOccurs="0" maxOccurs="1" name="SegmentType" type="TextParam" default="Spectrum"
/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="TextParam" mixed="true">
> <xs:attribute name="name" type="xs:string">
> </xs:attribute>
> <xs:attribute name="ucd" type="xs:string">
> </xs:attribute>
> </xs:complexType>
> </xs:schema>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon closed XMLBEANS-373.
----------------------------------
> pluggable XPath/XQuery engine support
> -------------------------------------
>
> Key: XMLBEANS-373
> URL: https://issues.apache.org/jira/browse/XMLBEANS-373
> Project: XMLBeans
> Issue Type: Improvement
> Components: XPath
> Affects Versions: Version 2.3
> Reporter: Wing Yew Poon
> Assignee: Wing Yew Poon
> Fix For: Version 2.4
>
> Attachments: delegate_diff3.txt
>
>
> This is an enhancement proposal.
> Currently, XMLBeans looks for certain engines in certain orders to process XPath/XQuery
expressions. In particular, it searches for the Saxon XQuery engine. There has been a request
(XMLBEANS-366) to support the use of JXPath for processing XPath expressions. The patch from
the user changes the engine lookup logic to add looking for JXPath if Saxon is not found.
I propose to make the choice of engine more pluggable instead of hardcoding logic to lookup
Saxon/JXPath/etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon resolved XMLBEANS-373.
------------------------------------
Resolution: Fixed
Fix Version/s: (was: TBD)
Version 2.4
This enhancement went into XMLBeans 2.4.0.
> pluggable XPath/XQuery engine support
> -------------------------------------
>
> Key: XMLBEANS-373
> URL: https://issues.apache.org/jira/browse/XMLBEANS-373
> Project: XMLBeans
> Issue Type: Improvement
> Components: XPath
> Affects Versions: Version 2.3
> Reporter: Wing Yew Poon
> Assignee: Wing Yew Poon
> Fix For: Version 2.4
>
> Attachments: delegate_diff3.txt
>
>
> This is an enhancement proposal.
> Currently, XMLBeans looks for certain engines in certain orders to process XPath/XQuery
expressions. In particular, it searches for the Saxon XQuery engine. There has been a request
(XMLBEANS-366) to support the use of JXPath for processing XPath expressions. The patch from
the user changes the engine lookup logic to add looking for JXPath if Saxon is not found.
I propose to make the choice of engine more pluggable instead of hardcoding logic to lookup
Saxon/JXPath/etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon closed XMLBEANS-367.
----------------------------------
> support for Saxon 9
> -------------------
>
> Key: XMLBEANS-367
> URL: https://issues.apache.org/jira/browse/XMLBEANS-367
> Project: XMLBeans
> Issue Type: Improvement
> Affects Versions: Version 2.3
> Reporter: Wing Yew Poon
> Assignee: Wing Yew Poon
> Fix For: Version 2.4
>
> Attachments: build.xml, saxon9_support_diff.txt, xbean_xpath.jar, XBeansXPath.java,
XBeansXQuery.java
>
>
> The current XMLBeans release, 2.3.0, supports Saxon 8.8. There have been requests from
the user community to upgrade support for Saxon to a more current version. The current version
of Saxon is 9.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon resolved XMLBEANS-367.
------------------------------------
Resolution: Fixed
Fix Version/s: (was: TBD)
Version 2.4
The changes to support Saxon 9 went into XMLBeans 2.4.0.
> support for Saxon 9
> -------------------
>
> Key: XMLBEANS-367
> URL: https://issues.apache.org/jira/browse/XMLBEANS-367
> Project: XMLBeans
> Issue Type: Improvement
> Affects Versions: Version 2.3
> Reporter: Wing Yew Poon
> Assignee: Wing Yew Poon
> Fix For: Version 2.4
>
> Attachments: build.xml, saxon9_support_diff.txt, xbean_xpath.jar, XBeansXPath.java,
XBeansXQuery.java
>
>
> The current XMLBeans release, 2.3.0, supports Saxon 8.8. There have been requests from
the user community to upgrade support for Saxon to a more current version. The current version
of Saxon is 9.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772649#action_12772649
]
Mike Barrett commented on XMLBEANS-268:
---------------------------------------
Thanks for the response - makes sense as it could be considered a "feature" at this point.
Keep up the good work!
> Collision detected while generating classnames for (except-case) identical schema names
> ---------------------------------------------------------------------------------------
>
> Key: XMLBEANS-268
> URL: https://issues.apache.org/jira/browse/XMLBEANS-268
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2
> Environment: unix
> Reporter: Mike Barrett
> Priority: Minor
>
> We have two schemas:
> slideshow.xsd and slideShow.xsd
> Which have identical names, except case. The issue is that it seems that this causes
a name collision, and causes the generated class name to have a number inserted:
> slideshow.xsd --> SlideshowDocumentImpl
> slideShow.xsd --> SlideShowDocument2Impl
> now if you remove the '2' from the slideShow class, you still have two unique java class
names. Therefore, I don't see the need to append a number to the generated name.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772648#action_12772648
]
Wing Yew Poon commented on XMLBEANS-268:
----------------------------------------
Mike,
a number of fixes have gone into the trunk since XMLBeans 2.4.0 was released more than a year
ago, and the currently active committers are planning to make a new release in the immediate
future. We are reviewing all the currently open issues and prioritizing what else we may try
to fix. Our resources are very limited and we are all working on a purely voluntary basis.
At this time, we do not expect to revisit the name-mangling algorithm used by XMLBeans, which
has been in use for a long time.
- Wing Yew
> Collision detected while generating classnames for (except-case) identical schema names
> ---------------------------------------------------------------------------------------
>
> Key: XMLBEANS-268
> URL: https://issues.apache.org/jira/browse/XMLBEANS-268
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2
> Environment: unix
> Reporter: Mike Barrett
> Priority: Minor
>
> We have two schemas:
> slideshow.xsd and slideShow.xsd
> Which have identical names, except case. The issue is that it seems that this causes
a name collision, and causes the generated class name to have a number inserted:
> slideshow.xsd --> SlideshowDocumentImpl
> slideShow.xsd --> SlideShowDocument2Impl
> now if you remove the '2' from the slideShow class, you still have two unique java class
names. Therefore, I don't see the need to append a number to the generated name.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772640#action_12772640
]
Mike Barrett commented on XMLBEANS-268:
---------------------------------------
Wing Yew Poon -
Any reason for the won't fix?
> Collision detected while generating classnames for (except-case) identical schema names
> ---------------------------------------------------------------------------------------
>
> Key: XMLBEANS-268
> URL: https://issues.apache.org/jira/browse/XMLBEANS-268
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2
> Environment: unix
> Reporter: Mike Barrett
> Priority: Minor
>
> We have two schemas:
> slideshow.xsd and slideShow.xsd
> Which have identical names, except case. The issue is that it seems that this causes
a name collision, and causes the generated class name to have a number inserted:
> slideshow.xsd --> SlideshowDocumentImpl
> slideShow.xsd --> SlideShowDocument2Impl
> now if you remove the '2' from the slideShow class, you still have two unique java class
names. Therefore, I don't see the need to append a number to the generated name.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon reassigned XMLBEANS-260:
--------------------------------------
Assignee: Wing Yew Poon
> Calling SchemaType.isSkippedAnonymousType() can throw a NPE
> -----------------------------------------------------------
>
> Key: XMLBEANS-260
> URL: https://issues.apache.org/jira/browse/XMLBEANS-260
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Java 1.5, Windows XP
> Reporter: Luke Peters
> Assignee: Wing Yew Poon
> Fix For: Version 2.1
>
>
> If isSkippedAnonymousType() is called on a SchemaType instance that does not have _outerSchemaTypeRef
set, then a NPE will be thrown. Example:
> MyXmlBean myBean = MyXmlBean.Factory.newInstance();
> boolean isSkipped = myBean.schemaType().isSkippedAnonymousType(); <- throws a NPE
> It seems that it should return false in this instance, rather than throw an exception.
All this needs to fix is to add a null check. I'm not sure which versions exactly are effected,
but it is an issue in 2.1.
> Current code:
> public boolean isSkippedAnonymousType()
> { return _outerSchemaTypeRef.get().getBaseType() == this ||
> _outerSchemaTypeRef.get().getContentBasedOnType() == this; }
> Potential fix:
> public boolean isSkippedAnonymousType()
> { return _outerSchemaTypeRef == null ? false : _outerSchemaTypeRef.get().getBaseType()
== this ||
> _outerSchemaTypeRef.get().getContentBasedOnType() == this; }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon reassigned XMLBEANS-262:
--------------------------------------
Assignee: Radu Preotiuc-Pietro
Radu, isn't this (the behavior reported) by design?
> Line ending behavior inconsistent when using save(OutputStream)
> ---------------------------------------------------------------
>
> Key: XMLBEANS-262
> URL: https://issues.apache.org/jira/browse/XMLBEANS-262
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Windows, JDK 1.5.0_06
> Reporter: Raman Gupta
> Assignee: Radu Preotiuc-Pietro
> Priority: Minor
>
> When executing an XmlObject.save(OutputStream) call, the output's line endings do not
conform to any consistent and expected behavior. Even though this should not be a problem
for any conformant XML processor due to http://www.w3.org/TR/REC-xml/#sec-line-ends, this
sometimes causes problems with other tools or code.
> Here is a code snippet to reproduce:
> XmlObject x = XmlObject.Factory.parse("<root>\r\n<test/>\r\n</root>");
> OutputStream o = new FileOutputStream("out.xml");
> x.save(o);
> o.close();
> Viewing out.xml in a hex editor will show that the line ending after the XML declaration
is determined by the System property line.separator (on windows, default is \r\n, or 0x0D,
0x0A) but the line endings after all the other elements is always a single \n (0x0A), regardless
of line.separator and the input XML. In other words, line endings do not match either the
line endings provided in the input XML, or the platform default value on Windows.
> I suppose there are several options for fixing this:
> 1) The XML declaration continues to use the System property, but for other line endings,
the input XML's line endings should be respected when output (\r\n on the input is output
as is), OR
> 2) That the output XML uses the System property and makes all line endings consistent.
> 3) Some combination of the above with new XmlOption's settings.
> My preference would be #3 so that the line ending behavior can be controlled by the user.
For the default, I have no preference except to have some known documented behavior. Option
#1 will sometimes result in a file with inconsistent line endings, but it could be argued
that the user requested it so it is ok.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[ https://issues.apache.org/jira/browse/XMLBEANS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wing Yew Poon resolved XMLBEANS-268.
------------------------------------
Resolution: Won't Fix
> Collision detected while generating classnames for (except-case) identical schema names
> ---------------------------------------------------------------------------------------
>
> Key: XMLBEANS-268
> URL: https://issues.apache.org/jira/browse/XMLBEANS-268
> Project: XMLBeans
> Issue Type: Bug
> Affects Versions: Version 2
> Environment: unix
> Reporter: Mike Barrett
> Priority: Minor
>
> We have two schemas:
> slideshow.xsd and slideShow.xsd
> Which have identical names, except case. The issue is that it seems that this causes
a name collision, and causes the generated class name to have a number inserted:
> slideshow.xsd --> SlideshowDocumentImpl
> slideShow.xsd --> SlideShowDocument2Impl
> now if you remove the '2' from the slideShow class, you still have two unique java class
names. Therefore, I don't see the need to append a number to the generated name.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org