This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 100716 - Allow clients to start Derby
Summary: Allow clients to start Derby
Status: NEW
Alias: None
Product: db
Classification: Unclassified
Component: Derby (show other bugs)
Version: 6.x
Hardware: PC All
: P3 blocker (vote)
Assignee: Libor Fischmeistr
Depends on:
Blocks: 108422
  Show dependency tree
Reported: 2007-04-12 00:44 UTC by John Baker
Modified: 2013-08-01 12:52 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description John Baker 2007-04-12 00:44:42 UTC
From DerbyDatabases, I'm proposing to add a start() method (see below)
to allow clients to start Derby .  This helps visualweb, since, at IDE startup,
when projects (that have components bound to Derby rowsets) are opened and Derby
is not running, as a result pages open with errors.  

Allowing visualweb APIs to invoke a start method can help with this issue.
There is a bug reported in visualweb and adding this start() method can
alleviate this limitation.

// in DerbyDatabases, a class that resides in a public package

     * Allow clients to start Derby server
    public void start() {
Comment 1 Andrei Badea 2007-04-12 14:11:20 UTC
VW modules should use ConnectionManager.showConnectionDialog() to make the
connection. This method will start the Derby server when connecting a Derby
connection. Is this possible?
Comment 2 John Baker 2007-04-12 18:28:55 UTC
When the IDE starts, Derby is not running.
Also as the IDE starts,  project(s) may also be opening (visualweb maintains a
cache of previous projects opened)

Before the IDE completely opens, a visualweb page from the project may contain
components that are bound to Derby rowsets.  Then, in this case, there is an
attempt to connect to Derby.  

It's not really a good practice to post a dialog when the IDE is starting and
even if the dialog isn't posted until the IDE has opened, I don't want to post
the dialog as the first action.  

I think the best solution is to add the start() method to DerbyDatabases
Comment 3 Andrei Badea 2007-04-12 20:33:38 UTC
Re. posting the dialog: if the connection passed to CM.showConnectionDialog()
has the user name and password stored, it will only display a modal progress
dialog. OTOH if the user name or password are not available, you're not able to
connect to the database anyway without asking the user, are you? And if the
modal progress dialog is a problem, we might turn it into a non-modal progress
bar in the status bar. 

By the way, currently connection passwords are not stored between sessions. How
do you currently handle this? Do you just use java.sql.Connection and store the
passwords separately?

When exactly during the startup do you need to connect to the database? I.e.,
when exactly do the data-bound components need to connect to the database? It
seems to me you need to ensure you don't connect to the database before the main
window is opened. Do you currently?

The start() method can be of course introduced, db/derby is a friend API so it
can be changed as needed. But it seems to me it's really not the right solution
and it only leads to the visual web component doing database stuff in its own
way. If it is to be introduced, I would like to see some discussion first.
Comment 4 John Baker 2007-04-13 08:00:36 UTC
visualweb design (not database) decision to allow components to bind when a page
is opened.  Binding to JSF expression language, to application data or to live
database connections is from the original design of Creator.

Current design for dataconnectivity is limited in that binding requires a live
database connection.   This is a problem if the user is developing on a standalone
machine.  For a future release, it would be nice to cache the metadata in the
project or userdir so a live connection would not be necessary.
There may be an issue filed for this, if not, then I'll file one.

In the meantime, we're limited to relying on a connection to a live database 

I'll try tomorrow to see if username and password can be passed to the
connection dialog.  At least for visualweb, the password is cached in the
project now.
Comment 5 John Baker 2007-04-16 08:22:18 UTC
Appears if a password is known then the ShowConnectionDialog still posts the
ConnectionPanel (with user and password fields) and not a progress dialog

  DatabaseConnection realConn = DatabaseConnection.create(jdbcDriver,
dbConn.getDatabaseURL(), username,  username.toUpperCase(), password,  true);

Executing this code, I confirmed that the password is set in "realConn"

Unless I'm missing something, the progress dialog does not get posted
Comment 6 Andrei Badea 2007-04-16 15:23:57 UTC
The following code:

        JDBCDriver driver = null;
        try {
            driver = JDBCDriver.create("oracle", "Oracle",
"oracle.jdbc.driver.OracleDriver", new URL[] {new
        } catch (MalformedURLException ex) {
        DatabaseConnection dbconn = null;
        try {
            dbconn = DatabaseConnection.create(driver, "some_oracle_URL",
"system", "SYSTEM", "vsds", true);
        } catch (DatabaseException ex) {

works for me. Did you by any change restart the IDE before calling

By the way, it seems there is code to connect a connection which "knows" its
password without displaying a modal progress dialog. There is not API for it,
but the API change should be very simple.
Comment 7 John Baker 2007-07-19 04:09:01 UTC
I thought that you said that ConnectionManager.getDefault().showConnectionDialog(appConn);
would open a dialog presuming the password was set to remember password

If not, then I'd like to know what code you're referring to
Comment 8 Andrei Badea 2007-07-20 10:40:52 UTC
I said it would *not* open the username/password dialog, just a model progress dialog, and that it can be modified not
to display even that progress dialog.
Comment 9 Jiri Prox 2007-09-17 20:16:21 UTC
Obsolete milestone, please reevaluate
Comment 10 Jiri Rechtacek 2009-10-16 14:00:53 UTC
Reassigned to new owner.