Should be fixed now
Jason T. Greene wrote:
> 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