1 2 3 4 Previous Next 49 Replies Latest reply on Sep 26, 2007 8:03 AM by wolfc Go to original post
      • 30. Re: Unifying metadata
        aloubyansky

         

        "adrian@jboss.org" wrote:
        "scott.stark@jboss.org" wrote:

        1. The existing ObjectModelFactoryDeployer based deployers producing legacy metadata need to be converted to SchemaResolverDeployer type deployers that produce the new metadata, and then create the legacy wrapper using the new metadata as the delegate. The JBossXBBuilder would be used to create the SchemaBinding for the new metadata.

        One little issue here is that the SchemaResolverDeployer does not have a SchemaBindingResolver getResolver() method to allow subclasses to easily extend the default resolver.


        This was something I asked Alex to look at.
        I'm not sure how much he has done?


        I haven't looked into the deployer issues above.

        • 31. Re: Unifying metadata

           

          "scott.stark@jboss.org" wrote:
          if we agree to merge


          Ok with me. The only reason it was a seperate project was that JBossXB/Common
          hadn't been updated to compile against JDK5 and retro when first I did it.

          • 32. Re: Unifying metadata
            wolfc

            App client 1.4/5 and JBoss client 5 are done. Will do JBoss client 1.4 tomorrow.

            More issues: the model assumes that meta data from an override xml is mappable on top of the overriden xml. But these might be overrides for annotations. So either we removed that requirement (which may lead to EJB 2 issues) or we process annotations before allowing jboss override files.

            • 33. Re: Unifying metadata
              starksm64

              Another issue is the need to parse multiple documents into one object instance. This shows up in the org.jboss.test.xml.metadata.JBossEjbObjectFactoryUnitTestCase test where both the standardjboss.xml and jboss.xml need to go into the JBoss50MetaData override.

              I'm looking into how that can be handled.

              • 34. Re: Unifying metadata
                alesj

                 

                "scott.stark@jboss.org" wrote:
                Another issue is the need to parse multiple documents into one object instance. This shows up in the org.jboss.test.xml.metadata.JBossEjbObjectFactoryUnitTestCase test where both the standardjboss.xml and jboss.xml need to go into the JBoss50MetaData override.

                I'm looking into how that can be handled.


                I guess this is related:
                - http://jira.jboss.com/jira/browse/JBMICROCONT-184

                I can look at this first thing in the morning, and we can discuss it during the MC call?



                • 35. Re: Unifying metadata
                  starksm64

                   

                  "alesj" wrote:

                  I guess this is related:
                  - http://jira.jboss.com/jira/browse/JBMICROCONT-184

                  I can look at this first thing in the morning, and we can discuss it during the MC call?

                  Not quite as the problem is really one of ejb-jar.xml/standardjboss.xml/jboss.xml. The current unified metadata already handles the ejb-jar.xml/jboss.xml case, but not merging multiple jboss.xml documents into the same JBoss50MetaData instance.

                  I don't see how this can be added to the org.jboss.xb.builder.runtime.BeanHandler that creates the metadata instance.

                  The root org.jboss.ejb.metadata.jboss.JBossMetaData would have to add a mergeOverridenMetaData method that took the existing override and merged the second override into it.



                  • 36. Re: Unifying metadata
                    starksm64

                    A bigger problem is lack of support for dom Elements as is needed for the standardjboss.xml proxy-factory-config elements. The content of these depends on the invoker type:

                     <proxy-factory-config>
                     <client-interceptors>
                     <home>
                     <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
                     <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
                     <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
                     <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
                     <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
                     </home>
                     <bean>
                     <interceptor>org.jboss.proxy.ejb.EntityInterceptor</interceptor>
                     <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
                     <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
                     <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
                     <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
                     </bean>
                     <list-entity>
                     <interceptor>org.jboss.proxy.ejb.ListEntityInterceptor</interceptor>
                     <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
                     <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
                     <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor>
                     <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor>
                     </list-entity>
                     </client-interceptors>
                     </proxy-factory-config>
                    
                    ...
                    
                     <proxy-factory-config>
                     <JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
                     <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
                     <CreateJBossMQDestination>false</CreateJBossMQDestination>
                     <!-- WARN: Don't set this to zero until a bug in the pooled executor is fixed -->
                     <MinimumSize>1</MinimumSize>
                     <MaximumSize>15</MaximumSize>
                     <KeepAliveMillis>30000</KeepAliveMillis>
                     <MaxMessages>1</MaxMessages>
                     <MDBConfig>
                     <ReconnectIntervalSec>10</ReconnectIntervalSec>
                     <DLQConfig>
                     <DestinationQueue>queue/DLQ</DestinationQueue>
                     <MaxTimesRedelivered>10</MaxTimesRedelivered>
                     <TimeToLive>0</TimeToLive>
                     </DLQConfig>
                     </MDBConfig>
                     </proxy-factory-config>
                    
                    



                    • 37. Re: Unifying metadata
                      starksm64

                      I raised this http://jira.jboss.com/jira/browse/JBXB-109 issue which has a failing test.

                      • 38. Re: Unifying metadata
                        wolfc

                        I don't like all the merge logic in the binding classes. Can't we have a separate class hierarchy for that?

                        Then it would become: new MergedJBossMetaData(ejbJarMetaData, jbossMetaData);
                        And standardjboss.xml: new MergedJBossMetaData(standardJbossMetaData, new MergedJBossMetaData(ejbJarMetaData, jbossMetaData));

                        (it still needs some polishing)

                        And no more the need to ask for merged beans or stuff.

                        • 39. Re: Unifying metadata

                           

                          "scott.stark@jboss.org" wrote:

                          The root org.jboss.ejb.metadata.jboss.JBossMetaData would have to add a mergeOverridenMetaData method that took the existing override and merged the second override into it.


                          Why do you need to merge standardjboss.xml?

                          standardjboss.xml should just be parsed once into a JBossMetaData
                          and then it should just be a case of delegating.

                          If you merge standardjboss.xml into the JBossMetaData then you'll loose the
                          reversability. Let's not make the same mistakes as the old metadata did!

                          • 40. Re: Unifying metadata

                             

                            "scott.stark@jboss.org" wrote:
                            A bigger problem is lack of support for dom Elements as is needed for the standardjboss.xml proxy-factory-config elements. The content of these depends on the invoker type:


                            This works in the MC stuff, so its obviously not defined correctly in the annotations
                            for the ejb stuff.
                            It shouldn't be trying to construct a javabean for an array of xml Elements.

                            It shouldn't even be going through the base jbossxb bean code.

                            There are seperate interceptors/handlers that understand xml wildcards
                            (and their collections) in the builder project.

                            • 41. Re: Unifying metadata

                               

                              "wolfc" wrote:
                              I don't like all the merge logic in the binding classes. Can't we have a separate class hierarchy for that?

                              Then it would become: new MergedJBossMetaData(ejbJarMetaData, jbossMetaData);
                              And standardjboss.xml: new MergedJBossMetaData(standardJbossMetaData, new MergedJBossMetaData(ejbJarMetaData, jbossMetaData));

                              (it still needs some polishing)

                              And no more the need to ask for merged beans or stuff.


                              That's ok as long as you can get back to the original metadata.
                              If you can't ask for the original ejb-jar and jboss metadata and marshal them
                              back to the original xml then its no good.


                              • 42. Re: Unifying metadata

                                 

                                "adrian@jboss.org" wrote:

                                This works in the MC stuff, so its obviously not defined correctly in the annotations
                                for the ejb stuff.


                                This is how you define it generically
                                public class ListElementWildcard
                                {
                                 private List<Element> wildcard;
                                
                                 public List<Element> getWildcard()
                                 {
                                 return wildcard;
                                 }
                                
                                 @XmlAnyElement(lax=true)
                                 public void setWildcard(List<Element> wildcard)
                                 {
                                 this.wildcard = wildcard;
                                 }
                                


                                You can also make it recognise specific types, e.g. we could define
                                the known JMSContainerInvoker config, etc. by adding @XmlElements
                                and specific types but then you need to make
                                List<Object>

                                if you also want it to have raw Elements as well as real types.

                                The real problem is that it just isn't implemented
                                (at least in the version in the JBossXB project)
                                @XmlType(name="invoker-proxy-bindingType")
                                public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions
                                {
                                ...
                                
                                 /** The proxy factory config */
                                 // TODO DOM private Element proxyFactoryConfig;
                                


                                • 43. Re: Unifying metadata
                                  starksm64

                                   

                                  "adrian@jboss.org" wrote:

                                  Why do you need to merge standardjboss.xml?

                                  standardjboss.xml should just be parsed once into a JBossMetaData
                                  and then it should just be a case of delegating.

                                  If you merge standardjboss.xml into the JBossMetaData then you'll loose the
                                  reversability. Let's not make the same mistakes as the old metadata did!

                                  Ok, I'll look at that approach.


                                  • 44. Re: Unifying metadata
                                    starksm64

                                     

                                    "adrian@jboss.org" wrote:

                                    This is how you define it generically
                                    public class ListElementWildcard
                                    {
                                     private List<Element> wildcard;
                                    
                                     public List<Element> getWildcard()
                                     {
                                     return wildcard;
                                     }
                                    
                                     @XmlAnyElement(lax=true)
                                     public void setWildcard(List<Element> wildcard)
                                     {
                                     this.wildcard = wildcard;
                                     }
                                    


                                    You can also make it recognise specific types, e.g. we could define
                                    the known JMSContainerInvoker config, etc. by adding @XmlElements
                                    and specific types but then you need to make
                                    List<Object>

                                    if you also want it to have raw Elements as well as real types.

                                    The real problem is that it just isn't implemented
                                    (at least in the version in the JBossXB project)
                                    @XmlType(name="invoker-proxy-bindingType")
                                    public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions
                                    {
                                    ...
                                    
                                     /** The proxy factory config */
                                     // TODO DOM private Element proxyFactoryConfig;
                                    


                                    I had unquoted this section in the merged jbossxb project, and that is what produced the errors seen in the JBXB-109 issue. Even if I change this to:
                                    @XmlType(name="invoker-proxy-bindingType")
                                    public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions
                                    {
                                     /** The proxy factory config */
                                     private List<Element> proxyFactoryConfig;
                                    ...
                                    
                                     public List<Element> getProxyFactoryConfig()
                                     {
                                     return proxyFactoryConfig;
                                     }
                                    
                                     @XmlAnyElement(lax=true)
                                     public void setProxyFactoryConfig(List<Element> proxyFactoryConfig)
                                     {
                                     this.proxyFactoryConfig = proxyFactoryConfig;
                                     }
                                    }
                                    


                                    I'm seeing the same error, which is happening on an xml fragment that does not even have the proxy-factory-config element:

                                    Caused by: java.lang.ClassCastException: java.util.ArrayList
                                    at org.jboss.javaee.metadata.support.MappedAnnotationMetaData.add(MappedAnnotationMetaData.java:39)
                                    at org.jboss.xb.builder.runtime.CollectionPropertyHandler.handle(CollectionPropertyHandler.java:133)
                                    ... 40 more



                                    If you or Alexey can look into the JBXB-109 issue it would help.