[jira] Created: (GERONIMO-4002) Tag Library Descriptor not being picked up from WEB-INF/lib
Tag Library Descriptor not being picked up from WEB-INF/lib --- Key: GERONIMO-4002 URL: https://issues.apache.org/jira/browse/GERONIMO-4002 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1 Environment: Windows XP, AG 2.1 Reporter: Ashish Jain Fix For: 2.1.1 The following illustration suggests the scenario:- 1) Package a TLD in a jar. The hierarchy of org.jar is META-INF/example.tld. 2) WEB-INF/lib/org.jar is the location for the jar. 3) In web.xml specify something like taglib taglib-uritest/taglib-uri taglib-location/WEB-INF/lib/org.jar/taglib-location /taglib I get the following error while deploying the application Could not parse TLD file at file:/C:/AG/test/geronimo-tomcat6-javaee5-2.1/repository/default/SimpleJSF/1.0/SimpleJSF-1.0.car/WEB-INF/lib/org.jar org.apache.geronimo.common.DeploymentException: Could not parse TLD file at file:/C:/AG/test/geronimo-tomcat6-javaee5-2.1/repository/default/SimpleJSF/1.0/SimpleJSF-1.0.car/WEB-INF/lib/org.jar at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:472) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:424) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:493) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:810) Caused by: org.apache.xmlbeans.XmlException: C:\AG\test\geronimo-tomcat6-javaee5-2.1\repository\default\SimpleJSF\1.0\SimpleJSF-1.0.car\WEB-INF\lib\org.jar:1:1: error: Illegal XML character: 0x3 org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML character: 0x3 at org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3474) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3958) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3439) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1270) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1257) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:657) at org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:76) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:438) at
[YOKO][DISCUSS] Time to create a 1.0 release?
I've recently completed an activity on seeing if we could get the IBM ObjectGrid product working with the Yoko ORB. This is a BIG CORBA application that rooted out quite a number of fringe bugs in the Yoko ORB. The testing effort involved no just interactions between a yoko client and server, but also in different client/server combinations with the IBM ORB (ObjectGrid has some problems running on the Sun ORB at the moment, so that interoperability was not tested). In the process of debugging these problems, I also added quite a bit of additional logging to the core orb. Things are looking pretty good and stable at this point. Currently, Geronimo is shipping using a pinned snapshot of the yoko code rather than an official release. Harmony is picking up SNAPSHOT builds, I believe. I think it is time to consider publishing the 1.0 release so there's finally an official release level to work from. I currently don't have any work items I feel need to be done before a 1.0 release can get created. I have a number of items I think need to get improved what I'd prefer doing after we cut a 1.0 release. Does anybody else know of additional items that might be required for the 1.0 release? Rick
Re: naming connection pools with a / in the name
David Jencks wrote: On Apr 30, 2008, at 2:14 PM, Hernan Cunico wrote: Hi all, When creating a connection pool and naming it in this from jdbc/something, the connection pool get created correctly. When I check the available connectors however, this pool is listed as console.dbpool/jdbc%2Fsomething/1.0/rar. So, when I define a dependency in a deployment plan I have to use jdbc%2Fsomething instead of jdbc/something I found 2 JIRAs (GERONIMO-2284 and GERONIMO-2314) mentioning the %2F. Is there any chance (or limitation) to use %2F only for creating the directories in the repo but having Geronimo to understand the requirement for a / in the dep plans instead of a %2F? This is leading to confusion as I am able to create a data source with a / in the name but not able to use it when referencing to the pool from a plan. I'm pretty sure we encode artifact names as uris all over the place so we'd have to move the encoding into the uri creating/parsing code. I'd be more tempted to prohibit / from artifactIds. Note that this issue is about the name of the module/plugin, NOT the name of the datasource gbean, which is what is used in persistence.xml and jndi resource-ref setup configuration. There is no problem naming a datasource jdbc/foo That's the thing, if there is no problem naming a datasource jdbc/foo then there should be no problem in referencing it. As it is now, If I add a dependency to jdbc/foo in the dep plan it will fail to deploy. Not sure how we can get away naming a datasource jdbc/foo and not slamming a / in the artifactId though. Cheers! Hernan thanks david jencks Cheers! Hernan
Re: naming connection pools with a / in the name
On May 2, 2008, at 7:40 AM, Hernan Cunico wrote: David Jencks wrote: On Apr 30, 2008, at 2:14 PM, Hernan Cunico wrote: Hi all, When creating a connection pool and naming it in this from jdbc/ something, the connection pool get created correctly. When I check the available connectors however, this pool is listed as console.dbpool/jdbc%2Fsomething/1.0/rar. So, when I define a dependency in a deployment plan I have to use jdbc%2Fsomething instead of jdbc/something I found 2 JIRAs (GERONIMO-2284 and GERONIMO-2314) mentioning the %2F. Is there any chance (or limitation) to use %2F only for creating the directories in the repo but having Geronimo to understand the requirement for a / in the dep plans instead of a %2F? This is leading to confusion as I am able to create a data source with a / in the name but not able to use it when referencing to the pool from a plan. I'm pretty sure we encode artifact names as uris all over the place so we'd have to move the encoding into the uri creating/parsing code. I'd be more tempted to prohibit / from artifactIds. Note that this issue is about the name of the module/plugin, NOT the name of the datasource gbean, which is what is used in persistence.xml and jndi resource-ref setup configuration. There is no problem naming a datasource jdbc/foo That's the thing, if there is no problem naming a datasource jdbc/ foo then there should be no problem in referencing it. As it is now, If I add a dependency to jdbc/foo in the dep plan it will fail to deploy. Not sure how we can get away naming a datasource jdbc/foo and not slamming a / in the artifactId though. ??? One is the datasource name, which ends up in a name=jdbc/Foo part of the gbean name, the other is the moduleId which has / separated components in the string or URI representation of the gbean name. so if I try to name both jdbc/foo I'd end up with something like org.foo/jdbc/foo/1.0/car?name=jdbc/ foo,j2eeType=JCAManagedConnectionFactory, As you can see the part before the ? won't parse into an artifact due to the unescaped / in the artifactId component. Assuming this module is an ancestor of my app, any resource-ref to jdbc/foo will resolve to this datasource, no matter what the name of the module. hope this clarifies what is going on david jencks Cheers! Hernan thanks david jencks Cheers! Hernan
[jira] Commented: (GERONIMO-4002) Tag Library Descriptor not being picked up from WEB-INF/lib
[ https://issues.apache.org/jira/browse/GERONIMO-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593839#action_12593839 ] Kevan Miller commented on GERONIMO-4002: I'm not aware of any requirement in the specification that says this should be supported. IIUC, taglib-location should refer to a .TLD file, not a .jar file. Do you have any evidence to the contrary? Otherwise, I think this should be closed as invalid... Tag Library Descriptor not being picked up from WEB-INF/lib --- Key: GERONIMO-4002 URL: https://issues.apache.org/jira/browse/GERONIMO-4002 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1 Environment: Windows XP, AG 2.1 Reporter: Ashish Jain Fix For: 2.1.1 The following illustration suggests the scenario:- 1) Package a TLD in a jar. The hierarchy of org.jar is META-INF/example.tld. 2) WEB-INF/lib/org.jar is the location for the jar. 3) In web.xml specify something like taglib taglib-uritest/taglib-uri taglib-location/WEB-INF/lib/org.jar/taglib-location /taglib I get the following error while deploying the application Could not parse TLD file at file:/C:/AG/test/geronimo-tomcat6-javaee5-2.1/repository/default/SimpleJSF/1.0/SimpleJSF-1.0.car/WEB-INF/lib/org.jar org.apache.geronimo.common.DeploymentException: Could not parse TLD file at file:/C:/AG/test/geronimo-tomcat6-javaee5-2.1/repository/default/SimpleJSF/1.0/SimpleJSF-1.0.car/WEB-INF/lib/org.jar at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:472) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:424) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:493) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:810) Caused by: org.apache.xmlbeans.XmlException: C:\AG\test\geronimo-tomcat6-javaee5-2.1\repository\default\SimpleJSF\1.0\SimpleJSF-1.0.car\WEB-INF\lib\org.jar:1:1: error: Illegal XML character: 0x3 org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML character: 0x3 at org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3474) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3958) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3439) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1270) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1257) at
Re: [YOKO][DISCUSS] Time to create a 1.0 release?
On May 2, 2008, at 9:43 AM, Rick McGuire wrote: I've recently completed an activity on seeing if we could get the IBM ObjectGrid product working with the Yoko ORB. This is a BIG CORBA application that rooted out quite a number of fringe bugs in the Yoko ORB. The testing effort involved no just interactions between a yoko client and server, but also in different client/ server combinations with the IBM ORB (ObjectGrid has some problems running on the Sun ORB at the moment, so that interoperability was not tested). In the process of debugging these problems, I also added quite a bit of additional logging to the core orb. Things are looking pretty good and stable at this point. Currently, Geronimo is shipping using a pinned snapshot of the yoko code rather than an official release. Harmony is picking up SNAPSHOT builds, I believe. I think it is time to consider publishing the 1.0 release so there's finally an official release level to work from. I currently don't have any work items I feel need to be done before a 1.0 release can get created. I have a number of items I think need to get improved what I'd prefer doing after we cut a 1.0 release. Does anybody else know of additional items that might be required for the 1.0 release? I'd love to see a 1.0 release. --kevan
[jira] Commented: (GERONIMO-3838) memory (probably related to sessions) leak
[ https://issues.apache.org/jira/browse/GERONIMO-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593919#action_12593919 ] Radim Kolar commented on GERONIMO-3838: --- using Sun hat tool i can confirm that this problem is related to allocating lot of sessions. dump from HAT tool Instance Counts for All Classes (excluding platform) 466128 instances of class [Ljava.util.concurrent.ConcurrentHashMap$HashEntry; 83106 instances of class [C 36330 instances of class [Ljava.lang.Object; 30464 instances of class [Ljava.util.Hashtable$Entry; 29133 instances of class [Ljava.util.concurrent.ConcurrentHashMap$Segment; 29086 instances of class org.apache.catalina.session.StandardSession 29086 instances of class org.apache.catalina.session.StandardSessionFacade There is difference between using IBM vs SUN JDK, If Sun jdk is used Geronimo never recovers from out of memory error. Proposed fix: Geronimo needs to swap inactive sessions to file or forget them and not to run out of memory. It would be nice to have number of sessions kept in main memory configurable via System configuration console. memory (probably related to sessions) leak -- Key: GERONIMO-3838 URL: https://issues.apache.org/jira/browse/GERONIMO-3838 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Memory Leaks Affects Versions: 2.0.2 Environment: tested with JDK 1.5 running on Windows XP and FreeBSD6.2 Reporter: Radim Kolar Priority: Critical There is memory leak and it can be repeated very easily, so it should be very easy to catch Install Geronimo and then run some kind of benchmarking software against its admin UI login page, for example program ab from Apache HTTP. This is realistic attack scenario, because lot of denial of service attacks are doing this (requesting one page many times). Watching memory used graph in admin console shows free memory slowly decreasing. After all available memory is exhausted, application server stops serving new requests and never restores ifself back to working state. I think that it is caused by allocating sessions without limiting total number of sessions to keep in memory and possibly to swap sessions out to file. There needs to be user-configurable setting for preventing this, it would be nice to add such setting to Admin console. Its very important to get this bug fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO][DISCUSS] Time to create a 1.0 release?
Hello Rick, Sorry, this is not directly related to your question. What kind of integration with ObjectGrid have you been working on? FWIW, I am working on a hierarchical, transactional, distributed, partitioned and replicated cache and data-grid solution as part of WADI and I am quite interested by this topic these days. Thanks, Gianny On 02/05/2008, at 11:43 PM, Rick McGuire wrote: I've recently completed an activity on seeing if we could get the IBM ObjectGrid product working with the Yoko ORB. This is a BIG CORBA application that rooted out quite a number of fringe bugs in the Yoko ORB. The testing effort involved no just interactions between a yoko client and server, but also in different client/ server combinations with the IBM ORB (ObjectGrid has some problems running on the Sun ORB at the moment, so that interoperability was not tested). In the process of debugging these problems, I also added quite a bit of additional logging to the core orb. Things are looking pretty good and stable at this point. Currently, Geronimo is shipping using a pinned snapshot of the yoko code rather than an official release. Harmony is picking up SNAPSHOT builds, I believe. I think it is time to consider publishing the 1.0 release so there's finally an official release level to work from. I currently don't have any work items I feel need to be done before a 1.0 release can get created. I have a number of items I think need to get improved what I'd prefer doing after we cut a 1.0 release. Does anybody else know of additional items that might be required for the 1.0 release? Rick
[jira] Commented: (GERONIMO-4002) Tag Library Descriptor not being picked up from WEB-INF/lib
[ https://issues.apache.org/jira/browse/GERONIMO-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593970#action_12593970 ] Ashish Jain commented on GERONIMO-4002: --- The same configuration works fine with Tomcat V6.0.13. Tag Library Descriptor not being picked up from WEB-INF/lib --- Key: GERONIMO-4002 URL: https://issues.apache.org/jira/browse/GERONIMO-4002 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1 Environment: Windows XP, AG 2.1 Reporter: Ashish Jain Fix For: 2.1.1 The following illustration suggests the scenario:- 1) Package a TLD in a jar. The hierarchy of org.jar is META-INF/example.tld. 2) WEB-INF/lib/org.jar is the location for the jar. 3) In web.xml specify something like taglib taglib-uritest/taglib-uri taglib-location/WEB-INF/lib/org.jar/taglib-location /taglib I get the following error while deploying the application Could not parse TLD file at file:/C:/AG/test/geronimo-tomcat6-javaee5-2.1/repository/default/SimpleJSF/1.0/SimpleJSF-1.0.car/WEB-INF/lib/org.jar org.apache.geronimo.common.DeploymentException: Could not parse TLD file at file:/C:/AG/test/geronimo-tomcat6-javaee5-2.1/repository/default/SimpleJSF/1.0/SimpleJSF-1.0.car/WEB-INF/lib/org.jar at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:472) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:424) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:493) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:810) Caused by: org.apache.xmlbeans.XmlException: C:\AG\test\geronimo-tomcat6-javaee5-2.1\repository\default\SimpleJSF\1.0\SimpleJSF-1.0.car\WEB-INF\lib\org.jar:1:1: error: Illegal XML character: 0x3 org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML character: 0x3 at org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3474) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3958) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3439) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1270) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1257) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:657)
