Algorithm for saving CDATA blocks in XML Beans 2.2 ?
I see that XML Beans 2.3 provides some control over when the saver generates CDATA. The XML Options setSaveCDataLengthThreshold and setSaveCDataEntityCountThreshold allow any of the following configurations: Every text is CDATA Only text that has an entity is CDATA Only text longer than x chars is CDATA Only text that has y entitazable chars is CDATA Only text longer than x chars and has y entitazable chars is CDATA My question is what is the behavior of the saver in XML Beans 2.2? When does it decide to use CDATA blocks? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Algorithm for saving CDATA blocks in XML Beans 2.2 ?
Cezar, If I am not mistaken, the older XML Beans version 2.2 does not does not support these options. Please clarify. Thanks, Steve -Original Message- From: Cezar Andrei [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 4:38 PM To: user@xmlbeans.apache.org Subject: RE: Algorithm for saving CDATA blocks in XML Beans 2.2 ? Steve, The javadoc for setSaveCDataLengthThreshold and setSaveCDataEntityCountThreshold seems to be quite clear: * CDATA will be used if the folowing condition is true: * textLength cdataLengthThreshold entityCount cdataEntityCountThreshold * The default value of cdataLengthThreshold is 32. * The default value of cdataEntityCountThreshold is 5. Cezar -Original Message- From: Steve Davis [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 2:11 PM To: user@xmlbeans.apache.org Subject: Algorithm for saving CDATA blocks in XML Beans 2.2 ? I see that XML Beans 2.3 provides some control over when the saver generates CDATA. The XML Options setSaveCDataLengthThreshold and setSaveCDataEntityCountThreshold allow any of the following configurations: Every text is CDATA Only text that has an entity is CDATA Only text longer than x chars is CDATA Only text that has y entitazable chars is CDATA Only text longer than x chars and has y entitazable chars is CDATA My question is what is the behavior of the saver in XML Beans 2.2? When does it decide to use CDATA blocks? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ArrayIndexOutOfBoundsException
Hi Pasi, I don't recall the exact details of the fix, but the problem was caused by a multi-threaded application using the XML Bean object in more than one thread. The fix was in my own code, not in XML Beans itself. - Steve -Original Message- From: Pasi [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 7:07 AM To: user@xmlbeans.apache.org Subject: Re: ArrayIndexOutOfBoundsException Hi Steve! I believe I have encountered the same problem. Local.java and Cur.java might have some threading problems (this might explain why the exception seem to occur quite irregulary). Did you manage to find any solution to this problem? -Pasi Steve Davis wrote: I am seeing the following exception from time to time when testing an application using XML Beans 2.0.0. It only happens rarely and is difficult to reproduce. Is this a known problem? Exception occurred: java.lang.ArrayIndexOutOfBoundsException: -1 at org.apache.xmlbeans.impl.store.Locale.exit(Locale.java:2840) at org.apache.xmlbeans.impl.store.Xobj.array_setter(Xobj.java:2320) at org.apache.xmlbeans.impl.values.XmlComplexContentImpl.arraySetterHelpe r( XmlComplexContentImpl.java:1055) -- View this message in context: http://www.nabble.com/ArrayIndexOutOfBoundsException-tf2124202.html#a102 51697 Sent from the Xml Beans - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ArrayIndexOutOfBoundsException
I am seeing the following exception from time to time when testing an application using XML Beans 2.0.0. It only happens rarely and is difficult to reproduce. Is this a known problem? Exception occurred: java.lang.ArrayIndexOutOfBoundsException: -1at org.apache.xmlbeans.impl.store.Locale.exit(Locale.java:2840)at org.apache.xmlbeans.impl.store.Xobj.array_setter(Xobj.java:2320)at org.apache.xmlbeans.impl.values.XmlComplexContentImpl.arraySetterHelper(XmlComplexContentImpl.java:1055)
RE: XmlBeans V2 and Piccolo
Title: Message Excellent. One more question. Is Piccolo thread-safe ? Thanks, Steve -Original Message-From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 3:56 PMTo: user@xmlbeans.apache.orgSubject: RE: XmlBeans V2 and Piccolo Yes, it does mean that. We repackage piccolo (so you can use a newer version if youd like) and then include it as part of xbean.jar. You do not need to do anything to get the advantages of Piccolo. Thanks, Radu -Original Message-From: Steve Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 10:01 AMTo: user@xmlbeans.apache.orgSubject: XmlBeans V2 and Piccolo The News page statesXML parsing is now by default performed by Piccolo. Does this mean Piccolo is somehow included in the XML Binary release? If so, which JAR file? Or do I need to install Piccolo separately?
RE: Application startup performance
After some experimenting, we found the startup time was greatly reduced by switching to XML Beans 2.0. Many thanks to the XML Beans development team for all your hard work! -Original Message- From: Steve Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 12:06 PM To: user@xmlbeans.apache.org Subject: Application startup performance One of our applications using XMLBeans 1.0.3 is pausing during startup for 60-90 seconds. The thread dump shows it mostly seems to be stuck in: at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.resolve(SchemaTypeS ystemImpl.java:2900) at schema.system.s3AA943C93EDDB1666BD35E9214C8CD9A.TypeSystemHolder.clinit (Unknown Source The jar file generated by scomp is over 9MB. We tried un-jarring the class files, but there is still a long delay. What can be done to improve startup time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jar file internals?
I would hope the schema\src directory is not needed for validation or parsing. We will try deleting the src and see what happens. -Original Message- From: Jacob Danner [mailto:[EMAIL PROTECTED] Sent: Monday, August 01, 2005 6:38 PM To: user@xmlbeans.apache.org Subject: RE: Jar file internals? I don't think any. All of the files beginning with schema contain the .xsb files that maintain sync with the xml infoset. I'm not sure what would happen if you deleted those, but I'm sure things like validate and parse would fail. -Original Message- From: Steve Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 01, 2005 3:28 PM To: user@xmlbeans.apache.org Subject: Jar file internals? Which parts of the jar file generated by scomp are needed for runtime execution? I am seeing directories: com\... META-INF\... schema\element\... schema\javaname\... schema\namespace\... schema\src\... schema\system\... schema\type\... Which of these directories can be safely removed without impacting the application at runtime? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jar file internals?
Thank you Cezar -Original Message- From: Cezar Andrei [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 12:42 PM To: user@xmlbeans.apache.org Subject: RE: Jar file internals? The directory schema/src is not needed for validation or parsing, but the .xsb files are needed. The src is included because there are applications that need the source file of a given schema type. If you don't use SchemaComponent.getSourceName() you probably don't use the files in schema\src. But remember, all the info from the schema files is still in the xsb files in a binary form and it's not impossible to infer an equivalent schema file. Cezar -Original Message- From: Steve Davis [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 11:09 AM To: user@xmlbeans.apache.org Subject: RE: Jar file internals? I would hope the schema\src directory is not needed for validation or parsing. We will try deleting the src and see what happens. -Original Message- From: Jacob Danner [mailto:[EMAIL PROTECTED] Sent: Monday, August 01, 2005 6:38 PM To: user@xmlbeans.apache.org Subject: RE: Jar file internals? I don't think any. All of the files beginning with schema contain the .xsb files that maintain sync with the xml infoset. I'm not sure what would happen if you deleted those, but I'm sure things like validate and parse would fail. -Original Message- From: Steve Davis [mailto:[EMAIL PROTECTED] Sent: Monday, August 01, 2005 3:28 PM To: user@xmlbeans.apache.org Subject: Jar file internals? Which parts of the jar file generated by scomp are needed for runtime execution? I am seeing directories: com\... META-INF\... schema\element\... schema\javaname\... schema\namespace\... schema\src\... schema\system\... schema\type\... Which of these directories can be safely removed without impacting the application at runtime? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jar file internals?
Which parts of the jar file generated by scomp are needed for runtime execution? I am seeing directories: com\... META-INF\... schema\element\... schema\javaname\... schema\namespace\... schema\src\... schema\system\... schema\type\... Which of these directories can be safely removed without impacting the application at runtime? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Schema Source in Jar
The XML Beans compiler copies the schema source file into the generated jar in the directory schema/src. I would like to avoid exposing the schema source for my application. 1. Is the schema source needed at run-time? 2. Is there any way to prevent the compiler from copying the schema into the Jar? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
