db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Is Monitor a public API? Can it be hooked to JMX?
Date Tue, 30 Nov 2004 18:18:05 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Boynes wrote:

> The crude bit is needing to make connections to the server to start it
> up or shut it down. This could be replaced with calls to the Monitor
> interface in a manner similar to what JDBCBoot.boot() does. This would
> also allow us to make properties like derby.service.jdbc manageable.

Why not use the JDBC driver to start the server, then you don't need the
connection to a dummy database? The JDBC driver and DataSource
implementations can be used interchangeably.

> Going further, the configuration of Derby itself is defined by
> modules.properties. The intention appears to be to allow people to
> create different configurations of the server for different applications
> (much like Cloudscape used to). For Geronimo there is a lot of stuff in
> there that is not needed - for example, we are mandated by J2EE to use a
> 1.4 JVM so when Derby is embedded inside we would not need any of the
> configurations that support older versions.

Well, the JDK 1.4 implementation of Derby requires about 99.99% of
derby,jar, so it's not really that Geronimo is burdened by a lot of
unused stuff.

> As an example of tighter integration, I can see us coupling Derby to the
> application server's authorization mechanisms. We have a Subject
> associated with any user Thread and have a SecurityManager in place to
> support JACC so I think it would be useful to allow Derby to use that
> identity and policy enforcement during SQL execution. To do that we
> would lower level integration than that supported by UserAuthenticator.

I think this is really saying that Derby should be supporting JAAC
(JACC?) in some way, rather than the monitor api should be exposed.

I agree closer integration would be good, but exposing internal api's
that are not standard removes flexibility in modifying those interfaces
in the future. AT this point I can't see any clear benefit to Derby or
Geronimo in exposing the monitor interface, since Derby already has
api's to start and stop itself.

Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBrLlcIv0S4qsbfuQRAlPfAKDFN7J+P7yelBBy765lECjhk2VmbQCgjrzV
mdYCO8vmSWCaa28SCojQGW4=
=DwWt
-----END PGP SIGNATURE-----


Mime
View raw message