[jboss-dev] changes in parsing with xb
Jason T. Greene
jason.greene at redhat.com
Tue Apr 7 14:30:41 EDT 2009
Ah yeah, i see the problem now. It's a property that disables validation
Carlo de Wolf wrote:
> It's in the testsuite:
>
> [carlo at nymph testsuite]$ ./build.sh jboss-minimal-tests
> Searching for build.xml ...
> Buildfile: /home/carlo/work/jboss-5.x/testsuite/build.xml
>
> jboss-minimal-tests:
> [server:start] Starting server "minimal", with command (start timeout is
> 120 seconds ):
> [server:start] /usr/java/jdk1.5.0_16/bin/java -cp
> /home/carlo/work/jboss-5.x/build/output/jboss-5.1.0.CR1/bin/run.jar:/usr/java/jdk1.5.0_16/lib/tools.jar
> -Djboss.vfs.forceNoReaper=true -Djboss.server.log.threshold=DEBUG
> org.jboss.Main -c minimal -b localhost -g DefaultPartition
>
> BUILD FAILED
> /home/carlo/work/jboss-5.x/testsuite/build.xml:1035: Error starting
> server "minimal": Server failed to start; see logs. exit code: 0
>
> Total time: 12 seconds
> [carlo at nymph testsuite]$ cat
> ../build/output/jboss-5.1.0.CR1/server/minimal/log/error.log
> Failed to boot JBoss:
> org.jboss.xb.binding.JBossXBException: Failed to parse source:
> file:/home/carlo/work/jboss-5.x/build/output/jboss-5.1.0.CR1/server/minimal/conf/bootstrap/deployers.xml at 46,56
>
> at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
>
> at
> org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:147)
> at
> org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:150)
>
> at
> org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:138)
> at
> org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
> at org.jboss.Main.boot(Main.java:216)
> at org.jboss.Main$1.run(Main.java:546)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException:
> {urn:jboss:bean-deployer:2.0}incallback cannot appear in this position.
> Expected content of {urn:jboss:bean-deployer:2.0}bean is sequence:
> {urn:jboss:bean-deployer:2.0}alias*
> {urn:jboss:bean-deployer:2.0}related-class*
> {urn:jboss:bean-deployer:2.0}annotation*
> {urn:jboss:bean-deployer:2.0}classloader?
> {urn:jboss:bean-deployer:2.0}constructor?
> {urn:jboss:bean-deployer:2.0}property*
> {urn:jboss:bean-deployer:2.0}create? {urn:jboss:bean-deployer:2.0}start?
> {urn:jboss:bean-deployer:2.0}stop? {urn:jboss:bean-deployer:2.0}destroy?
> {urn:jboss:bean-deployer:2.0}depends*
> {urn:jboss:bean-deployer:2.0}demand*
> {urn:jboss:bean-deployer:2.0}supply*
> {urn:jboss:bean-deployer:2.0}install*
> {urn:jboss:bean-deployer:2.0}uninstall*
> {urn:jboss:bean-deployer:2.0}incallback*
> {urn:jboss:bean-deployer:2.0}uncallback*
> at
> org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:494)
>
> at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
>
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at org.apache.xerces.xinclude.XIncludeHandler.emptyElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)
> at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173)
>
> ... 7 more
>
> Carlo
>
> Jason T. Greene wrote:
>>
>> Anyone else see this? It is working for me
>>
>> Carlo de Wolf wrote:
>>> Testsuite shows a 100% regression as minimal fails to boot up.
>>>
>>> Failed to boot JBoss:
>>> org.jboss.xb.binding.JBossXBException: Failed to parse source:
>>> file:/home/hudson/.hudson/jobs/JBoss-AS-5.x-TestSuite-sun15/workspace/Branch_5_x/build/output/jboss-5.1.0.CR1/server/minimal/conf/bootstrap/deployers.xml at 46,56
>>>
>>> Caused by: org.jboss.xb.binding.JBossXBRuntimeException:
>>> {urn:jboss:bean-deployer:2.0}incallback cannot appear in this
>>> position. Expected content of {urn:jboss:bean-deployer:2.0}bean is
>>> sequence: {urn:jboss:bean-deployer:2.0}alias*
>>> {urn:jboss:bean-deployer:2.0}related-class*
>>> {urn:jboss:bean-deployer:2.0}annotation*
>>> {urn:jboss:bean-deployer:2.0}classloader?
>>> {urn:jboss:bean-deployer:2.0}constructor?
>>> {urn:jboss:bean-deployer:2.0}property*
>>> {urn:jboss:bean-deployer:2.0}create?
>>> {urn:jboss:bean-deployer:2.0}start?
>>> {urn:jboss:bean-deployer:2.0}stop?
>>> {urn:jboss:bean-deployer:2.0}destroy?
>>> {urn:jboss:bean-deployer:2.0}depends*
>>> {urn:jboss:bean-deployer:2.0}demand*
>>> {urn:jboss:bean-deployer:2.0}supply*
>>> {urn:jboss:bean-deployer:2.0}install*
>>> {urn:jboss:bean-deployer:2.0}uninstall*
>>> {urn:jboss:bean-deployer:2.0}incallback*
>>> {urn:jboss:bean-deployer:2.0}uncallback*
>>>
>>> I'm inclined to do a rollback, because anything coming in *must* be
>>> backwards compatible.
>>> A log.warn instead of a failure would have been better.
>>>
>>> I'll give it 24 hours to be fixed.
>>>
>>> Your friendly BOFH,
>>>
>>> Carlo
>>>
>>> Alexey Loubyansky wrote:
>>>> There have been many fixes in the last two beta releases of XB that
>>>> will affect AS and other users.
>>>> Most noticeable changes/fixes are related to internal navigation
>>>> across schema structures during XML parsing. In simple words, XB is
>>>> now (much) more sensitive to validation issues (incorrect element
>>>> order, etc).
>>>> Some files that could be parsed before, now (with default settings)
>>>> won't. WRT AS it would be e.g. vfs, aop xml etc.
>>>>
>>>> To workaround this, you can set system property
>>>> xb.builder.useUnorderedSequence to true. This will make the order in
>>>> which elements from a sequence appear in xml not important.
>>>> Alternatively, you can call
>>>> JBossXBBuilder.setUseUnorderedSequence(boolean value) or use
>>>> annotation
>>>> @JBossXmlModelGroup(kind=JBossXmlConstants.MODEL_GROUP_UNORDERED_SEQUENCE)
>>>> to bind classes to unordered sequences.
>>>>
>>>> But this has to remain a workaround, not the default. There has to
>>>> be a good reason to use unordered sequences. Fix your XML and
>>>> binding now.
>>>>
>>>> The latest XB has not been integrated into the AS yet (although, I
>>>> ran some tests from the AS testsuite locally) due to dependency on
>>>> changes in VFS and deployers:
>>>> https://jira.jboss.org/jira/browse/JBVFS-99
>>>> https://jira.jboss.org/jira/browse/JBDEPLOY-173
>>>>
>>>> The latest metadata release (1.0.0.CR17) requires at least XB
>>>> 2.0.1.Beta3.
>>>>
>>>> If you are using XB, please, try the latest beta.
>>>>
>>>> Here are release notes for XB 2.0.1.Beta3
>>>> https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12313320&styleName=Html&projectId=10069
>>>>
>>>>
>>>> and XB 2.0.1.Beta2
>>>> https://jira.jboss.org/jira/secure/ReleaseNote.jspa?version=12313217&styleName=Html&projectId=10069
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
--
Jason T. Greene
JBoss, a division of Red Hat
More information about the jboss-development
mailing list