db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Another newbie internals question
Date Wed, 23 Jan 2008 00:22:36 GMT
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 

Hope this helps,

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

View raw message