Community
Participate
Working Groups
In 0.7, the deployment process does not create a context.xml (a file used by Tomcat to register database connection resources, etc) because it is not necessary (the EDT Java runtime looks up connection parameters from the deployed DD). The current solution (while nice and easy for developers) bypasses capabilities like connection pooling provided by the application server. Developers should not have to create this file, since the DD contains all the necessary information (or can be made to include all the necessary information). Note: this enhancement is dependent on JNDI support (bug 361030).
I think a context.xml should be created/populated when there is a Resource Binding that is explicitly setup to use
Created attachment 208975 [details] Design document v0.1 Here is a design draft for this enhancement, please review it. Thanks a lot.
Bug 361030 covers the overall design for JNDI support. This work item will be just for the actual deployment work. Two tasks: 1. A resource-ref entry must be added/updated in web.xml if the target project is a Web project, when one of the following is true: a) The binding in the model is using a URI that starts with "jndi://" - The JNDI name for the entry will come from this URI. Everything past "jndi://" is the JNDI name. b) The binding in the model has a parameter "deployAsJNDI" with the value "true", and the target project's runtime is Tomcat. - The JNDI name for the entry will come from a parameter on the binding in the model. The parameter name is "jndiName". 2. If the binding in the model has a parameter "deployAsJNDI" with the value "true", context.xml should be created/updated. The binding in the model will have two parameters that tell you what to use in the context.xml entry: "jndiName" - the JNDI name of the data source "dataSourceClassName" - the class to specify as the data source class in the entry. When creating the context.xml entry, values for the other attributes (like username and password) will either come from the workspace connection (the model will be using the workspace:// URI format which tells you the connection profile name to look up) or will be hard coded in the model. If the "deployAsJNDI" option is enabled, and the target project is not a Web project (or does not have Tomcat as its target runtime) then a warning should be issued in the deployment results indicating that the data source was not defined and JNDI will not be used for the resource binding. Please note: whenever looking at URIs in the model, make sure that the "useURI" attribute is "true", otherwise the hard-coded information should be used.
Until the UI work is done (I will open a separate bugzilla), you can hand-edit the .egldd file. The model itself is not changing so this will not break the editor. You won't be able to test this until bug 368366 is finished.
Hi Yun Feng, I'm taking over this one since you're out this week. A change to the design will be there is no 'dataSourceClassName' parameter. There is no standard among data source implementations and each has their own set of parameters. Tomcat by default uses its own BasicDataSource class which supports connection pooling, so we'll configure context.xml to specify the parameters that BasicDataSource expects (url, username, driverClassName, etc). If the user goes out of their way to change the data source class in context.xml, they will also have to update the parameters specified for it (e.g. DB2DataSource has no 'url' or 'driverClassName' parameter, and it has 'user' instead of 'username', to note just a couple of the *many* differences).
Hi Justin, I'm back, if there is anything uncompleted, let me know. Thanks a lot.
Done. A change to the design in comment 3 is there is no dataSourceClassName property.
close
