12 Replies Latest reply on Jun 23, 2008 4:46 AM by Emanuel Muckenhuber

    @Service and @Consumer in metadata

    Alexey Loubyansky Master

      Issue JBMETA-20 Include JBoss extensions to EJB3

      I'd like to clarify how this should be represented in the metadata. The test looks wrong to me. It expects to find MyService and MyConsumer among the beans in EjbJar30MetaData. I'd think they should be added later at merge.

        • 1. Re: @Service and @Consumer in metadata
          Kabir Khan Master

          That might well be the case. I wrote the test quickly in Neuchatel as requested by Carlo, so feel free to replace it with something more appropriate. In any case @Service + @Consumer need to be represented in the metadata, but one of the EJB 3 guys will need to clarify where

          • 2. Re: @Service and @Consumer in metadata
            Scott Stark Master

             

            "alex.loubyansky@jboss.com" wrote:
            Issue JBMETA-20 Include JBoss extensions to EJB3

            I'd like to clarify how this should be represented in the metadata. The test looks wrong to me. It expects to find MyService and MyConsumer among the beans in EjbJar30MetaData. I'd think they should be added later at merge.

            They can't possibly be in the spec EjbJar30MetaData. They can only be in the JBossMetaData where the jboss specific xml and annotations would show up.


            • 3. Re: @Service and @Consumer in metadata
              Alexey Loubyansky Master

              What do you think about changing EjbJar30Creator to produce JBossMetaData instead of the EjbJar30MetaData, which would contain merged metadata obtained from the spec and jboss annotations?

              It seems to me, it would be better to process the spec and JBoss annotations at one go instead of doing it in two steps and then merge.

              • 4. Re: @Service and @Consumer in metadata
                Andrew Rubinger Master

                 

                "alex.loubyansky@jboss.com" wrote:
                What do you think about changing EjbJar30Creator to produce JBossMetaData instead of the EjbJar30MetaData


                From a naming perspective alone, this seems misleading.

                Do we have any ambitions towards using metadata to merge non-JBoss descriptors looking forward? If so, we'd need to keep the two-step process and add support for other vendors' implementations later. Food for thought before we centralize everything to gain minor some deployment-time improvements.

                S,
                ALR

                • 5. Re: @Service and @Consumer in metadata
                  Carlo de Wolf Master

                  It's not a naming issue.

                  It might be interesting to have a deployer chain for other vendor descriptors, but that is not something we would/could support.

                  An alternative for @Consumer and @Service is having a JBoss5Creator and then leave it up to the merge.

                  • 6. Re: @Service and @Consumer in metadata
                    Andrew Rubinger Master

                     

                    "wolfc" wrote:
                    It might be interesting to have a deployer chain for other vendor descriptors, but that is not something we would/could support.


                    OT: So we leave the door open for our growing community. :)

                    "wolfc" wrote:
                    An alternative for @Consumer and @Service is having a JBoss5Creator and then leave it up to the merge.


                    Yes, this is what I was getting at. Change the *name* of the class to JBoss5Creator.

                    • 7. Re: @Service and @Consumer in metadata
                      Alexey Loubyansky Master

                      Actually, I didn't think about optimization. In case of jboss.xml, every bean there can be identified by the ejb-name, other metadata components that need filling in some details can also be identified by their names. So, parsing jboss.xml alone we can get EJBs and then merge them with the spec ones.
                      In case of annotations, it's different in the sense that looking only at the jboss annotations we can't identify an EJB or any other metadata component. I.e. the JBoss5Creator would still need to look at the spec annotations. So, I thought why not combine the processing of both.

                      • 8. Re: @Service and @Consumer in metadata
                        Alexey Loubyansky Master

                        Once again, are there reasons not to process spec and jboss annotations at once? The JBoss5Creator would do it anyway.

                        • 9. Re: @Service and @Consumer in metadata
                          Alexey Loubyansky Master

                          I've trying to follow this idea and this is what I think the big picture should look like:
                          1) the spec and jboss deployment descriptors are parsed and merged into the JBossMetaData
                          2) the spec and jboss annotations are parsed and also merged into the JBossMetaData (this I still think should be done in one go since the source is the same unlike XML and to avoid duplicate parsing of the spec annotations)
                          3) merge the two instances of JBossMetaData obtained on the previous steps with the DDs as the override.

                          I already wrote JBoss50Creator which parses EJB3 annotations and produces JBossMetaData (not committed at the moment)

                          I am currently missing the step 3). So I am going to add another merge method for JBossXXXMetaData classes that will merge JBoss metadata.

                          Any other suggestions/ideas?

                          • 10. Re: @Service and @Consumer in metadata
                            Emanuel Muckenhuber Master

                            I have two questions regarding the @Service and @Consumer annotation:

                            1) a @Service annotated Bean inherits more or less the annotation processing as a @Stateless bean ?

                            2) the @Consumer annotation defines:

                            ActivationConfigProperty[] activationConfig()
                            


                            which is not represented by the JBossConsumerBeanMetaData nor defined in the jboss_5_0.xsd.
                            So should this be added to the metadata and the xml schema?

                            • 11. Re: @Service and @Consumer in metadata
                              Carlo de Wolf Master

                               

                              "emuckenhuber" wrote:
                              1) a @Service annotated Bean inherits more or less the annotation processing as a @Stateless bean ?

                              @Stateful with a single instance is a better analogy.
                              Where it not that in the future I want a SLSB to be able to expose a JMX view as well.
                              "emuckenhuber" wrote:
                              2) the @Consumer annotation defines:
                              ActivationConfigProperty[] activationConfig()
                              


                              which is not represented by the JBossConsumerBeanMetaData nor defined in the jboss_5_0.xsd.
                              So should this be added to the metadata and the xml schema?

                              Yes.

                              • 12. Re: @Service and @Consumer in metadata
                                Emanuel Muckenhuber Master

                                 

                                "wolfc" wrote:

                                "emuckenhuber" wrote:
                                2) the @Consumer annotation defines:
                                ActivationConfigProperty[] activationConfig()
                                


                                which is not represented by the JBossConsumerBeanMetaData nor defined in the jboss_5_0.xsd.
                                So should this be added to the metadata and the xml schema?

                                Yes.


                                So maybe JBossConsumerMetaData should extend JBossMessageDrivenBeanMetaData instead of JBossEnterpriseBeanMetaData?