From: <ste...@jb...> - 2005-08-03 02:41:36
|
I'll have a think through this "registration" bit for the admin console. Seems easy enough, though. For the deployer bit, here's what I have done so far (which I think is enough to remove the deployer...): 1) Added code similiar to what Adrian posted regarding grabbing the classloader and "scanning it" for mappings. One additional thing I want to look at here is possibly using the new getDeploymentInfo() method Scott mentions and using getDeploymentInfo().ucl instead of Thread.currentThread().getContextClassLoader() to drive that. Maybe unfounded, but I am worried about start() coming from a source that perhaps does not go through the ServiceController. 2) Based on the new getDeploymentInfo() method, I internalized all the logic that used to be in HARDeployer.accepts() into the Hibernate MBean startService() method. It uses that to attempt to determine a "HarUrl". 3) The MBean is now capable of operating in essentially two modes. The first mode kicks in if the deployment was determined to be a HAR (see #2). Otherwise, it uses the code discussed in #1 to scan the classpath looking for mappings. 4) added a new attribute "scanForMappingsEnabled" which is used in "har deployment mode" to enable the classpath scanning logic even in that mode (in addition to using the HarUrl as a mapping source). I think all this combined covers all the functionality we wanted to see here. Using "har deployment mode", users can continue to use .har archives (see below) to create "segmented" multi-SessionFactory deployments. Using "non-har deployment mode", users can simply include a service descriptor defining a Hibernate MBean that will then scan the deployment's classpath for mappings. All without the need for the HARDeployer. I still need to register ".har" as an accepted SARDeployer extension. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888075#3888075 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888075 |