10 Replies Latest reply: Jul 9, 2009 8:26 PM by David Lloyd RSS

    Referencing the bean-deployer namespace from a custom metada

    David Lloyd Master

      In the jboss-logging.xml deployer that I'm developing, I want to reuse the MC's "AbstractPropertyMetaData" type in order to represent arbitrary properties that can be set on jboss-logging entities. To that end I have this:

      public abstract class AbstractHandlerMetaData {
       (...)
       private List<PropertyMetaData> propertyMetaDataList;
       (...)
       public List<PropertyMetaData> getPropertyMetaDataList() {
       return propertyMetaDataList;
       }
      
       @XmlElementWrapper(name="properties")
       @XmlElement(name="property", type=AbstractPropertyMetaData.class)
       public void setPropertyMetaDataList(final List<PropertyMetaData> propertyMetaDataList) {
       this.propertyMetaDataList = propertyMetaDataList;
       }
      


      But I get a weird error:

      Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: The type of the attribute search must be simple or complex with a value adapter: org.jboss.xb.binding.sunday.unmarshalling.TypeBinding@6acbdf6e[null]
      at org.jboss.beans.metadata.plugins.AbstractDependencyValueMetaData.search
      at org.jboss.beans.metadata.plugins.AbstractClassLoaderMetaData.classLoader
      at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.classLoader
      at org.jboss.beans.metadata.plugins.AbstractPropertyMetaData.value
      at org.jboss.logging.metadata.HandlerMetaData.propertyMetaDataList
      at org.jboss.logging.metadata.LoggingMetaData.handlerMetaDataList
      at org.jboss.logging.metadata.LoggingMetaData
       at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
       at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
       at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:189)
       at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:166)
       at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137)
       at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121)
       at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
       at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:188)
       at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:348)
       ... 33 more
      Caused by: org.jboss.xb.binding.JBossXBRuntimeException: The type of the attribute search must be simple or complex with a value adapter: org.jboss.xb.binding.sunday.unmarshalling.TypeBinding@6acbdf6e[null]
      at org.jboss.beans.metadata.plugins.AbstractDependencyValueMetaData.search
      at org.jboss.beans.metadata.plugins.AbstractClassLoaderMetaData.classLoader
      at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.classLoader
      at org.jboss.beans.metadata.plugins.AbstractPropertyMetaData.value
      at org.jboss.logging.metadata.HandlerMetaData.propertyMetaDataList
      at org.jboss.logging.metadata.LoggingMetaData.handlerMetaDataList
      at org.jboss.logging.metadata.LoggingMetaData
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.rethrowWithLocation(JBossXBNoSchemaBuilder.java:2018)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:346)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElements(JBossXBNoSchemaBuilder.java:321)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:232)
       at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:291)
       at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:181)
       at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:160)
       at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:261)
       at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:274)
       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.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
       at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
       at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
       at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(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:199)
       ... 41 more
      Caused by: org.jboss.xb.binding.JBossXBRuntimeException: The type of the attribute search must be simple or complex with a value adapter: org.jboss.xb.binding.sunday.unmarshalling.TypeBinding@6acbdf6e[null]
       at org.jboss.xb.binding.sunday.unmarshalling.AttributeBinding.<init>(AttributeBinding.java:60)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:931)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1118)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1118)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1141)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateCollection(JBossXBNoSchemaBuilder.java:710)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:514)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1118)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1118)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1118)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createElementBinding(JBossXBNoSchemaBuilder.java:361)
       at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:341)
       ... 62 more
      


      The weird thing is, this is all part of the bean deployer schema classes which were all registered already, so why is this suddenly a problem when my binding references it? Is there some other thing I need to do to make this work, or can I simply not reuse types in this way?

        • 2. Re: Referencing the bean-deployer namespace from a custom me
          Ales Justin Master

          I applied JBXB-125 to appropriate metadata,
          but since this is an api change (moved the classes), this will only be available in Kernel 2.2.x.

          • 3. Re: Referencing the bean-deployer namespace from a custom me
            Alexey Loubyansky Master

            Property bound to an attribute must be of a type that XB knows how to (un)marshal from/to a simple value, e.g. a primitive type (or a wrapper) or String.

            @XmlAttribute(name = "search")
             public void setSearch(SearchInfo search)


            Is none of that. An adapter should be provided that will perform (un)marshalling from/to simple string values.

            • 4. Re: Referencing the bean-deployer namespace from a custom me
              Ales Justin Master

               

              "alex.loubyansky@jboss.com" wrote:
              An adapter should be provided that will perform (un)marshalling from/to simple string values.

              This is already there:
              - http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/branches/Branch_2_0/kernel/src/main/java/org/jboss/beans/metadata/plugins/SearchInfoValueAdapter.java

              I would (still) say he's missing proper package-info.java with duplicated code
              from previous duplicated p-i.java across Kernel project.

              • 5. Re: Referencing the bean-deployer namespace from a custom me
                David Lloyd Master

                Do I need something on package-info.java? Never did before...

                • 6. Re: Referencing the bean-deployer namespace from a custom me
                  Ales Justin Master

                   

                  "david.lloyd@jboss.com" wrote:
                  Do I need something on package-info.java? Never did before...

                  Just copy/paste the one from Kernel.
                  And don't forget to change the package. ;-)

                  • 7. Re: Referencing the bean-deployer namespace from a custom me
                    David Lloyd Master

                    OK, awesome, that worked.

                    One other thing - I have my root element set up to be propOrder={} and modelgroup=CHOICE. I have two properties which are using XmlElements like this:

                     public List<AbstractLoggerMetaData> getLoggerMetaDataList() {
                     return loggerMetaDataList;
                     }
                    
                     @XmlElements({
                     @XmlElement(name = "root-logger", type = RootLoggerMetaData.class),
                     @XmlElement(name = "logger", type = LoggerMetaData.class)
                     })
                     public void setLoggerMetaDataList(final List<AbstractLoggerMetaData> loggerMetaDataList) {
                     this.loggerMetaDataList = loggerMetaDataList;
                     }
                    
                     public List<AbstractHandlerMetaData> getHandlerMetaDataList() {
                     return handlerMetaDataList;
                     }
                    
                     @XmlElements({
                     @XmlElement(name = "handler", type = HandlerMetaData.class),
                     @XmlElement(name = "log4j-appender", type = Log4jAppenderMetaData.class),
                     @XmlElement(name = "console-handler", type = ConsoleHandlerMetaData.class),
                     @XmlElement(name = "file-handler", type = FileHandlerMetaData.class),
                     @XmlElement(name = "periodic-rotating-file-handler", type = PeriodicRotatingFileHandlerMetaData.class),
                     @XmlElement(name = "size-rotating-file-handler", type = SizeRotatingFileHandlerMetaData.class),
                     @XmlElement(name = "async-handler", type = AsyncHandlerMetaData.class),
                     @XmlElement(name = "null-handler", type = NullHandlerMetaData.class)
                     })
                     public void setHandlerMetaDataList(final List<AbstractHandlerMetaData> handlerMetaDataList) {
                     this.handlerMetaDataList = handlerMetaDataList;
                     }
                    
                     public List<InstallHandlerMetaData> getInstallHandlerMetaDataList() {
                     return installHandlerMetaDataList;
                     }
                    
                     @XmlElement(name = "install-handler")
                     public void setInstallHandlerMetaDataList(final List<InstallHandlerMetaData> installHandlerMetaDataList) {
                     this.installHandlerMetaDataList = installHandlerMetaDataList;
                     }
                    


                    But it gives me this error:

                    org.jboss.xb.binding.JBossXBRuntimeException: {urn:jboss:logging:6.0}logger cannot appear in this position. Expected content of {urn:jboss:logging:6.0}logging is choice: {choice}* {choice}* {urn:jboss:logging:6.0}install-handler*
                    


                    I don't think this is correct behavior though. The source XML looks like (comments removed):

                    <logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0">
                     <periodic-rotating-file-handler
                     file-name="${jboss.server.log.dir}/server.log"
                     name="FILE"
                     autoflush="true"
                     append="true"
                     suffix=".yyyy-MM-dd">
                     <error-manager>
                     <only-once/>
                     </error-manager>
                    
                     <formatter>
                     <pattern-formatter pattern="%d %-5p [%c] (%t) %m%n"/>
                     </formatter>
                     </periodic-rotating-file-handler>
                    
                     <console-handler name="CONSOLE" autoflush="true" target="System.out">
                     <error-manager>
                     <only-once/>
                     </error-manager>
                    
                     <level name="INFO"/>
                    
                     <formatter>
                     <pattern-formatter pattern="%d %-5p [%c] (%t) %m%n"/>
                     </formatter>
                     </console-handler>
                    
                     <logger category="org.apache">
                     <level name="INFO"/>
                     </logger>
                    
                     (a bunch more loggers follow)
                    


                    So maybe it's treating the outer choice as maxOccurs=1 or something? Is there something else I need to add?


                    • 8. Re: Referencing the bean-deployer namespace from a custom me
                      David Lloyd Master

                      Unordered sequence seems to "fix" it, but it doesn't seem correct to me. But for now I am pacified :)

                      • 9. Re: Referencing the bean-deployer namespace from a custom me
                        Alexey Loubyansky Master

                         

                        So maybe it's treating the outer choice as maxOccurs=1 or something?


                        Yes, of course. And IMO that's how it should be. Otherwise, the structures of the bound components/types in Java and XSD are inconsistent. Why don't you use a sequence? What problem does it cause in this case?

                        I have my root element set up to be propOrder={} and modelgroup=CHOICE.

                        If you bind to a choice then propOrder should be removed. propOrder={} is supposed to bind to all.

                        • 10. Re: Referencing the bean-deployer namespace from a custom me
                          David Lloyd Master

                           

                          "alex.loubyansky@jboss.com" wrote:
                          So maybe it's treating the outer choice as maxOccurs=1 or something?


                          Yes, of course. And IMO that's how it should be. Otherwise, the structures of the bound components/types in Java and XSD are inconsistent. Why don't you use a sequence? What problem does it cause in this case?


                          The problem is that it prevents the user from putting the element in any order. In the schema, all the elements listed in this class are in one "choice"; the only reason they're grouped as they are here is because that's how they're mapped in terms of Java types. So the effect I'm really going for is to have XB take all the XmlElement instances in the class and make one big "choice" out of it with maxOccurs=unbounded.

                          I have my root element set up to be propOrder={} and modelgroup=CHOICE.

                          If you bind to a choice then propOrder should be removed. propOrder={} is supposed to bind to all.