1 2 3 4 Previous Next 53 Replies Latest reply on Sep 20, 2012 1:24 PM by thohawk Go to original post
      • 30. Data sources in EAR on AS7?
        atijms

        It sounds like an option. Thanks for the reference.

         

        The way I now understand it, it's a separate archive type (.cli?) that embeds the EAR and contains deployment instructions, right?

         

        If that's so, what about turning the concept of a "cli archive" a little around and have an EAR that embeds those CLI commands? That way it would be a lot easier to integrate this with existing deployment tools like e.g. Eclipse/WTP (including JBoss tools).

        • 31. Data sources in EAR on AS7?
          jesper.pedersen

          No, an .ear is an .ear as defined by EE 6.

           

          In the script you will setup the needed resources like datasources, JMS queues and topics, EJB pool sizes and so on through the standard management interface. Everything that is exposed by the management API you have access to.

           

          Tooling is a minor problem, since it is a "standard" JAR archive format.

           

          So

          1. Check management API -- through the CLI if you want
          2. Design the .cli container
          3. Implement it
          4. Submit patch

           

          We hang out on #jboss-as7 on FreeNode if there are any questions.

          • 32. Data sources in EAR on AS7?
            sebastian.koske

            This sound like something I would expect a .sar archive to contain.

            • 33. Data sources in EAR on AS7?
              atijms

              Jesper Pedersen wrote:

               

              No, an .ear is an .ear as defined by EE 6.

               

              In the script you will setup the needed resources like datasources, JMS queues and topics, EJB pool sizes and so on through the standard management interface. Everything that is exposed by the management API you have access to.

               

              That could indeed be interesting yes, and would give archives a lot more options than we have today.

               

               

              Tooling is a minor problem, since it is a "standard" JAR archive format.

               

              This is the part I have some doubts about. In Eclipse you would e.g. check out a project from a repository, go to your Servers view, add the project to a server and start it. The WTP server adaptor will then assemble the ear and deploy it. Changes to individual files will be hot deployed.

               

              It's this workflow that I found to be important to a lot of developers and that I'm trying to preserve.

               

              If the EAR would contain the instructions, this would be trivial to support (not only in Eclipse, but other IDEs as well). Specifically for Eclipse it might be an option to talk with the JBoss tools guys to see how open they are about optionally assembling such a .cli archive instead of a .ear.

              • 34. Re: Data sources in EAR on AS7?
                jesper.pedersen

                You are missing the point of the archive.

                 

                The archive will contain your entire setup including dependencies on resources and other artifacts - it is much more than a standard .ear:

                 

                myapp.cli:
                  - startup.scr
                  - shutdown.scr
                  - int1.rar
                  - int2.rar
                  - services.sar
                  - myapp.ear
                  - admin.war
                

                 

                The archive will install the needed resources (datasources, JMS queues, ...), then the two .rar files which etablish connections to external EIS' (maybe the script even changes the config of those too), then the .sar, then the .ear and finally the .war.

                 

                shutdown.scr makes sure that everything is done in the reverse order on undeploy.

                 

                And yes, I agree that JBoss Tools should support building / deploying such an archive.

                • 35. Data sources in EAR on AS7?
                  sebastian.koske

                  Ok, I see your point. Then there should also be a suitable maven packaging.

                  • 36. Data sources in EAR on AS7?
                    jesper.pedersen

                    Yes, this needs to support everything from a developer who wants to setup his/her datasource, deploy the .ear, and run the test suite within 10 sec to a massive deployment in a production environment.

                     

                    Download AS 7, play with it, send us feedback; once the basic building blocks are there the work can begin -- well, it could start already today

                    • 37. Data sources in EAR on AS7?
                      henk53

                      Jesper Pedersen wrote:

                       

                      No, an .ear is an .ear as defined by EE 6.

                       

                      The new proposed archive certainly sounds like a compromise that could possibly work, at least for deployment to production servers.

                       

                      I do wonder why you think an .ear with an embedded data source is not an .ear as defined by Java EE 6. Isn't the META-INF folder in an .ear allowed or actually intended to contain files concerning meta issues (e.g. deployment)?

                      • 38. Re: Data sources in EAR on AS7?
                        jesper.pedersen

                        The new proposed archive certainly sounds like a compromise that could possibly work, at least for deployment to production servers.

                         

                        It isn't a compromise - all deployments should go through the management layer.

                        I do wonder why you think an .ear with an embedded data source is not an .ear as defined by Java EE 6. Isn't the META-INF folder in an .ear allowed or actually intended to contain files concerning meta issues (e.g. deployment)?

                         

                        The -ds.xml and friends isn't part of the standard. If you want a datasource in your deployment use the EE 6 @DataSourceDefinition - but it won't be backed by a JCA container.

                         

                        I think we have discussed this enough; there is a breakdown of the overall idea for the correct solution. Once somebody has a design - maybe even a proof-of-concept implementation - open a new thread.

                        • 39. Re: Data sources in EAR on AS7?
                          will.tatam

                          So far the discussions seam to mostly relate to a single application, our need is a little more advanced

                           

                          We deploy many different self contained versions or our application to the same application server. This is required as it would be a waste of resources to use a single instance of jboss for each appication.

                           

                          We have both production systems, QA systems and of course dev systems.

                           

                          Our application's EAR contains the configuration for the JMS resources needed for each app (multiple topics and queues per instance of the app)

                           

                          We also have a standalone -ds.xml file for each ear so our systems administrators can point these apps to the right databases

                           

                          The "global" configuration introduced in AS7 works fine in the case where you only have a single application in any given jboss instance as it can be pre-configured by the system admins and then the app deployed. It does not work so well when you wish to hot-deploy a new application to the server and wish to migrate apps between application servers.

                           

                          It also currently requires that system admins know more about the "internals" of the application as they now need to build the JMS resources, rather than let the developers deal with these. So this now requires that system administrators need to re-config the application server for a specific version of our app for example if the latest version adds a new JMS queue

                           

                          It would be possible for system admins to login to the web and configure the database connections prior to deploying an app, but that feels like going backwards in term of flexibility and currently there is no similar method to define JMS resources, so it's impossible to hot deploy new apps in AS7 that require JMS due to the lack of web admin for this aspect

                          • 40. Re: Data sources in EAR on AS7?
                            henk53

                            Will Tatam wrote:

                             

                            We deploy many different self contained versions or our application to the same application server. This is required as it would be a waste of resources to use a single instance of jboss for each application.

                             

                            Although I sympathize with your situation and see it as 'proof' that there are many different use-cases in the wild for having such configuration inside an EAR, I would like to mention that typically a single instance of JBoss AS for each application version (production, qa, dev) is actually highly recommended.

                             

                            Unless you're a startup with extreme budgetary problems, I would not deploy a QA or DEV version on the same JBoss AS instance that runs the production version. I'm not sure how long you have running in this setup, but it's mostly a recipe for disaster. Even in the startups with the least amount of resources that I've seen, people were able to cobble together a €500 workstation and bless it as the 'server' to be used for QA.

                             

                            More typically, I've seen companies running one application per single JBoss AS instance per single (Linux) virtualized server. The overhead of this in relation to the current sizes of disks and memory isn't that much anymore.

                             

                            Our application's EAR contains the configuration for the JMS resources needed for each app (multiple topics and queues per instance of the app)

                             

                            Do note that even if the EAR contains the configuration for these resources, they are still deployed globally. You probably must know this already and I guess every version of the application uses (slightly) different names?

                             

                            I vaguely remember that there once was talk on the JBoss dev forum about having an option for resources like JMS destinations and datasources to be EAR scoped (so one EAR cannot see the resources of another EAR). I wonder what ever happened to this idea?

                             

                            The "global" configuration introduced in AS7 works fine in the case where you only have a single application in any given jboss instance as it can be pre-configured by the system admins and then the app deployed.

                             

                            In this case I would almost say that the deployable unit is not the EAR anymore, but JBoss AS itself with the EAR embedded inside it. The 'server' is then the plain JVM. Of course, Jesper's proposed CLI archive will change this for the better, but it doesn't yet exists.

                             

                             

                            It also currently requires that system admins know more about the "internals" of the application as they now need to build the JMS resources, rather than let the developers deal with these. So this now requires that system administrators need to re-config the application server for a specific version of our app for example if the latest version adds a new JMS queue

                             

                            Yes, that has been my argument for a long time.

                             

                            There is some school of thought that preaches EAR based applications should be deployed with unresolved dependencies, and that teams of system administrators having both intimate knowledge about the application server and about resources like JMS and Datasources are dedicated to wiring applications to the production environment.

                             

                            This school of thought is not wrong per se, but it's mostly applicable to *very* large enterprises. There's a huge section in between, where system administrators mostly have knowledge about Linux, firewalls, XEN installations, apt-get, DNS, routing etc etc, but where their knowledge about Java and JBoss typically does not extend much beyond using '/etc/init.d/jboss restart' to restart the server. In these cases, developers or devops people know about JMS destinations and are the ones who can judge whether a new JMS queue is allowed or not in the application etc.

                             

                            About that last thing, the "unresolved dependency"-approach typically seems to work the other way around. An application can not just add a new JMS queue. In this setup developers are often considered to be irresponsible cowboys who constantly endanger the stability of the production system, while the system administrator is the wise and knowledgeable 'defender' of said system. It's thus the system administrator who dictates what data sources are JMS queues are available and the developers just have to build the application around that.

                             

                            What I've seen in practice is that in such restricted environments developers then simply resort to shipping a different application server *inside* the EAR. In the majority of the cases this different application server is Spring.

                             

                            You probably do now want to know how many organizations run on Websphere (which strongly advocates the unresolved dependency approach) and decree that developers go to system administrators for resource definitions and upgrades of the server, but then base their EAR completely on Spring so that all Websphere functionality and 99% of the role of the system administrator is completely by-passed. It's scary and to be honest fairly depressing.

                            • 41. Re: Data sources in EAR on AS7?
                              sebastian.koske

                              Hi,

                               

                              as I wrote earlier, we face the same problems, but right now I'm working on a solution for us, where we will ship our EARs along with a CLI-Script. That way the admin will deploy the appication not by copying it into the server manually, but by executing the script (with some local modifications).

                               

                              This script will then create all datasources, queues, topics and security domains and so on and also deploy the archive into the running server. I think this will be acceptable and maybe also suitable for you?

                              • 42. Re: Data sources in EAR on AS7?
                                henk53

                                Sebastian Koske wrote:

                                 

                                This script will then create all datasources, queues, topics and security domains and so on and also deploy the archive into the running server. I think this will be acceptable and maybe also suitable for you?

                                 

                                Yes, such an approach will be acceptable for the deployment to our servers. Since we use the tool Fabric for deployment, we might even be able to copy the script out of the EAR and then run it programmatically to already achieve the affect Jesper intended with his .cli archives.

                                 

                                I'm thinking how to best support local development though. Currently our system is such that a developer simply has to checkout the EAR project in Eclipse, add it to the JBoss tools server runtime and he or she is good to go.

                                 

                                Letting the developer run the script once is painful, but doable. However, during development resources can be added, removed or renamed at any time and I'm not sure how to best handle that.

                                • 43. Re: Data sources in EAR on AS7?
                                  sebastian.koske

                                  Just thinking..

                                   

                                  maybe if the script itself would be considered as a deployable resource? Then you would just copy it under deployments together with the EAR. It should work with the Eclipse Tools... Maybe for security reasons cli deployments could be turned of in production as an option for the deployment scanner...

                                  • 44. Re: Data sources in EAR on AS7?
                                    will.tatam

                                    We do not mix platorms, a given AS instance will only be used for production, qa or dev

                                     

                                    The issue about resources is you don't want to run 30 seperate jvms, each with their own memory allocation to run a production and live copy of an application for different 15 clients in a SasS enviornment. This would be hidious micro managment

                                     

                                    The CLI approach works, but it fells like a work around. An enviroment should be able to support any ears i choose to deploy, you shouldn't have to change the server just because you have a new SaaS customer