From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-17 01:40:53
|
>I would think it would be much simpler to have on per factory. In >the case of JBoss, the user could setup each factory with a seperate >MBean entry in the jboss.jcml file. agreed. thats what I was expecting you to say. >How about reloading the mappings every time the mapping file changes? >JBoss does something like this with EJB jars. If you copy an EJB jar >to the deploy directory it will automatically undeploy the EJB and then >deploy the new EJB. It would be cool not to have to bounce the server each >time a mapping changed. What would be involved in this? ie. how would we know the mapping file changed, assuming we load it using getResourceAsStream()? >Another cool feature (though probably app server specific) would be the >ability to include the mapping with the EJB jar file. That is the recommended way to deploy mappings, as far as I'm concerned. So we would definately allow this. >> P.S. I would like this MBean to be generic - useable by other JMX applications apart from JBoss. (I think it is, anyway.)<< >JBoss adds the idea of a service life cycle and introduces it's own >interface for that purpose. The bean I created depends on that interface >plus some other JBoss support stuff. JMX itself does not have a concept >of a life cycle or any ordering with the startup of different beans (such >as a JNDI service) which should make your attempt at a generic MBean >interesting. As far as I can tell the only JBoss-specific thing in your MBean is the startService() / stopService() methods from the inherited JBossServiceMBean interface. (Since JBoss has a compatible license, we should be able to just distribute that interface along with Hibernate.) Then, as far as any other JMX client is concerned startService() / stopService() are just any old management operations that could be invoked by the user (rather than by the container in the case of JBoss). (I am in the process of learning JMX, so let me know if I went wrong somewhere there...) |