Design-time JNDI Context Rearchitecture for NetBeans 6.0

linked from VWPDataSourceIntegration

Tracked by Tracked by issue 93216

Review Page

This functional spec is based on the topic of discussion "Implementing the design-time JNDI context" documented in VWPDataSourceIntegration At design time VWP needs to render the components in the visual editor. A component will hold a VW datasource name and will attempt to do a JNDI lookup for that name in order to retrieve a DataSource instance and get a connection from that. It is necessary to implement this design-time JNDI name delegating either to the project the component is used in or to all open projects.


When user adds a JDBC Table from the expanded data source node to a component on the designer, the data source name from that data source node is used by the design time. A Designtime Naming Context implementation serves as the service data source name to the corresponding database connection information via the DatasourceManager. The DatasourceManager maintains the reference between the data source and connection which is persisted in the in the /context.xml. When a connection is requested for a given JNDI data source name, Designtime Naming Context obtains the JDBC connection via the DatasourceManager.

Database explorer includes both the JDBC driver node, where JDBC driver information can be added and removed and the Database Connection node, where database connection information can be added and removed. A Connection Manager maintains the connection information. It is possible to modify the structure of the table using the database connection node. Any number of data source JNDI name reference can be created from a single connection. So it is more versatile than the data source node. When a data source name is generated added to a page, there should be some saved data that maintains the link between data source name and the connection parameters. Since, the metadata is written to the project, the link between the data source name and the database connection parameter can be inferred from it

However, for Shortfin (VWP), we put a work around to minimize the work involved to do the above, by retaining most of the Creator side implementation in tact. This is what happens now

  • Database Explorer node introduced new Database Metadata Transferable, which has the table name and connection information
  • When designer received the transferable, a JNDI data source name is generated and added to the Java file
  • The connection information for the data source is locally saved in the <userdir>/context.xml, in a format understood by VWP DatasourceManager.
  • The JDBC driver corresponding to the connection is also saved in the <userdir>/jdbc-driver, that is understood by the DatasourceManager.
  • Using Server plugin API the JNDI data source name and connection information is also saved in the project as server specific meta-data.
  • When a data connection is requested by the designtime for a particular JNDI data source name, Design Time Naming Context creates the connection is from the saved connection information, via the Datasource Manager.

Proposed changes for the Visual Web module of NetBeans 6.0 ( in no particular order )

  1. Do away with serializing the context in a file and instead maintain a cache of contexts (one per project) or model
  2. Remove current implementation of DatasourceInfoManager
  3. DatasourceTransferManager will use a facility that will use a new NetBeans API to obtain the data source name from existing projects instead of using DatasourceInfoManager
  4. Remove current implementation of DatasourceInfo
  5. Replace binding implementation of DesignTimeDataSourceHelper to bind new data source(s) to each project context
  6. ProjectDatasourceManager to be modified to obtain a connection information from the project config file
  7. The implementation of method, addJdbcDriver of the static inner class, DatasourceBeanCreateInfoSet will instead obtain the JDBC driver info from the project information. This will eliminate the need for the jdbc-drivers folder in the userdir
  8. RowSetBeanCreateInfoSet will use the DesignTimeDatasource instead of DatasourceInfo
  9. DesignTimeDataSourceHelper will need to help collect data sources used from the project contexts instead of using the IDE context
  10. See DatasourceNaming - Data source name choice: when a new database table is dropped on a page, a new dialog will open showing a generated name (see the next item) that can be changed within this dialog
  11. See DatasourceNaming -Instead of generating a generic name for the data source, instead, generate a name based on the connection information, either parse the JDBC url or use some APIs from DBSchema to obtain catalog and vendor name. Still the name will be incremented for uniqueness
  12. See ResolveBrokenDataSourcesSpec - Database connection and/or JDBC driver used by a project is missing from the Services tab - notify the user by badging the Data source Reference node in the project. To determine that a connection is missing, possibly, listen in on the ConnectionManager and JDBCDriver manager and checking DatabaseConnection and JDBCDriver

Drilldown of the proposed changes

Context per project

When a project is created or opened, a context factory can be instantiated to create a context per project. Project APIs can obtain the current or "main" project. The project will be stored as part of the context. Each project will have its own context. The connection information is stored in each project. A design-time context will can retrieve the connection information from each project (multiple projects may be opened). There will be a project data source manager that determines reuse or creation of new data sources and binding each data source to each context.

Changes for DnD a new "fresh" database table on a page, component or outline

  • New class in dataconnectivity: Singleton DatasourceDesignTimeContext
  • constructor accepts a project object, using the "initialize-on-demand holder class idiom"
  • getContext(...) returns DatasourceDesignTimeContext
  • bind(...) will bind the data source object to JNDI using the context object.
  • lookup(...) looks up data source using JNDI through the project object (ProjectDataSourceManager gets the main project)

Sample code demonstrating "initialize-on-demand holder class idiom"

public class DesignTimeDatasourceContext {
    private static Project currentProj;
    /** Creates a new instance of DesignTimeDatasourceContext */
    private DesignTimeDatasourceContext(Project p) {
       currentProj = p;
    private static class DesignTimeDatasourceContextHolder {
        static final DesignTimeDatasourceContext dtDatasourceCtxt = new DesignTimeDatasourceContext(currentProj);
    public static void setDesignTimeDatasourceContext(Project p) {
        currentProj = p;
    public static DesignTimeDatasourceContext getDesignTimeDatasourceContext() {
        return DesignTimeDatasourceContextHolder.dtDatasourceCtxt;

  • DesignTimeTransfer uses project data source name, pass current project to DatasourceDesignTimeContext
  • DatasourceDesignTimeContextFactory
  • implements getInitialContext which creates a new DatasourceDesignTimeContext using the project object and environment
  • implements setInitialContextFactoryBuilder() to create the context factory; this is invoked at IDE startup by the DataConnectivityModuleInstaller
  • ProjectDataSourceManager changes:
  • add a HashMap property to store the DatasourceDesignTimeContexts used by all projects open in the IDE
  • when a project is opened, get the data sources used by the project (see Obtaining a Data source ) and check to see if data source can be reused (has the same connection properties) If the data source name is the same then delegate to the DatasourceNaming feature which will inform the user the data source is used and allow the user to give a new name for the data source.

Use cases (see also, DatasourceNaming)

1. User creates a new project then DnD a database table from a connection onto :

  • VWP page or Node in the Outline or a component

Desired result:
dialog opens with an textfield containing a generated data source name. User has the option to rename the data source OR
information dialog opens indicating the name of the data source and how to rename the data source

2. User opens a project that contains a data source

Desired result:
bindings retained if the database connection is alive

3. User creates, opens, closes multiple projects

  • create new project, myFirstNewProject, DnD a database table, new data source generated
  • create new project, mySecondNewProject then open myFirstNewProject that contains a data source
    Result: no conflicting project data source
  • with both myFirstNewProject and mySecondNewProject opened, DnD a database table to mySecondNewProject
    Result:no conflicting project data source
  • close, myFirstNewProject then create a new project, myThirdNewProject and DnD the same table as used in myFirstNewProject
  • close myThirdProject then deploy mySecondNewProject. Create new project, myFourthNewProject then DnD a table used by mySecondNewProject.
    Result: the data source name will be used for the data source name in myFourthNewProject

4. Migrating projects or if required database connection hasn't been implemented - covered in ResolveBrokenDataSourcesSpec


Issues to resolve

  1. Creating a Data source - issue 88871 needs some discussion
     when there's a conflict in the data source name (when the data source in the project points to a different JNDI name then the data source with the same name on the server) then we generate a new data source name. The description in the  VWPDataSourceIntegration document says to change the JNDI name, which I don't think is correct.
  1. How to inform the user of the Data source name generated and how to support naming or renaming - to be spec'd in DatasourceNaming
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo