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

        Having to create deployment plans sounds very webspherish and completely anti lean and mean where JBoss once stood for. External data sources may appeal to the big corporations, but forcing them is a slap in the face to those who helped the grassroots jboss get big.

        • 16. Data sources in EAR on AS7?
          jason.greene

          John Waterwood wrote:

           

          Having to create deployment plans sounds very webspherish and completely anti lean and mean where JBoss once stood for. External data sources may appeal to the big corporations, but forcing them is a slap in the face to those who helped the grassroots jboss get big.

          Good thing it's not.

          • 17. Data sources in EAR on AS7?
            jason.greene

            henk de boer wrote:

             

            Jason Greene wrote:

             

            It all depends on what jdbc Resource class you point the annotation/xml too. If you point it to a driver XADatasource you get XA, to a PooledDataSource you get connection pooling.

             

            Okay, I had some problems with this in JBoss AS 6, but I'll try again in AS7. Nevertheless, this does mean my DB driver (or other external code) needs to implement the pooling (PooledDataSource). Using this mechanism I won't automatically get the connection pooling provided by JBoss AS, will I?

             

            Also, David Lloyd hinted that a 'regular' (jboss) datasource definition inside an EAR might still be supported (without the ability of an administrator to control it). Can anyone comment on that?

             

            No plans as of yet. If someone can provide a good use case why the general EE stuff can't be used then we can do it. Not very likely for 7.0 though unless someone wants to contribute. It would certainly be unmanaged.

            .

            • 18. Data sources in EAR on AS7?
              jason.greene

              henk de boer wrote:

               

              Jesper Pedersen wrote:

               

              Why not try to use Alexey's CLI tool (jboss-admin.sh) to create the deployment plan that you are looking for - if there are any missing features we are always looking for feedback.

               

              One use case that I forgot to mention (sorry for making the post even longer), is the local development situation. Currently in our setup developers simply clone a project from the Hg repository and via JBoss tools they deploy it to JBoss AS. This almost can't be simpler

              So you never change a single server setting, like performance impacting web connector pool sizes etc (note that these can't be deployed)?

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

                Well, a web connector pool is in its nature a singleton shared ressource. Hence, there is no need to make it deployable. Datasources might be shared between applications too, but thats not the only case. As JMS resources - which as I understand are deployable for that reason - datasources are often used in "application scope" only. Therefore it makes perfect sense to provide (e.g. maintain) a way to deploy them along with your application - together with your JMS-Destinations and preferably cache configurations too.

                • 20. Data sources in EAR on AS7?
                  henk53

                  Jason Greene wrote:

                   

                  henk de boer wrote:

                   

                  Currently in our setup developers simply clone a project from the Hg repository and via JBoss tools they deploy it to JBoss AS. This almost can't be simpler

                  So you never change a single server setting, like performance impacting web connector pool sizes etc (note that these can't be deployed)?

                   

                  Well, certainly this would not often be needed for development on a local workstation, would it? Many projects I worked on, developers indeed deployed to a stock JBoss AS, or to a JBoss AS with only the ROOT.war removed. Why should it be any more complicated than that?

                   

                  For other projects, a JBoss AS was slimmed down and then archived again. This same archive was then used for all stages. I have not yet had to change the web connector pool size, or any of the container thread pool sizes. If that would be needed, I'm fairly sure this would again be done once and the same archive with those changes would be used throughout all stages.

                   

                  Of course I respect that such an approach would not suit every deployment out there, but this is the entire point I'm trying to make. There are various different usage scenarios out there. Some companies mandate that deployment happens to an absolutely stock application server, as-if it was say a JDK where you also don't change internal files. Others do slight modifications and use the same modified instance throughout all stages, while yet others consider the JDK as the deployment platform and ship a *heavily* modified JBoss AS with an EAR embedded inside it as the deployment unit.

                   

                  And yes, I know that there's also the scenario where an EAR is shipped with unresolved resource dependencies, and where the deployer has to resolve these when deploying it to a JBoss AS instance that may or may not be otherwise tuned. I'm sure this is a very reasonable strategy for some, but just not for all.

                   

                   

                  If someone can provide a good use case why the general EE stuff can't be used then we can do it.

                   

                  Some posts above I put a considerate amount of effort in describing the use case. Here I would just like to add that simply a lot of people use this feature. Removing it will make it unreasonably hard for us that use it to upgrade to JBoss AS 7.

                  • 21. Data sources in EAR on AS7?
                    superdev

                    I fully agree with Henk,

                     

                    In my group, we use staging for differenct phases or location of our deployment. We have different DS, JMS configuration for development, beta and test mode, in addtion, our group is relatively small but station in diferent part of the world, we have an central database server, but everyone has a local minimal database which is more efficient to do everyday work, in this situation, we have "central" and "local" mode. We maitain these definition files in EAR, We just need to launch Jboss with the staging parameter for different purpose,  It's one of the fancinating part we feel about deploymen in JBoss AS. So I hope JBoss AS 7 can support it as well. 

                    • 22. Data sources in EAR on AS7?
                      atijms

                      Jason, thanks for the replies. I'm still curious for answers to my earlier questions: is the reason for wanting to remove this feature technical and does it only concern data sources or also JMS queues, mail configs, etc?

                      • 23. Data sources in EAR on AS7?
                        jason.greene

                        arjan tijms wrote:

                         

                        Jason, thanks for the replies. I'm still curious for answers to my earlier questions: is the reason for wanting to remove this feature technical and does it only concern data sources or also JMS queues, mail configs, etc?

                         

                        Yes one of the big complaints we had with AS was that it was difficult to know what the actual server configuration was because it was spread out across many different files, some in deployments some not. Also those files intermixed system internals, wiring, and actual config. So a key design principal for 7 was to unify configuration in a consistent manner in one central place. You know exactly what resources are in use, what all the things you can tune are, and what you can lock down because you have one place to look. Also another requirement was that anything you can configure you can manage remotely via scripting languages, java clients, and a CLI. Deployment driven resources contradict all of this. So that's why we didn't plan on supporting them much beyond what the spec requires.

                         

                        To answer your second question, yes this applies to jms queues, and any other globally manageable resource as well.

                         

                        We certainly aren't against adding support for unmanaged deployed resources as a development-time feature. This is how we see the EE DataSourceDefinition support we already have being used. Since that can already be used for datasources, adding deployable JCA datasources isn't a high priority, so likely won't make 7.0. This could of course change if someone wants to help contribute a decent implementation.

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

                          Jason Greene wrote:

                           

                          You know exactly what resources are in use, what all the things you can tune are, and what you can lock down because you have one place to look.

                           

                          I see your point now. Thanks for the detailed explanation Jason. I really appreciate this.

                           

                          There is certainly value to have one place to look for configuration. We now often have to look in /conf, /deploy/ and /deployers/somedir, so uniting this to one location will certainly be for the better.

                           

                          With respect to resources in deployments, you perhaps might not always want to consider those pure configuration. Take the JMS queue example from above. Is this really configuration at the server level? Or is it a datastructure the application internally defines?

                           

                          Is a declaration like:

                           

                          <queue name="aQueue">
                             <entry name="/queue/aQueue" />
                          </queue>
                          

                           

                           

                          really conceptually much different from:

                           

                          public class Something {
                          
                              public static myQueue Queue<String> = new ConcurrentLinkedQueue<String>();
                          
                          }
                          

                           

                          ? (given that aQueue is purely an internal queue for the application and doesn't need any kind of external management)

                           

                          In a certain way this discussion is perhaps not entirely unlike annotations vs XML deployment descriptors. XML puts everything in once place, but annotations make it more clear to what something applies. There are two camps with each of them valid arguments. The Java EE spec decided to support them both, which is great I think.

                           

                           

                          this applies to jms queues, and any other globally manageable resource as well.

                          Does this also imply that any kind of mbean (-services.xml) and POJO (-jboss-beans.xml) can not longer be defined in an EAR?

                           

                          Over the years I've seen countless applications doing exactly that. I guess some of those usages could be replaced by @Startup @Singleton beans, but if all of this indeed also needed to be rewritten, the cost of upgrading to AS7 may be exceptionally high.

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

                            Hi Jason,

                             

                            I understand the need for a clear configuration layout and a centralized configuration file is clearly an advantage, but I'm quite shocked about the rigidness of the implementation. Why not give developers the alternative to choose what fits best for them? Erasing any alternatives or options has a significant impact on the whole deployment process.

                             

                            While now (using JBoss 5) Datasources and JMS-Destinations can ship predefined by the developers and packed within the application. There are no server alterations required. If server alterations such as memory, pools sizes, messaging configuration etc. are recommended, they can be done once and in advance of any deployment.

                             

                            After the server is installed, we distribute the application as an EAR and a script to replace the minimal set of configuration placeholder (basically the datasource connection). At the customer side the EAR is run through the script and deployed just by copying it into the deploy directory. Some customers deploy this EAR even multiple times (each with its own datasources, queues, caches etc). They don't need any knowledge of the internals (Topics, Queues, Datasource Names etc.) and they do not need to modify the server configuration again.

                             

                            If we migrate to JBoss 7, the process will become much more complicated. We will have to provide detailed instructions of all the internally required ressources and how to name and configure them properly. Yet, these customers are not experts, they are only interested in our software to run - some do not know much more than how to start a JBoss with a deployed EAR! If they do anything wrong, maybe just a mispelled queue, then the server wont start and they have to get back to us.

                             

                            To prevent this, we would have to come up with additional scipts which have to start editing all the same configuration file or provide completely new customized installation tools. That's certainly a huge amount of work for a much more complicated and error-prone workflow.

                             

                            You said

                            Also another requirement was that anything you can configure you can manage remotely via scripting languages, java clients, and a CLI. Deployment driven resources contradict all of this.

                             

                            Why? What is the difference between a java client managing resources and a deployer using a configuration file? I don't see any. Why eliminate a perfectly convinient solution instead of just providing an alternative? If the centralized configuration is better in all cases, developers will migrate to this anyway, but in cases where it's not you will cause your users serious headaches...

                            • 26. Data sources in EAR on AS7?
                              dmlloyd

                              Sebastian Koske wrote:

                               

                              Hi Jason,

                               

                              I understand the need for a clear configuration layout and a centralized configuration file is clearly an advantage, but I'm quite shocked about the rigidness of the implementation. Why not give developers the alternative to choose what fits best for them? Erasing any alternatives or options has a significant impact on the whole deployment process.

                               

                              I think the important thing to note here is that we didn't actually "erase" anything.  The capability to support deployable data sources/JMS queues/etc. is something we would have to commit extra resources to implement - resources we do not presently have available.  This would be a great thing for some enthusiastic community members to take up however; that would change the picture dramatically.

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

                                Well, I used "erase" since this is an available feature in current versions, but do you see my point? It's about separation of concerns. People who install and maintain servers (and some of our customers have this even outsourced, so our application runs in a shared server along with other applications) are different from the people who design applications. Maintainers should not have to read pages of instructions filled with internal details for all of their deployed applications. They certainly do not want to modify the server anytime a new application or version must be deployed. They must have generic knowledge about pools sizes, memories, muticast etc., anything application specific is not their concern and should therefor, if ever possible, be provided within the deployment unit. I think if you already have a management API for java clients, building a deployer around it to add resources to a subsystem isn't that hard anymore (but I dont know the internals) and would be worth the work.

                                 

                                I really look forward to AS 7 and been playing around with it since the first alpha. But if deployables queues, datasources or jaas-application-policies are left out, it would change our picture damatically too...

                                 

                                Another aspect is modularity. Since we include queues, topics and datasources as .sar archives it is very simple to include or exclude them in a customer specific EAR (not all customer have all of our application modules). This way, every customer gets exactly the resources he needs - no customer specific instructions are needed. If an additional module is sold later, a new EAR is shipped and thats it. We build software for public transport and have hundreds of different customers - we certainly cannot write and maintain customer specific configuration instruction for all of them, so we notably depend on an as-simple-as-possible modularity approach regarding deployment and ressources.

                                • 28. Data sources in EAR on AS7?
                                  atijms

                                  What about taking an approach like Tomcat does with respect to embedded context.xml files in a WAR;

                                   

                                  When the EAR is deployed, have a meta deployer first scan the archive and copy any "service files" (-ds.xml, -hornetq-jms.xml, etc) encountered to the location expected by AS 7. Then proceed with the deployment as it normally would be done.

                                   

                                  If the meta deployer uses both META-INF and jboss-app.xml or a simular file to discover the embedded service files, then everything that worked on AS 6 and before should continue to work on AS 7.

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

                                    All the concepts can be implemented by http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/001836.html

                                     

                                    Let us know if you want to work on it.