Is Monitor a public API? Can it be hooked to JMX?

[Jeremy Boynes <jb...@apache.org>]

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.

I started digging around looking for a better way and see that the 
driver is really booting a set of services using the Monitor API. It 
looks like it would be possible to integrate this directly into Geronimo 
and have it control the server directly rather than through JDBC. The 
big concern I have is whether this is an API intended for external use?

Another reason for doing this is to try and integrate Derby services 
into the management framework Geronimo exposes. It looks like it would 
be possible to wrap some of the Derby services themselves in GBeans 
which would then transparently expose them to management (e.g. via JMX 
or Geronimo's console).

--
Jeremy

Re: Is Monitor a public API? Can it be hooked to JMX?

[Daniel John Debrunner <dj...@debrunners.com>]

-----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-----

Re: Is Monitor a public API? Can it be hooked to JMX?

[Jeremy Boynes <jb...@apache.org>]

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

Re: Is Monitor a public API? Can it be hooked to JMX?

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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.
>>
>> I started digging around looking for a better way and see that the
>> driver is really booting a set of services using the Monitor API. It
>> looks like it would be possible to integrate this directly into
>> Geronimo and have it control the server directly rather than through
>> JDBC. The big concern I have is whether this is an API intended for
>> external use?
>>
>> Another reason for doing this is to try and integrate Derby services
>> into the management framework Geronimo exposes. It looks like it would
>> be possible to wrap some of the Derby services themselves in GBeans
>> which would then transparently expose them to management (e.g. via JMX
>> or Geronimo's console).

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.

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.

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

iD8DBQFBqVpjIv0S4qsbfuQRAoBkAKCPM1pQsJVBoAu5hAi0F0I17woh7gCglpsQ
YjXLhe0KHivwGNwj8ku3fwE=
=Z4mQ
-----END PGP SIGNATURE-----

Re: Is Monitor a public API? Can it be hooked to JMX?

[Jeremy Boynes <jb...@apache.org>]

Any thoughts? Is this something I should pursue or would I be heading in 
the wrong direction?

--
Jeremy

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.
> 
> I started digging around looking for a better way and see that the 
> driver is really booting a set of services using the Monitor API. It 
> looks like it would be possible to integrate this directly into Geronimo 
> and have it control the server directly rather than through JDBC. The 
> big concern I have is whether this is an API intended for external use?
> 
> Another reason for doing this is to try and integrate Derby services 
> into the management framework Geronimo exposes. It looks like it would 
> be possible to wrap some of the Derby services themselves in GBeans 
> which would then transparently expose them to management (e.g. via JMX 
> or Geronimo's console).
> 
> -- 
> Jeremy