11 Replies Latest reply on Jul 2, 2012 11:58 AM by Justin Bertram

    data-source in web.xml suitable for production use?

    henk de boer Master

      I wonder if in JBoss AS 7.1 (or the comming EAP version) a data-source that's defined in web.xml (or ejb-jar.xml or application.xml) is theoretically suited for production use?

       

      Just as the Java EE 6 spec documents states, the corresponding @DataSourceDefinition is only recommended for development and testing purposed in this document: https://community.jboss.org/wiki/DataSourceConfigurationInAS7

       

      But what about the XML variants?

       

      The reason the spec seems to give for the annotation being a testing/development thing is having passwords in compiled code (although these can always be overriden in XML). The XML variant of @DataSourceDefinition however is not that much different from JBoss specific deployable datasource files (*-ds.xml).

        • 1. Re: data-source in web.xml suitable for production use?
          henk de boer Master

          After https://issues.jboss.org/browse/AS7-4552 , the difference seems to be even less or perhaps entirely non-existent. Can anyone from JBoss confirm this?

          • 2. Re: data-source in web.xml suitable for production use?
            Jesper Pedersen Master

            @DataSourceDefinition is basically a -ds.xml deployment behind the scenes. The development and testing part still holds true, since these resources doesn't integrate with our management model.

            • 3. Re: data-source in web.xml suitable for production use?
              henk de boer Master

              Jesper Pedersen wrote:

               

              @DataSourceDefinition is basically a -ds.xml deployment behind the scenes. The development and testing part still holds true, since these resources doesn't integrate with our management model.

               

              Any plans to make the development and testing part untrue then?

               

              Are -ds.xml deployments in AS 6 and before also considered development and testing only? Are -ds.xml deployments in AS 7 in some aspects worse than they were in AS 6?

               

              And maybe on a more personal note, but why are you seemingly so against Java EE archives with embedded resources?

              • 4. Re: data-source in web.xml suitable for production use?
                François Hertay Newbie

                I don't think this recommendation (not use embedded data source) is more operation best practice related than on technical ground.

                 

                The standard ask for container managed datasource accessible by name via JNDI to allow this data soruce to be fully customizable (with correct pooling and other management) via the application server management tools.  This way the app developer only have to use easy to use standard data source and having complete good practice datasource management ask by the standard.  (If you ask ops the production password to put it in your code, they should kill you on the spot...)

                • 5. Re: data-source in web.xml suitable for production use?
                  Justin Bertram Master

                  I don't mean to speak for Jesper, but I'll try my hand at answering your questions...

                   

                  Any plans to make the development and testing part untrue then?

                  I'm not aware of any plans ot change this.

                   

                  Are -ds.xml deployments in AS 6 and before also considered development and testing only?

                  No.  However, AS 7 has a fundamentally different management model and that is why we recommend against using the application-packaged resources.

                   

                  Are -ds.xml deployments in AS 7 in some aspects worse than they were in AS 6?

                  They are essentially the same as they were in AS 6 which is to say they don't fit into the AS 7 management model.

                   

                  And maybe on a more personal note, but why are you seemingly so against Java EE archives with embedded resources?

                  We generally recommend against using application-packaged resources like this because they don't fit into the AS 7 management model.

                   

                   

                  When I say that application-packaged resources don't fit into the AS 7 management model I mean that, for example, you cannot monitor a datasource or change any of its configuration (e.g. min pool size, max pool size, etc.) from the standard management tools (e.g. web console, CLI, HTTP API).

                  • 6. Re: data-source in web.xml suitable for production use?
                    henk de boer Master

                    Justin Bertram wrote:

                     

                    When I say that application-packaged resources don't fit into the AS 7 management model I mean that, for example, you cannot monitor a datasource or change any of its configuration (e.g. min pool size, max pool size, etc.) from the standard management tools (e.g. web console, CLI, HTTP API).

                     

                    I see, but this by itself may not be necessarily a pre-condition to qualify for "suitable for production". The way it was worded sounded more like there could probably be performance issues, like connections not being pooled, or transaction handling going through some dummy or less robust implementation. What you thus mean to say is that embedded resources lose the ability to be managed via several external tools, but are not in any way less dependable (less robust) or perform worse, right?

                     

                     

                    (If you ask ops the production password to put it in your code, they should kill you on the spot...)

                     

                    There is code (like the @DataSourceDefinition), and there are deployment descriptors (data-source in web.xml etc). Passwords can be encrypted (see https://community.jboss.org/wiki/EncryptingDataSourcePasswords).

                     

                    There are applications that run their own local database for some things, either fully embedded (Derby, H2) or external to the AS, but local on the server node and private to the application. There are situations where there isn't any ops or production.

                     

                    I my personal opinion (yours clearly differs), I find it rather narrow minded to place the usage of Java EE and data sources only in the situation of enterprises with operation teams that guard big production databases with shotguns that they actually use to kill people who don't conform to the letter of a strict process.

                     

                    Java EE apps can just as well be used to ship to individual persons where they run it on their desktop. Java EE "runtimes" are now small enough and startup more than fast enough to make this a very real scenario.

                     

                    Tell me, why would a non-existent ops team want to kill someone that accesses a private embedded database in their app with a default password (possible a blank) inside that same app in a deployment descriptor?

                    • 7. Re: data-source in web.xml suitable for production use?
                      Justin Bertram Master

                      I see, but this by itself may not be necessarily a pre-condition to qualify for "suitable for production".

                      I never said that -ds.xml wasn't necessarily "suitable for production."  I said, "We generally recommend against using application-packaged resources like this because they don't fit into the AS 7 management model," and then I clarified what specifically that means.  The documentation states pretty much the same thing:

                      This feature is primarily intended for development, and thus has a few limitations to be aware of. It can not be altered in any of the management interfaces (consle, CLI, etc). Only limited runtime information is available. Also, password vaults and security domains are not deployable, so these can not be bundled with a datasource deployment.

                       

                      The way it was worded sounded more like there could probably be performance issues, like connections not being pooled, or transaction handling going through some dummy or less robust implementation.

                      What do you mean by it?  What specifically was worded in such a way that it sounded like there could be these issues?

                       

                      What you thus mean to say is that embedded resources lose the ability to be managed via several external tools...

                      To be clear, I said that they don't fit into the AS 7 management model, and then I clarified that point by enumerating a few tools which exercise that model. 

                       

                      ...but are not in any way less dependable (less robust) or perform worse, right?

                      To my knowledge, datasources deployed via -ds.xml are no less dependable and they do not perform worse than those deployed via standalone*.xml.  I don't recall ever saying otherwise (or reading someone else saying otherwise).

                       

                      Passwords can be encrypted (see https://community.jboss.org/wiki/EncryptingDataSourcePasswords).

                      The documentation you linked doesn't specifically address datasource password encryption in AS 7.  There's even a comment of yours at the bottom asking for the AS 7 instructions.  This is the best reference I could find, although it doesn't cover the -ds.xml use-case.

                       

                      I my personal opinion (yours clearly differs), I find it rather narrow minded to place the usage of Java EE and data sources only in the situation of enterprises with operation teams that guard big production databases with shotguns that they actually use to kill people who don't conform to the letter of a strict process.

                       

                      Java EE apps can just as well be used to ship to individual persons where they run it on their desktop. Java EE "runtimes" are now small enough and startup more than fast enough to make this a very real scenario.

                       

                      Tell me, why would a non-existent ops team want to kill someone that accesses a private embedded database in their app with a default password (possible a blank) inside that same app in a deployment descriptor?

                      It seems to me that you're responding here to François, and not to me.  That said, the use-case you describe is perfectly valid in my opinion, and if you want to implement it with a -ds.xml that seems fine as well although I don't quite understand why it's any better than using standalone*.xml.

                       

                      To be fair to François, I don't think he had your use-case in mind when he made his comment.

                      1 of 1 people found this helpful
                      • 8. Re: data-source in web.xml suitable for production use?
                        henk de boer Master

                        Justin Bertram wrote:

                        The way it was worded sounded more like there could probably be performance issues, like connections not being pooled, or transaction handling going through some dummy or less robust implementation.

                        What do you mean by it?  What specifically was worded in such a way that it sounded like there could be these issues?

                         

                        With it I was actually referring to the remark made in the documentation, which is "(Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.)". As a reader, I wasn't entirely confident what it would mean if this management layer was bypassed. Afterall, we're often talking about a "container managed" data source, and about managed connections. It kind of gave the feeling (to me at least), that you would somehow end up with a data source not much different from you get by loading your own JDBC driver Java SE style.

                         

                        It's maybe not that far-fetched, Jason Green seemed to say this almost literally last year: https://community.jboss.org/message/599653#599653 Please correct me if I'm wrong, but to the best of my understanding a data source that's not handled by the JCA doesn't use connection pooling, does it?

                         

                        Things have changed since of course, but getting that confirmed was really the entire purpose of this post.

                         

                         

                        Justin Bertram wrote:

                         

                        To be clear, I said that they don't fit into the AS 7 management model, and then I clarified that point by enumerating a few tools which exercise that model.

                         

                        The enumeration itself was pretty clear indeed, I was just seeking some more confirmation since you did say "for example, you cannot monitor a datasource", which could be interpretted as that monitoring was just an example of the things you would miss out on.

                         

                         

                        Justin Bertram wrote:

                         

                        It seems to me that you're responding here to François, and not to me.  That said, the use-case you describe is perfectly valid in my opinion, and if you want to implement it with a -ds.xml that seems fine as well although I don't quite understand why it's any better than using standalone*.xml.

                         

                        To be fair to François, I don't think he had your use-case in mind when he made his comment.

                         

                        I know he didn't, which was the entire point of my reaction There are plenty of use-cases where Java EE 6 can be used. Some people seem to write off embedded data sources just because they only ever have seen Java EE being used for use-cases where those mentioned ops will indeed try to kill you if you'd use them.

                         

                        Using standalone*.xml is troublesome since a user then can't just run the war I give on an installed generic JBoss. It has to be shipped with a readme that says which changes need to be made in which file (or can a standalone*.xml fragment be embedded as well?).

                         

                        At any length, GlassFish, WebLogic, TomEE, Resin and a bunch of other application servers don't support standalone*.xml, so those instructions would not  be really useful to them, would they?

                        • 9. Re: data-source in web.xml suitable for production use?
                          François Hertay Newbie

                          I aware of that the fully container managed data source is base on enterprise scenario (I probably not made it clear on my post).  JEE is an "enterprise" specification, the recommendation should be taken base on this fact.

                           

                          Data source management hasn't been standardize at it is considered application server responsibility so vender specific.  The @DataSourceDefinition annotation has been added to have a standard way to specify a data source (if you want you package to easily been deploy on several application server, and use container pooled data source, it is the way to go).  The added dev/test limitation recommendation is for enterprise environment, not sure every one evolved want to push JEE to a less "Enterprise grade" market...

                          • 10. Re: data-source in web.xml suitable for production use?
                            henk de boer Master

                            François Hertay wrote:

                             

                            The @DataSourceDefinition annotation has been added to have a standard way to specify a data source (if you want you package to easily been deploy on several application server, and use container pooled data source, it is the way to go).  The added dev/test limitation recommendation is for enterprise environment, not sure every one evolved want to push JEE to a less "Enterprise grade" market...

                             

                            Maybe not, but having the restriction (=mandating data sources to be defined externally) removed is a good thing IMO. It's a bit like removing the interface requirement from EJB. Especially in large systems it's often better for each service to have an interface anyway, but not requiring one lowers the barrier to start using EJB and makes the code less verbose when it's really not needed.

                             

                            When time comes, an application can always remove its embedded data source and rely on the container provided one instead. The beauty of the system is that this should be rather transparent to the rest of the code. As such I don't think anyone should be against embedded data sources really.

                            • 11. Re: data-source in web.xml suitable for production use?
                              Justin Bertram Master

                              I understand your confusion better now since managed is ambiguous.  Managed can be used in an administrative context (e.g. related to the web console, CLI, etc.) and in the JCA context.  Datasources in standalone*.xml and in -ds.xml are both managed in the JCA sense which means (among other things) they are pooled, are automatically enlisted into JTA transactions as appropriate, and can be configured for automated connection validation.  However, a datasource in -ds.xml cannot be managed administratively like a datasource in standalone*.xml.

                               

                              As I understand it, @DatasourceDefinition was originally targetted for use in the web-profile, which doesn't contain JCA, and the first JBoss implementation of @DatasourceDefinition for AS7 was written without leveraging JCA.  My guess is that is why Jason said what he said on https://community.jboss.org/message/599653#599653.  However, the current implementation of @DatasourceDefinition for AS7 does leverage JCA so it is essentially the same as a datasource deployed via -ds.xml (just as Jesper indicated previously in this thread).  Keep in mind that using JCA behind the scenes is just an implementation detail.  You cannot count on that same behavior in other containers.  To be clear, if an implementation did not leverage JCA for @DatasourceDefinition then the datasource would almost certainly act just like one you got by loading your own JDBC driver Java SE style.

                               

                              I hope that helps.