from:"Andreas Beeker"



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker updated XMLBEANS-426:

Fix Version/s: (was: Version 5.1.0)

> Generated XML from an XSD contains xsi:nil="true" attribute for an optional 
> (minOccurs="0") SimpleType element causing issue while processing of SOAP 
> request
> -
>
> Key: XMLBEANS-426
> URL: https://issues.apache.org/jira/browse/XMLBEANS-426
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Binding
>Affects Versions: Version 2.4 
> Environment: Windows OS, WAS 6.1,  xbean-2.4.0. AXIS2 with XMLBeans 
> binding for SOAP requests at client side. AXIS2 with ADB bindings at server 
> side.
>Reporter: Pundarikakshaiah Ganduri
>Priority: Blocker
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> In my project we are using AXIS2 along with XMLBeans binding to generate the 
> payload classes for the web services. The XSD has an element like  name="LoanPurposeDesc" type="xs:string" minOccurs="0" /> 
> The generated SOAP request xml contains the empty element for this field 
> "LoanPurposeDesc" with a xsi:nil="true" attribute as shown below. 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> This is causing the parsing error message on the receiving end of the SOAP 
> request. 
> Due to this the parser is throwing the error like for the element that is of 
> SimpleType the only expected attribute is its namespace declaration. 
> For time being to avoid this issue I have modified following way:
> Changed XSD to modify the defintion of that element as:
>  nillable="true"/>
> And changed the printSetterImpls() method of 
> org.apache.xmlbeans.impl.schema.SchemaTypeCodePrinter class so that it calls 
> the unSet methd of a property if the property value is coming as null as 
> below:
>   if (nillable
>   && optional
>   && !(javaType >= 
> SchemaProperty.JAVA_FIRST_PRIMITIVE && javaType <= 
> SchemaProperty.JAVA_LAST_PRIMITIVE)) {
>   emit("if ("+safeVarName+" == null){");
>   emit("\tunset" + propertyName + "();");
>   emit("return;");
>   emit("}");
>   
>   }
> Please provide a resolution for this or confirm if we can use the changes I 
> have specified.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-428) XmlException "Unexpected element: CDATA" is thrown when file size is 8k+1byte



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-428.
-
Fix Version/s: Version 5.1.0
   Resolution: Not A Problem

Piccolo is not used anymore.

> XmlException "Unexpected element: CDATA" is thrown when file size is 8k+1byte
> -
>
> Key: XMLBEANS-428
> URL: https://issues.apache.org/jira/browse/XMLBEANS-428
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 2.5
>Reporter: Volodymyr Bychkoviak
>Priority: Major
> Fix For: Version 5.1.0
>
> Attachments: test.tgz
>
>
> When xml file is 8193bytes (8k+1) and have CRLF in the end (after closing 
> tag) then exception "Unexpected element: CDATA" is thrown.
> Maybe it is somehow related to 8k buffer used in XMLReaderReader and 
> XMLStreamReader classes
> reproducible on latest svn revision (r884309)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-471) toString() and xmlText() break when "<\" appears at specific position with a & in the value of the tag.



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-471.
-
Fix Version/s: Version 5.1.0
   Resolution: Not A Problem

I've tried it with the following snipplet. The error doesn't occur anymore, 
i.e. apart of line-endings the contents match.
We've replace Piccolo a while back, which might have been the source of this 
problem.

{{try (FileInputStream fis = new FileInputStream("Test.xml");}}
{{    FileOutputStream fos = new FileOutputStream("Text.out.xml");}}
{{    OutputStreamWriter osw = new OutputStreamWriter(fos, 
StandardCharsets.UTF_8)) {}}
{{    XmlObject xo = XmlObject.Factory.parse(fis);}}
{{    osw.write(xo.xmlText());}}
{{}}}

> toString() and xmlText() break when "<\" appears at specific position with a 
> & in the value of the tag.
> ---
>
> Key: XMLBEANS-471
> URL: https://issues.apache.org/jira/browse/XMLBEANS-471
> Project: XMLBeans
>  Issue Type: Bug
>  Components: XmlObject
> Environment: Windows, Unix, JAVA.
>Reporter: Sweta Dhanuka
>Priority: Major
> Fix For: Version 5.1.0
>
> Attachments: Test.xml
>
>
> I am trying to convert a an XMLObject to a String. I tried using both the 
> toString() and xmltext() methods. They work fine in most of the cases, but it 
> seems they garble up the xml when converting to String when certain 
> conditions are met. The conditions are:
>  - the closing tag ("<\" ) starts right after the 131072(i.e.,128K) character 
>  - the text value preceding the "<\" characters has a special character such 
> as &
>  - there are more than 3 characters between the special character and the 
> closing tag. 
> If these conditions are met, then the text 3 characters after the special 
> character, till teh closing tag "<\" is overlayed at the start of the string..



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-226) Exception "Unexpected end of file after null"



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-226.
-
Fix Version/s: Version 5.1.0
   Resolution: Not A Problem

Piccolo has been removed for a while, so this is not an issue anymore.

> Exception "Unexpected end of file after null"
> -
>
> Key: XMLBEANS-226
> URL: https://issues.apache.org/jira/browse/XMLBEANS-226
> Project: XMLBeans
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: Version 2, Version 2.1
>Reporter: Peter lynch
>Priority: Major
> Fix For: Version 5.1.0
>
>
> The problem is best described here:
> http://www.mail-archive.com/user%40xmlbeans.apache.org/msg00850.html
> Additionally I will note that the identical problem happens with Tomcat 
> 5.5.12 ( instead of Jetty). It is always reproducible.
> Using an InputStream or a BufferedReader.
> I'd prefer to use Piccolo since it is faster but it seems the safeset thing 
> to do is use another parser entirely until the problem is fixed.
> So that searches in Jira are easier, I will paste the first part of the 
> thread here as well:
>  START 
> http://www.mail-archive.com/user%40xmlbeans.apache.org/msg00850.html 
> Hi,
> I am trying to upgrade my project which uses XMLBeans v1 to XMLBeans v2.
> I have the following situation: a client (using commons-httpclient)
> posts XML to a webserver (jetty), where the posted XML is parsed using
> something like:
> SomeXmlBeansGeneratedClass.Factory.parse(request.getInputStream());
> After upgrading to XMLBeans v2, this gives the following exception on
> every other request:
> org.xml.sax.SAXParseException: Unexpected end of file after null
> org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportFatalError(Piccolo.java:1038)
> org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:723)
> org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354)
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267)
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254)
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
> org.outerx.daisy.x10Publisher.PublisherRequestDocument$Factory.parse(Unknown 
> Source)
> org.outerj.daisy.publisher.serverimpl.PublisherHttpConnector$PublisherHttpHandler.handle(PublisherHttpConnector.java:115)
> org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
> org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
> org.mortbay.http.HttpServer.service(HttpServer.java:954)
> org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
> org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
> org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Thus the first request is OK, the second one gives this exception, the
> third one is OK again, the fourth one again gives this exception etc.
> After some investigation, I have tracked down the problem to Piccolo
> which only closes the InputStream of the previous parse when doing a new
> parse, i.e. the following in the class Piccolo:
> public void parse(InputSource source) throws IOException, SAXException {
> try {
> reset();
> validateParseState();
> try {
> docEntity.reset(source);
> lexer.reset(docEntity);
> whereby the docEntity.reset method does the close.
> I tried to fix this by doing a docEntity.close() in the finally.
> However, this then causes an NPE in PiccoloSaxLoader.postLoad where it
> tries to get the encoding and version from the piccolo parser after the
> parse finished. After temporarily disabling these lines, I found that
> everything worked OK and I did not have the above exception anymore.
> The reason I get this problem is probably specific to the Jetty
> situation, as Jetty seems to reuse the same InputStream object between
> different requests, and I could work around it by wrapping Jetty's input
> stream in a custom input stream which ignores additional close calls,
> but it would be nice if this was fixed in XMLBeans. I assume a user can
> expect that XMLBeans does not keep references to the inputstream after
> the parse finished.
> Thanks in advance,
> Bruno.
> -- 
> Bruno Dumon http://outerthought.org/
> Outerthought - O

[jira] [Reopened] (XMLBEANS-426) Generated XML from an XSD contains xsi:nil="true" attribute for an optional (minOccurs="0") SimpleType element causing issue while processing of SOAP request



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker reopened XMLBEANS-426:
-

> Generated XML from an XSD contains xsi:nil="true" attribute for an optional 
> (minOccurs="0") SimpleType element causing issue while processing of SOAP 
> request
> -
>
> Key: XMLBEANS-426
> URL: https://issues.apache.org/jira/browse/XMLBEANS-426
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Binding
>Affects Versions: Version 2.4 
> Environment: Windows OS, WAS 6.1,  xbean-2.4.0. AXIS2 with XMLBeans 
> binding for SOAP requests at client side. AXIS2 with ADB bindings at server 
> side.
>Reporter: Pundarikakshaiah Ganduri
>Priority: Blocker
> Fix For: Version 5.1.0
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> In my project we are using AXIS2 along with XMLBeans binding to generate the 
> payload classes for the web services. The XSD has an element like  name="LoanPurposeDesc" type="xs:string" minOccurs="0" /> 
> The generated SOAP request xml contains the empty element for this field 
> "LoanPurposeDesc" with a xsi:nil="true" attribute as shown below. 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> This is causing the parsing error message on the receiving end of the SOAP 
> request. 
> Due to this the parser is throwing the error like for the element that is of 
> SimpleType the only expected attribute is its namespace declaration. 
> For time being to avoid this issue I have modified following way:
> Changed XSD to modify the defintion of that element as:
>  nillable="true"/>
> And changed the printSetterImpls() method of 
> org.apache.xmlbeans.impl.schema.SchemaTypeCodePrinter class so that it calls 
> the unSet methd of a property if the property value is coming as null as 
> below:
>   if (nillable
>   && optional
>   && !(javaType >= 
> SchemaProperty.JAVA_FIRST_PRIMITIVE && javaType <= 
> SchemaProperty.JAVA_LAST_PRIMITIVE)) {
>   emit("if ("+safeVarName+" == null){");
>   emit("\tunset" + propertyName + "();");
>   emit("return;");
>   emit("}");
>   
>   }
> Please provide a resolution for this or confirm if we can use the changes I 
> have specified.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] (XMLBEANS-426) Generated XML from an XSD contains xsi:nil="true" attribute for an optional (minOccurs="0") SimpleType element causing issue while processing of SOAP request



[ https://issues.apache.org/jira/browse/XMLBEANS-426 ]


Andreas Beeker deleted comment on XMLBEANS-426:
-

was (Author: kiwiwings):
Piccolo has been removed for a while, so this is not an issue anymore.

> Generated XML from an XSD contains xsi:nil="true" attribute for an optional 
> (minOccurs="0") SimpleType element causing issue while processing of SOAP 
> request
> -
>
> Key: XMLBEANS-426
> URL: https://issues.apache.org/jira/browse/XMLBEANS-426
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Binding
>Affects Versions: Version 2.4 
> Environment: Windows OS, WAS 6.1,  xbean-2.4.0. AXIS2 with XMLBeans 
> binding for SOAP requests at client side. AXIS2 with ADB bindings at server 
> side.
>Reporter: Pundarikakshaiah Ganduri
>Priority: Blocker
> Fix For: Version 5.1.0
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> In my project we are using AXIS2 along with XMLBeans binding to generate the 
> payload classes for the web services. The XSD has an element like  name="LoanPurposeDesc" type="xs:string" minOccurs="0" /> 
> The generated SOAP request xml contains the empty element for this field 
> "LoanPurposeDesc" with a xsi:nil="true" attribute as shown below. 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> This is causing the parsing error message on the receiving end of the SOAP 
> request. 
> Due to this the parser is throwing the error like for the element that is of 
> SimpleType the only expected attribute is its namespace declaration. 
> For time being to avoid this issue I have modified following way:
> Changed XSD to modify the defintion of that element as:
>  nillable="true"/>
> And changed the printSetterImpls() method of 
> org.apache.xmlbeans.impl.schema.SchemaTypeCodePrinter class so that it calls 
> the unSet methd of a property if the property value is coming as null as 
> below:
>   if (nillable
>   && optional
>   && !(javaType >= 
> SchemaProperty.JAVA_FIRST_PRIMITIVE && javaType <= 
> SchemaProperty.JAVA_LAST_PRIMITIVE)) {
>   emit("if ("+safeVarName+" == null){");
>   emit("\tunset" + propertyName + "();");
>   emit("return;");
>   emit("}");
>   
>   }
> Please provide a resolution for this or confirm if we can use the changes I 
> have specified.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-426) Generated XML from an XSD contains xsi:nil="true" attribute for an optional (minOccurs="0") SimpleType element causing issue while processing of SOAP request



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-426.
-
Fix Version/s: Version 5.1.0
   Resolution: Not A Problem

Piccolo has been removed for a while, so this is not an issue anymore.

> Generated XML from an XSD contains xsi:nil="true" attribute for an optional 
> (minOccurs="0") SimpleType element causing issue while processing of SOAP 
> request
> -
>
> Key: XMLBEANS-426
> URL: https://issues.apache.org/jira/browse/XMLBEANS-426
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Binding
>Affects Versions: Version 2.4 
> Environment: Windows OS, WAS 6.1,  xbean-2.4.0. AXIS2 with XMLBeans 
> binding for SOAP requests at client side. AXIS2 with ADB bindings at server 
> side.
>Reporter: Pundarikakshaiah Ganduri
>Priority: Blocker
> Fix For: Version 5.1.0
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> In my project we are using AXIS2 along with XMLBeans binding to generate the 
> payload classes for the web services. The XSD has an element like  name="LoanPurposeDesc" type="xs:string" minOccurs="0" /> 
> The generated SOAP request xml contains the empty element for this field 
> "LoanPurposeDesc" with a xsi:nil="true" attribute as shown below. 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> This is causing the parsing error message on the receiving end of the SOAP 
> request. 
> Due to this the parser is throwing the error like for the element that is of 
> SimpleType the only expected attribute is its namespace declaration. 
> For time being to avoid this issue I have modified following way:
> Changed XSD to modify the defintion of that element as:
>  nillable="true"/>
> And changed the printSetterImpls() method of 
> org.apache.xmlbeans.impl.schema.SchemaTypeCodePrinter class so that it calls 
> the unSet methd of a property if the property value is coming as null as 
> below:
>   if (nillable
>   && optional
>   && !(javaType >= 
> SchemaProperty.JAVA_FIRST_PRIMITIVE && javaType <= 
> SchemaProperty.JAVA_LAST_PRIMITIVE)) {
>   emit("if ("+safeVarName+" == null){");
>   emit("\tunset" + propertyName + "();");
>   emit("return;");
>   emit("}");
>   
>   }
> Please provide a resolution for this or confirm if we can use the changes I 
> have specified.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-592) still some generated code that use List return type without setting the inner type (generics)

2022-02-09 Thread Andreas Beeker (Jira)



[ 
https://issues.apache.org/jira/browse/XMLBEANS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489806#comment-17489806
 ] 

Andreas Beeker commented on XMLBEANS-592:
-

if you look for those occurrences at build/generated/sources/base/main, they 
are all part of XmlAnySimpleType implementations.

I don't think it will be feasible to provide an java.lang.Object alternative. 
Any polymorphic solution would be more complex than simply instance checking 
the return type for a primitive wrapper.

> still some generated code that use List return type without setting the inner 
> type (generics)
> -
>
> Key: XMLBEANS-592
> URL: https://issues.apache.org/jira/browse/XMLBEANS-592
> Project: XMLBeans
>  Issue Type: Improvement
>Reporter: PJ Fanning
>Priority: Minor
>
> java.util.List getListValue();
> java.util.List xgetListValue();



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-595) upgrade to saxon 11.1

2022-02-09 Thread Andreas Beeker (Jira)



[ 
https://issues.apache.org/jira/browse/XMLBEANS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489774#comment-17489774
 ] 

Andreas Beeker commented on XMLBEANS-595:
-

As of Saxon 11.1.1, can we resolve this now for the trunk?

> upgrade to saxon 11.1 
> --
>
> Key: XMLBEANS-595
> URL: https://issues.apache.org/jira/browse/XMLBEANS-595
> Project: XMLBeans
>  Issue Type: Improvement
>  Components: XPath
>Reporter: PJ Fanning
>Priority: Major
> Fix For: Version 5.1.0
>
>
> From Saxon 10.6.
> Early analysis indicates this upgrade breaks compatibility so XMLBeans and 
> POI users should not use Saxon 11.x until there is a new XMLBeans release 
> that officially supports Saxon 11.x.
> It does cause compile problems (see below) and also requires that users add 
> an extra jar to their classpath (https://saxonica.plan.io/issues/5265).
>  
> {code:java}
>                 return DateTimeValue.makeDateTimeValue(value.toString(), 
> config.getConversionRules()).asAtomic();
>                                     ^
>     method 
> net.sf.saxon.value.DateTimeValue.makeDateTimeValue(net.sf.saxon.value.DateValue,net.sf.saxon.value.TimeValue)
>  is not applicable
>       (argument mismatch; java.lang.String cannot be converted to 
> net.sf.saxon.value.DateValue)
>     method 
> net.sf.saxon.value.DateTimeValue.makeDateTimeValue(net.sf.saxon.str.UnicodeString,net.sf.saxon.lib.ConversionRules)
>  is not applicable
>       (argument mismatch; java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString)
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:258:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return DateValue.makeDateValue(value.toString(), 
> config.getConversionRules()).asAtomic();
>                                                              ^
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:260:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return TimeValue.makeTimeValue(value.toString()).asAtomic();
>                                                              ^
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:262:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return GYearValue.makeGYearValue(value.toString(), 
> config.getConversionRules()).asAtomic();
>                                                                ^
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:264:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return GYearMonthValue.makeGYearMonthValue(value.toString(), 
> config.getConversionRules()).asAtomic();
>                                                                          ^
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:271:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return GMonthValue.makeGMonthValue(val).asAtomic();
>                                                    ^
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:273:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return 
> GMonthDayValue.makeGMonthDayValue(value.toString()).asAtomic();
>                                                                        ^
> /Users/pj.fanning/svn/xmlbeans/src/main/java/org/apache/xmlbeans/impl/xpath/saxon/SaxonXQuery.java:275:
>  error: incompatible types: java.lang.String cannot be converted to 
> net.sf.saxon.str.UnicodeString
>                 return GDayValue.makeGDayValue(value.toString()).asAtomic(); 
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-596) Upgrade to Junit 5

2022-02-05 Thread Andreas Beeker (Jira)



[ 
https://issues.apache.org/jira/browse/XMLBEANS-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487617#comment-17487617
 ] 

Andreas Beeker commented on XMLBEANS-596:
-

Applied via 
[r1897795|http://svn.apache.org/viewvc?view=revision&revision=1897795]

> Upgrade to Junit 5
> --
>
> Key: XMLBEANS-596
> URL: https://issues.apache.org/jira/browse/XMLBEANS-596
> Project: XMLBeans
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: Version 5.1.0
>Reporter: Andreas Beeker
>Assignee: Andreas Beeker
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rework tests to be suitable for Junit 5.
> Replace try, fail, catch constructs with assertThrows.
> Use ParameterizedTest annotation where suitable.
> Later on, we can try to parallelize the tests. 
> Open todos: adapt ant-junit tests - see CompilationTests.testSimple for an 
> example on how to launch Junit5 tests from the runtime



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Created] (XMLBEANS-596) Upgrade to Junit 5

2022-02-05 Thread Andreas Beeker (Jira)

Andreas Beeker created XMLBEANS-596:
---

 Summary: Upgrade to Junit 5
 Key: XMLBEANS-596
 URL: https://issues.apache.org/jira/browse/XMLBEANS-596
 Project: XMLBeans
  Issue Type: Improvement
  Components: Tools
Affects Versions: Version 5.1.0
Reporter: Andreas Beeker
Assignee: Andreas Beeker


Rework tests to be suitable for Junit 5.

Replace try, fail, catch constructs with assertThrows.

Use ParameterizedTest annotation where suitable.

Later on, we can try to parallelize the tests. 

Open todos: adapt ant-junit tests - see CompilationTests.testSimple for an 
example on how to launch Junit5 tests from the runtime



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Java 9+ build issues

2022-01-22 Thread Andreas Beeker


HI,

On 22.01.22 15:37, PJ Fanning wrote:

I've tried to fix the build issues in Java 9+ that happened after 
https://github.com/apache/poi/commit/bba249d52207799dc984efd884353aa4783c1c40


If anyone knows more about Jigsaw modules than me (and I don't much) -- maybe 
they can have a look.


I think that change makes things more complicated, the test classes sometimes 
use the main classes on a package level, i.e. what a user code can't do. 
Therefore with JPMS they are either in the same jar or we use patch-module more 
extensively. Referencing the test archives seems to be easier than specifying 
the patch-modules for each transitive module.

I'm not sure, if this was a thought involved, but working on the class output directories 
directly (aka in "gradle style") instead on the jars probably doesn't work 
correctly with JPMS.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache POI 5.2.0 release (RC2)

2022-01-09 Thread Andreas Beeker


+1 from me. Thank you for providing the release, PJ!

Eventually we need to decide, if we only provide the logging api jars or also 
the implementation,
as SLF4J is used at least in XmlSec and providing the api is not enough [1].
On the other side for log4j-shell, we had the excuse of only providing the api 
...

Andi

[1] https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-585) add sonarqube build

2022-01-08 Thread Andreas Beeker (Jira)



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-585.
-
Resolution: Fixed

Sonarqube issues are now available:

https://sonarcloud.io/project/issues?id=apache_xmlbeans&resolved=false

> add sonarqube build
> ---
>
> Key: XMLBEANS-585
> URL: https://issues.apache.org/jira/browse/XMLBEANS-585
> Project: XMLBeans
>  Issue Type: Improvement
>Reporter: PJ Fanning
>    Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.1.0
>
>
> We have one for POI already so this can be used to guide how to do it for 
> XMLBeans



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-47) Inner Class Handler is not supported



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-47.

Fix Version/s: Version 5.1.0
 Assignee: (was: Cezar Cristian Andrei)
   Resolution: Fixed

I think this test covers this issue: 
xmlobject.extensions.interfaceFeature.methodNameCollision.checkin.NameCollisionTest

... it works with inner static interfaces and the resulting name collisions.

> Inner Class Handler is not supported
> 
>
> Key: XMLBEANS-47
> URL: https://issues.apache.org/jira/browse/XMLBEANS-47
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: Version 2 Beta 1
> Environment: Windows 2000, JDK 1.4.2_05
>Reporter: jean-christophe.pazzaglia
>Priority: Minor
> Fix For: Version 5.1.0, Version 2 Beta 2
>
>
>  tried to move my 'Handler' as an inner classes
> of the 'Inteface' and I get a 'Class not found' if I refer
> to it as 'Interface.Handler' in the xsdconfig
> [java] FigureWithExt.xsdconfig:0: error: Class 
> 'AreaInterface.FigureSquareHandler' not found.
> [java] FigureWithExt.xsdconfig:0: error: Handler class 
> 'AreaInterface.FigureSquareHandler' not found on classpath, skip validation.
> ie using the example on my previous post,
> it is complaining when I am doing something like :
> 
>   
>   
> AreaInterface.FigureSquareHandler
>   
>   
> [using AreaInterface$FigureSquareHandler but do not 'java' compile]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-567) Problems with XMLBeans Extension Interfaces Feature



[ 
https://issues.apache.org/jira/browse/XMLBEANS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470246#comment-17470246
 ] 

Andreas Beeker commented on XMLBEANS-567:
-

I've fixed some disabled test regarding the extension interfaces. Beside the 
javaparser, you'll also need the javaparser-symbol-solver-core jar. Please try 
it again with the trunk version. If it doesn't work, please provide me the test 
files.

> Problems with XMLBeans Extension Interfaces Feature
> ---
>
> Key: XMLBEANS-567
> URL: https://issues.apache.org/jira/browse/XMLBEANS-567
> Project: XMLBeans
>  Issue Type: Task
>Affects Versions: Version 5.0.0
>Reporter: Dmitry Lastochkin
>Priority: Major
>
> Hello! In our project we are using [XMLBeans Extension Interfaces 
> Feature|https://cwiki.apache.org/confluence/display/XMLBEANS/ExtensionInterfacesFeature].
>  When we compile the TypeSystem (using {{SchemaTypeSystemCompiler.compile}}), 
> we add the jar with our extension classes to classpath parameter. In XMLBeans 
> 2.4 it works perfectly. But when we updated to XMLBeans 5.0.0, we encountered 
> the following error during an extensions validation:
> {code}
> Interface 'SomeInterface' not found."
> {code}
> As far as I understand, this is because 
> {{org.apache.xmlbeans.impl.config.Parser}} does not search classes in 
> classpath (only in files). 
> When we added the sources of the extension interface to the parameters, 
> TypeSystem compiled successfuly. But then we ran into another problem. When 
> XMLBeans generates java files from XSD, it uses simple class names (instead 
> of fully qualified names as it was in XMLBeans 2.4.0) for the classes that 
> are used in methods of the extension interface (like parameters types or 
> return types). And therefore the geneted files cannot be compiled if the 
> extension classes are in a different package.
> Are those changes (ingorning classpath when searching for extenstions  and 
> using simple names for extenstion classes in code generation instead of fully 
> qualified names) were made intentionally? Such limitations are hard to work 
> around, making an upgrade from older XMLBeans version very complicated.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-422) org.apache.xmlbeans.XmlException: error: Unexpected end of file while parsing xml-document



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-422.
-
Fix Version/s: Version 5.1.0
   Resolution: Abandoned

This issue is ancient and in the meantime we removed the Picco parser, which 
might have been the reason for this error.

> 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
>Priority: Major
> Fix For: Version 5.1.0
>
>
> 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 was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-421) Link to XMLBeans Samples on Getting Started is dead



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-421.
-
Fix Version/s: Version 5.1.0
   Resolution: Not A Problem

The docs aren't provided anymore in the binary archive and the website (and its 
links) have been rearranged a while ago.

> 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
> Fix For: Version 5.1.0
>
>
> 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 was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-416) When specifying user types in an xsdconfig, types that are not being compiled cannot be referenced properly



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-416.
-
Fix Version/s: (was: TBD)
   Version 5.1.0
   Resolution: Fixed

Applied via 
[r1896770|https://svn.apache.org/viewvc?view=revision&revision=1896770]

> When specifying user types in an xsdconfig, types that are not being compiled 
> cannot be referenced properly
> ---
>
> Key: XMLBEANS-416
> URL: https://issues.apache.org/jira/browse/XMLBEANS-416
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: TBD
>Reporter: Wesley Leggette
>Priority: Minor
> Fix For: Version 5.1.0
>
> Attachments: fix-cross-xsd-user-types.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Fixes issue where specifying user types in an xsdconfig for types that are 
> not currently be compiled (but are being referenced) does not work.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-391) Assert in Xobj.fetch_text() firing in seemingly ok cases



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-391.
-
Fix Version/s: Version 5.1.0
   Resolution: Cannot Reproduce

This error is not reproducible anymore. So it seems to be fixed in the past.

> Assert in Xobj.fetch_text() firing in seemingly ok cases
> 
>
> Key: XMLBEANS-391
> URL: https://issues.apache.org/jira/browse/XMLBEANS-391
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Cursor
>Affects Versions: Version 2.4.1 
>Reporter: Radu Preotiuc
>Priority: Minor
> Fix For: Version 5.1.0
>
>
> Xobj.fetch_text() starts with an assert like this:
> assert isValid() && isOccupied();
> But it seems that sometimes this 'assert' fires incorrectly. Here's a repro 
> case:
> Schema:
> 
> http://www.w3.org/2001/XMLSchema"; xmlns="http://cfnxml"; 
> targetNamespace="http://cfnxml";
> elementFormDefault="qualified">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Document ("test.xml"):
> 
> http://cfnxml"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 
> 100
> 
> 
> Code:
> File f = new File("test.xml");
> XmlObject doc = XmlObject.Factory.parse(f);
> System.out.println("Root type = " + doc.schemaType());
> System.out.println("Valid = " + doc.validate());
> InvoiceType invoice = ((RootDocument) doc).getRoot().getInvoice();
> invoice.setTermsOfPaymentId(null);
> invoice.setTermsOfPaymentId(BigInteger.valueOf(10));
> invoice.getTermsOfPaymentId();
> System.out.println("Final document = " + doc.xmlText());
> If you run the repro with assertions enabled, then the assert fires, but if 
> you disable assertions, the repro seems to work, so maybe the assert is 
> incorrect.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-423) Extra semi-colon in SchemaTypeCodePrinter changes apparent semantics of 'if' statement



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-423.
-
Fix Version/s: Version 5.1.0
   Resolution: Cannot Reproduce

There have been so many changes to SchemaCodePrinter and even after fixing the 
[svn 
url|https://svn.apache.org/viewvc/xmlbeans/trunk/src/main/java/org/apache/xmlbeans/SchemaCodePrinter.java?annotate=799073]
  I don't see where this duplicated semicolon is mentioned. 

 

> 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
> Fix For: Version 5.1.0
>
>
> See line 807:
> http://svn.apache.org/viewvc/xmlbeans/trunk/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeCodePrinter.java?annotate=799073



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Resolved] (XMLBEANS-425) Wrong class loaded



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker resolved XMLBEANS-425.
-
Fix Version/s: Version 5.1.0
 Assignee: Andreas Beeker
   Resolution: Works for Me

> Wrong class loaded
> --
>
> Key: XMLBEANS-425
> URL: https://issues.apache.org/jira/browse/XMLBEANS-425
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 2.4 
>Reporter: Matej Perse
>    Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.1.0
>
> Attachments: model_2009-11-24.xsd, model_2009-11-24.xsdconfig, 
> posebniVpliviSchema.jar, posebni_vplivi_2009-11-24.xsd, 
> posebni_vplivi_2009-11-24.xsdconfig, xmlSchema.jar, xmlbeans-425.zip
>
>
> Hi,
> We get an rather unusual exception. We building two separate packages 
> (posebniVpliviSchema and xmlSchema) from two different schemas. In both 
> packegies we have the same class name (PosebniVpliviDocumentImpl.class).
> When we include both packages into the same project, we obtain the following 
> error:
> com.sinergise.pvn.xmlSchema.impl.PosebniVpliviDocumentImpl
> java.lang.ClassCastException: 
> com.sinergise.pvn.xmlSchema.impl.PosebniVpliviDocumentImpl
> at 
> com.sinergise.pvn.posebniVpliviSchema.PosebniVpliviDocument$Factory.parse(PosebniVpliviDocument.java:59)
> at 
> com.sinergise.pvn.server.utils.XMLImporter.savePosebniVplivi(XMLImporter.java:280)
> at com.sinergise.pvn.server.main.PVNImporter.main(PVNImporter.java:60)
> As you can see from the error, we parse the xml document using the 
> "posebniVpliviSchema" package but in the parsing process the XMLBeans try to 
> use the class from the "xmlSchema" package.
> It looks like the package information is completely ignored since when we 
> invert the order of the linked project the above error is resolved, but then 
> we get the error in the other project.
> Regards,
> Matej



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-425) Wrong class loaded



[ 
https://issues.apache.org/jira/browse/XMLBEANS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467704#comment-17467704
 ] 

Andreas Beeker commented on XMLBEANS-425:
-

I've created sample xmls and a test class. If the schemas are generated 
seperately with different xmlbeans schema aliases, it works.

The reason might be a change in the SchemaTypeLoader a while ago.

[^xmlbeans-425.zip]

> Wrong class loaded
> --
>
> Key: XMLBEANS-425
> URL: https://issues.apache.org/jira/browse/XMLBEANS-425
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 2.4 
>Reporter: Matej Perse
>Priority: Major
> Attachments: model_2009-11-24.xsd, model_2009-11-24.xsdconfig, 
> posebniVpliviSchema.jar, posebni_vplivi_2009-11-24.xsd, 
> posebni_vplivi_2009-11-24.xsdconfig, xmlSchema.jar, xmlbeans-425.zip
>
>
> Hi,
> We get an rather unusual exception. We building two separate packages 
> (posebniVpliviSchema and xmlSchema) from two different schemas. In both 
> packegies we have the same class name (PosebniVpliviDocumentImpl.class).
> When we include both packages into the same project, we obtain the following 
> error:
> com.sinergise.pvn.xmlSchema.impl.PosebniVpliviDocumentImpl
> java.lang.ClassCastException: 
> com.sinergise.pvn.xmlSchema.impl.PosebniVpliviDocumentImpl
> at 
> com.sinergise.pvn.posebniVpliviSchema.PosebniVpliviDocument$Factory.parse(PosebniVpliviDocument.java:59)
> at 
> com.sinergise.pvn.server.utils.XMLImporter.savePosebniVplivi(XMLImporter.java:280)
> at com.sinergise.pvn.server.main.PVNImporter.main(PVNImporter.java:60)
> As you can see from the error, we parse the xml document using the 
> "posebniVpliviSchema" package but in the parsing process the XMLBeans try to 
> use the class from the "xmlSchema" package.
> It looks like the package information is completely ignored since when we 
> invert the order of the linked project the above error is resolved, but then 
> we get the error in the other project.
> Regards,
> Matej



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Updated] (XMLBEANS-425) Wrong class loaded



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker updated XMLBEANS-425:

Attachment: xmlbeans-425.zip

> Wrong class loaded
> --
>
> Key: XMLBEANS-425
> URL: https://issues.apache.org/jira/browse/XMLBEANS-425
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 2.4 
>Reporter: Matej Perse
>Priority: Major
> Attachments: model_2009-11-24.xsd, model_2009-11-24.xsdconfig, 
> posebniVpliviSchema.jar, posebni_vplivi_2009-11-24.xsd, 
> posebni_vplivi_2009-11-24.xsdconfig, xmlSchema.jar, xmlbeans-425.zip
>
>
> Hi,
> We get an rather unusual exception. We building two separate packages 
> (posebniVpliviSchema and xmlSchema) from two different schemas. In both 
> packegies we have the same class name (PosebniVpliviDocumentImpl.class).
> When we include both packages into the same project, we obtain the following 
> error:
> com.sinergise.pvn.xmlSchema.impl.PosebniVpliviDocumentImpl
> java.lang.ClassCastException: 
> com.sinergise.pvn.xmlSchema.impl.PosebniVpliviDocumentImpl
> at 
> com.sinergise.pvn.posebniVpliviSchema.PosebniVpliviDocument$Factory.parse(PosebniVpliviDocument.java:59)
> at 
> com.sinergise.pvn.server.utils.XMLImporter.savePosebniVplivi(XMLImporter.java:280)
> at com.sinergise.pvn.server.main.PVNImporter.main(PVNImporter.java:60)
> As you can see from the error, we parse the xml document using the 
> "posebniVpliviSchema" package but in the parsing process the XMLBeans try to 
> use the class from the "xmlSchema" package.
> It looks like the package information is completely ignored since when we 
> invert the order of the linked project the above error is resolved, but then 
> we get the error in the other project.
> Regards,
> Matej



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-586) Migrate ant build to gradle



[ 
https://issues.apache.org/jira/browse/XMLBEANS-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467051#comment-17467051
 ] 

Andreas Beeker commented on XMLBEANS-586:
-

Applied via 
[r1896561|https://svn.apache.org/viewvc?view=revision&revision=1896561]

> Migrate ant build to gradle
> ---
>
> Key: XMLBEANS-586
> URL: https://issues.apache.org/jira/browse/XMLBEANS-586
> Project: XMLBeans
>  Issue Type: Task
>Affects Versions: Version 5.1.0
>    Reporter: Andreas Beeker
>Assignee: Andreas Beeker
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> as the title says ... migrate the ant build to gradle to benefit various 
> features like automatic dependency version update notifications



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Updated] (XMLBEANS-586) Migrate ant build to gradle



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker updated XMLBEANS-586:

Affects Version/s: Version 5.1.0
   (was: TBD)

> Migrate ant build to gradle
> ---
>
> Key: XMLBEANS-586
> URL: https://issues.apache.org/jira/browse/XMLBEANS-586
> Project: XMLBeans
>  Issue Type: Task
>Affects Versions: Version 5.1.0
>        Reporter: Andreas Beeker
>    Assignee: Andreas Beeker
>Priority: Major
>
> as the title says ... migrate the ant build to gradle to benefit various 
> features like automatic dependency version update notifications



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Created] (XMLBEANS-586) Migrate ant build to gradle

Andreas Beeker created XMLBEANS-586:
---

 Summary: Migrate ant build to gradle
 Key: XMLBEANS-586
 URL: https://issues.apache.org/jira/browse/XMLBEANS-586
 Project: XMLBeans
  Issue Type: Task
Affects Versions: TBD
Reporter: Andreas Beeker
Assignee: Andreas Beeker


as the title says ... migrate the ant build to gradle to benefit various 
features like automatic dependency version update notifications



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

XmlBeans - migrate gradle build

2021-12-30 Thread Andreas Beeker


Hi Devs,

I think the gradle build is ready and I will merge now the changes to the trunk.

I haven't fixed/adapted the ant build anymore - I hope you are ok with that.

After merging, I'll adapt the jenkins configs. The docs around building are 
also to be adapted.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-585) add sonarqube build



[ 
https://issues.apache.org/jira/browse/XMLBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467000#comment-17467000
 ] 

Andreas Beeker commented on XMLBEANS-585:
-

Hopefully it's not a duplicate, but I've requested the addition: INFRA-22685

and later on set up the gradle build for it

> add sonarqube build
> ---
>
> Key: XMLBEANS-585
> URL: https://issues.apache.org/jira/browse/XMLBEANS-585
> Project: XMLBeans
>  Issue Type: Improvement
>Reporter: PJ Fanning
>Priority: Major
> Fix For: Version 5.1.0
>
>
> We have one for POI already so this can be used to guide how to do it for 
> XMLBeans



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: XmlBeans test TypesTest.testDate fails on non UTC TZ

2021-12-30 Thread Andreas Beeker


Hi,

I've activated the POI rule set for forbidden APIs locally and there are 
several locations popping up which are related to this.
I currently don't know yet on how to fix this, but my idea would be either ...
a) to use the XmlOptions somehow to set the default timezone (and locale) for 
dates - the goal is to avoid ThreadLocals. Or ...
b) for literals without timezone, we try to use the system/local timezone

As we do a) in POI - I would prefer this. And to minimize confusion, I would 
raise the version to 6.0.0 and don't provide a j.u.Date and JSR 310 support in 
parallel if we choose JSR 310.

Regarding the XPath plugins, I guess XmlCursor usage is more performant - if 
you need a kind of plugin support again, we can work something out.

Andi



-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

XmlBeans gradle migration

2021-12-27 Thread Andreas Beeker


Hi Devs,

I'm currently migrating XmlBeans to gradle:
https://svn.apache.org/repos/asf/xmlbeans/branches/gradle-build
https://svn.apache.org/viewvc?view=revision&revision=1896456

Up till now the migration contains the following changes:
* activate most of the Tests - the ant build runs only on **/*Test(s).java
* fix InterfaceExtensions
* to handle inherited methods for InterfaceExtensions, I've added the 
JavaParser solver artifact.
   the transitive dependencies need to be adjusted, because most/all 
dependencies aren't necessary ...
   maybe it would make sense to add a special gradle configuration which users 
can depend on, if they use InterfaceExtensions
* I've imported and annotated the w3c dom tests from the w3c_domts.jar to 
src/test/java.
   There were already @ignored Test mainly because of missing XmlBeans 
functionality.
   The W3C tests are under the W3C license, which is ASF compatible and 
therefore inclusion/adaption is not an issue.

What's missing:
* a few tests need to be fixed. There is one strange case with 
scomp.elements.detailed.GlobalElt... which failed when executed without 
debugger but suddenly worked when inspected ...
* javadoc, bin/src-release, rat, forbiddenapis ...

Although I guess no-one intents to, but please don't make structural changes to 
trunk, i.e. move directories, as this makes merging the branch back more 
difficult.

Best wishes,
Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache XmlBeans 5.0.3 release (RC1)

2021-12-12 Thread Andreas Beeker


+1 - I've compared the contents of 5.0.2 vs 5.0.3, and only saw those minimal 
changes.

Thank you for providing the RC.

Andi

On 12.12.21 20:56, PJ Fanning wrote:

Hi everyone,

I've prepared artifacts for the release of Apache XmlBeans 5.0.3 (RC1).

The most notable changes in this release are:

* SampleXmlUtil misses root element with only one child
* Upgrade dependencies (javaparser 3.23.1, log4j 2.15.0)


A full list of changes is available in the change log:
https://issues.apache.org/jira/projects/XMLBEANS/versions/12350699

The artifacts are at:
https://dist.apache.org/repos/dist/release/poi/xmlbeans/dev/


You can use this maven URL for your mvn/gradle builds:
https://repository.apache.org/content/repositories/staging



I haven't updated the "provided" dependencies as those have to be activated 
anyway explicitly.

Please vote to release the artifacts.
The vote keeps open until 2021-12-15 23:00 UTC.
Planned release announcement date is Friday, 2021-12-17.


Here is my +1


PJ

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: XMLBeans 5.0.3 release

2021-12-12 Thread Andreas Beeker


Hi PJ,

On 12.12.21 11:07, PJ Fanning wrote:

If there are no objections, I propose to create a RC1 for XMLBeans 5.0.3 today.


+1.

Do you prepare it or should I do it?

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Move poi:main:org.apache.poi.hssf.dev to poi:test

2021-11-25 Thread Andreas Beeker


Hi Dominik,

there's a replacement, but with a limitation.

the limitation: asking users to execute BiffViewer with the poi.jar won't work 
anymore.
I can't remember having seen this request ever.

In other usecases - use the Junit chttps://github.com/kiwiwings/poi-visualizer

Andi

On 25.11.21 07:32, Dominik Stadler wrote:

Hi Andi,

It seems you removed the main() method from BiffViewer as part of this
move. This was a handy tool on it's own for inspecting the raw contents of
.xls files, fairly useful when investigating bugs with handling of the raw
format in HSSF. Is there a replacement?

Not sure about the other tools that are gone now, they might be useful for
some specific things, but at least I did not use them much.

Thanks... Dominik.

On Sun, Nov 14, 2021 at 3:31 PM Andreas Beeker  wrote:


Hi Devs,

those *-saved.xls left-overs in the test-data directory cause/d build
problems.
I'm quite sure those are created by org.apache.poi.hssf.dev.ReSave.
I'll now move all development utils of that package to poi:test and change
the output directory to the temp path, because I think those tools are used
by developers working on the source / project ... or I'll remove a few
completely, as the same functionality is invoked many times by the other
tests.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Move poi:main:org.apache.poi.hssf.dev to poi:test

2021-11-14 Thread Andreas Beeker


Hi Devs,

those *-saved.xls left-overs in the test-data directory cause/d build problems.
I'm quite sure those are created by org.apache.poi.hssf.dev.ReSave.
I'll now move all development utils of that package to poi:test and change the 
output directory to the temp path, because I think those tools are used by 
developers working on the source / project ... or I'll remove a few completely, 
as the same functionality is invoked many times by the other tests.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache POI 5.1.0 release (RC2)

2021-10-25 Thread Andreas Beeker


Hi PJ,

thank you for your hard work in this release!

Here is my +1 and those are my 2 cents:

JPMS execution looks good from my side - I've added an instruction to 
http://poi.apache.org/components/slideshow/ppt-wmf-emf-renderer.html
So basically xml-apis-1.4.01.jar needs to be excluded for Java11+ and 
batik-script.jar be modified

build.javacheck.xml seems to be a left-over in the src zip/tgz

Yegor might want to have a look at the OSGi stuff, which can be adapted after 
the release

poi-javadoc-5.1.0.jar doesn't contain legal notices, but this is not a 
redistributable, so it doesn't matter

Not sure if we should tell users not to put poi*javadoc.jar in the same 
directory as the poi*.jar when they use JPMS - basically they shouldn't use the 
maven directory structure as a module-path as this will result in duplicate 
fake class entries

as usual the slow death of the web of trust makes it difficult for anyone who 
hasn't participate in a key signing ceremony to verify the signature ...

Andi




On 25.10.21 13:55, PJ Fanning wrote:

Hi everyone,

I've prepared artifacts for the release of Apache POI 5.1.0 (RC2).

The most notable changes in this release are:

* upgrade dependencies: XmlBeans 5.0.2, XMLSec 2.2.3, Batik 1.14, BouncyCastle 
1.69, Commons-Compress 1.21, ...
* switching build to Gradle - Ant build is not supported anymore [#65206]
* XSLFTable::addRow functionality reverted to pre-5.0.0 [github-221]
* XSSFDrawing - import chart from other drawing [#63901]
* Support for Excel functions IFS, SWITCH, TEXTJOIN, IFNA, MAXIFS, MINIFS, 
AVERAGEIFS, TDIST
* Fix SVG-related image rendering

https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC2/

https://repository.apache.org/content/groups/staging/org/apache/poi/


Things to check:
According to Stackoverflow there were some problems with JPMS and XmlBeans -
so maybe check for potential problems there.

Please vote to release the artifacts.
The vote keeps open until November 1, 2021 (23:00 UTC)
Planned release announcement date is November 3, 2021.

Here is my +1

The SVN repo is open again. Can we avoid major changes until this vote succeeds 
or starts getting -1s.

PJ



-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: POI 5.1.0 RC2?

2021-10-24 Thread Andreas Beeker


Hi PJ,

On 24.10.21 16:58, PJ Fanning wrote:

I added a change to poi-ooxml-lite gradle file to force the inclusion of the 
107 extra XSBs.

  poi-ooxml-lite 5.0.0 - XSB count=1498

poi-ooxml-lite latest snapshot - XSB count=1220

no 5.0.0 XSBs are missing from snapshot.

Is there anything else blocking an RC2? If not, I can see about creating the 
artifacts.


Thanks for taking care about the XSBs.

If you start rolling the release, please send a message to the dev list - it 
makes your life easier if no-one else commits and in cases you would need to 
fix the gradle scripts.

I'm not sure if this is essential, but I set the file stamps of the zip/tgz 
archives to the expected announcement day.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: POI 5.1.0 RC2?

2021-10-18 Thread Andreas Beeker


Hi Dominik,


Would be nice to know what changes made them required now as the documents 
themselves did not change.


I think you know, but to be safe, I mentioned it again.
Originally only the classes where filtered, but I've added the .xsb filtering 
also a while ago, to minimize the lite jar further,
because they are a substantial part of the jar.

I could iterate through all document parts and try to see if those parts are 
parsed and check the structure recursive.

On the other hand, I've optimized the xmlbeans schema generation, so the schema 
shrunk from 19mb to 13mb.
There would be the option to split the schema jar to the sub schemas including 
the necessary dependencies to the base/abstract schemas - but I guess this will 
be even more confusing for the user base.

Regarding the 107 documents, it's fairly easy to add the documents locally and 
see which deltas, i.e. not yet loaded .xsbs, are added from file to file, to 
identify the files which needed to be added to the integration directory.

Andi.

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: POI 5.1.0 RC2?

2021-10-14 Thread Andreas Beeker


"Kept you waiting, huh?" (tm) -No problem for me ... XmlBeans RC2 looks good so 
far, therefore it can be only a matter of days.


On 15.10.21 00:06, PJ Fanning wrote:

With POI trunk, I've added a use case that relies on XMLBeans 5.0.2 release. 
Can we wait until XMLBeans 5.0.2 is released? Alternatively, I can remove the 
new POI code that use XmlOptions setDisallowDocTypeDeclaration.



-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

POI 5.1.0 RC2?

2021-10-14 Thread Andreas Beeker


Hi Devs,

there were heaps of changes since RC1 and it looks like PJ is working full-time 
on POI.

When should I provide the RC2?

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache XmlBeans 5.0.2 release (RC2)

2021-10-14 Thread Andreas Beeker


Thank you again for providing the RC2 immediately.

As we provide the module-info, the Automatic-Module-Name is probably not needed.

So +1 from me.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: XMLBeans 5.0.2 release

2021-10-13 Thread Andreas Beeker


Hi PJ;

thank you for all the work you've put in the last months - actually 
unbelievable.
I think it's good, if someone else gives releasing also a try - so +1 from me.
As I made a mistake last time - please make sure to use JDK 8 for the build.

Andi


On 13.10.21 15:29, PJ Fanning wrote:

I don't think this blocks a release of POI 5.1.0. There are still a few fixes 
in XMLBeans trunk awaiting release. I can prepare a XMLBeans 5.0.2-RC1 if 
people think this is a good idea.

https://issues.apache.org/jira/browse/XMLBEANS-572?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%205.0.2%22

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Commented] (XMLBEANS-571) Excel file read failure using xmlbeans 3.0.0 whereas it works on xmlbeans 2.6.0

2021-09-27 Thread Andreas Beeker (Jira)



[ 
https://issues.apache.org/jira/browse/XMLBEANS-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420993#comment-17420993
 ] 

Andreas Beeker commented on XMLBEANS-571:
-

although this thread was already quite entertaining, I wonder if JDK6 is 
something which keeps you from upgrading beyond POI 3.X. If so, security seems 
not so important ... otherwise POI 4.x and 5.x have a baseline of JDK8 and 
provide support for JPMS (JDK9+). You are better off using a current 
POI/XmlBeans version - of course you need to test those first! - as we try to 
be compatible with current JDKs and also update our dependencies + fix findings 
of Sonar.
Sticking around with that old version means also sticking with the old 
dependencies.

You haven't actually mentioned what blocks you apart of "dependencies", maybe 
we can help you there, if it's related to POI/XmlBeans

> Excel file read failure using xmlbeans 3.0.0 whereas it works on xmlbeans 
> 2.6.0
> ---
>
> Key: XMLBEANS-571
> URL: https://issues.apache.org/jira/browse/XMLBEANS-571
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 3.0.0
> Environment: linux
>Reporter: Sateesh
>Priority: Blocker
> Fix For: Version 3.0.0
>
> Attachments: XLSXReaderExample.java, test.xlsx
>
>
> I have an Excel file cell with note processing successfully with Apache POI 
> 3.14 + xmlbeans 2.6.0. 
> But when we moved to xmlbeans 3.0.0 it fails with following exception. If 
> I delete the note in the Excel file it processes successfully with 3.0.0. 
> Attached the testcase
> Source_File,0: org.apache.poi.POIXMLException: 
> java.lang.reflect.InvocationTargetException
>  at 
> org.apache.poi.POIXMLFactory.createDocumentPart(POIXMLFactory.java:65)
>  at 
> org.apache.poi.POIXMLDocumentPart.read(POIXMLDocumentPart.java:601)
>  at 
> org.apache.poi.POIXMLDocumentPart.read(POIXMLDocumentPart.java:613)
>  at org.apache.poi.POIXMLDocument.load(POIXMLDocument.java:174)
>  at 
> org.apache.poi.xssf.usermodel.XSSFWorkbook.(XSSFWorkbook.java:249)
>  ...
> Caused by: java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
>  at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83)
>  at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
>  at java.lang.reflect.Constructor.newInstance(Constructor.java:437)
>  at 
> org.apache.poi.xssf.usermodel.XSSFFactory.createDocumentPart(XSSFFactory.java:56)
>  at 
> org.apache.poi.POIXMLFactory.createDocumentPart(POIXMLFactory.java:62)
>  ... 12 more
> Caused by: org.apache.xmlbeans.XmlException: error: Content is not allowed 
> in trailing section.
>  at 
> org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3439)
>  at 
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1271)
>  at 
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1258)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
>  at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:747)
>  at 
> org.apache.poi.xssf.usermodel.XSSFVMLDrawing.read(XSSFVMLDrawing.java:128)
>  at 
> org.apache.poi.xssf.usermodel.XSSFVMLDrawing.(XSSFVMLDrawing.java:116)
>  ... 18 more
> Caused by: org.xml.sax.SAXParseException: Content is not allowed in 
> trailing section.
>  at 
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
> Source)
>  at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown 
> Source)
>  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
> Source)
>  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
> Source)
>  at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown 
> Source)
>  at 
> org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown
>  
> Source)
>  at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>  at org.apache.xerces.parsers.XML11Configuration.parse(Unknown 
> Source)
>  at org.apache.xerces.parsers.XML11Configuration.parse(Unknown 
> Source)
>  at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>  at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown 
> Source)
>  at 
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
>  at 
> org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3413)
>  ... 24 more



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: slf4j dependency on an beta version

2021-09-23 Thread Andreas Beeker


Hi PJ,

On 23.09.21 20:54, PJ Fanning wrote:

Does anyone know why we don't just rely on slf4j-api 1.7.x?


I've raised the dependency to the beta version, because I saw the 2.x alpha and 
thought this would be the latest stable and they aren't continuing on the 1.x 
branch.

1.7.x is ok for me, if you ask me in that way ;)

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache POI 5.1.0 release (RC1)

2021-09-20 Thread Andreas Beeker


Hi Devs,

in the process of modifying the BitmapImageRenderer, I ran my EMF / PPTX 
related regression tests and found a few samples which ran forever.

The profiler revealed that the duplicated parsing of custom shape geometries is 
causing 18% of the load for those specific files.
I'd like to fix this performance issue before continuing with RC2.

i have a few more issues related to HSLF shape geometry parsing in the pipeline 
which I would postpone after RC2.

Is this ok for you?

Andi




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Possible License Problems in BitmapImageRenderer and StringCodepointsIterable

2021-09-17 Thread Andreas Beeker


Hi Devs,

I've changed BitmapImageRenderer locally, but I need to find the test files 
which trigger mode 1 (grayscale) and mode 2 (truncated).
I've added the handling based on the regression tests on 20.06.2016 - so if you 
would have the test-results from back then, it might be easier to identify the 
culprit.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Optional dependencies and JPMS?

2021-09-12 Thread Andreas Beeker


Hi Devs,


Yegor: What exactly is wrong with Batik?  Does it pull conflicting transitive 
dependencies?

technically: https://issues.apache.org/jira/browse/BATIK-1260
organizational: same as POI - too few people to have frequent releases


Yegor: we need to ensure users get an exception with a sensible message with 
instructions on what/how to add on the classpath.


If the dependency is required, JPMS will check at the program start and quits 
if it isn't there.
If it's optional (requires static), we probably can use reflection to check for 
the classes.
My preferred way in the long run would be more/specialized POI modules.
When one is using Gradle capabilities, you have the problem that the features 
are mutual exclusive.
So I've defined a "signing", "render" and "rendersign" feature.
This would be unnecessary with dedicated render and signing modules.
We had discussions on this point also several times, which resulted in no 
change.
Basically we would weigh between confusing users with new modules vs. users not 
reading a FAQ entry, which explains on how to use the components (e.g. how to 
exclude or include dependencies).


Yegor: Do we care about existing applications running POI  and Batik/XmlSec?

I think the answer is not so simple:
do we care about existing applications which are now need to exclude modules 
after the upgrade?
e.g. https://stackoverflow.com/questions/67789203
do we care about people complaining, that we/I change the (part of the) API 
with each release?


PJ: we should include all the transitive dependencies and document how users 
can choose to exclude certain dependencies

My idea was to work with mavens optional dependencies. The dependency will be 
marked as optional, if the dependency is part of Gradle feature/capability. So 
if a user looks at the pom, they might get the idea what to include.


PJ: it feels like you need to use '--add-module'

I have to correct myself, it's enough to add the module in the module-info.
Similar to the maven pom, the expectation would be, that the user looks in the 
module-info of the corresponding POI jar.

If you don't mind, I would commit my excludes now and wait for your feedback 
before the release.

Andi

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Optional dependencies and JPMS?

2021-09-11 Thread Andreas Beeker


Hi Devs,

I want to pick up an older thread.
Back at the time of the discussion, we didn't know that Batik makes so many 
problems.
For the next release (5.1.0), I thought about making the maven dependencies to 
Batik and XmlSec optional.
In Gradle this is realized via features/capabilities.

So here are the decision to be made:
a) make Batik optional? (Batik is used for rendering slideshows, WMF, EMF to 
SVG and SVG processing in XSLF)
b) make XmlSec/BouncyCastle optional? (those are used for signing and extended 
crypto)
c) provide gradle metadata additional to maven POMs?

Please also read below for the consequences of making a dependency optional - 
this still applies.

Andi

On 06.11.20 11:31, Yegor Kozlov wrote:

Hi Andi,

Got you. I thought you were going to change module-infos only and catch
ClassNotFound at module load time instead of runtime, so that if a module
is missing  POI would load anyway with a sensible message . Pardon my JPMS
ignorance, I  thought it was possible.

Option (a) makes sense (though I myself prefer slim distros). It will make
it easier to use POI with JPMS which is good. Changing the scope in Maven
will add a few MBs to the application size, but it shouldn't be a problem
either.
As to OSGi packaging, I'd still like to keep these dependencies optional as
they are now.

Regards,
Yegor

On Thu, Nov 5, 2020 at 11:21 PM Andreas Beeker  wrote:


Yegor, either I don't understand you or one of us two is wrong ...


  From a user perspective  bouncycastle  & co  will still be optional
but it will be us who catch  ClassNotFoundException.

It's fine then to make them mandatory.

This is a contradiction in my view.


So we can either pick ..

a)
- if classpath loading is used, we need to catch ClassNotFoundExceptions
- our dependencies are mandatory
- we use "requires" in module-info
- we change all "provided" maven dependencies to "compile"
- the user don't need to add "--add-modules"
- if one required dependency is not on the users module path - for
whatever reason - the application can't be launched

b)
- if classpath loading is used, we need to catch ClassNotFoundExceptions
- our dependencies are optional (current state)
- we use "requires static" in module-info
- we keep the "provided" maven dependencies
- the user needs to add "--add-modules"
- if an optional dependency (which isn't added via add-modules) is not on
the classpath - the ClassNotFound is catched (see above)
- with the Service Loader pattern, the loading of a scratchpad format will
simply fail, if the corresponding scratchpad jar is not requested

Disclaimer: although I've tested several configurations while setting up
the multi-module build,
I'm by far (not?) an expert in JPMS - so maybe my conclusions above are
wrong ...

Andi


On 05.11.20 09:37, Yegor Kozlov wrote:

I see. From a user perspective  bouncycastle  & co  will still be

optional

but it will be us who catch  ClassNotFoundException.

It's fine then to make them mandatory.

On Thu, Nov 5, 2020 at 12:37 AM Andreas Beeker 

wrote:

I haven't tested it, but I assume we can catch the

ClassNotFoundException.

So when defined as "requires static" the POI module would load and

throw a

ClassNotFound/NotDefined when the code is reached.
When we define it as "requires" and the dependencies aren't on the

module

path, I think it will crash in the beginning.



-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache POI 5.1.0 release (RC1)

2021-09-10 Thread Andreas Beeker


Hi Pj,

in the integration tests POIXMLDocumentHandler::cursorRecursive can be used to 
recurse through the main document of a format - currently only used for XSSF 
and XWPF (I thought it would be also used for XSLF). Additionally there's the 
test-data/integration directory, which I've used to put documents with missing 
xmlbeans types in.

The ooxml-lite task should be executed after poi-ooxml:test and 
poi-integration:test - I thought, I have handled that.

So if the missing XmlBeans types are in the main document of an .xlsx/.docx, it 
should be enough to put them in test-data/integration.

Btw. I changed a few dependency (e.g. using gradle capabilities for optional 
stuff) and struggle with gradle again - it might take another few days until it 
is working correctly.

Andi



On 10.09.21 10:51, PJ Fanning wrote:

What do we think is the best way to get the missing xsbs added to 
poi-ooxml-lite? Maybe, adding more files to test-data dir and adding tests that 
read them is the best solution? I suppose these tests will need to be in 
poi-ooxml because that is the project that generates the poi-ooxml-lite report.






On Sunday 5 September 2021, 19:34:37 IST, Dominik Stadler 
 wrote:





Preliminary results of the test-run are at

   - 5.0.0-RC2 to 5.1.0-RC1
   
<http://people.apache.org/~centic/poi_regression/reports/index500RC2to510RC1.html>
   - 5.1.0-RC1-All
   
<http://people.apache.org/~centic/poi_regression/reportsAll/index500RC2to510RC1.html>

We now run 3.5mio documents, 200k more than in the previous runs.

There are 88124 failures compared to 5.0.0 due to missing ".xsb" files in
poi-ooxml-lite, e.g. ctsdtrow2f71type and others.

Also a few other failures, NPEs, NotImplementedException, ..., some may
trigger now because new functionality triggers them now, a few are because
commons-math3 was not up-to-date in the test-driver.

Dominik.


On Sat, Sep 4, 2021 at 1:00 PM Dominik Stadler 
wrote:


Hi,

I started the test-suite today and hopefully can report on it before
voting ends.

Dominik.

On Sat, Sep 4, 2021 at 1:10 AM PJ Fanning 
wrote:


Thanks Andi for prepping the RC.

Have we run the test suite with the large number of test files to see if
the results are ok?





On Friday 3 September 2021, 23:40:08 IST, Andreas Beeker <
kiwiwi...@apache.org> wrote:





Hi *,

I've prepared artifacts for the release of Apache POI 5.1.0 (RC1).

The most notable changes in this release are:

* upgrade dependencies: XmlBeans 5.0.1, Batik 1.14, BouncyCastle 1.69,
Commons-Compress 1.21, ...
* switching build to Gradle - Ant build is not supported anymore [#65206]
* XSLFTable::addRow functionality reverted to pre-5.0.0 [github-221]
* XSSFDrawing - import chart from other drawing [#63901]
* Support for Excel functions IFS, SWITCH, TEXTJOIN, IFNA, MAXIFS,
MINIFS, AVERAGEIFS
* Fix SVG-related image rendering

https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/

Things to check:
According to Stackoverflow there were some problems with JPMS and
XmlBeans -
so maybe check for potential problems there.

Please vote to release the artifacts.
The vote keeps open until 2021-09-10.
Planned release announcement date is Saturday, 2021-09-11.

Here is my +1

The SVN repo is open again.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [VOTE] Apache POI 5.1.0 release (RC1)

2021-09-04 Thread Andreas Beeker

Hi Devs,

first of all, thank you for getting the gradle teething problems
identified/solved. This should get better over time.

@RC1: -1, I'll provide a new one, after the mass regression tests

@poi-ooxml-lite -> poi-ooxml-full (runtime) and poi-integration (runtime): this
should be fixed - either you or I have a look

@Javac 14: this is of course my fault. I had used Java8 until I've fixed the other
ooxml-lite issue, then I forgot to switch back. I thought the --release javac switch
would take care about this. We probably should add a "release" task similar to
the ant release task, which checks for Java 8.

@poi-5.1.0.pom.sha*: I forgot to add those, but that could be still signed. The
pom files will be automatically signed by Nexus for the maven dist and I've
added also the gpg signatures there.

@License/Notice: yes, need to be added

@MANIFEST.MF "Specification-*" and"Implementation-*": not sure if this is
needed, but we should include those too.

@poi-integration: that's test stuff, I've omit it on-purpose

@XmlBeans *Factory classes: that's on purpose - I've changed the XmlBeans
generation

@org.apache.poi.Version: again, needs to be added

Andi

On 04.09.21 18:22, PJ Fanning wrote:

I think there is an issue in the poi-ooxml-lite pom - it has a dependency on
poi-ooxml-full.

https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/maven/org/apache/poi/poi-ooxml-lite/5.1.0/poi-ooxml-lite-5.1.0.pom

On Saturday 4 September 2021, 15:10:03 IST, PJ Fanning
wrote:

The java jars on https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/maven/
seem to have been built with Java 14 and do not work with Java 8.

I'm getting this when trying to use poi-ooxml jar:

Caused by: java.lang.UnsupportedClassVersionError:
org/apache/poi/openxml4j/opc/OPCPackage has been compiled by a more recent
version of the Java Runtime (class file version 58.0), this version of the Java
Runtime only recognizes class file versions up to 52.0

One other thing: I've added
https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/maven/org/apache/poi/ to
allow this to be more easily used as a maven repo. I left the jars in the
original locations too.

I can now use this in my maven pom when testing in another project:

my-repo1
your custom repo
https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/maven

On Saturday 4 September 2021, 14:20:09 IST, Dominik Stadler
wrote:

Hi,

When comparing the release files with 5.0.0, I saw the following, not sure
which one are on-purpose and which one should be changed:

* Files poi-5.1.0.pom.sha256 and poi-5.1.0.pom.sha512 are not included
* The jar-files under maven/* do not contain "LICENSE" and "NOTICE" any
more under "META-INF"
* Jar-file "poi.jar" does not contain class "org.apache.poi.Version" any
more
* The MANIFEST.MF file previously had fields for "Specification-*" and
"Implementation-*" which are now missing
* jars for "poi-integration" are not included any more. These are mostly
used for mass-regression-testing, which usually works off of locally built
binaries anyway, so likely not needed.
* the poi-ooxml-lite and poi-ooxml-full packages do not include all the
*Factory classes any more

Thanks... Dominik.

On Sat, Sep 4, 2021 at 12:40 AM Andreas Beeker wrote:

Hi *,

I've prepared artifacts for the release of Apache POI 5.1.0 (RC1).

The most notable changes in this release are:

* upgrade dependencies: XmlBeans 5.0.1, Batik 1.14, BouncyCastle 1.69,
Commons-Compress 1.21, ...
* switching build to Gradle - Ant build is not supported anymore [#65206]
* XSLFTable::addRow functionality reverted to pre-5.0.0 [github-221]
* XSSFDrawing - import chart from other drawing [#63901]
* Support for Excel functions IFS, SWITCH, TEXTJOIN, IFNA, MAXIFS, MINIFS,
AVERAGEIFS
* Fix SVG-related image rendering

https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/

Things to check:
According to Stackoverflow there were some problems with JPMS and XmlBeans
-
so maybe check for potential problems there.

Please vote to release the artifacts.
The vote keeps open until 2021-09-10.
Planned release announcement date is Saturday, 2021-09-11.

Here is my +1

The SVN repo is open again.

Andi

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[VOTE] Apache POI 5.1.0 release (RC1)

2021-09-03 Thread Andreas Beeker


Hi *,

I've prepared artifacts for the release of Apache POI 5.1.0 (RC1).

The most notable changes in this release are:

* upgrade dependencies: XmlBeans 5.0.1, Batik 1.14, BouncyCastle 1.69, 
Commons-Compress 1.21, ...
* switching build to Gradle - Ant build is not supported anymore [#65206]
* XSLFTable::addRow functionality reverted to pre-5.0.0 [github-221]
* XSSFDrawing - import chart from other drawing [#63901]
* Support for Excel functions IFS, SWITCH, TEXTJOIN, IFNA, MAXIFS, MINIFS, 
AVERAGEIFS
* Fix SVG-related image rendering

https://dist.apache.org/repos/dist/dev/poi/5.1.0-RC1/

Things to check:
According to Stackoverflow there were some problems with JPMS and XmlBeans -
so maybe check for potential problems there.

Please vote to release the artifacts.
The vote keeps open until 2021-09-10.
Planned release announcement date is Saturday, 2021-09-11.

Here is my +1

The SVN repo is open again.

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Next release of POI

2021-09-02 Thread Andreas Beeker


Hi,

the ooxml-lite module is currently not filtering correctly.
I need to fix that first before continuing with preparing the release candidate.

Andi.


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Next release of POI

2021-09-02 Thread Andreas Beeker


Hi,

I'm now working on the release - please stop committing.

Andi

On 01.09.21 10:14, Sayi wrote:



Hi,

a) It’s time to release a new version and the new version solves many serious 
bugs.

c) My opinion is that 5.1.0 is better.

Best regards,
Sayi














在 2021-09-01 04:28:34，"Dominik Stadler"  写道：

Similar for me,

a) good time roll the next release

b) whatever is easier right now, we can also use Ant once again if Gradle
needs a bit more work

c) I'd also opt for 5.1.0, it does not feel like big enough changes for a
major release

Dominik.


On Tue, Aug 31, 2021 at 5:08 PM Alain FAGOT BÉAREZ 
wrote:


Hi,

a) many changes deserve to be released

b) up to you to estimate the benefits or the burden

c) I don't think we introduced API breaking changes, so 5.1.0 would
encompass the logging changes

Best regards,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android

Em 29 de ago de 2021 21:11, em 21:11, PJ Fanning
 escreveu:

Hi Andi,

a) I think we need a new release

b) I don't think we need to solve all the build issues before the next
release

c) I'd prefer to call the next release 6.0.0 or failing that 5.1.0. The
log4j change makes calling next release 5.0.1 problematic for me.






On Sunday 29 August 2021, 18:57:42 IST, Andreas Beeker
 wrote:





Hi Devs,

a) what's your opinion about rolling the next release?


>From my side, only the distsource build is not implemented in gradle

and a few of the release task need to be done manually.

b) Now that the gradle dist plugin picks up all the dependencies, how
important is the distsource check?

c) what's our next release version? 5.0.1,  5.1 or 6.0

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Next release of POI

2021-08-29 Thread Andreas Beeker


Hi Devs,

a) what's your opinion about rolling the next release?

From my side, only the distsource build is not implemented in gradle and a few 
of the release task need to be done manually.

b) Now that the gradle dist plugin picks up all the dependencies, how important 
is the distsource check?

c) what's our next release version? 5.0.1,  5.1 or 6.0

Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: ant build

2021-08-16 Thread Andreas Beeker


HI PJ,

I could try to look at the ant build, but my goal would be to remove it in this 
release and only use gradle.
Why would you like to use the ant build?

My open todos for gradle are:
* add the distsource build again to Jenkins - this is currently omitted
* use gradle in the windows builds ... as I usually don't use windows for 
building, this will be either a Jenkins trial-and-error or I have to scrap my 
principles :)

Andi

On 16.08.21 18:37, PJ Fanning wrote:

Hi,
I've had a look at the getting the POI ant build to use xmlbeans 5.0.1 but with 
little success. The immediate issue is in the poi-ooxml-lite jar creation 
logic. Would someone else be able to have a look?

Regards,
PJ

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[ANNOUNCE] Apache XMLBeans 5.0.1 release

2021-07-14 Thread Andreas Beeker


The Apache POI project is pleased to announce the release of Apache XMLBeans 
5.0.1.
The POI team took over the ownership of XMLBeans since version 3.0.0.

See the downloads page for binary and source distributions:
https://xmlbeans.apache.org/download

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not
have replicated the release yet. If that is the case, please try another mirror.
This also goes for Maven access.



Release Notes

Changes

The most notable changes in this release are:

* Support annotations longer than 64kb
* Support enumerations with more than 64k entries
* Enable mapping of schema annotations to javadoc entries in the generated 
classes via schema compiler option
* Generate TypeSystemHolder as .java (in sources) instead of .class (in 
resources)


A full list of changes is available in the change log:
https://xmlbeans.apache.org/status.html
https://issues.apache.org/jira/projects/XMLBEANS/versions/12350037

People interested should also follow the *POI* dev mailing list to track 
further progress.



Release Contents


This release comes in two forms:
 - pre-built binaries containing compiled versions of all Apache XMLBeans 
components and documentation
   (xmlbeans-bin-5.0.1-20210710.zip or xmlbeans-bin-5.0.1-20210710.tgz)
 - source archive you can build XMLBeans from (xmlbeans-src-5.0.1-20210710.zip 
or xmlbeans-src-5.0.1-20210710.tgz)
  Unpack the archive and use the following command to build all XMLBeans 
components with Apache Ant 1.8+ and JDK 1.8 or higher:

  ant deploy

 Pre-built versions of all XMLBeans components are also available in the 
central Maven repository
 under Group ID "org.apache.xmlbeans" and Version "5.0.1"

All release artifacts are accompanied by SHA checksums and PGP signatures
that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at

https://www.apache.org/dist/poi/KEYS


About Apache XMLBeans
---

XMLBeans is a tool that allows access to the full power of XML in a Java 
friendly way.
The idea is to take advantage of the richness and features of XML and XML Schema
and have these features mapped as naturally as possible to the equivalent Java
language and typing constructs.

See https://xmlbeans.apache.org for more details


About Apache POI
---

Apache POI is well-known in the Java field as a library for reading and
writing Microsoft Office file formats, such as Excel, PowerPoint, Word,
Visio, Publisher and Outlook. It supports both the older (OLE2) and
new (OOXML - Office Open XML) formats.

See https://poi.apache.org/ for more details

On behalf of the Apache POI PMC,
Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-475) Adding image using XSSF with previous images corrupts the entire file



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-475.
---

> Adding image using XSSF with previous images corrupts the entire file
> -
>
> Key: XMLBEANS-475
> URL: https://issues.apache.org/jira/browse/XMLBEANS-475
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions:  Version 2.3
> Environment: Windows 7, eclipse, java 1.6
>Reporter: Michael Benoit
>Priority: Major
> Fix For: Version 5.0.1
>
> Attachments: OnePicture.xlsx
>
>
> When I try to add images to an xlsx file that already contains images, the 
> image is appended as a fragment at the end of the file which causes Microsoft 
> Office to say the file is corrupted and gives the option of trying to recover.
> Workbook workbook = new XSSFWorkbook(doc);
> Sheet sheet;
> if(workbook.getNumberOfSheets() > 0){
>   sheet = workbook.getSheetAt(0);
> } else {
>   sheet = workbook.createSheet();
> }
> Drawing patriarch = sheet.createDrawingPatriarch();
> ClientAnchor anchor = workbook.getCreationHelper().createClientAnchor();
> anchor.setCol1(10);
> anchor.setRow1(1);
> anchor.setDx1(100);
> anchor.setDy1(190);
> ((XSSFDrawing) patriarch).createLinkedPicture(anchor,"a location");
> workbook.write(outDoc);
> doc.close();
> outDoc.close();



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Deleted] (XMLBEANS-430) tt



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker deleted XMLBEANS-430:



> tt
> --
>
> Key: XMLBEANS-430
> URL: https://issues.apache.org/jira/browse/XMLBEANS-430
> Project: XMLBeans
>  Issue Type: Bug
> Environment: tt
>Reporter: michael.liu
>Priority: Major
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> tt



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-235) Support annotations > 64kb



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-235.
---

> Support annotations > 64kb
> --
>
> Key: XMLBEANS-235
> URL: https://issues.apache.org/jira/browse/XMLBEANS-235
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 2.1
> Environment: WIndows XP, J2SE Version 1.5.0 (build 1.5.0_06-b05)
>Reporter: Chris Isbell
>Assignee: Andreas Beeker
>Priority: Blocker
> Fix For: Version 5.0.1
>
> Attachments: Common.xsd, Document.xsd, Enumerations.xsd, 
> JobSearchAgent.xsd, JobSeeker.xsd
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> scomp fails with the following output:
> Time to build schema type system: 1.492 seconds
> Exception in thread "main" org.apache.xmlbeans.SchemaTypeLoaderException: 
> encoded string too long: 80643 bytes 
> (schemaorg_apache_xmlbeans.system.sD8C47734011B153A3D6BBC3BCCA9AC04.allassetsmodelgroup)
>  - code 9
>   at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$StringPool.writeTo(SchemaTypeSystemImpl.java:1021)
>   at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.writeRealHeader(SchemaTypeSystemImpl.java:1602)
>   at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.saveModelGroup(SchemaTypeSystemImpl.java:1406)
>   at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.saveModelGroups(SchemaTypeSystemImpl.java:1347)
>   at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.save(SchemaTypeSystemImpl.java:1296)
>   at 
> org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1098)
>   at 
> org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:368)
> The problem appears to be with the line "output.writeUTF(str);" in the method 
> writeTo in class org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl (line 
> 1016). java.io.DataOutputStream.writeUTF has an implicit 64K byte length 
> limit (because it stores the length in a two-byte integer) and this limit is 
> being exceeded.
> The schema I am compiling comes from a third party and it is unlikely that it 
> can be modified to work around this problem.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-563) apache maven plugin does not have feature parity with codehaus maven plugin or allow all configuration options



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-563.
---

> apache maven plugin does not have feature parity with codehaus maven plugin 
> or allow all configuration options
> --
>
> Key: XMLBEANS-563
> URL: https://issues.apache.org/jira/browse/XMLBEANS-563
> Project: XMLBeans
>  Issue Type: Improvement
>Affects Versions: Version 5.0.0
>Reporter: Travis Schneeberger
>    Assignee: Andreas Beeker
>Priority: Blocker
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Upgrading to xmlbeans 5.0 requires switching to the apache xmlbeans maven 
> plugin from the codehaus xmlbeans maven plugin.  This was not possible for us 
> as not all configuration options available in the apache plugin are available 
> in the codehaus plugin.  Specifically, we need to ensure that the plugin does 
> not attempt to download resources.  After looking at the java source for the 
> plugin we noticed the following commented out lines:
> {code}
> //params.setBaseDir(null);
> //params.setJavaFiles(new File[0]);
> //params.setCompiler(null);
> //params.setMemoryInitialSize(null);
> //params.setMemoryMaximumSize(null);
> //params.setOutputJar(null);
> //params.setDownload(false);
> //params.setDebug(debug);
> //params.setExtensions(null);
> {code}
> There may be other problems as well as we weren't able to get very far in our 
> upgrade process.  Thanks for all your work in maintaining this project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-394) probleme in escaping character with xmlbeans 1.0.4



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-394.
---

> probleme in escaping character with xmlbeans 1.0.4
> --
>
> Key: XMLBEANS-394
> URL: https://issues.apache.org/jira/browse/XMLBEANS-394
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 1.0.4 (jdk1.3 port)
> Environment: windowsXP
>Reporter: dev2dev
>Priority: Critical
> Fix For: Version 5.0.1
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> It is about xmlbeans. I want to escape some special characteres like ">" 
> with xmlbeans but i didn't find the solution for that and i can't use 
> XmlOptionCharEscapeMap because the release of xmlbeans that i'm using is 
> 1.0.4.
> for example i have this file in input : 
> this is a mention ...< > & '  " 
> in ouput i have that : 
> this is a mention...< > & '  " 
> But i want in out put the same thing that i had in input so that : 
> this is a mention ...< > & '  " 
> thanks,
> best regards
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-562) java.lang.ClassCastException: org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl cannot be cast to org.apache.xmlbeans.SchemaTypeLoader



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-562.
---

> java.lang.ClassCastException: 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl cannot be cast to 
> org.apache.xmlbeans.SchemaTypeLoader
> -
>
> Key: XMLBEANS-562
> URL: https://issues.apache.org/jira/browse/XMLBEANS-562
> Project: XMLBeans
>  Issue Type: Bug
>  Components: XmlObject
>Affects Versions: Version 4.0.0
>Reporter: Annapurna Theerthala
>Priority: Critical
> Fix For: Version 5.0.1
>
>
> I am getting the below error when exporting excel using POI 5 with xmlbeans 4.
>  
> `at java.lang.Class.forName0(Native Method)
>  at java.lang.Class.forName(Class.java:348)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl.build(SchemaTypeLoaderImpl.java:161)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.(SchemaTypeSystemImpl.java:168)
>  at 
> org.apache.xmlbeans.metadata.system.sXMLSCHEMA.TypeSystemHolder.(TypeSystemHolder.java:41)
>  Truncated. see log file for complete stacktrace
> Caused By: org.apache.xmlbeans.XmlRuntimeException: 
> java.lang.ClassCastException: 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl cannot be cast to 
> org.apache.xmlbeans.SchemaTypeLoader
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl.build(SchemaTypeLoaderImpl.java:164)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.(SchemaTypeSystemImpl.java:168)
>  at 
> org.apache.xmlbeans.metadata.system.sXMLTOOLS.TypeSystemHolder.(TypeSystemHolder.java:41)
>  at 
> org.apache.xmlbeans.metadata.system.sXMLTOOLS.TypeSystemHolder.(TypeSystemHolder.java:44)
>  at java.lang.Class.forName0(Native Method)
>  Truncated. see log file for complete stacktrace
> Caused By: java.lang.ClassCastException: 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl cannot be cast to 
> org.apache.xmlbeans.SchemaTypeLoader
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl.build(SchemaTypeLoaderImpl.java:162)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.(SchemaTypeSystemImpl.java:168)
>  at 
> org.apache.xmlbeans.metadata.system.sXMLTOOLS.TypeSystemHolder.(TypeSystemHolder.java:41)
>  at 
> org.apache.xmlbeans.metadata.system.sXMLTOOLS.TypeSystemHolder.(TypeSystemHolder.java:44)
>  at java.lang.Class.forName0(Native Method)
>  Truncated. see log file for complete stacktrace
> I have checked that my `xmlbeans` come from `xmlbeans-4.0.0.jar` and the 
> `ooxml-schema` has been removed and replaced with `poi-ooxml-full-5.0.0.jar`
> {{Tried with poi-ooxml-schemas-5.0.0.jar as well. still the same issue.}}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-457) Mixed and restricted element fails validation



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-457.
---

> Mixed and restricted element fails validation
> -
>
> Key: XMLBEANS-457
> URL: https://issues.apache.org/jira/browse/XMLBEANS-457
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Validator
>Affects Versions: Version 2.4 
> Environment: jdk1.6.0_25
>Reporter: Caroline Rosin
>Priority: Critical
>  Labels: mixed, restricted, validation
> Fix For: Version 5.0.1
>
>
> I have noticed that when an element is defined as a restriction from a mixed 
> type, if there is some text in this element the Xmlbeans validation 
> fails.However the same xml file is valid if I run it against schema 
> validation in XmlSpy. Here is the example (I tried to make it as simple as 
> possible):
> xml schema:
> http://www.w3.org/2001/XMLSchema"; 
> elementFormDefault="qualified" attributeFormDefault="unqualified">
> 
> 
> Comment describing your root 
> element
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> xml file:
> http://www.w3.org/2001/XMLSchema-instance";>
> text 
> text1
> text2
> 
> For XmlSpy, this is valid. Here's what I get when validating with Xmlbeans :
> Message: Element 'ChildRestricted' with empty content type cannot have text 
> or element content.
> Location of invalid XML:  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
> I guess this is linked to this issue : 
> http://www.mail-archive.com/dev@xmlbeans.apache.org/msg02004.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-82) Use XSD Annotations for comment generation



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-82.
--

> Use XSD Annotations for comment generation
> --
>
> Key: XMLBEANS-82
> URL: https://issues.apache.org/jira/browse/XMLBEANS-82
> Project: XMLBeans
>  Issue Type: New Feature
>  Components: Compiler
>Affects Versions: Version 1.0.3, Version 2.1
>Reporter: Walter Dorninger
>    Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
> Attachments: xmlbean_patch_comment_generation_11_23_2011
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It would be a powerful feature if XSD Annotaions would be read and placed in 
> the comment of the generated Java methods (setter/getters) instead of the 
> hard-coded comment. 
> This will add plenty of power to the generation of XMLBeans because having 
> this feature it would be possible to later use XDOCLETS for further 
> generation of code (e.g. BeanInfo etc.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-485) Whitespace is not stripped if text starts on byte 90112 or higher



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-485.
---

> Whitespace is not stripped if text starts on byte 90112 or higher
> -
>
> Key: XMLBEANS-485
> URL: https://issues.apache.org/jira/browse/XMLBEANS-485
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Cursor
>Affects Versions: Version 2.5
> Environment: Linux amd64
>Reporter: johan jarkovic
>Assignee: Andreas Beeker
>Priority: Critical
>  Labels: 90112, strip, whitespace
> Fix For: Version 5.0.1
>
> Attachments: XmlBeansBugReprod-485.zip
>
>
> (I ve used XmlOptions.setLoadStripWhitespace() option)
> If the text of an element starts on byte 90112 of the document, and there is 
> whitespace before it, then the whitespace before it is not fully trimmed. 
> There is one space left. If the text starts on  90113 there are two spaces 
> left, and so on. 
> - This happens if the parent element has closed before byte 90112 followed by 
> some whitepsace and text. 
> - It happens with with plain text but also with CDATA.
> - It occurs also on byte: 90112*2,  90112*3 and so on



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-483) parse the xml unsuccessfully



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-483.
---

> parse the xml unsuccessfully 
> -
>
> Key: XMLBEANS-483
> URL: https://issues.apache.org/jira/browse/XMLBEANS-483
> Project: XMLBeans
>  Issue Type: Bug
>  Components: XmlObject
>Affects Versions: Version 2.2.1,  Version 2.3
> Environment: uname -a
> Linux bmps4 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008 x86_64 
> x86_64 x86_64 GNU/Linux
> lsb_release -a
> LSB Version:
> core-2.0-noarch:core-3.0-noarch:core-2.0-x86_64:core-3.0-x86_64:desktop-3.1-amd64:desktop-3.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch
> Distributor ID: SUSE LINUX
> Description:SUSE Linux Enterprise Server 10 (x86_64)
> Release:10
> Codename:   n/a
> <119 bmps4 [bmp] :/home/bmp/jboss/server/default/log>java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxa64dev-20090707 
> (SR10 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64 
> j9vmxa6423-20090707 (JIT enabled)
> J9VM - 20090706_38445_LHdSMr
> JIT  - 20090623_1334_r8
> GC   - 200906_09)
> JCL  - 20090705
>Reporter: shihouming
>Assignee: Andreas Beeker
>Priority: Critical
> Fix For: Version 5.0.1
>
>   Original Estimate: 360h
>  Remaining Estimate: 360h
>
> 1. Our system (J2EE base on jboss) got the following errors on one host, all 
> the service was interrupted  , but other host was normal(all is the same as 
> that host)  :
> 2012-06-14 14:00:57 | ERROR | [http-0.0.0.0-7782-7] Servlet.service() for 
> servlet default threw exception
> java.lang.ArrayIndexOutOfBoundsException
>   at org.apache.xmlbeans.impl.store.Locale.exit(Locale.java:2883)
>   at org.apache.xmlbeans.impl.store.Xobj.fetch_text(Xobj.java:1800)
>   at 
> org.apache.xmlbeans.impl.values.XmlObjectBase.get_wscanon_text(XmlObjectBase.java:1332)
>   at 
> org.apache.xmlbeans.impl.values.XmlObjectBase.check_dated(XmlObjectBase.java:1269)
>   at 
> org.apache.xmlbeans.impl.values.XmlObjectBase.stringValue(XmlObjectBase.java:1484)
>   at 
> org.apache.xmlbeans.impl.values.XmlObjectBase.getStringValue(XmlObjectBase.java:1492)
>   at 
> com.huawei.bme.das.config.xmlbean.namingsql.impl.SqlDocumentImpl$SqlImpl.getDatasource(SqlDocumentImpl.java:769)
>   at 
> com.huawei.bme.das.route.RouteCfgReader.getNmSQLDefaultDataSource(RouteCfgReader.java:80)
>   at 
> com.huawei.bme.das.route.DASRouter.getDataSourceByLabel(DASRouter.java:89)
>   at 
> com.huawei.bme.das.route.DASRouter.getRouteDataSource(DASRouter.java:46)
>   at 
> com.huawei.bme.das.util.DataSourceUtil.getRoutDataSources(DataSourceUtil.java:131)
>   at 
> com.huawei.bme.das.util.DataSourceUtil.reinitRequest(DataSourceUtil.java:62)
>   at 
> com.huawei.bme.das.impl.DASCommandImpl.getCmdProcessor(DASCommandImpl.java:880)
>   at 
> com.huawei.bme.das.impl.DASCommandImpl.execute(DASCommandImpl.java:111)
>   at 
> com.huawei.bme.system.dao.impl.LoginDAOImpl.getLogin(LoginDAOImpl.java:145)
>   at 
> com.huawei.bme.system.impl.SystemManageDBImpl.getLoginList(SystemManageDBImpl.java:1672
> 2. when we  restarted the application(jboss),  the errors disappear 
> immediately.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-214) Support the 2009 version of xml.xsd



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-214.
---

> Support the 2009 version of xml.xsd
> ---
>
> Key: XMLBEANS-214
> URL: https://issues.apache.org/jira/browse/XMLBEANS-214
> Project: XMLBeans
>  Issue Type: Improvement
>  Components: SOM
>Affects Versions: TBD
> Environment: All
>Reporter: Lawrence Aston Jones
>Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We currently have checked in the 2001/03 version of xml.xsd in 
> src/xmlschema/schema. This supports the xml:base, xml:lang and xml:space 
> attributes. As of 2005/08 a new version has been produced which adds an 
> xml:id attribute (see http://www.w3.org/TR/xml-id/). We should update xml.xsd 
> and see if there's anything else that needs to be done to support xml:id.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-477) Piccolo parser improperly retains and re-closes InputStream from previous invocation



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-477.
---

> Piccolo parser improperly retains and re-closes InputStream from previous 
> invocation
> 
>
> Key: XMLBEANS-477
> URL: https://issues.apache.org/jira/browse/XMLBEANS-477
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 2.4 , Version 2.5
>Reporter: Robby Morgan
>Priority: Major
> Fix For: Version 5.0.1
>
>
> I have uncovered odd behavior within the Piccolo parser when XMLBeans is 
> asked to parse a second document on the same thread.  What I have observed is 
> that, while the Piccolo parser closes the input stream after parsing the 
> first document, it retains a reference to the input stream and closes it 
> again immediately before parsing the input stream for the second document.  
> If the input stream reference is the same for the two documents, as is the 
> case when a request is processed on the same thread in Tomcat, then the 
> second document will fail to parse.
> Here is sample code that demonstrates the issue:
> {code}
> import my.xmlbeans.ServerDocument;
> import org.apache.commons.io.input.ProxyInputStream;
> import org.apache.xmlbeans.XmlException;
> import org.apache.xmlbeans.XmlOptions;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.io.InputStream;
> /**
>  * Issue:  XmlBeans (when using the Piccolo SAX parser) retains a reference 
> to the previous input stream on the
>  *  current thread, and if that stream is reopened and passed back into 
> XmlBeans, then the stream will be closed
>  *  prior to parsing any of the contents, producing the following exception:
>  *
>  * Exception in thread "main" java.lang.IllegalStateException: Stream is 
> already closed
>  * at 
> XmlBeansReclosingIssue$ReopenableInputStream.beforeRead(XmlBeansReclosingIssue.java:50)
>  * at 
> org.apache.commons.io.input.ProxyInputStream.read(ProxyInputStream.java:98)
>  * at 
> org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.fillByteBuffer(XMLStreamReader.java:209)
>  * at 
> org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.reset(XMLStreamReader.java:97)
>  * at 
> org.apache.xmlbeans.impl.piccolo.xml.DocumentEntity.open(DocumentEntity.java:94)
>  * at 
> org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.reset(PiccoloLexer.java:982)
>  * at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:709)
>  * at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3454)
>  * at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1276)
>  * at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1250)
>  * at 
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
>  * at my.xmlbeans.ServerDocument$Factory.parse(Unknown Source)
>  * at XmlBeansReclosingIssue.main(XmlBeansReclosingIssue.java:40)
>  */
> public class XmlBeansReclosingIssue {
> public static void main(String[] args) throws IOException, XmlException {
> File inputFile = new File(args[0]);
> ReopenableInputStream reopenableInputStream = new 
> ReopenableInputStream(new FileInputStream(inputFile));
> ServerDocument.Factory.parse(reopenableInputStream, new 
> XmlOptions().setUnsynchronized());
> reopenableInputStream.reopen(new FileInputStream(inputFile));
> ServerDocument.Factory.parse(reopenableInputStream, new 
> XmlOptions().setUnsynchronized());
> }
> private static class ReopenableInputStream extends ProxyInputStream {
> private boolean _closed;
> public ReopenableInputStream(FileInputStream inputStream) {
> super(inputStream);
> _closed = false;
> }
> public void reopen(InputStream in) {
> if (!_closed) {
> throw new IllegalStateException("Stream is not closed");
> }
> _closed = false;
> this.in = in;
> }
> @Override
> protected void beforeRead(int n) throws IOException {
> if (_closed) {
> throw new IllegalStateException("Stream is already closed");
> }
> }
> @Override
> public void close() throws IOException {
> if (_closed) {
> throw new IllegalStateException("Stream is already closed");
>

[jira] [Closed] (XMLBEANS-481) Base64 to byte[] is not very efficient



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-481.
---

> Base64 to byte[] is not very efficient
> --
>
> Key: XMLBEANS-481
> URL: https://issues.apache.org/jira/browse/XMLBEANS-481
> Project: XMLBeans
>  Issue Type: Improvement
>  Components: DOM
>Affects Versions: Version 2.5
>Reporter: Matej Spiller-Muys
>    Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are using 30 mb large byte[] string represented as base64 binary type in 
> shema and it is causing out of memory for us on server. Basically converting 
> from base64 string to byte[] is not very efficient.
> JavaBase64Holder.java is using: vBytes = v.getBytes("UTF-8") and according to 
> http://www.evanjones.ca/software/java-string-encoding-internals.html it uses 
> base64 size * 4. In our case where there is 30mb large byte[] it uses around 
> 160 mb just for converting string into byte[].
> Would it be possible to use v.getBytes("ASCII")? This would reduce the memory 
> usage when converting from string to byte[] by 4 times.
> According to http://www.w3.org/TR/xmlschema-2/#base64Binary it should use 
> only ASCII chars anyway.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-487) Entity replacement in wrong place when expansion coincides with buffer growth



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-487.
---

> Entity replacement in wrong place when expansion coincides with buffer growth
> -
>
> Key: XMLBEANS-487
> URL: https://issues.apache.org/jira/browse/XMLBEANS-487
> Project: XMLBeans
>  Issue Type: Bug
>  Components: XmlObject
>Affects Versions: Version 2.6
>Reporter: Jesper Steen Møller
>    Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
> Attachments: TestEntityNearBufferGrowth.java, patch.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When serializing an object to XML using newReader(), some of the entity 
> replacements for '&' appear in the wrong places, giving invalid XML.
> Example:
> Hall & Oates
> could be serialized as:
> Hall & Oates
> The bug depends on the sequence of the read()-calls, the size of the 
> requested buffer, and the content. We're using the newReader to feed a Xalan 
> transformation, and in some tens of millions different transformations, this 
> has happened just a few times -- but this time, we've isolated the problem, 
> which is attached as a stand-alone test case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-546) These classes (org.apache.xmlbeans.impl.store.Locale, org.apache.xmlbeans.impl.tool.BaseSchemaResourceManager and org.apache.xmlbeans.impl.tool.SchemaCodeGenerator) have



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-546.
---

> These classes (org.apache.xmlbeans.impl.store.Locale, 
> org.apache.xmlbeans.impl.tool.BaseSchemaResourceManager and 
> org.apache.xmlbeans.impl.tool.SchemaCodeGenerator) have bugs??
> 
>
> Key: XMLBEANS-546
> URL: https://issues.apache.org/jira/browse/XMLBEANS-546
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 3.1.0
>Reporter: Xiao Yuan
>Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Is there a dead loop in the exit() method of class 
> org.apache.xmlbeans.impl.store.Locale?
> public void exit()
> {
> // assert _numTempFramesLeft >= 0;
> //asserts computed frame fits between 
> //0 and _tempFrames.length
> assert _numTempFramesLeft >= 0 &&
> (_numTempFramesLeft <= _tempFrames.length - 1):
> " Temp frames mismanaged. Impossible stack frame. Unsynchronized: 
> " + noSync();
> int frame = _tempFrames.length - ++_numTempFramesLeft;
> while (_tempFrames[frame] != null)
> _tempFrames[frame].release();
> }
>  The process(String[], String[], boolean, boolean, boolean) method of class
> org.apache.xmlbeans.impl.tool.BaseSchemaResourceManager has a bug. Here's the 
> code snippet for the fix:
> for (int i = 0; i < filenames.length; i++)
>  {
>   SchemaResource resource = 
> (SchemaResource)_resourceForFilename.get(filenames[i]);
> if (resource != null)
> starterset.add(resource);
>  }
> In the class org.apache.xmlbeans.impl.tool.SchemaCodeGenerator, does that 
> thread not need to be started in the tryToDeleteLater(File) method?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-556) Support enumerations with more than 64k entries



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-556.
---

> Support enumerations with more than 64k entries
> ---
>
> Key: XMLBEANS-556
> URL: https://issues.apache.org/jira/browse/XMLBEANS-556
> Project: XMLBeans
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: Version 3.0.1, Version 3.1.0, Version 4.0.0, Version 
> 5.0.0
> Environment: windows 10
>Reporter: Marco Rouse
>Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I can't generate code from schema, I keep getting an error when running:
> scomp -dl -src java-src -out cfdv33.jar 
> [http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv33.xsd]
>  
> warning: SchemaType Enumeration found with too many enumeration values to 
> create a Java enumeration. The base SchemaType 
> "T=c_CodigoPostal@http://www.sat.gob.mx/sitio_internet/cfd/catalogos"; will be 
> used instead
> warning: SchemaType Enumeration found with too many enumeration values to 
> create a Java enumeration. The base SchemaType 
> "T=c_ClaveProdServ@http://www.sat.gob.mx/sitio_internet/cfd/catalogos"; will 
> be used instead
> warning: SchemaType Enumeration found with too many enumeration values to 
> create a Java enumeration. The base SchemaType 
> "T=c_Colonia@http://www.sat.gob.mx/sitio_internet/cfd/catalogos"; will be used 
> instead
> Time to build schema type system: 8.391 seconds
> Exception in thread "main" org.apache.xmlbeans.SchemaTypeLoaderException: 
> Value 95777 out of range: must fit in a 16-bit unsigned short. 
> (org.apache.xmlbeans.metadata.system.s456D395FEA75638FA3D29AFED09B48F7.ccodigopostald8d2type)
>  - code 10
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.writeShort(SchemaTypeSystemImpl.java:1569)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.writeTypeData(SchemaTypeSystemImpl.java:2537)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.saveType(SchemaTypeSystemImpl.java:1258)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.saveTypesRecursively(SchemaTypeSystemImpl.java:1141)
>  at 
> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.save(SchemaTypeSystemImpl.java:1117)
>  at 
> org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:973)
>  at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:333)
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-535) Error line number always -1 for XML validation errors



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-535.
---

> Error line number always  -1 for XML validation errors
> --
>
> Key: XMLBEANS-535
> URL: https://issues.apache.org/jira/browse/XMLBEANS-535
> Project: XMLBeans
>  Issue Type: Bug
>  Components: XmlObject
>Affects Versions: Version 3.0.1
>Reporter: Paola Bonini
>    Assignee: Andreas Beeker
>Priority: Major
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After upgrading to xmlbeans 3.0.1 the validation of an XML document returns 
> always -1 as line number of detected XML errors.
> I execute validation calling XmlObject.validate(XmlOptions), where XmlOptions 
> class has this settings:
> setLoadLineNumbers()
> setSavePrettyPrint()
> setErrorListener()
> The same code works correctly returning the line number of detected XML 
> validation errors using xmlbeans 2.3.0.
> Is there a way to get the correct line for XML validation error salso in 
> 3.0.1 version?
> Regards,
> Paola



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-559) Race condition in SchemaIdentityConstraintImpl.java



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-559.
---

> Race condition in SchemaIdentityConstraintImpl.java
> ---
>
> Key: XMLBEANS-559
> URL: https://issues.apache.org/jira/browse/XMLBEANS-559
> Project: XMLBeans
>  Issue Type: Bug
>Affects Versions: Version 5.0.0
>Reporter: Thorsten Goetzke
>Assignee: PJ Fanning
>Priority: Major
> Fix For: Version 5.0.1
>
> Attachments: bugfix.java
>
>
> The race condition can lead to a rare exception in a multithreaded 
> environment.
> The class uses two fields and initialises them lazy. The problem is that the 
> process of initializing the field is not atomic, and simply declaring the 
> fields volatile is not sufficient.
> As an example: Thread A enters getFieldPath(1). 
> fieldPaths is is null so buildPaths happen.
> Thread A build the first Path (index 0). Then Thread A pauses and Thread B 
> the methode getFieldPath(1)
> Thread B sees that _fieldPath is not null so it tries to access element 1, 
> but that element was not build yet-> So Thread B gets null and bad things 
> happen 
> This issue has  been around since basicly forever, I just never reported it.
> I will attach a fairly old source file wich I used to workaround this issue
> {code:java}
>   private volatile XPath _selectorPath;
> private volatile XPath[] _fieldPaths; {code}
> {code}
> public Object getFieldPath(int index) {
> XPath[] p = _fieldPaths;
> if (p == null) {
> try {
> buildPaths();
> p = _fieldPaths;
> } catch (XPath.XPathCompileException e) {
> assert false : "Failed to compile xpath. Should be caught by 
> compiler " + e;
> return null;
> }
> }
> return p[index];
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-564) SAXHelper creates noisy logging with stacktraces



 [ 
https://issues.apache.org/jira/browse/XMLBEANS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Beeker closed XMLBEANS-564.
---

> SAXHelper creates noisy logging with stacktraces
> 
>
> Key: XMLBEANS-564
> URL: https://issues.apache.org/jira/browse/XMLBEANS-564
> Project: XMLBeans
>  Issue Type: Improvement
>Affects Versions: Version 5.0.0
>Reporter: Travis Schneeberger
>    Assignee: Andreas Beeker
>Priority: Minor
> Fix For: Version 5.0.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Upgrading to xmlbeans 5 creates new noisy logging when xerces is not 
> available.  We aren't sure if this indicates a runtime library problem or is 
> unnecessarily noisy but regardless this type of logging did not occur in 
> previous versions.  The code in question is:   SAXHelper. 
> trySetXercesSecurityManager().  Please advise.  Thank you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[jira] [Closed] (XMLBEANS-565) Generate TypeSystemHolder as .java (in sources) instead of .class (in resources)