14 Replies Latest reply on Nov 19, 2009 8:55 AM by nickarls

    Portable extensions and Alternatives

    swd847

      Is it possible for a portable extension to specify what alternatives get installed?


      An example use case, a portable extension that detects that the app is running on glassfish and installs all @Glassfish alternative beans?


        • 1. Re: Portable extensions and Alternatives
          swd847

          Oops, I was thinking of the old deployment types, where did all that stuff go? I'm not going to list all the beans in an xml file. What if I have 100 mock objects?

          • 2. Re: Portable extensions and Alternatives
            swd847

            Hmm, it looks like it would be possible to get something like deployment types back as a portable extension (by simply vetoing the beans that you don't want to install), which answers my original question.

            • 3. Re: Portable extensions and Alternatives
              gavin.king

              @Alternative @Stereotype is equivalent to the old deployment type stuff. See refdoc section 13.1.

              • 4. Re: Portable extensions and Alternatives
                swd847

                Ah, I was looking in the wrong section of the spec.

                • 5. Re: Portable extensions and Alternatives
                  nickarls

                  Now that JNDI namespaces are standardized, it would be nice to have an extension that would flip alternatives based on JNDI data so that you could drop the same application into different appservers (with same JNDI key, different data) and it would auto-configure.

                  • 6. Re: Portable extensions and Alternatives
                    swd847

                    As far as I can tell there is no way for a portable extension to change what alternatives are deployed, is that correct Gavin?


                    It can just veto any beans it does not want installed, which amounts to the same thing really.

                    • 7. Re: Portable extensions and Alternatives
                      nickarls

                      Perhaps one could nuke the list of URLs to bean.xml and replace them with a custom one(?)

                      • 8. Re: Portable extensions and Alternatives
                        gavin.king

                        That is correct. If people really have a usecase for this, it would be an easy enough thing to add. We're already planning on adding a Module and ProcessModule to the SPI.

                        • 9. Re: Portable extensions and Alternatives
                          swd847

                          A few uses cases


                          - Automatically install correct framework components depending on the application server. e.g. if seam 3 is going to support @Transactional(REQUIRES_NEW) then the websphere code for this is going to be totally different to the general case, it would be neat if this could just happen automatically.


                          - Allow for more understandable end user configuration, e.g. from a properties file:


                          
                          someFeatureEnabled=true
                          useSomeOtherFeature=false
                          
                          



                          - Allow for configuration from JNDI or system properties.


                          If this was allowed it makes it much easier to create an app that can just be dropped in without having to open up the archive and change beans.xml.

                          • 10. Re: Portable extensions and Alternatives
                            gavin.king

                            I don't really see how layering this stuff over the @Alternative mechanism helps you very much here. Why not just put if ( .. ) { ... } in the code of your portable extension?

                            • 11. Re: Portable extensions and Alternatives
                              swd847

                              I just though that it would be nice to have another way to configure this stuff other than an XML file. Having the ability to enable or disable beans based on system properties or other things can be a lot easier to manage than editing an XML file inside an archive.


                              e.g. if you have 10 different sites that need different configurations you need to maintain 10 different versions of beans.xml (well probably not because you could use token replacement or something like that, but it is still more difficult to manage).

                              • 12. Re: Portable extensions and Alternatives
                                asookazian

                                Stuart Douglas wrote on Nov 19, 2009 00:16:


                                I just though that it would be nice to have another way to configure this stuff other than an XML file. Having the ability to enable or disable beans based on system properties or other things can be a lot easier to manage than editing an XML file inside an archive.

                                e.g. if you have 10 different sites that need different configurations you need to maintain 10 different versions of beans.xml (well probably not because you could use token replacement or something like that, but it is still more difficult to manage).


                                Agree.  I'm not down with this possible multiple beans.xml per EAR hard requirement (one per WAR, one per EAR, one per JAR).

                                • 13. Re: Portable extensions and Alternatives
                                  nickarls

                                  Well, BeanDeployment.parseBeansXml() gets all the beans.xml:s from the deployment archive and processes these. If I have an extension that adds a bean.xml from JNDI (and that file only contains an alternative stereotype), isn't this sort of autoconfiguring? Hmmm, can I get to the deployment archivies from an extension during bootstrap, gotta check.

                                  • 14. Re: Portable extensions and Alternatives
                                    nickarls

                                    Apparently they get tossed around with the BeforeBeanDiscovery-event