6 Replies Latest reply on Jan 17, 2007 11:33 AM by adrian.brock

    Why SingletonSchemaResolverFactory?

    starksm64

      Why is the BasicXMLDeployer using the SingletonSchemaResolverFactory? This cannot be extended and does not allow one to add new schemas without modifying the existing private ctor, which mean modifying the jbossxb release:

       private SingletonSchemaResolverFactory()
       {
       addSchema("urn:jboss:aop-beans:1.0", "org.jboss.aop.microcontainer.beans.xml.AOPBeansSchemaInitializer", Boolean.FALSE);
       addSchema("urn:jboss:bean-deployer", "org.jboss.kernel.plugins.deployment.xml.BeanSchemaInitializer", Boolean.FALSE);
       addSchema("urn:jboss:bean-deployer:2.0", "org.jboss.kernel.plugins.deployment.xml.BeanSchemaInitializer20", Boolean.FALSE);
       addSchema("urn:jboss:javabean:1.0", "org.jboss.kernel.plugins.config.xml.JavaBeanSchemaInitializer", Boolean.FALSE);
       }
      


      Either this should be subclassable, the mutator methods public, or BasicXMLDeployer using a different resolver factory.


        • 1. Re: Why SingletonSchemaResolverFactory?
          alesj

          I used this 'hack' to temp add new Spring schema:

           public void setUp() throws Exception
           {
           SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();
           DefaultSchemaResolver defaultSchemaResolver = (DefaultSchemaResolver) resolver;
           defaultSchemaResolver.addSchemaInitializer("urn:jboss:spring-beans:2.0", new SpringSchemaInitializer());
           defaultSchemaResolver.addSchemaLocation("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd");
           super.setUp();
           }
          


          But I agree with you.

          • 2. Re: Why SingletonSchemaResolverFactory?

            There is an MBean/POJO that can be deployed to add schemas at runtime.

            The singleton is just a mechanism to setup "known ones" automatically.
            i.e. factory settings.

            There is a post about it somewhere in the JBossXB forum.
            If search worked I could find it for you. :-)

            e.g.

            <bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig">
            
             <!-- The initializer classes -->
             <property name="SchemaInitializers">
             urn:somenamespace=some.class.name
             </property>
            
             <!-- The locations these are added to JBossEntityResolver -->
             <property name="SchemaLocations">
             urn:somenamespace=schema/some.xsd
             </property>
            
             <!-- Only for performance if your schema is annotated, but only with coments -->
             <property name="ParseAnnotations">
             urn:somenamespace=false
             </property>
            </bean>
            


            • 3. Re: Why SingletonSchemaResolverFactory?

               

              "alesj" wrote:
              I used this 'hack' to temp add new Spring schema:
               public void setUp() throws Exception
               {
               SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();
               DefaultSchemaResolver defaultSchemaResolver = (DefaultSchemaResolver) resolver;
               defaultSchemaResolver.addSchemaInitializer("urn:jboss:spring-beans:2.0", new SpringSchemaInitializer());
               defaultSchemaResolver.addSchemaLocation("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd");
               super.setUp();
               }
              


              But I agree with you.


              The Spring one (and other known ones) should be added to the singleton.
              If the initializer class is not in the classpath, it will ignore it.

              • 4. Re: Why SingletonSchemaResolverFactory?
                alesj

                 

                "adrian@jboss.org" wrote:
                There is an MBean/POJO that can be deployed to add schemas at runtime.
                <bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig">
                ...
                


                And this beans should be installed before any other with new schema usage.
                Meaning that the order matters - since those beans cannot depend on this one.
                Right?


                • 5. Re: Why SingletonSchemaResolverFactory?

                  Yes, obviously it can't read minds.

                  Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use
                  MC (Spring) xml to define this POJO either. :-)

                  • 6. Re: Why SingletonSchemaResolverFactory?

                     

                    "adrian@jboss.org" wrote:
                    Yes, obviously it can't read minds.

                    Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use
                    MC (Spring) xml to define this POJO either. :-)


                    Well actually you could if you know the system location of the xsd.

                    But that isn't very nice.

                    Which is better, having to know the schema that is going to be used and its location

                    <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                     xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
                     xmlns="urn:jboss:bean-deployer">
                    


                    or just specifying the namespace?

                    <deployment xmlns="urn:jboss:bean-deployer">