1 2 Previous Next 25 Replies Latest reply on May 24, 2008 2:52 AM by Ales Justin

    SchemaResolverDeployer is parsing but not deploying

    David Lloyd Master

      It seems to parse my file OK:

      2008-05-21 16:06:24,230 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Deploying vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml
      2008-05-21 16:06:24,230 DEBUG [org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer] (HDScanner) Parsing file: FileHandler@91501340[path=jboss-io.xml context=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/ real=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml] for deploymentType: class org.jboss.cx.io.metadata.DeploymentMetaData
      2008-05-21 16:06:24,231 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) Created parser: org.apache.xerces.jaxp.SAXParserImpl@4dec5ecc, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
      2008-05-21 16:06:24,231 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) http://xml.org/sax/features/validation set to: true
      2008-05-21 16:06:24,231 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) http://xml.org/sax/features/namespaces set to: true
      2008-05-21 16:06:24,231 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) http://apache.org/xml/features/validation/dynamic set to: true
      2008-05-21 16:06:24,231 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) http://apache.org/xml/features/validation/schema set to: true
      2008-05-21 16:06:24,231 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) http://xml.org/sax/features/validation set to: true
      2008-05-21 16:06:24,232 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] (HDScanner) Created parser: org.apache.xerces.jaxp.SAXParserImpl@4dec5ecc, isNamespaceAware: true, isValidating: true, isXIncludeAware: true
      2008-05-21 16:06:24,234 DEBUG [org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer] (HDScanner) Parsed file: FileHandler@91501340[path=jboss-io.xml context=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/ real=file:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml] to: org.jboss.cx.io.metadata.DeploymentMetaData@5bc2832e
      2008-05-21 16:06:24,235 DEBUG [org.jboss.deployers.vfs.plugins.classloader.InMemoryClassesDeployer] (HDScanner) Dynamic class root for vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml is vfsmemory://3j001-fb7hzw-fgibuklu-1-fgienkh6-1q
      2008-05-21 16:06:24,235 DEBUG [org.jboss.classloader.spi.base.BaseClassLoader] (HDScanner) Created BaseClassLoader@3f327012{vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml} with policy VFSClassLoaderPolicy@85bce28{name=vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml domain=null roots=[MemoryContextHandler@1127983201[path=classes context=vfsmemory://3j001-fb7hzw-fgibuklu-1-fgienkh6-1q real=vfsmemory://3j001-fb7hzw-fgibuklu-1-fgienkh6-1q/classes]] delegates=null exported=[] <IMPORT-ALL>NON_EMPTY}
      2008-05-21 16:06:24,235 DEBUG [org.jboss.classloader.spi.base.BaseClassLoaderDomain] (HDScanner) ClassLoaderDomain@7c33788d{<DEFAULT>} registerClassLoader BaseClassLoader@3f327012{vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml}
      2008-05-21 16:06:24,238 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Fully Deployed vfsfile:/home/david/src/java/jboss-5.0.0.CR1-r73551/server/default/deploy/jboss-io.xml
      


      However, the getBeans() method of my root metadata object isn't called (it implements org.jboss.beans.metadata.spi.BeanMetaDataFactory). Is there some other special steps I have to follow?

      The metadata class is here: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/networking/deployer/src/main/java/org/jboss/cx/io/metadata/DeploymentMetaData.java

      My jboss-beans.xml contains:

      <bean:deployment xmlns:bean="urn:jboss:bean-deployer:2.0">
       <bean:bean name="XnioDeployer" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer">
       <bean:constructor>
       <bean:parameter>org.jboss.cx.io.metadata.DeploymentMetaData</bean:parameter>
       </bean:constructor>
       <bean:property name="name">jboss-io.xml</bean:property>
       <bean:property name="registerWithJBossXB">true</bean:property>
       </bean:bean>
      </bean:deployment>
      


      I'm using JBossAS trunk as my testbed.

        • 1. Re: SchemaResolverDeployer is parsing but not deploying
          Ales Justin Master

           

          "david.lloyd@jboss.com" wrote:

          However, the getBeans() method of my root metadata object isn't called (it implements org.jboss.beans.metadata.spi.BeanMetaDataFactory). Is there some other special steps I have to follow?

          It would only be called if you had your custom xml inside MC's deployment element.
          Then it would consider your custom xml as wildcard, and expect it to implement BeanMetaDataFactory.

          What you are missing is a deployer that breaks your custom DeploymentMD into MC's BeanMetaData and attaches them into new component deployment unit. See KernelDeploymentDeployer on how to do this.

          • 2. Re: SchemaResolverDeployer is parsing but not deploying
            David Lloyd Master

            I thought that's what the SchemaResolverDeployer was doing, and in fact that was the whole point of making my DeploymentMetaData implement BeanMetaDataFactory.

            If not, isn't this a step that would have to be duplicated for every project that has a customized XML deployment format?

            Or, are you suggesting that I should use the MC's root deployment element instead?

            • 3. Re: SchemaResolverDeployer is parsing but not deploying
              David Lloyd Master

              BTW, what does KernelDeploymentDeployer actually *do*? Keeping in mind that, as of last time I checked anyway, I have been unable to find any documentation anywhere that explains in regular-person language what the difference and relationship between a KernelDeployment, DeploymentUnit, and BeanMetaData instance really is.

              I've figured out BeanMetaData by trial and error, but I still don't quite understand the role of the other bits.

              • 4. Re: SchemaResolverDeployer is parsing but not deploying
                David Lloyd Master

                Wait, don't answer that last. I just found the reference guide...

                • 5. Re: SchemaResolverDeployer is parsing but not deploying
                  Ales Justin Master

                   

                  "david.lloyd@jboss.com" wrote:
                  I thought that's what the SchemaResolverDeployer was doing, and in fact that was the whole point of making my DeploymentMetaData implement BeanMetaDataFactory.

                  SRD just does what you told it to do - create a custom DeploymentMD. :-)
                  The fact that it implement BMDF only comes handy in case I mentioned before - if it is used inside MC's deployment element.

                  "david.lloyd@jboss.com" wrote:

                  If not, isn't this a step that would have to be duplicated for every project that has a customized XML deployment format?

                  Or, are you suggesting that I should use the MC's root deployment element instead?

                  Yes, then you don't need that extra deployer.
                  But if you still want to have your custom xml with your custom root, then there is no other way - at least not out-of-the-box.

                  • 6. Re: SchemaResolverDeployer is parsing but not deploying
                    Ales Justin Master

                    I'll answer it anyway since reference guide doesn't say much. ;-)

                    "david.lloyd@jboss.com" wrote:
                    BTW, what does KernelDeploymentDeployer actually *do*?

                    In new Deployers there is a notion of component.
                    As I see components, they are the atoms of what you pass around in deployer's attachments - cannot be split any further.
                    And those are the items that represent the actual runtime components, e.g. BeanMetaData ~ bean, ServiceMetaData ~ MBean, ...
                    e.g. if admin console needs to inspect its runtime environment, all it needs to do is look at the deployer's/deployment unit's components.

                    So, in order to have components, something needs to create them.
                    Usually splitting some group of components from plain deployment unit into component deployment units.

                    And that's what KDD does. It takes KD and splits it into BMDs. Or takes BMD from plain deployment unit and puts it into component du - so that it really is a component.

                    It's more of a conceptual thing, keeping things clean and prepared for things that follow - profile service, etc.

                    OK, this is how I see it. :-)
                    I just had a discussion with MarkN about it, and we don't completely agree on everything.
                    Adrian might explain it better, and I hope I didn't do a shot in the dark (too much). :-)

                    • 7. Re: SchemaResolverDeployer is parsing but not deploying
                      David Lloyd Master

                       

                      "alesj" wrote:
                      "david.lloyd@jboss.com" wrote:

                      If not, isn't this a step that would have to be duplicated for every project that has a customized XML deployment format?

                      Or, are you suggesting that I should use the MC's root deployment element instead?

                      Yes, then you don't need that extra deployer.
                      But if you still want to have your custom xml with your custom root, then there is no other way - at least not out-of-the-box.


                      OK, well I thought about this some more, and I still don't like this option because the integration with the MC descriptor doesn't work the way that I think would make sense.

                      To illustrate what I mean, say the user wants to define a TCP server. The XML snippet would look like this:

                      ...
                      <io:tcp-server name="MyServer" handler-factory-bean="MyHandlerFactory">
                       <io:bind-address port="12345"/>
                      </io:tcp-server>
                      ...
                      


                      This basically expands to a BeanMetaData that describes a bean named "MyServer". So a "tcp-server" is basically just a way to define a specific kind of bean - so from the user's perspective, they might expect that a "tcp-server" could be used anywhere a "bean" might be used, since "tcp-server" just describes a bean. If I use the BeanMetaDataFactory method though, it's not a 1:1 mapping like that.

                      Make any sense? I mean I guess it might be handy to be able to have the bean deployments and I/O deployments in one file, so you can define your handler beans and then in the same file deploy the servers that use it. On the other hand, I don't want to force the users to do that.

                      The problem I continue to have is that those of us trying to make deployers using the new stuff are basically pioneering new territory, and since there are no established idioms we're really just making it up as we go.

                      • 8. Re: SchemaResolverDeployer is parsing but not deploying
                        David Lloyd Master

                        OK, I've now realized that there's absolutely no point in using the schema resolver deployer if you're going to embed your customized descriptor inside of a bean-deployment descriptor. It took me long enough to figure out. But basically the reason is that all that is necessary to do so is to register your schema with JBossXB - if you do the schema resolver deployer bit, at best it's a useless deployer laying around.

                        That said - I've looked at KernelDeploymentDeployer and it has brought me no closer to understanding how to make the container use my BeanMetaData. The class doesn't even have any non-static members. :-)

                        • 9. Re: SchemaResolverDeployer is parsing but not deploying
                          David Lloyd Master

                          Wait... wait... omg, I just figured it out!

                          A KernelDeployment is the Java representation of a "deployment" element, just as a BeanMetaData is the Java representation of a "bean" element!

                          l feel like a genius and a moron at the same time. Laugh if you want to.

                          • 10. Re: SchemaResolverDeployer is parsing but not deploying
                            David Lloyd Master

                            Wow, that totally changes my perspective (again). I think what I really want to do is to just provide a way to specify the various I/O beans, because that's all my (incorrectly-named) "deployments" really are for the most part. So I guess what I need to do is to figure out a way to "merge" in my metadata with the regular BeanMetaData - should just be a question of some JAXB research I hope...

                            • 11. Re: SchemaResolverDeployer is parsing but not deploying
                              Ales Justin Master

                               

                              "david.lloyd@jboss.com" wrote:
                              I think what I really want to do is to just provide a way to specify the various I/O beans, because that's all my (incorrectly-named) "deployments" really are for the most part. So I guess what I need to do is to figure out a way to "merge" in my metadata with the regular BeanMetaData - should just be a question of some JAXB research I hope...

                              You already done that. ;-)

                              e.g. you now have
                              <dml:deployment>
                               <dml:io someattrib="foobar" />
                               <dml:remote otherattrib="barfoo" />
                              </dml:deployment>
                              


                              And you can simply do this
                              <mc:deployment>
                               <dml:deployment>
                               <dml:io someattrib="foobar" />
                               <dml:remote otherattrib="barfoo" />
                               </dml:deployment>
                              </mc:deployment>
                              


                              But I would still leave your deployer.
                              And I would now add some generic deployer that takes custom metadata which implements BeanMetaDataFactory and turns it into component beans
                              public class CustomMD2BMD<T extends BeanMetaDataFactory> extends SomeHandyHelperDeployer
                              {
                               public CustomMD2BMD(Class<T> metadata)
                               {
                               super(metadata);
                               }
                              
                               public void deploy(DeploymentUnit unit, T deployment)
                               {
                               List<BMD> beans = deployment.getBeans();
                               for(BMD bean : beans)
                               putBMDtoComponent(bean);
                               }
                              
                               ...
                              }
                              


                              And then adding such deployer would be 1line of xml/code:
                              <bean name="DML2BMD" class="CustomMD2BMD">
                               <constructor><parameter>io.DeploymentMetaData</parameter></constructor>
                              </bean>
                              

                              Or/and I might even do similar shortcut xml element (as I did with SRD).

                              Simple enough now? ;-)

                              • 12. Re: SchemaResolverDeployer is parsing but not deploying
                                David Lloyd Master

                                Well I can say for sure that there definitely ought to be a shortcut deployer for BeanMetaDataFactory deployment. That said, I'm not sure I want my deployments to look like that. Just seems kinda weird/unintuitive from the user perspective.

                                Now I'm thinking something more like this:

                                <bean:deployment
                                 xmlns:bean="urn:jboss:bean-deployer:2.0"
                                 xmlns:io="urn:jboss:io:1.0">
                                 <bean:bean ..../>
                                 <io:tcp-server> ... </io:tcp-server>
                                 <io:tcp-connection> ... </io:tcp-connection>
                                 ...etc...
                                </bean:deployment>
                                


                                In other words I think it would be nice to let the user specify an I/O bean anywhere they'd specify a regular bean.

                                I'm about 95% sure I can get my tags to work inside a "bean:deployment" tag. But I'm maybe about 60% confident that I can get my bean tags to work in other places where a bean deployer "bean" tag can go.


                                • 13. Re: SchemaResolverDeployer is parsing but not deploying
                                  Ales Justin Master

                                   

                                  "david.lloyd@jboss.com" wrote:

                                  <bean:deployment
                                   xmlns:bean="urn:jboss:bean-deployer:2.0"
                                   xmlns:io="urn:jboss:io:1.0">
                                   <bean:bean ..../>
                                   <io:tcp-server> ... </io:tcp-server>
                                   <io:tcp-connection> ... </io:tcp-connection>
                                   ...etc...
                                  </bean:deployment>
                                  


                                  In other words I think it would be nice to let the user specify an I/O bean anywhere they'd specify a regular bean.

                                  Then each of the corresponding metadata classes (tcp-server --> metadata class, tcp-connection --> metadata class, ...) must implement BeanMetaDatafactory.
                                  Which isn't hard to achieve.
                                  And your top level dlm:deployment can just take all of them, call getBeans on each of them, add those beans to top list, and you have your custom xml functional as well (+ the new deployer that I'm just about to write).

                                  "david.lloyd@jboss.com" wrote:

                                  I'm about 95% sure I can get my tags to work inside a "bean:deployment" tag. But I'm maybe about 60% confident that I can get my bean tags to work in other places where a bean deployer "bean" tag can go.

                                  These % are confusing me. :-)

                                  • 14. Re: SchemaResolverDeployer is parsing but not deploying
                                    David Lloyd Master

                                    What about dependencies - if I go this route, is there an automatic way to prevent any beans containing I/O tags from being deployed before the I/O bindings are registered with JAXB?

                                    1 2 Previous Next