Hi Frank,
You might be able to accomplish what you need by doing the following:
1) Bring up the server with user authentication turned on, with
derby.database.defaultConnectionMode set to noAccess, and with
derby.database.fullAccess set to be the name of your database owner.
This should lock out everyone except for the database owner.
2) Then connect as the database owner, create your database, and
initialize it with your functions, other schema objects, and data.
3) Then set derby.database.defaultConnectionMode to fullAccess and unset
derby.database.fullAccess. This should allow the other users in.
I say "might" because I haven't tried this experiment. These properties
along with authentication are discussed in the Derby Developer's Guide
in the sections titled "User authorizations" and "Working with user
authentication".
Hope this helps,
-Rick
Frank Griffin wrote:
I want to bring up a "captive" instance of Derby as a JDBC server. I
want to do this using a "front" class of my own, because I want to
customize the environment somewhat (set a few system properties, load
and launch a few custom classes, whatever).
This should all a simple thing, just wrapping the normal Derby
invocation class; here's the kicker: once Derby is initialized, I want
to initiate a JDBC session with it and submit a series of customizing
SQL statements (CREATE FUNCTIONs for Table Functions).
Modifying Derby code is OK for this, but I'd rather keep modifications
to a minimum. Is there a clean way to do this other than starting a
Thread which attempts JDBC connect() until Derby is ready ?
Basically, I need to hook into someplace in Derby once it is enabled for
JDBC in order to force-feed some commands before the real clients come
along, so that the TableFunctions I'm setting up will be available for
them. I don't really care if users are locked out before these things
are processed; I can live with telling people "just let it come up
fully", but of course it would be nice to ensure availability from the
get-go (of course, how you could open JDBC access without actually
opening JDBC access is a bit of a conundrum).
Any ideas or direction ?
Thanks,
Frank Griffin
