Menu
▾
▴
hibernate-devel
|
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-15 14:52:39
|
> I have a first shot at a JBoss MBean to set up Hibernate. Thanks for this. I will have a go at installing JBoss and getting this working sometime in the next few days. Now as for this issue of the MBean needing classpath to the persistent classes, am I right in assuming that no management calls to the MBean would ever be able to see the application classpath? If so, is a possible solution to create a new implentation of the SessionFactory interface that creates a datastore and builds a SessionFactory when first invoked by the application ... and then forwards requests to the actual SessionFactory implementation? Gavin |
|
From: Urberg, J. <ju...@ve...> - 2002-07-15 16:19:40
|
>> Now as for this issue of the MBean needing classpath to the persistent classes, am I right in assuming that no management calls to the MBean would ever be able to see the application classpath? << I believe that is the case. My (limited) understanding is that anything in an EJB jar gets its own class path and class loader seperate from the rest of the server and other EJBs. >> If so, is a possible solution to create a new implentation of the SessionFactory interface that creates a datastore and builds a SessionFactory when first invoked by the application ... and then forwards requests to the actual SessionFactory implementation? << Only if everything is in one big EJB jar file. If they are split between seperate EJB jar files, then there is still a problem. If one was to put mappings in seperate files for each class (like the eg/Foo.hbm.xml and eg/Bar.hbm.xml example in the docs), you could wait to load the mapping for a class until the class was first accessed. That might fix the problem. |
|
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-16 00:34:34
|
>Only if everything is in one big EJB jar file. If they are split between >seperate EJB jar files, then there is still a problem. > >If one was to put mappings in seperate files for each class (like the >eg/Foo.hbm.xml and eg/Bar.hbm.xml example in the docs), you could wait to >load the mapping for a class until the class was first accessed. That >might fix the problem. Remember that Hibernate will let you have multiple instances of SessionFactory. It would seem sensible to have a different SessionFactory for each EJB jar. So, drawing up a little requirements list, we need a JMX interface to Hibernate that lets us: 1. manipulate all properties dynamically at runtime 2. configure multiple SessionFactory instances with specified mappings 3. start and stop the Hibernate "service" (ie. register and deregister the SessionFactories in JNDI) 4. actually build the SessionFactory when it is first used issues: 1. might require some modification to how certain properties are currently managed by Hibernate (the system-level properties). 4. will require some kind of trickery with a delegating class since the javax.naming.event package has no objectLookedUp() event. Now, is the best way to support multiple SessionFactories to allow multiple instances of the MBean, or should a single MBean manage all the factories? Can anyone think of any other issues/requirements? P.S. I would like this MBean to be generic - useable by other JMX applications apart from JBoss. (I think it is, anyway.) John, may I add your class to a new package cirrus.hibernate.jmx in CVS? |
|
From: Urberg, J. <ju...@ve...> - 2002-07-16 15:12:55
|
>> Now, is the best way to support multiple SessionFactories to allow multiple instances of the MBean, or should a single MBean manage all the factories? << 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. >> Can anyone think of any other issues/requirements? << 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. Another cool feature (though probably app server specific) would be the ability to include the mapping with the EJB jar file. >> 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. >> John, may I add your class to a new package cirrus.hibernate.jmx in CVS?<< Yes. |
|
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...) |
|
From: Urberg, J. <ju...@ve...> - 2002-07-17 12:52:24
|
>> > How about reloading the mappings every time the mapping file changes?...< What would be involved in this? ie. how would we know the mapping file changed, assuming we load it using getResourceAsStream()? << I think you'd have to get the file's timestamp and then poll it at regular intervals to see if it changed. I wanted to do that with the Hibernate MBean I created but didn't have the time. >> That is the recommended way to deploy mappings, as far as I'm concerned. So we would definately allow this. << Hmm. I've been assuming the use of one big mapping file. I supposed if you put each class mapping in a seperate file, that would take care of it. It would also make the part about checking for the mapping file changing more difficult. >>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).<< How would the service get started in non-JBoss containers? Regards, John Urberg |
|
From: Jon L. <jon...@xe...> - 2002-07-17 14:47:38
|
> > How would the service get started in non-JBoss containers? > Like JBoss, our self written application server uses JMX for all pluggable services (Thread Pools, Connection Pools, etc...). In the case of our application server we have an XML configuration file that lists all MBeans to startup at runtime, and we are able to define the startup / shutdown methods that get called after the MBeans are registered. After looking at the example that was created to wrap Hibernate as an MBean for JBoss, it would only take a few seconds to get it started up in our container. Jon... |
|
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-17 15:07:28
|
>I think you'd have to get the file's timestamp and then poll it at regular >intervals to see if it changed. I wanted to do that with the Hibernate >MBean I created but didn't have the time. Hmmmm....not totally convinced on this. Don't like the whole concept of polling the hard drive actually. I *can* be convined though.... >> That is the recommended way to deploy mappings, as far as I'm concerned. So we would definately allow this. << >Hmm. I've been assuming the use of one big mapping file. I supposed if you >put each class mapping in a seperate file, that would take care of it. It >would also make the part about checking for the mapping file changing more >difficult. I really like the idea of having little mapping files living in the same directory/jar as the class they map. I should more strongly recommend this in the documentation. Monolithic mapping files are much less elegant. >>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).<< >How would the service get started in non-JBoss containers? I hadn't quite made up my mind on that yet. From a JMX client possibly. Though that would require user-interaction.... P.S. I realised my mistake above. Your *implementation* class actually inherits some JBoss-specific stuff. Ima have to track down that code to see what it does. Anyway, since JBoss is the only appserver that really supports JMX, I'm thinking mainly about non-application-server usage. It may turn out we need one MBean for JBoss and one for other JMX applications. Okay, let me get back to learning JMX, after I fix this damn bug in 1.0.1 :( |
|
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-18 03:38:54
|
Okay, a long quote from the JBoss manual below tells me just about
everything I need to know. You dont *have* to inherit any JBoss specific
interfaces, etc. Approach (1) of the 3 approaches listed gives you a way to
avoid this.
I propose the following MBean interface
package cirrus.hibernate.jmx;
public interface HibernateServiceMBean {
// the JNDI name
public String getName();
public void setName(String jndiName);
// bind / unbind the SessionFactory
public void start() throws Exception;
public void stop() throws Exception;
public boolean isStarted();
public boolean setStarted(boolean started) throws Exception;
public boolean getShowSQL();
public void setShowSQL(boolean showSQL);
// a comma-seperated list of properties
public void setProperties(String properties);
public String getProperties();
// a comma-seperated list of resources
public void setMapResources(String mapResourceList);
public String getMapResources();
// some attributes for extra-important properties
public String getDatasource();
public void setDatasource(String datasource);
public boolean getUseOuterJoin();
public void setUseOuterJoin(boolean uoj);
}
which is not very different from John's original one, except
it doesn't inherit org.jboss.util.ServiceMBean.
============================================================
Quote:
Writing JBoss MBean Services
----------------------------
Writing a custom service that integrates into the JBoss server requires the
use of the org.jboss.util.Service interface pattern if the custom service
is depdendent on other JBoss services. This means that you cannot perform
any JBoss service dependent intialization in any of the
javax.management.MBeanRegistration interface methods. Instead, you must do
this in the Service interface init and/or start methods. You need to do one
of the following:
(1) Add any of the Service methods that you want called on your MBean to
your MBean interface.
(2) Have your MBean interface extend the org.jboss.util.Service interface.
(3) Have your MBean interface extend the org.jboss.util.ServiceMBean
interface. This is a subinterface of org.jboss.util.Service that adds
String getName(), int getState(), and String getStateString() methods.
Which approach you choose depends on whether or not you want to be
associated with JBoss specific code. If you don't, then you would use the
first approach. If you don't mind, then the simplest approach is to have
your MBean interface extend from org.jboss.util.ServiceMBean and your MBean
implementation class extend from the abstract
org.jboss.util.ServiceMBeanSupport class. This class implements the
org.jboss.util.ServiceMBean interface except for the String getName()
method. ServiceMBeanSupport provides implementations of the init, start,
stop and destroy methods that integrate logging and JBoss service state
management. Each method delegates any subclass specific work to
initService, startService, stopService, and destroyService methods
respectively. When subclassing ServiceMBeanSupport you would override one
or more of the initService, startService, stopService, and destroyService
methods in addition to getName as required.
|
|
From: Urberg, J. <ju...@ve...> - 2002-07-18 14:54:30
|
>> I propose the following MBean interface...<< >>public void setProperties(String properties);<< Would this be properties that are normally placed in the hibernate.properties file? |
|
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-18 23:44:52
|
> >>public void setProperties(String properties);<< > >Would this be properties that are normally placed in the >hibernate.properties file? yes, exactly. this would let you list the properties as a comma-seperated list in the jcml file, and change them dynamically from a management client. Some of the properties are so important they warrant their own attribute on the MBean, but not *all* of them... |
|
From: Gavin_King/Cirrus%<CI...@ci...> - 2002-07-24 14:10:31
|
I have checked in a first-cut of the Hibernate MBean. It's loosely based on John's original code with most of the changes we discussed on the list. This is completely untested but since I havn't got JBoss installed just yet, if someone else wants to try it out and track down issues, they are very welcome ;) The cirrus.hibernate.jmx package contains the offending classes. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X