[jira] [Commented] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
[ https://issues.apache.org/jira/browse/XMLBEANS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258877#comment-14258877 ] Daniel Bramblett commented on XMLBEANS-499: --- Download the binary jar then unzip (I simply changed the .jar extension to .zip and proceeded) it which will remove the duplicate .class files (8 in this case) then use the jar tool to recreate the .jar file. The command is: "jar cf (path)\xmlbeans-2.6.0.jar -C (unzipped folder path) ." Don't forget the period at the end of the command. Then I copied the new xmlbeans-2.6.0.jar into my lib directory and all is now well. Hope this helps someone else! :-) > xmlbeans2.6.0.jar contians duplicate class files > > > Key: XMLBEANS-499 > URL: https://issues.apache.org/jira/browse/XMLBEANS-499 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Peter Klerehag > > The xlmbeans-2.6.0.jar contains some duplicate class files which in some > cases can generate problems with classloading. > It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other > locations as well > Did following and there you clearly see 2x of ReferenceResolver > unzip -l xmlbeans-2.6.0.jar | grep Resolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 214 2012-07-23 15:42 > org/apache/xmlbeans/impl/common/PrefixResolver.class > 45339 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class > 11284 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscResolver.class > 26162 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class > 3524 2012-07-23 15:42 > org/apache/xmlbeans/impl/tool/SchemaImportResolver.class > 1069 2012-07-23 15:42 > org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-513) SampleXmlUtil.processChoice() does not honor xs:choice boundaries
[ https://issues.apache.org/jira/browse/XMLBEANS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212330#comment-14212330 ] Victor Roldan Betancort commented on XMLBEANS-513: -- For the record, not sure if xmlbeans is any longer maintained, but decided to file this bug for documentation purposes. > SampleXmlUtil.processChoice() does not honor xs:choice boundaries > - > > Key: XMLBEANS-513 > URL: https://issues.apache.org/jira/browse/XMLBEANS-513 > Project: XMLBeans > Issue Type: Bug > Components: Samples >Affects Versions: Version 2.6 >Reporter: Victor Roldan Betancort >Priority: Minor > > When generating a sample for an XSD making use of xs:choice. SampleXmlUtil > does not consider the boundaries of the choice, but in fact generate an > instance of every element in the choice. This leads to invalid XML, depending > on the value of the minOccurs and maxOccurs. > http://www.w3schools.com/schema/el_choice.asp -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-513) SampleXmlUtil.processChoice() does not honor xs:choice boundaries
[
https://issues.apache.org/jira/browse/XMLBEANS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212328#comment-14212328
]
Victor Roldan Betancort commented on XMLBEANS-513:
--
proposed fix:
{code:title=SampleXmlUtil.java|borderStyle=solid}
private void processChoice(SchemaParticle sp, XmlCursor xmlc, boolean mixed)
{
SchemaParticle[] spc = sp.getParticleChildren();
xmlc.insertComment("You have a CHOICE of the next " +
String.valueOf(spc.length) + " items at this level");
for (int i = sp.getIntMinOccurs(); i <= sp.getIntMaxOccurs(); i++)
{
processParticle(spc[i], xmlc, mixed);
}
}
{code}
also randomization of the choice could be introduced, but not sure if that is
desirable:
{code:title=SampleXmlUtil.java|borderStyle=solid}
processParticle(spc[pick(spc.length)], xmlc, mixed);
{code}
> SampleXmlUtil.processChoice() does not honor xs:choice boundaries
> -
>
> Key: XMLBEANS-513
> URL: https://issues.apache.org/jira/browse/XMLBEANS-513
> Project: XMLBeans
> Issue Type: Bug
> Components: Samples
>Affects Versions: Version 2.6
>Reporter: Victor Roldan Betancort
>Priority: Minor
>
> When generating a sample for an XSD making use of xs:choice. SampleXmlUtil
> does not consider the boundaries of the choice, but in fact generate an
> instance of every element in the choice. This leads to invalid XML, depending
> on the value of the minOccurs and maxOccurs.
> http://www.w3schools.com/schema/el_choice.asp
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-513) SampleXmlUtil.processChoice() does not honor xs:choice boundaries
Victor Roldan Betancort created XMLBEANS-513: Summary: SampleXmlUtil.processChoice() does not honor xs:choice boundaries Key: XMLBEANS-513 URL: https://issues.apache.org/jira/browse/XMLBEANS-513 Project: XMLBeans Issue Type: Bug Components: Samples Affects Versions: Version 2.6 Reporter: Victor Roldan Betancort Priority: Minor When generating a sample for an XSD making use of xs:choice. SampleXmlUtil does not consider the boundaries of the choice, but in fact generate an instance of every element in the choice. This leads to invalid XML, depending on the value of the minOccurs and maxOccurs. http://www.w3schools.com/schema/el_choice.asp -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212093#comment-14212093 ] Christian Fechner commented on XMLBEANS-502: We are facing the same problem in production and are waiting for the workaround fix. Will you add a comment on the original issue (https://issues.apache.org/bugzilla/show_bug.cgi?id=55149) or how will I know, when a new release of POI will contain the fix? > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191951#comment-14191951 ] Jochen Kemnade commented on XMLBEANS-502: - As a workaround, I moved the POI transformations to a dedicated thread pool which I shutdown when my webapp context is destroyed. This way, all the leaks go down with the pool and Tomcat's handler threads stay clean. > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Comment Edited] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[
https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174794#comment-14174794
]
Jochen Kemnade edited comment on XMLBEANS-502 at 10/17/14 7:14 AM:
---
These problem usually occur when you subclass ThreadLocal (usually to implement
{{initialValue}}). Those classes reference the webapp's classloader. The
ThreadLocal subclass in turn is referenced by each Thread instance (that's how
ThreadLocals are implemented, they have a "helper-Map" in each Thread instance,
so the leak is actually not a tiny Random instance but the whole webapp's
classloader with a bunch of class definitions and statically referenced parts
of the webapp.
If you don't subclass ThreadLocal and set the value lazily instead, the problem
should be solved.
Btw., this probably also affects 2.6.0:
http://svn.apache.org/viewvc/xmlbeans/tags/2.6.0/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeLoaderImpl.java?view=markup#l69
http://svn.apache.org/viewvc/xmlbeans/tags/2.6.0/src/store/org/apache/xmlbeans/impl/store/CharUtil.java?view=markup#l909
was (Author: jkemnade):
These problem usually occur when you subclass ThreadLocal (usually to implement
}}initialValue}}). Those classes reference the webapp's classloader. The
ThreadLocal subclass in turn is referenced by each Thread instance (that's how
ThreadLocals are implemented, they have a "helper-Map" in each Thread instance,
so the leak is actually not a tiny Random instance but the whole webapp's
classloader with a bunch of class definitions and statically referenced parts
of the webapp.
If you don't subclass ThreadLocal and set the value lazily instead, the problem
should be solved.
> Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
> -
>
> Key: XMLBEANS-502
> URL: https://issues.apache.org/jira/browse/XMLBEANS-502
> Project: XMLBeans
> Issue Type: Bug
>Affects Versions: Version 2.3
> Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE
> 6/7, any operating system
>Reporter: Christopher Brown
> Attachments: leak1.png, leak2.png
>
>
> Hello,
> After creating this issue
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to
> create the issue here. This appears to be similar to
> https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as
> FIXED and as I'm using a more recent version (and as it's not completely
> identical), I'm creating a new issue.
> It would appear that XMLBeans is creating (and not clearing) ThreadLocal
> variables. This causes Tomcat to complain about classloader leaks (see
> messages below). Based on information in XMLBEANS-103, I have tried to coax
> the JVM to clear the ThreadLocal (by performing garbage collection on the
> JVM), but that doesn't clear the ThreadLocals, even if allowing time to
> elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat.
> To workaround this, we're having to impose long downtime when a restart is
> required. Perhaps a utility class within XMLBeans could be made available
> with the POI distribution such as:
> XMLBeansCache.clearThreadLocals()
> ...that I could call from a "finally" block after processing the XSSF
> document?
> Here's the information from Tomcat's logs:
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type
> [org.apache.xmlbeans.XmlBeans$1] (value
> [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type
> [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65])
> but failed to remove it when the web application was stopped. This is very
> likely to create a memory leak.
> Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type
> [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value
> [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a
> value of type [java.util.ArrayList] (value
> [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the
> web application was stopped. This is very likely to create a memory leak.
> Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type
> [org.apache.xmlbeans.impl.store.Locale$1] (value
> [org.ap
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174794#comment-14174794 ] Jochen Kemnade commented on XMLBEANS-502: - These problem usually occur when you subclass ThreadLocal (usually to implement }}initialValue}}). Those classes reference the webapp's classloader. The ThreadLocal subclass in turn is referenced by each Thread instance (that's how ThreadLocals are implemented, they have a "helper-Map" in each Thread instance, so the leak is actually not a tiny Random instance but the whole webapp's classloader with a bunch of class definitions and statically referenced parts of the webapp. If you don't subclass ThreadLocal and set the value lazily instead, the problem should be solved. > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
[
https://issues.apache.org/jira/browse/XMLBEANS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172306#comment-14172306
]
Andreas Lenerz commented on XMLBEANS-499:
-
The problem appears for the target "xmlpublic.classes" of the build script
where the classes are copied to a second location.
Changing the target to:
{code:xml}
...
{code}
solves the problem for me and allows to rebuild and sign the jar.
> xmlbeans2.6.0.jar contians duplicate class files
>
>
> Key: XMLBEANS-499
> URL: https://issues.apache.org/jira/browse/XMLBEANS-499
> Project: XMLBeans
> Issue Type: Bug
>Affects Versions: Version 2.6
>Reporter: Peter Klerehag
>
> The xlmbeans-2.6.0.jar contains some duplicate class files which in some
> cases can generate problems with classloading.
> It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other
> locations as well
> Did following and there you clearly see 2x of ReferenceResolver
> unzip -l xmlbeans-2.6.0.jar | grep Resolver.class
> 394 2012-07-23 15:42
> org/apache/xmlbeans/xml/stream/ReferenceResolver.class
> 394 2012-07-23 15:42
> org/apache/xmlbeans/xml/stream/ReferenceResolver.class
> 214 2012-07-23 15:42
> org/apache/xmlbeans/impl/common/PrefixResolver.class
> 45339 2012-07-23 15:42
> org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class
> 11284 2012-07-23 15:42
> org/apache/xmlbeans/impl/schema/StscResolver.class
> 26162 2012-07-23 15:42
> org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class
> 3524 2012-07-23 15:42
> org/apache/xmlbeans/impl/tool/SchemaImportResolver.class
> 1069 2012-07-23 15:42
> org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125315#comment-14125315 ] Marceau Dewilde commented on XMLBEANS-502: -- We use XMLBeans in a reasonably large webapp. We checked and XMLBeans is responsible for at least 90% of the resource leaks since July 2013. These have caused production servers to come down after redeploys (classes can not be unloaded because ThreadLocals are not correctly cleaned up). Is there any chance of this issue being looked at and hopefully resolved? Some samples: catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created a ThreadLocal with key of type org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1 (value org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@57a73656) and a value of type java.util.ArrayList (value java.lang.ref.SoftReference@22e0750f) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created a ThreadLocal with key of type org.apache.xmlbeans.impl.store.CharUtil$1 (value org.apache.xmlbeans.impl.store.CharUtil$1@32c00f6e) and a value of type java.lang.ref.SoftReference (value java.lang.ref.SoftReference@3e253dac) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created a ThreadLocal with key of type org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1 (value org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@57a73656) and a value of type java.util.ArrayList (value java.lang.ref.SoftReference@7ef40713) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThread
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112088#comment-14112088 ] Rick Oosterholt commented on XMLBEANS-502: -- This issue is still there. Has someone found a solution? Why is this not fixed? > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new XmlReaderSaxLoader(xr);
// I've noticed that most XMLReaders don't like a null
EntityResolver...
if (er != null)
xr.setEntityResolver(er);
}
{code}
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.common.SystemCache;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.err.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.err.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. When using a different parser, everything's fine");
SystemCache.get().setSaxLoader(null);
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("5. After resetting the cached SaxLoader, Piccolo works
again");
}
}
{code}
was:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new XmlReaderSaxLoader(xr);
// I've noticed that most XMLReaders don't like a null
EntityResolver...
if (er != null)
xr.setEntityResolver(er);
}
{code}
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.common.SystemCache;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.err.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.err.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. When using a different parser, everything's fine");
SystemCache.get().setSaxLoader(null);
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("5. After resetting the cached SaxLoader, Piccolo works
again");
}
}
{code}
The problem's here (Locale.java:3296):
{code}
if (_insideEntity!=0)
{
if ((_entityBytes += length) > _entityBytesLimit)
{
XmlError err =
XmlError.forMessage(XmlErrorCodes.EXCEPTION_EXCEEDED_ENTITY_BYTES,
new Integer[]{ new Integer(_entityBytesLimit) });
throw new SAXException(err.getMessage());
}
}
{code}
was:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCac
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new XmlReaderSaxLoader(xr);
// I've noticed that most XMLReaders don't like a null
EntityResolver...
if (er != null)
xr.setEntityResolver(er);
}
{code}
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.err.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.err.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. Using the JDK parser, everything's fine");
}
}
{code}
The problem's here (Locale.java:3296):
{code}
if (_insideEntity!=0)
{
if ((_entityBytes += length) > _entityBytesLimit)
{
XmlError err =
XmlError.forMessage(XmlErrorCodes.EXCEPTION_EXCEEDED_ENTITY_BYTES,
new Integer[]{ new Integer(_entityBytesLimit) });
throw new SAXException(err.getMessage());
}
}
{code}
was:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) op
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when the same
{{SaxHandler}} parses another, valid XML message, the same exception is thrown
again. This only happens when using the default XMLReader {{Piccolo}}, since
its {{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new XmlReaderSaxLoader(xr);
// I've noticed that most XMLReaders don't like a null
EntityResolver...
if (er != null)
xr.setEntityResolver(er);
}
{code}
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. Using the JDK parser, everything's fine");
}
}
{code}
The problem's here (Locale.java:3296):
{code}
if (_insideEntity!=0)
{
if ((_entityBytes += length) > _entityBytesLimit)
{
XmlError err =
XmlError.forMessage(XmlErrorCodes.EXCEPTION_EXCEEDED_ENTITY_BYTES,
new Integer[]{ new Integer(_entityBytesLimit) });
throw new SAXException(err.getMessage());
}
}
{code}
was:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when parsing another,
valid XML message, the same exception is thrown again. However, this only
happens when using the default XMLReader {{Piccolo}}, since
{{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In {{SaxHandler}}, if an XML entity exceeds the entity byte limit, an exception
is thrown. Too bad the counter is not being reset, so when parsing another,
valid XML message, the same exception is thrown again. However, this only
happens when using the default XMLReader {{Piccolo}}, since
{{PiccoloSaxHandler}} is cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new XmlReaderSaxLoader(xr);
// I've noticed that most XMLReaders don't like a null
EntityResolver...
if (er != null)
xr.setEntityResolver(er);
}
{code}
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. Using the JDK parser, everything's fine");
}
}
{code}
The problem's here (Locale.java:3296):
{code}
if (_insideEntity!=0)
{
if ((_entityBytes += length) > _entityBytesLimit)
{
XmlError err =
XmlError.forMessage(XmlErrorCodes.EXCEPTION_EXCEEDED_ENTITY_BYTES,
new Integer[]{ new Integer(_entityBytesLimit) });
throw new SAXException(err.getMessage());
}
}
{code}
was:
In SaxHandler, if an XML entity exceeds the entity byte limit, an exception is
thrown. Too bad the counter is not being reset, so when parsing another, valid
XML message, the same exception is thrown again. However, this only happens
when using the default XMLReader {{Piccolo}}, since {{PiccoloSaxHandler}} is
cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOpti
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In SaxHandler, if an XML entity exceeds the entity byte limit, an exception is
thrown. Too bad the counter is not being reset, so when parsing another, valid
XML message, the same exception is thrown again. However, this only happens
when using the default XMLReader {{Piccolo}}, since {{PiccoloSaxHandler}} is
cached:
{code}
private static SaxLoader getPiccoloSaxLoader()
{
SaxLoader piccoloLoader = (SaxLoader) SystemCache.get().getSaxLoader();
if (piccoloLoader == null)
{
piccoloLoader = PiccoloSaxLoader.newInstance();
SystemCache.get().setSaxLoader(piccoloLoader);
}
return piccoloLoader;
}
{code}
When using a differend XMLReader, everything is fine since the XMLReader is
never cached:
{code}
if (options.hasOption(XmlOptions.LOAD_USE_XMLREADER))
{
XMLReader xr = (XMLReader) options.get(
XmlOptions.LOAD_USE_XMLREADER);
if (xr == null)
throw new IllegalArgumentException("XMLReader is null");
sl = new XmlReaderSaxLoader(xr);
// I've noticed that most XMLReaders don't like a null
EntityResolver...
if (er != null)
xr.setEntityResolver(er);
}
{code}
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. Using the JDK parser, everything's fine");
}
}
{code}
The problem's here (Locale.java:3296):
{code}
if (_insideEntity!=0)
{
if ((_entityBytes += length) > _entityBytesLimit)
{
XmlError err =
XmlError.forMessage(XmlErrorCodes.EXCEPTION_EXCEEDED_ENTITY_BYTES,
new Integer[]{ new Integer(_entityBytesLimit) });
throw new SAXException(err.getMessage());
}
}
{code}
was:
In SaxHandler, if an XML entity exceeds the entity byte limit, an exception is
thrown. Too bad the counter is not being reset, so when parsing another, valid
XML message, the same exception is thrown again.
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n&quo
[jira] [Updated] (XMLBEANS-512) SaxHandler should be reset on exception
[
https://issues.apache.org/jira/browse/XMLBEANS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michel Jung updated XMLBEANS-512:
-
Description:
In SaxHandler, if an XML entity exceeds the entity byte limit, an exception is
thrown. Too bad the counter is not being reset, so when parsing another, valid
XML message, the same exception is thrown again.
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. Using the JDK parser, everything's fine");
}
}
{code}
The problem's here (Locale.java:3296):
{code}
if (_insideEntity!=0)
{
if ((_entityBytes += length) > _entityBytesLimit)
{
XmlError err =
XmlError.forMessage(XmlErrorCodes.EXCEPTION_EXCEEDED_ENTITY_BYTES,
new Integer[]{ new Integer(_entityBytesLimit) });
throw new SAXException(err.getMessage());
}
}
{code}
was:
In SaxHandler, if an XML entity exceeds the entity byte limit, an exception is
thrown. Too bad the counter is not being reset, so when parsing another, valid
XML message, the same exception is thrown again.
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseX
[jira] [Created] (XMLBEANS-512) SaxHandler should be reset on exception
Michel Jung created XMLBEANS-512:
Summary: SaxHandler should be reset on exception
Key: XMLBEANS-512
URL: https://issues.apache.org/jira/browse/XMLBEANS-512
Project: XMLBeans
Issue Type: Bug
Affects Versions: Version 2.6
Reporter: Michel Jung
In SaxHandler, if an XML entity exceeds the entity byte limit, an exception is
thrown. Too bad the counter is not being reset, so when parsing another, valid
XML message, the same exception is thrown again.
The following example reproduces the problem:
{code}
package xmlbeansbug;
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.impl.store.Locale;
import org.xml.sax.SAXException;
public class Bug {
private static final String BILLION_LAUGHS = "\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"\n" +
"]>\n" +
"&lol9;";
private static final String VALID_XML = "\n" +
"foobar";
public static void main(String[] args) throws IOException, SAXException,
XmlException, ParserConfigurationException {
new Bug().demonstrate();
}
private void demonstrate() throws IOException, SAXException, XmlException,
ParserConfigurationException {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
System.out.println("1. Valid XML message was parsed successfully");
try {
Locale.parseToXmlObject(null, BILLION_LAUGHS, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("2. Billion Laughs XML could not be parsed: " +
e.getMessage());
}
try {
Locale.parseToXmlObject(null, VALID_XML, null, new XmlOptions());
} catch (XmlException e) {
System.out.println("3. Now, parsing a valid XML message also throws an
exception");
}
XmlOptions xmlOptions = new XmlOptions();
xmlOptions.setLoadUseXMLReader(SAXParserFactory.newInstance().newSAXParser().getXMLReader());
Locale.parseToXmlObject(null, VALID_XML, null, xmlOptions);
System.out.println("4. Using the JDK parser, everything's fine");
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-376) LinkageError: loader constraint violation ... when resolving method org.apache.xmlbeans.impl.store.Xobj$NodeXobj.setUserData
[ https://issues.apache.org/jira/browse/XMLBEANS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969351#comment-13969351 ] Theo Gülcher commented on XMLBEANS-376: --- This is solved since 2.6.0 is compatible with Java 6. > LinkageError: loader constraint violation ... when resolving method > org.apache.xmlbeans.impl.store.Xobj$NodeXobj.setUserData > > > Key: XMLBEANS-376 > URL: https://issues.apache.org/jira/browse/XMLBEANS-376 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: OS: Windows XP SP2 > Java: JDK 1.6.0_06 > JBoss 5.0.1 CR1 >Reporter: Aldrin E Baroi >Priority: Minor > > I get linkage error in JBoss 5.0.1 CR1 with XMLBean 2.3.0. > I have fixed the problem by creating xbean.jar from 2.3.0 source by modifying > the following in the ANT build.xml file: > > <--- commented it out > > <--- changed value from 1.4 to 1.5 > excludes="javax/**,org/w3c/**"/> <--- modified to exclude javax & org/w3c > in "xbean.jar" target > Here is the partial stacktrace: > 15:45:54,543 INFO [STDOUT] 2008-07-08 15:45:54,543 HDScanner INFO > NotificationManager : Loading notifcation configuration... > 15:45:54,746 ERROR [[/...ELIDED...]] Exception sending context initialized > event to listener instance of class [...ELIDED...] > java.lang.LinkageError: loader constraint violation in interface itable > initialization: when resolving method > "org.apache.xmlbeans.impl.store.Xobj$NodeXobj.setU > serData(Ljava/lang/String;Ljava/lang/Object;Lorg/w3c/dom/UserDataHandler;)Ljava/lang/Object;" > the class loader (instance of org/jboss/classloader/spi/base/BaseC > lassLoader) of the current class, > org/apache/xmlbeans/impl/store/Xobj$NodeXobj, and the class loader (instance > of ) for interface org/w3c/dom/Node have different Class objects > for the type org/w3c/dom/UserDataHandler used in the signature > at > org.apache.xmlbeans.impl.store.Cur.createDomDocumentRootXobj(Cur.java:244) > at > org.apache.xmlbeans.impl.store.Cur.createDomDocumentRootXobj(Cur.java:233) > at > org.apache.xmlbeans.impl.store.Cur$CurLoadContext.(Cur.java:2836) > ... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-511) NPE @ SchemaTypeImpl.isAssignableFrom()
[
https://issues.apache.org/jira/browse/XMLBEANS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Keller updated XMLBEANS-511:
Description:
I caught following NullPointerException, using XmlBeans Version 2.5:
java.lang.NullPointerException
at
org.apache.xmlbeans.impl.schema.SchemaTypeImpl.isAssignableFrom(SchemaTypeImpl.java:2267)
at
org.apache.xmlbeans.impl.schema.SchemaTypeImpl.createElementType(SchemaTypeImpl.java:1044)
at
org.apache.xmlbeans.impl.values.XmlObjectBase.create_element_user(XmlObjectBase.java:927)
at org.apache.xmlbeans.impl.store.Xobj.getUser(Xobj.java:1669)
at org.apache.xmlbeans.impl.store.Xobj.find_element_user(Xobj.java:2074)
Seems, like there's a missing Null-Check.
/xmlbeans/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeImpl.java,
line 2269 and following
type is set by type.getBaseType() which explicitly may return null. The
following type.equals(this) produces above seen NPE.
was:
I caught following NullPointerException, using XmlBeans Version 2.5:
{noformat}
java.lang.NullPointerException
at
org.apache.xmlbeans.impl.schema.SchemaTypeImpl.isAssignableFrom(SchemaTypeImpl.java:2267)
at
org.apache.xmlbeans.impl.schema.SchemaTypeImpl.createElementType(SchemaTypeImpl.java:1044)
at
org.apache.xmlbeans.impl.values.XmlObjectBase.create_element_user(XmlObjectBase.java:927)
at org.apache.xmlbeans.impl.store.Xobj.getUser(Xobj.java:1669)
at org.apache.xmlbeans.impl.store.Xobj.find_element_user(Xobj.java:2074)
...
{noformat}
Seems, like there's a missing Null-Check.
/xmlbeans/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeImpl.java,
line 2269 and following
{{type}} is set by {{type.getBaseType()}} which explicitly may return null. The
following {{type.equals(this)}} produces above seen NPE.
> NPE @ SchemaTypeImpl.isAssignableFrom()
> ---
>
> Key: XMLBEANS-511
> URL: https://issues.apache.org/jira/browse/XMLBEANS-511
> Project: XMLBeans
> Issue Type: Bug
>Affects Versions: Version 2.5, Version 2.6.1
>Reporter: Florian Keller
>
> I caught following NullPointerException, using XmlBeans Version 2.5:
> java.lang.NullPointerException
> at
> org.apache.xmlbeans.impl.schema.SchemaTypeImpl.isAssignableFrom(SchemaTypeImpl.java:2267)
> at
> org.apache.xmlbeans.impl.schema.SchemaTypeImpl.createElementType(SchemaTypeImpl.java:1044)
> at
> org.apache.xmlbeans.impl.values.XmlObjectBase.create_element_user(XmlObjectBase.java:927)
> at org.apache.xmlbeans.impl.store.Xobj.getUser(Xobj.java:1669)
> at org.apache.xmlbeans.impl.store.Xobj.find_element_user(Xobj.java:2074)
> Seems, like there's a missing Null-Check.
> /xmlbeans/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeImpl.java,
> line 2269 and following
> type is set by type.getBaseType() which explicitly may return null. The
> following type.equals(this) produces above seen NPE.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-511) NPE @ SchemaTypeImpl.isAssignableFrom()
Florian Keller created XMLBEANS-511:
---
Summary: NPE @ SchemaTypeImpl.isAssignableFrom()
Key: XMLBEANS-511
URL: https://issues.apache.org/jira/browse/XMLBEANS-511
Project: XMLBeans
Issue Type: Bug
Affects Versions: Version 2.5, Version 2.6.1
Reporter: Florian Keller
I caught following NullPointerException, using XmlBeans Version 2.5:
{noformat}
java.lang.NullPointerException
at
org.apache.xmlbeans.impl.schema.SchemaTypeImpl.isAssignableFrom(SchemaTypeImpl.java:2267)
at
org.apache.xmlbeans.impl.schema.SchemaTypeImpl.createElementType(SchemaTypeImpl.java:1044)
at
org.apache.xmlbeans.impl.values.XmlObjectBase.create_element_user(XmlObjectBase.java:927)
at org.apache.xmlbeans.impl.store.Xobj.getUser(Xobj.java:1669)
at org.apache.xmlbeans.impl.store.Xobj.find_element_user(Xobj.java:2074)
...
{noformat}
Seems, like there's a missing Null-Check.
/xmlbeans/src/typeimpl/org/apache/xmlbeans/impl/schema/SchemaTypeImpl.java,
line 2269 and following
{{type}} is set by {{type.getBaseType()}} which explicitly may return null. The
following {{type.equals(this)}} produces above seen NPE.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-510) inst2xsd produces incorrect xsd for simple xml
[ https://issues.apache.org/jira/browse/XMLBEANS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Slama updated XMLBEANS-510: -- Attachment: works_well.xsd works_well.xml bug.xsd bug.xml > inst2xsd produces incorrect xsd for simple xml > -- > > Key: XMLBEANS-510 > URL: https://issues.apache.org/jira/browse/XMLBEANS-510 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Martin Slama > Attachments: bug.xml, bug.xsd, works_well.xml, works_well.xsd > > > See attached file bug.xml. XSD file bug.xsd is generated by inst2xsd. Compare > it with works_well.xml and generated works_well.xsd. Order of elements at > given xml affects generated xsd. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-510) inst2xsd produces incorrect xsd for simple xml
Martin Slama created XMLBEANS-510: - Summary: inst2xsd produces incorrect xsd for simple xml Key: XMLBEANS-510 URL: https://issues.apache.org/jira/browse/XMLBEANS-510 Project: XMLBeans Issue Type: Bug Affects Versions: Version 2.6 Reporter: Martin Slama See attached file bug.xml. XSD file bug.xsd is generated by inst2xsd. Compare it with works_well.xml and generated works_well.xsd. Order of elements at given xml affects generated xsd. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
[ https://issues.apache.org/jira/browse/XMLBEANS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Klerehag updated XMLBEANS-499: Affects Version/s: Version 2.6 > xmlbeans2.6.0.jar contians duplicate class files > > > Key: XMLBEANS-499 > URL: https://issues.apache.org/jira/browse/XMLBEANS-499 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Peter Klerehag > > The xlmbeans-2.6.0.jar contains some duplicate class files which in some > cases can generate problems with classloading. > It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other > locations as well > Did following and there you clearly see 2x of ReferenceResolver > unzip -l xmlbeans-2.6.0.jar | grep Resolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 214 2012-07-23 15:42 > org/apache/xmlbeans/impl/common/PrefixResolver.class > 45339 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class > 11284 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscResolver.class > 26162 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class > 3524 2012-07-23 15:42 > org/apache/xmlbeans/impl/tool/SchemaImportResolver.class > 1069 2012-07-23 15:42 > org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
[ https://issues.apache.org/jira/browse/XMLBEANS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13857246#comment-13857246 ] Chad Wilson commented on XMLBEANS-499: -- This issues makes it so we cannot use this version, our maven enforcer kills the build when we include this dependency. > xmlbeans2.6.0.jar contians duplicate class files > > > Key: XMLBEANS-499 > URL: https://issues.apache.org/jira/browse/XMLBEANS-499 > Project: XMLBeans > Issue Type: Bug >Reporter: Peter Klerehag > > The xlmbeans-2.6.0.jar contains some duplicate class files which in some > cases can generate problems with classloading. > It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other > locations as well > Did following and there you clearly see 2x of ReferenceResolver > unzip -l xmlbeans-2.6.0.jar | grep Resolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 214 2012-07-23 15:42 > org/apache/xmlbeans/impl/common/PrefixResolver.class > 45339 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class > 11284 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscResolver.class > 26162 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class > 3524 2012-07-23 15:42 > org/apache/xmlbeans/impl/tool/SchemaImportResolver.class > 1069 2012-07-23 15:42 > org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Comment Edited] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
[ https://issues.apache.org/jira/browse/XMLBEANS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13857246#comment-13857246 ] Chad Wilson edited comment on XMLBEANS-499 at 12/27/13 2:04 AM: This issues makes it so we cannot use this version, our maven enforcer kills the build when we include this dependency. This issue exists in both maven central as well as the xmlbeans download page. was (Author: chadawilson): This issues makes it so we cannot use this version, our maven enforcer kills the build when we include this dependency. > xmlbeans2.6.0.jar contians duplicate class files > > > Key: XMLBEANS-499 > URL: https://issues.apache.org/jira/browse/XMLBEANS-499 > Project: XMLBeans > Issue Type: Bug >Reporter: Peter Klerehag > > The xlmbeans-2.6.0.jar contains some duplicate class files which in some > cases can generate problems with classloading. > It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other > locations as well > Did following and there you clearly see 2x of ReferenceResolver > unzip -l xmlbeans-2.6.0.jar | grep Resolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 214 2012-07-23 15:42 > org/apache/xmlbeans/impl/common/PrefixResolver.class > 45339 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class > 11284 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscResolver.class > 26162 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class > 3524 2012-07-23 15:42 > org/apache/xmlbeans/impl/tool/SchemaImportResolver.class > 1069 2012-07-23 15:42 > org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-509) License problem with xmlbeans-2.6.0.jar because there is a SUN license on it
Wieslaw Calinski created XMLBEANS-509: - Summary: License problem with xmlbeans-2.6.0.jar because there is a SUN license on it Key: XMLBEANS-509 URL: https://issues.apache.org/jira/browse/XMLBEANS-509 Project: XMLBeans Issue Type: Bug Components: XmlObject Affects Versions: Version 2.6 Environment: Linux Reporter: Wieslaw Calinski it seems like there is a license problem with it because there is a SUN license on it: org.apache.xmlbeans xmlbeans 2.6.0 -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836291#comment-13836291 ] zjerich commented on XMLBEANS-502: -- Tomcat 7 + JDK 6 + POI 3.9 (xmlbeans2.3 ~ 2.6) created a ThreadLocal with key of type [org.apache.xmlbeans... > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-508) inst2xsd fails with StackOverflowError on simple xml
[ https://issues.apache.org/jira/browse/XMLBEANS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Slama updated XMLBEANS-508: -- Affects Version/s: Version 2.6 > inst2xsd fails with StackOverflowError on simple xml > > > Key: XMLBEANS-508 > URL: https://issues.apache.org/jira/browse/XMLBEANS-508 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Martin Slama > Attachments: input.xml > > > Try to extract schema from attached file using inst2xsd. It fails with > StackOverflowError. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-508) inst2xsd fails with StackOverflowError on simple xml
[ https://issues.apache.org/jira/browse/XMLBEANS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Slama updated XMLBEANS-508: -- Attachment: input.xml > inst2xsd fails with StackOverflowError on simple xml > > > Key: XMLBEANS-508 > URL: https://issues.apache.org/jira/browse/XMLBEANS-508 > Project: XMLBeans > Issue Type: Bug >Reporter: Martin Slama > Attachments: input.xml > > > Try to extract schema from attached file using inst2xsd. It fails with > StackOverflowError. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-508) inst2xsd fails with StackOverflowError on simple xml
Martin Slama created XMLBEANS-508: - Summary: inst2xsd fails with StackOverflowError on simple xml Key: XMLBEANS-508 URL: https://issues.apache.org/jira/browse/XMLBEANS-508 Project: XMLBeans Issue Type: Bug Reporter: Martin Slama Try to extract schema from attached file using inst2xsd. It fails with StackOverflowError. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820210#comment-13820210 ] Jochen Kemnade commented on XMLBEANS-502: - Still an issue with poi-3.10-beta-2 which relies on xmlbeans 2.3.0. > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-354) SCOMP generates two methods with same name but different return types when generating java 1.5 code
[ https://issues.apache.org/jira/browse/XMLBEANS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807886#comment-13807886 ] Steven Keens commented on XMLBEANS-354: --- Bug 396, which was fixed, might also be related to this bug. > SCOMP generates two methods with same name but different return types when > generating java 1.5 code > --- > > Key: XMLBEANS-354 > URL: https://issues.apache.org/jira/browse/XMLBEANS-354 > Project: XMLBeans > Issue Type: Bug > Components: Compiler >Affects Versions: Version 2.3, Version 2.3.1 > Environment: Windows XP > Java 1.6.0_03 >Reporter: Steven Keens > Attachments: xmlbeanbug.xsd > > > When I run scomp.bat generating Java 1.5 source on the attached XSD I get > uncompilable java code. When I run scomp generating Java 1.4 source I don't > get the errors. > Note: The attached XSD is a stripped down version of a publicly available > schema from the OGC's (Open Geospatial Consortium) GML version 3.1.1 schemas. > You would not have wanted to fix this bug based upon those schemas! > --- Screen grab to Generate Java 1.4 > c:\xmlbeans\bug>scomp -javasource 1.4 xmlbeansbug.xsd > Time to build schema type system: 0.5 seconds > Time to generate code: 0.156 seconds > Time to compile code: 0.875 seconds > Compiled types to: xmltypes.jar > --- Screen grab to Generate Java 1.5 > c:\xmlbeans\bug>scomp -javasource 1.5 xmlbeansbug.xsd > Time to build schema type system: 0.516 seconds > Time to generate code: 0.14 seconds > c:\Temp\xbean9041.d\src\net\opengis\gml\TestDocument.java:132: getPosList() > is already defined in net.opengis.gml.TestDocument.Test > net.opengis.gml.DirectPositionListType getPosList(); >^ > c:\Temp\xbean9041.d\src\net\opengis\gml\impl\TestDocumentImpl.java:385: > getPosList() is already defined in > net.opengis.gml.impl.TestDocumentImpl.TestImpl > public net.opengis.gml.DirectPositionListType getPosList() > ^ > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: c:\Temp\xbean9041.d\src\net\opengis\gml\impl\TestDocumentImpl.java uses > un > checked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 2 errors -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-354) SCOMP generates two methods with same name but different return types when generating java 1.5 code
[ https://issues.apache.org/jira/browse/XMLBEANS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807882#comment-13807882 ] Steven Keens commented on XMLBEANS-354: --- I think bug 225 and this bug are duplicates. > SCOMP generates two methods with same name but different return types when > generating java 1.5 code > --- > > Key: XMLBEANS-354 > URL: https://issues.apache.org/jira/browse/XMLBEANS-354 > Project: XMLBeans > Issue Type: Bug > Components: Compiler >Affects Versions: Version 2.3, Version 2.3.1 > Environment: Windows XP > Java 1.6.0_03 >Reporter: Steven Keens > Attachments: xmlbeanbug.xsd > > > When I run scomp.bat generating Java 1.5 source on the attached XSD I get > uncompilable java code. When I run scomp generating Java 1.4 source I don't > get the errors. > Note: The attached XSD is a stripped down version of a publicly available > schema from the OGC's (Open Geospatial Consortium) GML version 3.1.1 schemas. > You would not have wanted to fix this bug based upon those schemas! > --- Screen grab to Generate Java 1.4 > c:\xmlbeans\bug>scomp -javasource 1.4 xmlbeansbug.xsd > Time to build schema type system: 0.5 seconds > Time to generate code: 0.156 seconds > Time to compile code: 0.875 seconds > Compiled types to: xmltypes.jar > --- Screen grab to Generate Java 1.5 > c:\xmlbeans\bug>scomp -javasource 1.5 xmlbeansbug.xsd > Time to build schema type system: 0.516 seconds > Time to generate code: 0.14 seconds > c:\Temp\xbean9041.d\src\net\opengis\gml\TestDocument.java:132: getPosList() > is already defined in net.opengis.gml.TestDocument.Test > net.opengis.gml.DirectPositionListType getPosList(); >^ > c:\Temp\xbean9041.d\src\net\opengis\gml\impl\TestDocumentImpl.java:385: > getPosList() is already defined in > net.opengis.gml.impl.TestDocumentImpl.TestImpl > public net.opengis.gml.DirectPositionListType getPosList() > ^ > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: c:\Temp\xbean9041.d\src\net\opengis\gml\impl\TestDocumentImpl.java uses > un > checked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 2 errors -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-506) NPE trying to load resource file if XmlBeans was loaded by the bootstrap ClassLoader
[ https://issues.apache.org/jira/browse/XMLBEANS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hengst updated XMLBEANS-506: --- Description: To solve a dependency issue, we put XmlBeans 2.5.0 into the endorsed folder. This brought the following exception: java.lang.NullPointerException at org.apache.xmlbeans.impl.store.Path.(Path.java:65) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.getMethod(SchemaTypeLoaderBase.java:73) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.(SchemaTypeLoaderBase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.xmlbeans.XmlBeans.getNoType(XmlBeans.java:856) at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:881) The source code of org.apache.xmlbeans.impl.store.Path looks like this: 63: ClassLoader cl = Path.class.getClassLoader(); 64: String id = "META-INF/services/org.apache.xmlbeans.impl.store.PathDelegate.SelectPathInterface"; 65: InputStream in = cl.getResourceAsStream(id); <- NPE occurs here This appears to be a bug. The JavaDoc for getClassLoader() says: "Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader." So the caller of getClassLoader() should take into account that it might return null, which does not happen here. I would suggest changing line 65 to the following: InputStream in = Path.class.getResourceAsStream(id); Note: The Class method works slightly different. If the resource name does not contain a path it will look for the file in the package where the Class is located. I checked XmlBeans 2.6.0 and browsed the SVN sources, the problem still exists. was: To solve a dependency issue, we put XmlBeans 2.5.0 into the endorsed folder. This brought the following exception: java.lang.NullPointerException at org.apache.xmlbeans.impl.store.Path.(Path.java:65) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.getMethod(SchemaTypeLoaderBase.java:73) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.(SchemaTypeLoaderBase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.xmlbeans.XmlBeans.getNoType(XmlBeans.java:856) at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:881) The source code of org.apache.xmlbeans.impl.store.Path looks like this: 63: ClassLoader cl = Path.class.getClassLoader(); 64: String id = "META-INF/services/org.apache.xmlbeans.impl.store.PathDelegate.SelectPathInterface"; 65: InputStream in = cl.getResourceAsStream(id); <- NPE occurs here This appears to be a bug. The JavaDoc for getClassLoader() says: "Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader." So the caller of getClassLoader() should take into account that it might return null, which does not happen here. I would suggest changing line 65 to the following: InputStream in = Path.class.getResourceAsStream(id); I checked XmlBeans 2.6.0 and browsed the SVN sources, the problem still exists. Affects Version/s: Version 2.6 > NPE trying to load resource file if XmlBeans was loaded by the bootstrap > ClassLoader > > > Key: XMLBEANS-506 > URL: https://issues.apache.org/jira/browse/XMLBEANS-506 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.5, Version 2.6 > Environment: JBoss 6.1.0, JVM 1.6.0_30, CentOS 5.7 x86_64 >Reporter: Daniel Hengst > > To solve a dependency issue, we put XmlBeans 2.5.0 into the endorsed folder. > This brought the following exception: > java.lang.NullPointerException > at org.apache.xmlbeans.impl.store.Path.(Path.java:65) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:169) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.getMethod(SchemaTypeLoaderBase.java:73) > at > org.apache.xmlbeans.impl.schem
[jira] [Updated] (XMLBEANS-507) XmlBeans deploys sources with "source" classifier into Maven repos
[ https://issues.apache.org/jira/browse/XMLBEANS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bondarenko updated XMLBEANS-507: - Description: XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar Also files not related to XmlBeans (like org.w3c.* and javax.xml.*) must be removed from source packages. was: XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar Also files not related to XmlBeans (like ) > XmlBeans deploys sources with "source" classifier into Maven repos > -- > > Key: XMLBEANS-507 > URL: https://issues.apache.org/jira/browse/XMLBEANS-507 > Project: XMLBeans > Issue Type: Bug >Reporter: Ivan Bondarenko >Priority: Trivial > > XmlBeans sources are deployed with "source" classifier into Maven repos, > while by convention must be deployed with "sources" classifier. Thus it is > not understandable by Maven and soft related to Maven. > So xmlbeans-XXX-sources.jar file must be deployed next to each > xmlbeans-XXX-source.jar > Also files not related to XmlBeans (like org.w3c.* and javax.xml.*) must be > removed from source packages. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-507) XmlBeans deploys sources with "source" classifier into Maven repos
[ https://issues.apache.org/jira/browse/XMLBEANS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bondarenko updated XMLBEANS-507: - Description: XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar Also files not related to XmlBeans (like ) was: XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar > XmlBeans deploys sources with "source" classifier into Maven repos > -- > > Key: XMLBEANS-507 > URL: https://issues.apache.org/jira/browse/XMLBEANS-507 > Project: XMLBeans > Issue Type: Bug >Reporter: Ivan Bondarenko >Priority: Trivial > > XmlBeans sources are deployed with "source" classifier into Maven repos, > while by convention must be deployed with "sources" classifier. Thus it is > not understandable by Maven and soft related to Maven. > So xmlbeans-XXX-sources.jar file must be deployed next to each > xmlbeans-XXX-source.jar > Also files not related to XmlBeans (like ) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-507) XmlBeans deploys sources with "source" classifier into Maven repos
[ https://issues.apache.org/jira/browse/XMLBEANS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bondarenko updated XMLBEANS-507: - Description: XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar Also files not related to XmlBeans (like org.w3c.* and javax.xml.* packages) must be removed from sources. was: XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar Also files not related to XmlBeans (like org.w3c.* and javax.xml.*) must be removed from source packages. > XmlBeans deploys sources with "source" classifier into Maven repos > -- > > Key: XMLBEANS-507 > URL: https://issues.apache.org/jira/browse/XMLBEANS-507 > Project: XMLBeans > Issue Type: Bug >Reporter: Ivan Bondarenko >Priority: Trivial > > XmlBeans sources are deployed with "source" classifier into Maven repos, > while by convention must be deployed with "sources" classifier. Thus it is > not understandable by Maven and soft related to Maven. > So xmlbeans-XXX-sources.jar file must be deployed next to each > xmlbeans-XXX-source.jar > Also files not related to XmlBeans (like org.w3c.* and javax.xml.* packages) > must be removed from sources. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-507) XmlBeans deploys sources with "source" classifier into Maven repos
Ivan Bondarenko created XMLBEANS-507: Summary: XmlBeans deploys sources with "source" classifier into Maven repos Key: XMLBEANS-507 URL: https://issues.apache.org/jira/browse/XMLBEANS-507 Project: XMLBeans Issue Type: Bug Reporter: Ivan Bondarenko Priority: Trivial XmlBeans sources are deployed with "source" classifier into Maven repos, while by convention must be deployed with "sources" classifier. Thus it is not understandable by Maven and soft related to Maven. So xmlbeans-XXX-sources.jar file must be deployed next to each xmlbeans-XXX-source.jar -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-484) org.w3c.dom classes lead to jar-hell
[ https://issues.apache.org/jira/browse/XMLBEANS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784945#comment-13784945 ] Tobias Mattsson commented on XMLBEANS-484: -- Seems like this also fixes XMLBEANS-376 > org.w3c.dom classes lead to jar-hell > > > Key: XMLBEANS-484 > URL: https://issues.apache.org/jira/browse/XMLBEANS-484 > Project: XMLBeans > Issue Type: Bug >Reporter: Ivan Bondarenko >Assignee: Cezar Andrei > Fix For: Version 2.5.1 > > > org.w3c.dom classes are included into xmlbeans release. This leads to > jar-hell, so the classes must be removed from there. Including such classes > is the responsibility of XML APIs. > Offtop (don't know where to write this): xmlbeans-2.5.0 sources are deployed > incorrectly into repository - classifier 'source' is used instead of > 'sources'. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-506) NPE trying to load resource file if XmlBeans was loaded by the bootstrap ClassLoader
Daniel Hengst created XMLBEANS-506: -- Summary: NPE trying to load resource file if XmlBeans was loaded by the bootstrap ClassLoader Key: XMLBEANS-506 URL: https://issues.apache.org/jira/browse/XMLBEANS-506 Project: XMLBeans Issue Type: Bug Affects Versions: Version 2.5 Environment: JBoss 6.1.0, JVM 1.6.0_30, CentOS 5.7 x86_64 Reporter: Daniel Hengst To solve a dependency issue, we put XmlBeans 2.5.0 into the endorsed folder. This brought the following exception: java.lang.NullPointerException at org.apache.xmlbeans.impl.store.Path.(Path.java:65) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.getMethod(SchemaTypeLoaderBase.java:73) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.(SchemaTypeLoaderBase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.xmlbeans.XmlBeans.getNoType(XmlBeans.java:856) at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:881) The source code of org.apache.xmlbeans.impl.store.Path looks like this: 63: ClassLoader cl = Path.class.getClassLoader(); 64: String id = "META-INF/services/org.apache.xmlbeans.impl.store.PathDelegate.SelectPathInterface"; 65: InputStream in = cl.getResourceAsStream(id); <- NPE occurs here This appears to be a bug. The JavaDoc for getClassLoader() says: "Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader." So the caller of getClassLoader() should take into account that it might return null, which does not happen here. I would suggest changing line 65 to the following: InputStream in = Path.class.getResourceAsStream(id); I checked XmlBeans 2.6.0 and browsed the SVN sources, the problem still exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Closed] (XMLBEANS-505) aaaaaaaaaa
[ https://issues.apache.org/jira/browse/XMLBEANS-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Danner closed XMLBEANS-505. - Resolution: Invalid Doesn't seem like a valid bug... > aa > -- > > Key: XMLBEANS-505 > URL: https://issues.apache.org/jira/browse/XMLBEANS-505 > Project: XMLBeans > Issue Type: New Feature >Reporter: raja satish >Priority: Minor > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-505) aaaaaaaaaa
raja satish created XMLBEANS-505: Summary: aa Key: XMLBEANS-505 URL: https://issues.apache.org/jira/browse/XMLBEANS-505 Project: XMLBeans Issue Type: New Feature Reporter: raja satish Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-504) GDate and associated classes allow year values that don't conform to the XML Schema 1.0 specification
[ https://issues.apache.org/jira/browse/XMLBEANS-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harry Wambolt updated XMLBEANS-504: --- Affects Version/s: Version 2.5 > GDate and associated classes allow year values that don't conform to the XML > Schema 1.0 specification > - > > Key: XMLBEANS-504 > URL: https://issues.apache.org/jira/browse/XMLBEANS-504 > Project: XMLBeans > Issue Type: Bug > Components: XmlObject >Affects Versions: Version 2.5, Version 2.6 > Environment: All >Reporter: Harry Wambolt >Priority: Critical > > Comments in the GDate code specify that a change was made in revision 783519 > "Extended the year limitations or (sic) dates". This breaks schema > validation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-504) GDate and associated classes allow year values that don't conform to the XML Schema 1.0 specification
[ https://issues.apache.org/jira/browse/XMLBEANS-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harry Wambolt updated XMLBEANS-504: --- Priority: Critical (was: Major) > GDate and associated classes allow year values that don't conform to the XML > Schema 1.0 specification > - > > Key: XMLBEANS-504 > URL: https://issues.apache.org/jira/browse/XMLBEANS-504 > Project: XMLBeans > Issue Type: Bug > Components: XmlObject >Affects Versions: Version 2.6 > Environment: All >Reporter: Harry Wambolt >Priority: Critical > > Comments in the GDate code specify that a change was made in revision 783519 > "Extended the year limitations or (sic) dates". This breaks schema > validation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-504) GDate and associated classes allow year values that don't conform to the XML Schema 1.0 specification
Harry Wambolt created XMLBEANS-504: -- Summary: GDate and associated classes allow year values that don't conform to the XML Schema 1.0 specification Key: XMLBEANS-504 URL: https://issues.apache.org/jira/browse/XMLBEANS-504 Project: XMLBeans Issue Type: Bug Components: XmlObject Affects Versions: Version 2.6 Environment: All Reporter: Harry Wambolt Comments in the GDate code specify that a change was made in revision 783519 "Extended the year limitations or (sic) dates". This breaks schema validation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-503) [patch] Add support for passing -nowarn to the Ant task
[ https://issues.apache.org/jira/browse/XMLBEANS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elvis Stansvik updated XMLBEANS-503: Summary: [patch] Add support for passing -nowarn to the Ant task (was: Add support for passing -nowarn to the Ant task) > [patch] Add support for passing -nowarn to the Ant task > --- > > Key: XMLBEANS-503 > URL: https://issues.apache.org/jira/browse/XMLBEANS-503 > Project: XMLBeans > Issue Type: New Feature > Components: Compiler, Website >Affects Versions: unspecified >Reporter: Elvis Stansvik >Priority: Minor > Attachments: xmlbeans-ant-support-nowarn.diff > > > The attached patch adds support for a new "nowarn" attribute to the Ant task, > for controlling whether -nowarn should be passed to the JDK compiler (analog > to the attribute of the javac task with the same name). > As a user, you're often not interested in warnings in generated code. In my > case I wanted to suppress > [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction > with -source 1.4 > but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Issue Comment Deleted] (XMLBEANS-503) Add support for passing -nowarn to the Ant task
[ https://issues.apache.org/jira/browse/XMLBEANS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elvis Stansvik updated XMLBEANS-503: Comment: was deleted (was: Patch to add the "nowarn" attribute to Ant task.) > Add support for passing -nowarn to the Ant task > --- > > Key: XMLBEANS-503 > URL: https://issues.apache.org/jira/browse/XMLBEANS-503 > Project: XMLBeans > Issue Type: New Feature > Components: Compiler, Website >Affects Versions: unspecified >Reporter: Elvis Stansvik >Priority: Minor > Attachments: xmlbeans-ant-support-nowarn.diff > > > The attached patch adds support for a new "nowarn" attribute to the Ant task, > for controlling whether -nowarn should be passed to the JDK compiler (analog > to the attribute of the javac task with the same name). > As a user, you're often not interested in warnings in generated code. In my > case I wanted to suppress > [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction > with -source 1.4 > but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Issue Comment Deleted] (XMLBEANS-503) Add support for passing -nowarn to the Ant task
[ https://issues.apache.org/jira/browse/XMLBEANS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elvis Stansvik updated XMLBEANS-503: Comment: was deleted (was: Patch to add the "nowarn" attribute to Ant task.) > Add support for passing -nowarn to the Ant task > --- > > Key: XMLBEANS-503 > URL: https://issues.apache.org/jira/browse/XMLBEANS-503 > Project: XMLBeans > Issue Type: New Feature > Components: Compiler, Website >Affects Versions: unspecified >Reporter: Elvis Stansvik >Priority: Minor > Attachments: xmlbeans-ant-support-nowarn.diff, > xmlbeans-ant-support-nowarn.diff > > > The attached patch adds support for a new "nowarn" attribute to the Ant task, > for controlling whether -nowarn should be passed to the JDK compiler (analog > to the attribute of the javac task with the same name). > As a user, you're often not interested in warnings in generated code. In my > case I wanted to suppress > [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction > with -source 1.4 > but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-503) Add support for passing -nowarn to the Ant task
[ https://issues.apache.org/jira/browse/XMLBEANS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elvis Stansvik updated XMLBEANS-503: Attachment: (was: xmlbeans-ant-support-nowarn.diff) > Add support for passing -nowarn to the Ant task > --- > > Key: XMLBEANS-503 > URL: https://issues.apache.org/jira/browse/XMLBEANS-503 > Project: XMLBeans > Issue Type: New Feature > Components: Compiler, Website >Affects Versions: unspecified >Reporter: Elvis Stansvik >Priority: Minor > Attachments: xmlbeans-ant-support-nowarn.diff > > > The attached patch adds support for a new "nowarn" attribute to the Ant task, > for controlling whether -nowarn should be passed to the JDK compiler (analog > to the attribute of the javac task with the same name). > As a user, you're often not interested in warnings in generated code. In my > case I wanted to suppress > [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction > with -source 1.4 > but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-503) Add support for passing -nowarn to the Ant task
[ https://issues.apache.org/jira/browse/XMLBEANS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elvis Stansvik updated XMLBEANS-503: Attachment: xmlbeans-ant-support-nowarn.diff Patch to add the "nowarn" attribute to Ant task. > Add support for passing -nowarn to the Ant task > --- > > Key: XMLBEANS-503 > URL: https://issues.apache.org/jira/browse/XMLBEANS-503 > Project: XMLBeans > Issue Type: New Feature > Components: Compiler, Website >Affects Versions: unspecified >Reporter: Elvis Stansvik >Priority: Minor > Attachments: xmlbeans-ant-support-nowarn.diff, > xmlbeans-ant-support-nowarn.diff > > > The attached patch adds support for a new "nowarn" attribute to the Ant task, > for controlling whether -nowarn should be passed to the JDK compiler (analog > to the attribute of the javac task with the same name). > As a user, you're often not interested in warnings in generated code. In my > case I wanted to suppress > [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction > with -source 1.4 > but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-503) Add support for passing -nowarn to the Ant task
[ https://issues.apache.org/jira/browse/XMLBEANS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elvis Stansvik updated XMLBEANS-503: Attachment: xmlbeans-ant-support-nowarn.diff Patch to add the "nowarn" attribute to Ant task. > Add support for passing -nowarn to the Ant task > --- > > Key: XMLBEANS-503 > URL: https://issues.apache.org/jira/browse/XMLBEANS-503 > Project: XMLBeans > Issue Type: New Feature > Components: Compiler, Website >Affects Versions: unspecified >Reporter: Elvis Stansvik >Priority: Minor > Attachments: xmlbeans-ant-support-nowarn.diff, > xmlbeans-ant-support-nowarn.diff > > > The attached patch adds support for a new "nowarn" attribute to the Ant task, > for controlling whether -nowarn should be passed to the JDK compiler (analog > to the attribute of the javac task with the same name). > As a user, you're often not interested in warnings in generated code. In my > case I wanted to suppress > [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction > with -source 1.4 > but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-503) Add support for passing -nowarn to the Ant task
Elvis Stansvik created XMLBEANS-503: --- Summary: Add support for passing -nowarn to the Ant task Key: XMLBEANS-503 URL: https://issues.apache.org/jira/browse/XMLBEANS-503 Project: XMLBeans Issue Type: New Feature Components: Compiler, Website Affects Versions: unspecified Reporter: Elvis Stansvik Priority: Minor The attached patch adds support for a new "nowarn" attribute to the Ant task, for controlling whether -nowarn should be passed to the JDK compiler (analog to the attribute of the javac task with the same name). As a user, you're often not interested in warnings in generated code. In my case I wanted to suppress [ant:xmlbean] warning: [options] bootstrap class path not set in conjunction with -source 1.4 but I think the option to pass -nowarn is generally useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Popov updated XMLBEANS-502: Attachment: leak2.png leak1.png xmlbeans(ThreadLocal) + tomcat + threadpool = memory leak > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > Attachments: leak1.png, leak2.png > > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707140#comment-13707140 ] Valentin Popov commented on XMLBEANS-502: - We have same but little different situation. Tomcat 7 + JDK7 + POI 3.9 20121203. Some 6 treads on threadpoolexecutor iterate filesystem and parse of office documents. On that thread pool executer at the and we have OME. Snapshot is taken automatically by yourkit profiler and I see 8Gb of softreference generated by xmlbeans. Screenshot is attached > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > - > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > > Hello, > After creating this issue > https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to > create the issue here. This appears to be similar to > https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as > FIXED and as I'm using a more recent version (and as it's not completely > identical), I'm creating a new issue. > It would appear that XMLBeans is creating (and not clearing) ThreadLocal > variables. This causes Tomcat to complain about classloader leaks (see > messages below). Based on information in XMLBEANS-103, I have tried to coax > the JVM to clear the ThreadLocal (by performing garbage collection on the > JVM), but that doesn't clear the ThreadLocals, even if allowing time to > elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. > To workaround this, we're having to impose long downtime when a restart is > required. Perhaps a utility class within XMLBeans could be made available > with the POI distribution such as: > XMLBeansCache.clearThreadLocals() > ...that I could call from a "finally" block after processing the XSSF > document? > Here's the information from Tomcat's logs: > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.XmlBeans$1] (value > [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value > [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a > value of type [java.util.ArrayList] (value > [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the > web application was stopped. This is very likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.Locale$1] (value > [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/foobar] created a ThreadLocal with key of type > [org.apache.xmlbeans.impl.store.CharUtil$1] (value > [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type > [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-497) Unable to sign xbean.jar
[ https://issues.apache.org/jira/browse/XMLBEANS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696428#comment-13696428 ] Suresh Marru commented on XMLBEANS-497: --- Any update on this bug? This is gating the use of 2.6.0. An update release will be great. I can see the following classes duplicated: 251 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/Location.class 394 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/ReferenceResolver.class 1243 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/XMLEvent.class 858 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/XMLInputStream.class 245 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/XMLName.class 2335 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/XMLStreamException.class 2407 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/utils/NestedThrowable$Util.class 454 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/utils/NestedThrowable.class 0 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/events/ 277 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/Attribute.class 268 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/AttributeIterator.class 353 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/BufferedXMLInputStream.class 298 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/ChangePrefixMapping.class 256 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/CharacterData.class 178 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/Comment.class 202 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/ElementFilter.class 181 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/EndDocument.class 179 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/EndElement.class 234 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/EndPrefixMapping.class 213 Mon Jul 23 15:42:14 EDT 2012 org/apache/xmlbeans/xml/stream/EntityReference.class > Unable to sign xbean.jar > > > Key: XMLBEANS-497 > URL: https://issues.apache.org/jira/browse/XMLBEANS-497 > Project: XMLBeans > Issue Type: Bug > Components: XmlObject >Affects Versions: Version 2.6 > Environment: jarsigner >Reporter: J S >Priority: Critical > > jarsigner complains about a duplicate entry of > org/apache/xmlbeans/xml/stream/Location.class in xbean.jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Brown updated XMLBEANS-502: --- Description: Hello, After creating this issue https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to create the issue here. This appears to be similar to https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as FIXED and as I'm using a more recent version (and as it's not completely identical), I'm creating a new issue. It would appear that XMLBeans is creating (and not clearing) ThreadLocal variables. This causes Tomcat to complain about classloader leaks (see messages below). Based on information in XMLBEANS-103, I have tried to coax the JVM to clear the ThreadLocal (by performing garbage collection on the JVM), but that doesn't clear the ThreadLocals, even if allowing time to elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. To workaround this, we're having to impose long downtime when a restart is required. Perhaps a utility class within XMLBeans could be made available with the POI distribution such as: XMLBeansCache.clearThreadLocals() ...that I could call from a "finally" block after processing the XSSF document? Here's the information from Tomcat's logs: SEVERE: The web application [/foobar] created a ThreadLocal with key of type [org.apache.xmlbeans.XmlBeans$1] (value [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/foobar] created a ThreadLocal with key of type [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a value of type [java.util.ArrayList] (value [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/foobar] created a ThreadLocal with key of type [org.apache.xmlbeans.impl.store.Locale$1] (value [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/foobar] created a ThreadLocal with key of type [org.apache.xmlbeans.impl.store.CharUtil$1] (value [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. was: Hello, After creating this issue https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to create the issue here. This appears to be similar to https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as FIXED and as I'm using a more recent version (and as it's not completely identical), I'm creating a new issue. It would appear that XMLBeans is creating (and not clearing) ThreadLocal variables. This causes Tomcat to complain about classloader leaks (see messages below). Based on information in XMLBEANS-103, I have tried to coax the JVM to clear the ThreadLocal (by performing garbage collection on the JVM), but that doesn't clear the ThreadLocals, even if allowing time to elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. To workaround this, we're having to impose long downtime when a restart is required. Perhaps a utility class within XMLBeans could be made available with the POI distribution such as: XMLBeansCache.clearThreadLocals() ...that I could call from a "finally" block after processing the XSSF document? > Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF > ----- > > Key: XMLBEANS-502 > URL: https://issues.apache.org/jira/browse/XMLBEANS-502 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3 > Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE > 6/7, any operating system >Reporter: Christopher Brown > > Hell
[jira] [Created] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
Christopher Brown created XMLBEANS-502: -- Summary: Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF Key: XMLBEANS-502 URL: https://issues.apache.org/jira/browse/XMLBEANS-502 Project: XMLBeans Issue Type: Bug Affects Versions: Version 2.3 Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE 6/7, any operating system Reporter: Christopher Brown Hello, After creating this issue https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to create the issue here. This appears to be similar to https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as FIXED and as I'm using a more recent version (and as it's not completely identical), I'm creating a new issue. It would appear that XMLBeans is creating (and not clearing) ThreadLocal variables. This causes Tomcat to complain about classloader leaks (see messages below). Based on information in XMLBEANS-103, I have tried to coax the JVM to clear the ThreadLocal (by performing garbage collection on the JVM), but that doesn't clear the ThreadLocals, even if allowing time to elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat. To workaround this, we're having to impose long downtime when a restart is required. Perhaps a utility class within XMLBeans could be made available with the POI distribution such as: XMLBeansCache.clearThreadLocals() ...that I could call from a "finally" block after processing the XSSF document? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-501) Can't use encoded HTML entities
[ https://issues.apache.org/jira/browse/XMLBEANS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane StClair updated XMLBEANS-501: --- Description: Due to hardcoding in TextSaver, currently it's impossible to set HTML encoded values (e.g. €, ™, etc) using xmlbeans. This is because ampersands are detected and replaced with & in various methods in TextSaver (entitizeContent, entitizeAttrValue, emitAttrValue, and entitizeAndWriteText). I believe the intent is to replace naked ampersands with the encoded entity (&), however currently entities that are already encoded are not detected, so you end up with things like €, , etc. Seems like there are a few options: 1. Confine all character replacement to XmlOptionCharEscapeMap and provide a method to initialize without defaults or remove defaults (i.e. remove & -> & replacement) 2. Provide an XmlOptions setting to disable ampersand replacement and let the user be responsible for preventing invalid content 3. In TextSaver, examine characters following the ampersand to see if the ampersand begins an encoded entity. Affects Version/s: Version 2.6 Summary: Can't use encoded HTML entities (was: Can) > Can't use encoded HTML entities > --- > > Key: XMLBEANS-501 > URL: https://issues.apache.org/jira/browse/XMLBEANS-501 > Project: XMLBeans > Issue Type: Improvement >Affects Versions: Version 2.6 >Reporter: Shane StClair >Priority: Minor > > Due to hardcoding in TextSaver, currently it's impossible to set HTML encoded > values (e.g. €, ™, etc) using xmlbeans. This is because ampersands > are detected and replaced with & in various methods in TextSaver > (entitizeContent, entitizeAttrValue, emitAttrValue, and entitizeAndWriteText). > I believe the intent is to replace naked ampersands with the encoded entity > (&), however currently entities that are already encoded are not > detected, so you end up with things like €, , etc. > Seems like there are a few options: > 1. Confine all character replacement to XmlOptionCharEscapeMap and provide a > method to initialize without defaults or remove defaults (i.e. remove & -> > & replacement) > 2. Provide an XmlOptions setting to disable ampersand replacement and let the > user be responsible for preventing invalid content > 3. In TextSaver, examine characters following the ampersand to see if the > ampersand begins an encoded entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-501) Can
Shane StClair created XMLBEANS-501: -- Summary: Can Key: XMLBEANS-501 URL: https://issues.apache.org/jira/browse/XMLBEANS-501 Project: XMLBeans Issue Type: Improvement Reporter: Shane StClair Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676331#comment-13676331 ] Cezar Andrei commented on XMLBEANS-493: --- I also opened a new issue on Infrastructure to enable XMLBeans on Nexus Apache Maven: https://issues.apache.org/jira/browse/INFRA-6355 > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp >Assignee: Cezar Andrei > Fix For: Version 2.6 > > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-500) In org.apache.xmlbeans.impl.store.Saver.java constructor prefix and uri added to map in reverse
Scott McFarlane created XMLBEANS-500: Summary: In org.apache.xmlbeans.impl.store.Saver.java constructor prefix and uri added to map in reverse Key: XMLBEANS-500 URL: https://issues.apache.org/jira/browse/XMLBEANS-500 Project: XMLBeans Issue Type: Bug Affects Versions: Version 2.6 Environment: Happens when XmlOptions.SAVE_IMPLICIT_NAMESPACES is set. Reporter: Scott McFarlane Priority: Minor On lines 98 and 99 of Saver.java the prefix and uri fields are reversed when calling the addMapping method. This causes namespaces to not be set as requested because _uriMap and _prefixMap lookups don't work correctly. Original code is: String prefix = (String) i.next(); addMapping( prefix, (String) m.get( prefix ) ); Suggested code is: String uri = (String) i.next(); addMapping( (String) m.get( uri ), uri); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Resolved] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cezar Andrei resolved XMLBEANS-493. --- Resolution: Fixed Fix Version/s: Version 2.6 Fixed per Shane's directions. > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp >Assignee: Cezar Andrei > Fix For: Version 2.6 > > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Assigned] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cezar Andrei reassigned XMLBEANS-493: - Assignee: Cezar Andrei > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp >Assignee: Cezar Andrei > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675784#comment-13675784 ] Matthes Rieke commented on XMLBEANS-493: it might work without another release. There is a related bug at MVNCENTRAL, stating that the auto-sync might solve the issue: https://issues.sonatype.org/browse/MVNCENTRAL-281 Please, anyone give this a shot. It should not be too much effort. Thanks. > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675777#comment-13675777 ] Shane StClair commented on XMLBEANS-493: According to this: http://maven.apache.org/guides/mini/guide-maven-evangelism.html It might not be possible to just add the pom. In that case, maybe we could get a 2.6.1 release to fix this issue? > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675694#comment-13675694 ] Shane StClair commented on XMLBEANS-493: Any plans to fix this? 2.6.0 is somewhat unusable until this is fixed since xmlbeans dependencies aren't resolved. > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664144#comment-13664144 ] Marcus Collins commented on XMLBEANS-493: - I get the artifact which works find, but no source/javadoc attachment as Gradle needs the POM. > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Comment Edited] (XMLBEANS-446) too restrictive prefix constraint
[ https://issues.apache.org/jira/browse/XMLBEANS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657134#comment-13657134 ] Tammo van Lessen edited comment on XMLBEANS-446 at 5/14/13 3:37 PM: I agree, this can be a blocker for certain use cases. Is there any chance to get this fixed soonish? was (Author: vanto): I agree, this can be blocker for certain usecases. Is there any chance to get this fixed soonish? > too restrictive prefix constraint > - > > Key: XMLBEANS-446 > URL: https://issues.apache.org/jira/browse/XMLBEANS-446 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3, Version 2.4 , Version 2.5 >Reporter: Vojtech Janota >Priority: Minor > > XML Specification clearly states that when declaring namespace bindings > prefixes starting with "xml" are reserved and must not be used. However it > also states that processors must NOT treat them as fatal errors. Current > implementation fails to parse XML files with such prefixes: > org.apache.xmlbeans.XmlRuntimeException: error: Prefix can't begin with XML: > xml2uddi_portType > at > org.apache.xmlbeans.impl.store.Locale$SaxHandler.startPrefixMapping(Locale.java:3321) > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-446) too restrictive prefix constraint
[ https://issues.apache.org/jira/browse/XMLBEANS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657134#comment-13657134 ] Tammo van Lessen commented on XMLBEANS-446: --- I agree, this can be blocker for certain usecases. Is there any chance to get this fixed soonish? > too restrictive prefix constraint > - > > Key: XMLBEANS-446 > URL: https://issues.apache.org/jira/browse/XMLBEANS-446 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.3, Version 2.4 , Version 2.5 >Reporter: Vojtech Janota >Priority: Minor > > XML Specification clearly states that when declaring namespace bindings > prefixes starting with "xml" are reserved and must not be used. However it > also states that processors must NOT treat them as fatal errors. Current > implementation fails to parse XML files with such prefixes: > org.apache.xmlbeans.XmlRuntimeException: error: Prefix can't begin with XML: > xml2uddi_portType > at > org.apache.xmlbeans.impl.store.Locale$SaxHandler.startPrefixMapping(Locale.java:3321) > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Comment Edited] (XMLBEANS-328) Problems in multi-processor environment
[ https://issues.apache.org/jira/browse/XMLBEANS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642747#comment-13642747 ] Daniel Ewing edited comment on XMLBEANS-328 at 4/26/13 11:09 AM: - Can anyone please provide an update on this threading defect? Is it fixed in any release build of xbean.jar? If not, what would it take to get this on the schedule for being fixed? It sure seems likely that it is a fairly simple issue of unsynchronized access to a map causing the exception. was (Author: dew...@opentext.com): Can anyone please provide an update on this threading defect? Is it fixed in any release build of xbean.jar? If not, what would it take to get this on the schedule for being fixed? It sure likely that it is a fairly simple issue of unsynchronized access to a map causing the exception. > Problems in multi-processor environment > --- > > Key: XMLBEANS-328 > URL: https://issues.apache.org/jira/browse/XMLBEANS-328 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.2, Version 2.2.1 > Environment: At least Win XP and Linux 2.6 with Sun JRE. Intel > multi-core processor. >Reporter: Pasi Lehtimaki >Assignee: Radu Preotiuc-Pietro >Priority: Critical > Attachments: patch-xmlbeans-2.2.0, patch-XMLBEANS328-2.4.0.patch, > xbean.jar > > > Running a strongly threadded Eclipse application using xmlbeans in > multi-processor (/multi-core) computer causes frequent crashes in xmlbeans > code. > Most of the crases happen in Cur.java in form of a NPE: > *** > java.lang.NullPointerException > at org.apache.xmlbeans.impl.store.Cur.listRemove(Cur.java:2783) > at org.apache.xmlbeans.impl.store.Locale.getCur(Locale.java:2775) > at org.apache.xmlbeans.impl.store.Locale.tempCur(Locale.java:2736) > at org.apache.xmlbeans.impl.store.Locale.tempCur(Locale.java:2731) > at org.apache.xmlbeans.impl.store.Xobj.tempCur(Xobj.java:348) > at org.apache.xmlbeans.impl.store.Xobj.new_cursor(Xobj.java:1810) > at > org.apache.xmlbeans.impl.values.XmlObjectBase.newCursor(XmlObjectBase.java:250) > at > org.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:424) > at > org.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:415) > *** > In some cases the crash happens in Locale.exit(): > *** > Exception occurred: java.lang.ArrayIndexOutOfBoundsException: -1 > at > org.apache.xmlbeans.impl.store.Locale.exit(Locale.java:2840) > *** > This problem problem occurs in xmlbeans 2.2. and in the latest version in > SVN. The problem disappears when I turn the multi-core support off from BIOS > and reappears again immediently when I turn it back on. So I believe that > this has something to do with threading. Only classes Locale.java and > Cur.java seem to be affected. I haven't encountered any exceptions from other > classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-328) Problems in multi-processor environment
[ https://issues.apache.org/jira/browse/XMLBEANS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642747#comment-13642747 ] Daniel Ewing commented on XMLBEANS-328: --- Can anyone please provide an update on this threading defect? Is it fixed in any release build of xbean.jar? If not, what would it take to get this on the schedule for being fixed? It sure likely that it is a fairly simple issue of unsynchronized access to a map causing the exception. > Problems in multi-processor environment > --- > > Key: XMLBEANS-328 > URL: https://issues.apache.org/jira/browse/XMLBEANS-328 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.2, Version 2.2.1 > Environment: At least Win XP and Linux 2.6 with Sun JRE. Intel > multi-core processor. >Reporter: Pasi Lehtimaki >Assignee: Radu Preotiuc-Pietro >Priority: Critical > Attachments: patch-xmlbeans-2.2.0, patch-XMLBEANS328-2.4.0.patch, > xbean.jar > > > Running a strongly threadded Eclipse application using xmlbeans in > multi-processor (/multi-core) computer causes frequent crashes in xmlbeans > code. > Most of the crases happen in Cur.java in form of a NPE: > *** > java.lang.NullPointerException > at org.apache.xmlbeans.impl.store.Cur.listRemove(Cur.java:2783) > at org.apache.xmlbeans.impl.store.Locale.getCur(Locale.java:2775) > at org.apache.xmlbeans.impl.store.Locale.tempCur(Locale.java:2736) > at org.apache.xmlbeans.impl.store.Locale.tempCur(Locale.java:2731) > at org.apache.xmlbeans.impl.store.Xobj.tempCur(Xobj.java:348) > at org.apache.xmlbeans.impl.store.Xobj.new_cursor(Xobj.java:1810) > at > org.apache.xmlbeans.impl.values.XmlObjectBase.newCursor(XmlObjectBase.java:250) > at > org.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:424) > at > org.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:415) > *** > In some cases the crash happens in Locale.exit(): > *** > Exception occurred: java.lang.ArrayIndexOutOfBoundsException: -1 > at > org.apache.xmlbeans.impl.store.Locale.exit(Locale.java:2840) > *** > This problem problem occurs in xmlbeans 2.2. and in the latest version in > SVN. The problem disappears when I turn the multi-core support off from BIOS > and reappears again immediently when I turn it back on. So I believe that > this has something to do with threading. Only classes Locale.java and > Cur.java seem to be affected. I haven't encountered any exceptions from other > classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
[ https://issues.apache.org/jira/browse/XMLBEANS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631588#comment-13631588 ] Shouvik Basu commented on XMLBEANS-499: --- problem appears in the below package org.apache.xmlbeans.xml.stream there are numerous files repeated > xmlbeans2.6.0.jar contians duplicate class files > > > Key: XMLBEANS-499 > URL: https://issues.apache.org/jira/browse/XMLBEANS-499 > Project: XMLBeans > Issue Type: Bug >Reporter: Peter Klerehag > > The xlmbeans-2.6.0.jar contains some duplicate class files which in some > cases can generate problems with classloading. > It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other > locations as well > Did following and there you clearly see 2x of ReferenceResolver > unzip -l xmlbeans-2.6.0.jar | grep Resolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 394 2012-07-23 15:42 > org/apache/xmlbeans/xml/stream/ReferenceResolver.class > 214 2012-07-23 15:42 > org/apache/xmlbeans/impl/common/PrefixResolver.class > 45339 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class > 11284 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscResolver.class > 26162 2012-07-23 15:42 > org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class > 3524 2012-07-23 15:42 > org/apache/xmlbeans/impl/tool/SchemaImportResolver.class > 1069 2012-07-23 15:42 > org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-497) Unable to sign xbean.jar
[ https://issues.apache.org/jira/browse/XMLBEANS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631587#comment-13631587 ] Shouvik Basu commented on XMLBEANS-497: --- problem appears in the below package org.apache.xmlbeans.xml.stream there are numerous files repeated > Unable to sign xbean.jar > > > Key: XMLBEANS-497 > URL: https://issues.apache.org/jira/browse/XMLBEANS-497 > Project: XMLBeans > Issue Type: Bug > Components: XmlObject >Affects Versions: Version 2.6 > Environment: jarsigner >Reporter: J S >Priority: Critical > > jarsigner complains about a duplicate entry of > org/apache/xmlbeans/xml/stream/Location.class in xbean.jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616509#comment-13616509 ] Jeremy Stowell commented on XMLBEANS-493: - Any more info on this? I don't see it in the repo as of yet. > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-499) xmlbeans2.6.0.jar contians duplicate class files
Peter Klerehag created XMLBEANS-499: --- Summary: xmlbeans2.6.0.jar contians duplicate class files Key: XMLBEANS-499 URL: https://issues.apache.org/jira/browse/XMLBEANS-499 Project: XMLBeans Issue Type: Bug Reporter: Peter Klerehag The xlmbeans-2.6.0.jar contains some duplicate class files which in some cases can generate problems with classloading. It is mainly under "/org/apache/xmlbeans/xml/stream/" but there is some other locations as well Did following and there you clearly see 2x of ReferenceResolver unzip -l xmlbeans-2.6.0.jar | grep Resolver.class 394 2012-07-23 15:42 org/apache/xmlbeans/xml/stream/ReferenceResolver.class 394 2012-07-23 15:42 org/apache/xmlbeans/xml/stream/ReferenceResolver.class 214 2012-07-23 15:42 org/apache/xmlbeans/impl/common/PrefixResolver.class 45339 2012-07-23 15:42 org/apache/xmlbeans/impl/schema/StscComplexTypeResolver.class 11284 2012-07-23 15:42 org/apache/xmlbeans/impl/schema/StscResolver.class 26162 2012-07-23 15:42 org/apache/xmlbeans/impl/schema/StscSimpleTypeResolver.class 3524 2012-07-23 15:42 org/apache/xmlbeans/impl/tool/SchemaImportResolver.class 1069 2012-07-23 15:42 org/apache/xmlbeans/impl/store/Locale$DefaultEntityResolver.class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-378) Add system property to allow override of default piccolo parser
[ https://issues.apache.org/jira/browse/XMLBEANS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rodrigo Setti updated XMLBEANS-378: --- Attachment: xmlbeans-system-default-xml-reader.diff Hi, I have some cases in my application that piccolo parser enter's a infinite loop and eventually I get into a heap exception. Therefore I replaced it with the platform's default parser, and it worked great. The time performance difference is unnoticeable. I'm providing a patch that allow xmlbeans to select the platform's default Sax Parser, instead of relying in a another configuration option. > Add system property to allow override of default piccolo parser > --- > > Key: XMLBEANS-378 > URL: https://issues.apache.org/jira/browse/XMLBEANS-378 > Project: XMLBeans > Issue Type: Wish > Components: XmlObject >Affects Versions: Version 2.3 >Reporter: Kevin Jones >Priority: Minor > Attachments: patch_alt_parser, xmlbeans-system-default-xml-reader.diff > > > It would be useful to allow the default piccolo parser to be replaced by > other SAX2 conformant parsers that may other more features/performance > without having to make application code changes. > This can be done by some minor changes to the Store Locale.java mechanism > that caches piccolo parsers per thread. In a trial implementation (see > attached patch) an xmlbeans specific system property is added which has the > same meaning as the 'org.xml.sax.driver' property, i.e. it specifies the name > of a org.xml.sax.XMLReader class. If the property is set this parser is > instantiated instead of a piccolo parser. > The patch passes checkintest when the property > "org.apache.xmlbeans.xmlreader" is set to > "com.sun.org.apache.xerces.internal.parsers.SAXParser" on a jdk1.5.0_15 on > WIN32. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-498) XmlValueOutOfRangeException on accessing xmlbean objects by multiple threads
Gerhard created XMLBEANS-498: Summary: XmlValueOutOfRangeException on accessing xmlbean objects by multiple threads Key: XMLBEANS-498 URL: https://issues.apache.org/jira/browse/XMLBEANS-498 Project: XMLBeans Issue Type: Bug Components: XmlObject Affects Versions: Version 2.3, Version 2.6 Environment: Linux Server Reporter: Gerhard We have two threads sharing the same xmlbeans object. Although they perform only read actions on it, we sometimes get exceptions like XmlValueOutOfRangeException, ArrayIndexOutOfBoundsException and NullPointerException. See below for example of an error stack. We found out, that all of the generated xmlbean object methods are thread safe, using "synchonize(monitor()") - that's fine. But some basic methods do not synchronize on monitor(). e.g. we have a generated class EventDateImpl, which is derived from JavaGDateHolderEx. The method getCalendarValue() is implemented in XmlObjectBase, which forwards the call to JavaGDateHolderEx #calendarValue(), which accesses the check_date() method NOT secured by synchonize(monitor()). This leads to a race condition: -> XmlObjectBase#check_dated() -> XmlObjectBase#get_wscanon_text() -> Xobj#fetch_text (is the type store) -> Xobj#getValueAsString() -> getFirstChars() -> Xobj#getChars() -> Xobj#getCharsHelper() -> (over)writes the _locale._offSrc and _locale._cchSrc of the common shared Locale which are used by both threads reading on the xmlbeans object after a few lines in getValueAsString(): scrub.scrub( src, _locale._offSrc, _locale._cchSrc ); This leads to reading the wrong text and invalid data. Caused by: org.apache.xmlbeans.impl.values.XmlValueOutOfRangeException: Invalid date value: 26 at org.apache.xmlbeans.impl.values.XmlObjectBase$ValueOutOfRangeValidationContext.invalid(XmlObjectBase.java:285) ~[xmlbeans-2.3.0.jar:na] at org.apache.xmlbeans.impl.values.JavaGDateHolderEx.lex(JavaGDateHolderEx.java:74) ~[xmlbeans-2.3.0.jar:na] at org.apache.xmlbeans.impl.values.JavaGDateHolderEx.set_text(JavaGDateHolderEx.java:56) ~[xmlbeans-2.3.0.jar:na] at org.apache.xmlbeans.impl.values.XmlObjectBase.update_from_wscanon_text(XmlObjectBase.java:1135) ~[xmlbeans-2.3.0.jar:na] at org.apache.xmlbeans.impl.values.XmlObjectBase.check_dated(XmlObjectBase.java:1274) ~[xmlbeans-2.3.0.jar:na] at org.apache.xmlbeans.impl.values.JavaGDateHolderEx.calendarValue(JavaGDateHolderEx.java:192) ~[xmlbeans-2.3.0.jar:na] at org.apache.xmlbeans.impl.values.XmlObjectBase.getCalendarValue(XmlObjectBase.java:1516) ~[xmlbeans-2.3.0.jar:na] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-446) too restrictive prefix constraint
[
https://issues.apache.org/jira/browse/XMLBEANS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580590#comment-13580590
]
Martin Spamer commented on XMLBEANS-446:
This issue should NOT be classified as minor.
It causes a fatal errors with ALL correctly specified W3C name space extensions.
It is a clear miss-interpretation of the specification and relatively easy fix,
removing these lines
3324if (beginsWithXml(prefix) &&
3325!("xml".equals(prefix) && _xml1998Uri.equals(uri)))
3326{
3327XmlError err =
3328XmlError.forMessage(
3329"Prefix can't begin with XML: " + prefix,
3330XmlError.SEVERITY_ERROR);
3331
3332throw new XmlRuntimeException(err.toString(), null, err);
from org.apache.xmlbeans.impl.store.Locale
> too restrictive prefix constraint
> -
>
> Key: XMLBEANS-446
> URL: https://issues.apache.org/jira/browse/XMLBEANS-446
> Project: XMLBeans
> Issue Type: Bug
>Affects Versions: Version 2.3, Version 2.4 , Version 2.5
>Reporter: Vojtech Janota
>Priority: Minor
>
> XML Specification clearly states that when declaring namespace bindings
> prefixes starting with "xml" are reserved and must not be used. However it
> also states that processors must NOT treat them as fatal errors. Current
> implementation fails to parse XML files with such prefixes:
> org.apache.xmlbeans.XmlRuntimeException: error: Prefix can't begin with XML:
> xml2uddi_portType
> at
> org.apache.xmlbeans.impl.store.Locale$SaxHandler.startPrefixMapping(Locale.java:3321)
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-497) Unable to sign xbean.jar
J S created XMLBEANS-497: Summary: Unable to sign xbean.jar Key: XMLBEANS-497 URL: https://issues.apache.org/jira/browse/XMLBEANS-497 Project: XMLBeans Issue Type: Bug Components: XmlObject Affects Versions: Version 2.6 Environment: jarsigner Reporter: J S Priority: Critical jarsigner complains about a duplicate entry of org/apache/xmlbeans/xml/stream/Location.class in xbean.jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-429) Schema Compilation fails on case insensitive file systems when targetnamespaces of two schemas only differ by case
[ https://issues.apache.org/jira/browse/XMLBEANS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559488#comment-13559488 ] Bart Blommaerts commented on XMLBEANS-429: -- Although this issue is old, the behavior is still happening in 2.6.0. > Schema Compilation fails on case insensitive file systems when > targetnamespaces of two schemas only differ by case > --- > > Key: XMLBEANS-429 > URL: https://issues.apache.org/jira/browse/XMLBEANS-429 > Project: XMLBeans > Issue Type: Bug > Components: Binding, Compiler >Affects Versions: TBD > Environment: Windows XP >Reporter: Scott L'Hommedieu > > Case insensitive files systems (Windows XP for example) leads to failures > when compiling schemas whose targetnamespace is only distinct by case. > Files and folders cannot be created during compilation and schema compilation > fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-496) org.apache.xmlbeans.impl.values.XmlAnyTypeImpl cannot be cast to AttachmentType
Adinarayana created XMLBEANS-496:
Summary: org.apache.xmlbeans.impl.values.XmlAnyTypeImpl cannot be
cast to AttachmentType
Key: XMLBEANS-496
URL: https://issues.apache.org/jira/browse/XMLBEANS-496
Project: XMLBeans
Issue Type: Bug
Components: XmlObject
Affects Versions: Version 2.5
Environment: Jboss7 application serverver and windows XP environment
Reporter: Adinarayana
I am getting above exception
here is my sample xsd e:
it's failing in the following java code
AttachmentType attachmentType = null;
if (upldMetadataReqType.isSetUploadMetadata()) {
//it's working for getUploadMetaData()
attachmentType = upldMetadataReqType.getUploadMetadata();
}else {
// getting the error when i am trying to access getExportmetadata()
attachmentType = upldMetadataReqType.getExportMetadata();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-493) No pom at central for 2.6.0
[ https://issues.apache.org/jira/browse/XMLBEANS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajay updated XMLBEANS-493: -- Attachment: xmlbeans-2.6.0.pom Attaching the required pom > No pom at central for 2.6.0 > --- > > Key: XMLBEANS-493 > URL: https://issues.apache.org/jira/browse/XMLBEANS-493 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.6 >Reporter: Daniel Kulp > Attachments: xmlbeans-2.6.0.pom > > > There is no pom for xmlbeans-2.6.0 at: > http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ > someone should take the 2.5.0 pom, update the version number to 2.6.0, and > add that to > /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 > (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-495) StackOverflowError when parsing a large number of characters in an XML element
[ https://issues.apache.org/jira/browse/XMLBEANS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mandy Warren updated XMLBEANS-495: -- Description: When XMLBeans validates a very long XML String (4000 or so chars), it generates a StackOverFlowError as shown below. In the schema for this element I have defined a pattern and a min/max length but XMLBeans is applying the pattern first before checking the length. The solution is the fix applied to the class RegularExpression in xerces - see https://issues.apache.org/jira/browse/XERCESJ-589 which went into version 2.11. Exception in thread "main" java.lang.StackOverflowError at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1662) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) was: When XMLBeans validates a very long XML String (1000 or more chars), it generates a StackOverFlowException as shown below. In the schema for this element I have defined a pattern and a min/max length but XMLBeans is applying the pattern first before checking the length. The solution is the fix applied to the class RegularExpression in xerces - see https://issues.apache.org/jira/browse/XERCESJ-589 which went into version 2.11. Exception in thread "main" java.lang.StackOverflowError at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1662) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) > StackOverflowError when parsing a large number of characters in an XML element > -- > > Key: XMLBEANS-495 > URL: https://issues.apache.org/jira/browse/XMLBEANS-495 > Project: XMLBeans > Issue Type: Bug > Components: Validator >Affects Versions: Version 2.6 > Environment: All >Reporter: Mandy Warren > > When XMLBeans validates a very long XML String (4000 or so chars), it > generates a StackOverFlowError as shown below. In the schema for this element > I have defined a pattern and a min/max length but XMLBeans is applying the > pattern first before checking the length. The solution is the fix applied to > the class RegularExpression in xerces - see > https://issues.apache.org/jira/browse/XERCESJ-589 which went into version > 2.11. > > > > > > > > Exception in thread "main" java.lang.StackOverflowError > at > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1662) > at > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) > at > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) > at > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) > at > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) > at > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Comment Edited] (XMLBEANS-235) scomp fails with error "encoded string too long"
[ https://issues.apache.org/jira/browse/XMLBEANS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526476#comment-13526476 ] Jon Schroeder edited comment on XMLBEANS-235 at 12/7/12 4:02 PM: - I have the same problem with 2.6.0 version. I am attempting to compile a Monster Schema. I have attached the xsd's that are required. The xsd to compile to reproduce the error is JobSeeker.xsd I reproduced this error on Windows7 using jdk1.6.0_37 and Ubuntu using jdk1.6.0_27 Here is the Ubuntu output scomp -out JobSeeker.jar JobSeeker.xsd Time to build schema type system: 1.833 seconds Exception in thread "main" org.apache.xmlbeans.SchemaTypeLoaderException: encoded string too long: 91578 bytes (schemaorg_apache_xmlbeans.system.s79A4106C33DD5C3CB79E9FF9B64FCECF.monsteroccupationidtier3enum7fcftype) - code 9 at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$StringPool.writeTo(SchemaTypeSystemImpl.java:1036) at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.writeRealHeader(SchemaTypeSystemImpl.java:1617) at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.saveType(SchemaTypeSystemImpl.java:1455) at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.saveTypesRecursively(SchemaTypeSystemImpl.java:1331) at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.save(SchemaTypeSystemImpl.java:1306) at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile(SchemaCompiler.java:1126) at org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:373) was (Author: jonschro): I have the same problem with 2.6.0 version. I am attempting to compile a Monster Schema. I have attached the xsd's that are required. The xsd to compile to reproduce the error is JobSeeker.xsd > scomp fails with error "encoded string too long" > > > 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 >Priority: Blocker > Attachments: Common.xsd, Document.xsd, Enumerations.xsd, > JobSearchAgent.xsd, JobSeeker.xsd > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Comment Edited] (XMLBEANS-235) scomp fails with error "encoded string too long"
[ https://issues.apache.org/jira/browse/XMLBEANS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526476#comment-13526476 ] Jon Schroeder edited comment on XMLBEANS-235 at 12/7/12 4:00 PM: - I have the same problem with 2.6.0 version. I am attempting to compile a Monster Schema. I have attached the xsd's that are required. The xsd to compile to reproduce the error is JobSeeker.xsd was (Author: jonschro): I have the same problem with 2.6.0 version. I am attempting to compile a Monster Schema. I have attached the xsd's that are required. The xsd to compile is JobSeeker.xsd > scomp fails with error "encoded string too long" > > > 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 >Priority: Blocker > Attachments: Common.xsd, Document.xsd, Enumerations.xsd, > JobSearchAgent.xsd, JobSeeker.xsd > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Issue Comment Deleted] (XMLBEANS-235) scomp fails with error "encoded string too long"
[ https://issues.apache.org/jira/browse/XMLBEANS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Schroeder updated XMLBEANS-235: --- Comment: was deleted (was: JobSeeker.xsd is the one that needs to be compiled) > scomp fails with error "encoded string too long" > > > 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 >Priority: Blocker > Attachments: Common.xsd, Document.xsd, Enumerations.xsd, > JobSearchAgent.xsd, JobSeeker.xsd > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-235) scomp fails with error "encoded string too long"
[ https://issues.apache.org/jira/browse/XMLBEANS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526476#comment-13526476 ] Jon Schroeder commented on XMLBEANS-235: I have the same problem with 2.6.0 version. I am attempting to compile a Monster Schema. I have attached the xsd's that are required. The xsd to compile is JobSeeker.xsd > scomp fails with error "encoded string too long" > > > 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 >Priority: Blocker > Attachments: Common.xsd, Document.xsd, Enumerations.xsd, > JobSearchAgent.xsd, JobSeeker.xsd > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-235) scomp fails with error "encoded string too long"
[ https://issues.apache.org/jira/browse/XMLBEANS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Schroeder updated XMLBEANS-235: --- Attachment: JobSeeker.xsd JobSearchAgent.xsd Enumerations.xsd Document.xsd Common.xsd JobSeeker.xsd is the one that needs to be compiled > scomp fails with error "encoded string too long" > > > 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 >Priority: Blocker > Attachments: Common.xsd, Document.xsd, Enumerations.xsd, > JobSearchAgent.xsd, JobSeeker.xsd > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-494) ArrayIndexOutOfBoundsException on query
[ https://issues.apache.org/jira/browse/XMLBEANS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526320#comment-13526320 ] Paulo Henrique Leal commented on XMLBEANS-494: -- Sorry, I dont know how I got to the xmlbeans forum. You are correct, this is meant to the openJPA. So sorry about this. > ArrayIndexOutOfBoundsException on query > --- > > Key: XMLBEANS-494 > URL: https://issues.apache.org/jira/browse/XMLBEANS-494 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.2 > Environment: Websphere 8.0.0.3 >Reporter: Paulo Henrique Leal > > Running a query I get a message: openjpa.Runtime: Warn: Supplied user > parameters "[1, 2, 3, 4, 5]" do not match expected parameters "[1, 1, 2, 3, > 4, 5]" for the prepared query > the query is like > SELECT > test > FROM > com.phleal.persistence.model.Test test > WHERE > EXISTS ( > SELECT attr > FROM com.phleal.persistence.model.TestAttribute attr > WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = > ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) > ) > AND ?5 MEMBER OF reg.testTypes > AND reg.testCompleted = false > After this Warning I get an ArrayIndexOutOfBoundsException: > Failed to execute query SELECT > test > FROM > com.phleal.persistence.model.Test test > WHERE > EXISTS ( > SELECT attr > FROM com.phleal.persistence.model.TestAttribute attr > WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = > ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) > ) > AND ?5 MEMBER OF reg.testTypes > AND reg.testCompleted = false". Check the query syntax for correctness. > See nested exception for details.. > nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Failed > to execute query "SELECT > test > FROM > com.phleal.persistence.model.Test test > WHERE > EXISTS ( > SELECT attr > FROM com.phleal.persistence.model.TestAttribute attr > WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = > ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) > ) > AND ?5 MEMBER OF reg.testTypes > AND reg.testCompleted = false". Check the query syntax for correctness. > See nested exception for details. > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:872) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:794) > at > org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:542) > at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:286) > at > org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:302) > at > com.phleal.persistence.TestManager.getRelatedTest(TestManager.java:1794) > . > . > . > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at > com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1783) > Caused by: java.lang.ArrayIndexOutOfBoundsException: Array index out of > range: 5 > at > org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQLExecutor.toParameterArray(PreparedSQLStoreQuery.java:161) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:857) > ... 89 more > I am sure I only pass 5 attributes to the query, I don't know what could > generate the "[1, 1, 2, 3, 4, 5]" from the message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-495) StackOverflowError when parsing a large number of characters in an XML element
Mandy Warren created XMLBEANS-495: - Summary: StackOverflowError when parsing a large number of characters in an XML element Key: XMLBEANS-495 URL: https://issues.apache.org/jira/browse/XMLBEANS-495 Project: XMLBeans Issue Type: Bug Components: Validator Affects Versions: Version 2.6 Environment: All Reporter: Mandy Warren When XMLBeans validates a very long XML String (1000 or more chars), it generates a StackOverFlowException as shown below. In the schema for this element I have defined a pattern and a min/max length but XMLBeans is applying the pattern first before checking the length. The solution is the fix applied to the class RegularExpression in xerces - see https://issues.apache.org/jira/browse/XERCESJ-589 which went into version 2.11. Exception in thread "main" java.lang.StackOverflowError at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1662) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) at org.apache.xmlbeans.impl.regex.RegularExpression.matchString(RegularExpression.java:1872) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Resolved] (XMLBEANS-494) ArrayIndexOutOfBoundsException on query
[ https://issues.apache.org/jira/browse/XMLBEANS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Danner resolved XMLBEANS-494. --- Resolution: Cannot Reproduce I'm not sure this is the right product for your bug. The stack lists nothing about xmlbeans, but rather JPA. If this is xmlbeans related could you post some repro code? > ArrayIndexOutOfBoundsException on query > --- > > Key: XMLBEANS-494 > URL: https://issues.apache.org/jira/browse/XMLBEANS-494 > Project: XMLBeans > Issue Type: Bug >Affects Versions: Version 2.2 > Environment: Websphere 8.0.0.3 >Reporter: Paulo Henrique Leal > > Running a query I get a message: openjpa.Runtime: Warn: Supplied user > parameters "[1, 2, 3, 4, 5]" do not match expected parameters "[1, 1, 2, 3, > 4, 5]" for the prepared query > the query is like > SELECT > test > FROM > com.phleal.persistence.model.Test test > WHERE > EXISTS ( > SELECT attr > FROM com.phleal.persistence.model.TestAttribute attr > WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = > ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) > ) > AND ?5 MEMBER OF reg.testTypes > AND reg.testCompleted = false > After this Warning I get an ArrayIndexOutOfBoundsException: > Failed to execute query SELECT > test > FROM > com.phleal.persistence.model.Test test > WHERE > EXISTS ( > SELECT attr > FROM com.phleal.persistence.model.TestAttribute attr > WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = > ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) > ) > AND ?5 MEMBER OF reg.testTypes > AND reg.testCompleted = false". Check the query syntax for correctness. > See nested exception for details.. > nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Failed > to execute query "SELECT > test > FROM > com.phleal.persistence.model.Test test > WHERE > EXISTS ( > SELECT attr > FROM com.phleal.persistence.model.TestAttribute attr > WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = > ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) > ) > AND ?5 MEMBER OF reg.testTypes > AND reg.testCompleted = false". Check the query syntax for correctness. > See nested exception for details. > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:872) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:794) > at > org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:542) > at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:286) > at > org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:302) > at > com.phleal.persistence.TestManager.getRelatedTest(TestManager.java:1794) > . > . > . > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) > at > com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1783) > Caused by: java.lang.ArrayIndexOutOfBoundsException: Array index out of > range: 5 > at > org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQLExecutor.toParameterArray(PreparedSQLStoreQuery.java:161) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:857) > ... 89 more > I am sure I only pass 5 attributes to the query, I don't know what could > generate the "[1, 1, 2, 3, 4, 5]" from the message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-494) ArrayIndexOutOfBoundsException on query
Paulo Henrique Leal created XMLBEANS-494: Summary: ArrayIndexOutOfBoundsException on query Key: XMLBEANS-494 URL: https://issues.apache.org/jira/browse/XMLBEANS-494 Project: XMLBeans Issue Type: Bug Affects Versions: Version 2.2 Environment: Websphere 8.0.0.3 Reporter: Paulo Henrique Leal Running a query I get a message: openjpa.Runtime: Warn: Supplied user parameters "[1, 2, 3, 4, 5]" do not match expected parameters "[1, 1, 2, 3, 4, 5]" for the prepared query the query is like SELECT test FROM com.phleal.persistence.model.Test test WHERE EXISTS ( SELECT attr FROM com.phleal.persistence.model.TestAttribute attr WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) ) AND ?5 MEMBER OF reg.testTypes AND reg.testCompleted = false After this Warning I get an ArrayIndexOutOfBoundsException: Failed to execute query SELECT test FROM com.phleal.persistence.model.Test test WHERE EXISTS ( SELECT attr FROM com.phleal.persistence.model.TestAttribute attr WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) ) AND ?5 MEMBER OF reg.testTypes AND reg.testCompleted = false". Check the query syntax for correctness. See nested exception for details.. org.apache.openjpa.persistence.ArgumentException: Failed to execute query "SELECT test FROM com.phleal.persistence.model.Test test WHERE EXISTS ( SELECT attr FROM com.phleal.persistence.model.TestAttribute attr WHERE attr.test = test AND attr.namespace.namespaceURI = ?1 AND attr.name = ?2 AND ( ( attr.valueTypeId = ?3 AND attr.stringValue = ?4 ) ) ) AND ?5 MEMBER OF reg.testTypes AND reg.testCompleted = false". Check the query syntax for correctness. See nested exception for details. at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:872) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:794) at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:542) at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:286) at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:302) at com.phleal.persistence.TestManager.getRelatedTest(TestManager.java:1794) . . . at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1783) Caused by: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 5 at org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQLExecutor.toParameterArray(PreparedSQLStoreQuery.java:161) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:857) ... 89 more I am sure I only pass 5 attributes to the query, I don't know what could generate the "[1, 1, 2, 3, 4, 5]" from the message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Created] (XMLBEANS-493) No pom at central for 2.6.0
Daniel Kulp created XMLBEANS-493: Summary: No pom at central for 2.6.0 Key: XMLBEANS-493 URL: https://issues.apache.org/jira/browse/XMLBEANS-493 Project: XMLBeans Issue Type: Bug Affects Versions: Version 2.6 Reporter: Daniel Kulp There is no pom for xmlbeans-2.6.0 at: http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.6.0/ someone should take the 2.5.0 pom, update the version number to 2.6.0, and add that to /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xmlbeans/xmlbeans/2.6.0 (and sign it). Otherwise, users get warnings when they run maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-351) Need for public interface to check if an XmlObject is orphaned
[ https://issues.apache.org/jira/browse/XMLBEANS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503123#comment-13503123 ] lujun commented on XMLBEANS-351: why did not respond to this question? > Need for public interface to check if an XmlObject is orphaned > -- > > Key: XMLBEANS-351 > URL: https://issues.apache.org/jira/browse/XMLBEANS-351 > Project: XMLBeans > Issue Type: Bug > Components: XmlObject >Affects Versions: unspecified > Environment: XmlBeans >Reporter: Michael Hedenus > Fix For: unspecified > > > Currently there is no public interface to check if an XmlObject is orphaned; > there is only a protected method in XmlObjectBase. Consider following > situation: > 1) The XmlBeans data model is display by a GUI (e.g. JTree). > 2) The data model is changed, e.g. an element is deleted. > 3) The GUI is repainting but the element that shall be displayed is orphaned > and an exception is thrown. This exception must be caught to keep the GUI in > a valid state or even alive. > The last point is the reason why I consider the problem as a bug. > Of course it is always possible to surround the accessing of XmlBeans with > try-catch but I think this is neither the intention nor a good solution. > I propose two possible solutions: > 1) instance method for XmlObject: isOrphaned() > 2) static utility function: XmlBeans.isOrphaned(XmlObject) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Commented] (XMLBEANS-351) Need for public interface to check if an XmlObject is orphaned
[ https://issues.apache.org/jira/browse/XMLBEANS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503121#comment-13503121 ] lujun commented on XMLBEANS-351: 为什么这个问题没有回应的 > Need for public interface to check if an XmlObject is orphaned > -- > > Key: XMLBEANS-351 > URL: https://issues.apache.org/jira/browse/XMLBEANS-351 > Project: XMLBeans > Issue Type: Bug > Components: XmlObject >Affects Versions: unspecified > Environment: XmlBeans >Reporter: Michael Hedenus > Fix For: unspecified > > > Currently there is no public interface to check if an XmlObject is orphaned; > there is only a protected method in XmlObjectBase. Consider following > situation: > 1) The XmlBeans data model is display by a GUI (e.g. JTree). > 2) The data model is changed, e.g. an element is deleted. > 3) The GUI is repainting but the element that shall be displayed is orphaned > and an exception is thrown. This exception must be caught to keep the GUI in > a valid state or even alive. > The last point is the reason why I consider the problem as a bug. > Of course it is always possible to surround the accessing of XmlBeans with > try-catch but I think this is neither the intention nor a good solution. > I propose two possible solutions: > 1) instance method for XmlObject: isOrphaned() > 2) static utility function: XmlBeans.isOrphaned(XmlObject) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-492) parse(XmlStreamReader) does sometimes not work properly
[ https://issues.apache.org/jira/browse/XMLBEANS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Goetzke updated XMLBEANS-492: -- Attachment: BeansBug.java > parse(XmlStreamReader) does sometimes not work properly > --- > > Key: XMLBEANS-492 > URL: https://issues.apache.org/jira/browse/XMLBEANS-492 > Project: XMLBeans > Issue Type: Bug > Components: Validator, XmlObject >Affects Versions: Version 2.4 , Version 2.6 > Environment: jdk.1.7.0_10 >Reporter: Thorsten Goetzke > Attachments: animal.xsd, BeansBug.java > > > Under some circumstances xmlbeans will 'forget' to create a namespace needed > for the 'xsi:type' > attribute. This happens after an XmlObject is created by > XmlObject.parse(XmlStreamReader). > This behaviour causes a NullpointerException in the Validation (amongst other > unfortunate things). > This can be triggered by a save-load circle. > I will attach a schema and a JUnitTest to reproduce this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-492) parse(XmlStreamReader) does sometimes not work properly
[ https://issues.apache.org/jira/browse/XMLBEANS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Goetzke updated XMLBEANS-492: -- Attachment: (was: BeansBug.java) > parse(XmlStreamReader) does sometimes not work properly > --- > > Key: XMLBEANS-492 > URL: https://issues.apache.org/jira/browse/XMLBEANS-492 > Project: XMLBeans > Issue Type: Bug > Components: Validator, XmlObject >Affects Versions: Version 2.4 , Version 2.6 > Environment: jdk.1.7.0_10 >Reporter: Thorsten Goetzke > Attachments: animal.xsd, BeansBug.java > > > Under some circumstances xmlbeans will 'forget' to create a namespace needed > for the 'xsi:type' > attribute. This happens after an XmlObject is created by > XmlObject.parse(XmlStreamReader). > This behaviour causes a NullpointerException in the Validation (amongst other > unfortunate things). > This can be triggered by a save-load circle. > I will attach a schema and a JUnitTest to reproduce this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
[jira] [Updated] (XMLBEANS-492) parse(XmlStreamReader) does sometimes not work properly
[ https://issues.apache.org/jira/browse/XMLBEANS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Goetzke updated XMLBEANS-492: -- Description: Under some circumstances xmlbeans will 'forget' to create a namespace needed for the 'xsi:type' attribute. This happens after an XmlObject is created by XmlObject.parse(XmlStreamReader). This behaviour causes a NullpointerException in the Validation (amongst other unfortunate things). This can be triggered by a save-load circle. I will attach a schema and a JUnitTest to reproduce this issue. was: Under some circumstances xmlbeans will 'forget' to create a namespace needed for the 'xsi:type' attribute. This happens after an XmlObject is created by XmlObject.parse(XmlStreamReader). This behaviour causes a NullpointerException in the Validation (amongst other unfortunate things). For some reason xmlbeans Jsr173-Stream works fine, while the XmlStreamReader obtained from the XmlInputFactory doesn't. I will attach a schema and a JUnitTest to reproduce this issue. Summary: parse(XmlStreamReader) does sometimes not work properly (was: StAX Incomptibility with Oracles XmlStreamReader) > parse(XmlStreamReader) does sometimes not work properly > --- > > Key: XMLBEANS-492 > URL: https://issues.apache.org/jira/browse/XMLBEANS-492 > Project: XMLBeans > Issue Type: Bug > Components: Validator, XmlObject >Affects Versions: Version 2.4 , Version 2.6 > Environment: jdk.1.7.0_10 >Reporter: Thorsten Goetzke > Attachments: animal.xsd, BeansBug.java > > > Under some circumstances xmlbeans will 'forget' to create a namespace needed > for the 'xsi:type' > attribute. This happens after an XmlObject is created by > XmlObject.parse(XmlStreamReader). > This behaviour causes a NullpointerException in the Validation (amongst other > unfortunate things). > This can be triggered by a save-load circle. > I will attach a schema and a JUnitTest to reproduce this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: dev-h...@xmlbeans.apache.org
