6 Replies Latest reply on Feb 1, 2007 11:08 AM by Bill Burke

    MC/Seam integration and unification

    Bill Burke Master

      I've been looking at Seam a little bit to integrate the new Embedded JBoss stuff and had some thoughts about further unifying Seam with the rest of the JBoss 5 architecture.

      1) Create a Seam deployer. Hopefully, for JBoss AS Seam deployments, you can avoid extra bootstrap configuration and simplify things for users. Also, hopefully, we can have a unified bootstrap process in which Embedded JBoss bootstraps Seam in non-JBoss-AS environments. This would be something easy to do and we could see where it takes us.

      2) unified configuration. Instead of your own XML schema, use a Bean bean based configuration to get rid of the proliferation of configuration file formats.


      3) I've been looking at the Seam component model and wondering if there should be some unification with MC and Seam. In looking at your component model "components.xml" I see that components need:

      * rich IoC (lists, maps, references to other components, etc...) all that the MC provides

      * dependency management (component doesn't get deployed unless its dependencies are resolved). Again something that MC does as well.

      * The ability to reference other components, beans, services and have those dependencies resolved before instantiation/starting

      What I don't see in MC is:
      * Context aware scopes. Ability to deploy a bean (seam component) and only have it instantiated as part of a scope. We're discussing this here:

      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100349

      * class dependencies (don't deploy a component unless its class is available. We're discussing this here:

      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100385

      * precedence levels. We're discussing this here:

      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100384


      I don't know what the best unification of MC/Seam should be, but I do know that Seam needs to leverage the MC/Kernel more so that you don't have to do *everything* and can delegate things to other JBoss projects. Many other projects (ESB, JBPM) need similar features for their domains. The end goal would be that all JEMS products/projects are unified in how they are configured, bootstrapped, and deployed so that users have a consistent way of doing things across JBoss projects.

        • 1. Re: MC/Seam integration and unification
          Bill Burke Master

          I think at least 1) could be done intially. To do the rest has MC/Kernel dependencies.

          BTW, there are other advantages to getting this stuff under the MC/Kernel umbrella in that we'll be able to snap on the management and hotdeployment optimizations that Scott/Adrian are adding in JBoss 5.

          • 2. Re: MC/Seam integration and unification
            Gavin King Master

            1) I'm really not sure if there is enough value of this, it just makes things more complex by providing *yet another* deployment option to support and test, and one that is much less portable than the others. Deployment is already way too complex for users, and this does not make it simpler, AFAICT.

            2) Definitely won't work. The component models are totally different.

            3) Again, I don't see much synergy here.

            * rich IoC - components.xml already has lists, maps, references, and its easier to use than MC
            * dependency mgmt as you are describing is not useful for us, I don't think ... for us, "dependency" is more a way to avoid ClassCastExceptions ;-)

            I long ago investigated basing this stuff on MC, but it turned out to not be doable. Two totally different problems, even if they look superficially similar. Same reason Seam isn't based on Spring or Pico or anything else.

            What we might want to do, however, is provide an MC integration layer (similar to the integration layer we are doing from Spring), where an MC component can be a Seam component at the same time. I have not thought this through, however.

            • 3. Re: MC/Seam integration and unification
              Gavin King Master

              I know that 1) can be done easily enough. Trouble is that it makes Seam more difficult to learn and to support.

              Regarding management, it is not useful for application components, I don't think.

              Regarding hotdeploy, I may be wrong I don't see how that can ever work for the *individual Seam components*. However, larger units such as EJB jars and WARs should support hotdeploy, but that does not really require changes to Seam.

              • 4. Re: MC/Seam integration and unification
                Bill Burke Master

                 

                I know that 1) can be done easily enough. Trouble is that it makes Seam more difficult to learn and to support.


                Really, how so? Package format would remain the same as it currently is, except bootstrap and config of bootstrap is the same as embedded jboss, jboss. Again, the end goal being that all our projects/products are configured, deployed, bootstrapped and installed the same way or as similar as possible.

                Regarding hotdeploy, I may be wrong I don't see how that can ever work for the *individual Seam components*. However, larger units such as EJB jars and WARs should support hotdeploy, but that does not really require changes to Seam.


                I highly doubt there won't be configuration requirements...

                I looked at your code and what you're doing deployment wise is *exactly* the same as what the kernel does except it is solely specific to Seam, minus the flexility. MC/kernel gives an abstraction for deployment so that things like management can be snapped on later.

                Deployment has changed radically in JBoss 5. In the old kernel, there was a one to one relationship between deployer and archive. In JBoss 5 kernel, each deployer has a chance to look at and process each archive.

                Some of the things Scott is architecting into the ProfileService will allow deployers to serialize/most of their metadata so that the next time the app server is booted up (or the WAR redeployed) deployment is a lot faster as you can skip the metadata phase and just focus on binding. Not only that, but a lot of thought has been put into how things could be configured through IDEs and such.






                • 5. Re: MC/Seam integration and unification
                  Gavin King Master

                   

                  Really, how so? Package format would remain the same as it currently is, except bootstrap and config of bootstrap is the same as embedded jboss, jboss.


                  If this Seam deployer could apply special deployment semantics to a standard Java EE 5 EAR, then great! In JBoss 4 this is not the case, special packaging and descriptors are required.

                  I looked at your code and what you're doing deployment wise is *exactly* the same as what the kernel does except it is solely specific to Seam, minus the flexility.


                  Our requirement in terms of deployment are pretty trivial and are handled by a very small amount of code which costs very little to maintain. Our requirements in terms of lifecycle management and context management are extremely nontrivial and can't be implemented on top of any other container that exists today.



                  • 6. Re: MC/Seam integration and unification
                    Bill Burke Master

                     

                    "gavin.king@jboss.com" wrote:
                    Really, how so? Package format would remain the same as it currently is, except bootstrap and config of bootstrap is the same as embedded jboss, jboss.


                    If this Seam deployer could apply special deployment semantics to a standard Java EE 5 EAR, then great! In JBoss 4 this is not the case, special packaging and descriptors are required.


                    Like I said before, in MC Kernel every deployer looks at every archive and decides if it needs to do any processing. You could add special Seam deployment semantics to any deployment unit you wanted. The Seam Deployer could even augment the metamodel of a WAR/EJB/EAR, for instance, to add seam filters automatically, or add a default EJB interceptor.

                    In the new architecture, best practices dictate that one logical deployer is at least broken up into 2 separate concrete ones: metadata processing and actual deployment. For instance, there is a single deployer for just parsing bean.xml and a separate deployer for actually taking the metadata and deploying the beans into the kernel.



                    I looked at your code and what you're doing deployment wise is *exactly* the same as what the kernel does except it is solely specific to Seam, minus the flexility.


                    Our requirement in terms of deployment are pretty trivial and are handled by a very small amount of code which costs very little to maintain.


                    That's understandable. But trivial things can start to add up. Also, if we start getting everybody following the same architecture it becomes much easier to integrate things.


                    Our requirements in terms of lifecycle management and context management are extremely nontrivial and can't be implemented on top of any other container that exists today.



                    The thing is, other JEMS projects/products have similar/exact requirements. Also, many JEMS projects want to be able to run in other environments other than app server and they are all writing their own configuration/deployment/bootstrapping models. Many JEMS projects also want to be able to leverage other different JEMS projects in non-JBoss-AS environments. For instance, what if we want to combine ESB/Seam/Drools/JBMessaging and run it in Websphere or WLS? That's 4 deployment models, 4 different types of configuration formats, 4 different ways to bootstrap. Yeah sure, the code to do all this stuff is "trivial", but it is a fucking headache for users.

                    The end goal of all of this should be a JEMS stack that can be run integrated a la carte in a multitude of different environments.