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
