db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Is Monitor a public API? Can it be hooked to JMX?
Date Sun, 28 Nov 2004 20:05:17 GMT
Daniel John Debrunner wrote:
> 
> 
>>>Jeremy Boynes wrote:
>>>
>>>
>>>>The way we have currently embedded Derby into Geronimo is a little
>>>>crude and relies on a GBean (Geronimo component) starting Derby by
>>>>instantiating an EmbeddedDriver.
>>>>
> 
> Well, the monitor was never intended as a public api. The public api is
> defined by classes included in the javadoc created by the 'publishedapi'
> target at the top level api.
> 
> I would be interested to see what you think is actually crude about the
> current Geronimo integration. Integration with other application servers
> such as tomcat or websphere typically use one of Derby's data source
> implementations and not the embedded driver.
> 

I'm integrating in two parts. We integrate at the MCF level much like 
the others - we wrap a Derby Driver or Datasource in a Connector and 
deploy that as a RAR. However, at this level the actual Derby server is 
invisible to Geronimo.

We also have a Derby System GBean that models the Derby server itself. 
This allows an admin to manage properties (such as the directory to use 
for derby.system.home) as GBean attributes in the same way as any other 
value for the server. When this GBean starts it boots the Derby server 
by connecting to a dummy database and when it shuts down it issues the 
shutdown by connection with shutdown set.

This also allows people to create dependencies on the Derby server so 
applications won't start until it is up and will shut down if it gets 
shut down.

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.

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.

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.

> The management aspect sounds good, but it seems like that is exposing
> management of Derby componenets through standard JMX interfaces, and
> doesn't require exposing internal interfaces.
> 

We can obviously do that through the definition of custom MBeans that 
interact with the server using SQL and system properties. I was hoping 
we could go deeper than that.

--
Jeremy

Mime
View raw message