From: <ste...@jb...> - 2005-07-27 16:16:48
|
Follow-on question: Does this neccessarily need to happen from The Hibernate MBean's startService()? Specifically, the Thread.currentThread().getContextClassLoader() part... The MBean gives the user a managed operation to rebuild the SessionFactory; both this and the startService() go through an internal method named buildSessionFactory(). Would it be safe to have the Thread.currentThread().getContextClassLoader() call in that method, such that rebuilding the session factory could potentially "notice" added/removed domain classes? I guess this would depend upon whether subsequent calls into the MBean (aka, the rebuildSessionFactory() managed operation) would be executed on a thread which has the same "URL visibility" as the one from startService(); is this always the case (at least as long as the request is made through the JMX container)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886850#3886850 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886850 |
From: <ad...@jb...> - 2005-07-27 17:26:38
|
My understanding is that you only need the deployer to get the urls to search from the DeploymentInfo. If you use code like the AbstractWebContainer.getClassLoaderURLs() you don't need the deployment info. I'm not saying use the above method as is, which will give you ALL urls of all classloaders in the loader repository. Rather you just need the urls of the mbean's context classloader (the TCL during startService or whatever it invokes), i.e. the sar, ejb, ear, etc. urls from the deployment it is a part of. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886870#3886870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886870 |
From: <ad...@jb...> - 2005-07-27 17:28:03
|
I don't understand the added/removed domain classes stuff. JBoss does not currently support classloader dependencies or hot deployment of single classes inside a deployment (other than what the jvm provides for hotswap when debugging) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886873#3886873 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886873 |
From: <ste...@jb...> - 2005-07-27 17:46:43
|
what i mean is this; currently the .har format is: .har/ meta-inf/ hibernate-service.xml MyMapping.hbm.xml org/ myproject/ MyMapping.class ehcache.jar myotherjars.jar So, the .har itself is added to the deployment classloader. The HARDeployer, then marks any nested jars as deployable (mimicing the behavior of SARDeployer). However, what would be nice, and people have asked for, is to instead be able to do this: .har/ meta-inf/ hibernate-service.xml mydomainclassesandmappings.jar ehcache.jar myotherjars.jar such that mydomainclassesandmappings.jar contains the domain classes as well as their mappings. Then later, say I (assuming .har is exploded) drop in "myextendeddomainclassesandmappings.jar" which contains further domain classes and mappings. I understand JBoss will not handle this automatically in terms of forcing a redploy of the mbean/deployment. I am talking about the information available to me when the user does the above mentioned "drop" and then performs the "rebuildSessionFactory()" managed operation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886883#3886883 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886883 |
From: <ste...@jb...> - 2005-07-27 17:48:33
|
*** OK actually formatted :) *** what i mean is this; currently the .har format is: | .har/ | meta-inf/ | hibernate-service.xml | MyMapping.hbm.xml | org/ | myproject/ | MyMapping.class | ehcache.jar | myotherjars.jar | So, the .har itself is added to the deployment classloader. The HARDeployer, then marks any nested jars as deployable (mimicing the behavior of SARDeployer). However, what would be nice, and people have asked for, is to instead be able to do this: | .har/ | meta-inf/ | hibernate-service.xml | mydomainclassesandmappings.jar | ehcache.jar | myotherjars.jar | such that mydomainclassesandmappings.jar contains the domain classes as well as their mappings. Then later, say I (assuming .har is exploded) drop in "myextendeddomainclassesandmappings.jar" which contains further domain classes and mappings. I understand JBoss will not handle this automatically in terms of forcing a redploy of the mbean/deployment. I am talking about the information available to me when the user does the above mentioned "drop" and then performs the "rebuildSessionFactory()" managed operation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886885#3886885 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886885 |
From: <ste...@jb...> - 2005-07-27 17:55:40
|
"ad...@jb..." wrote : Rather you just need the urls of the mbean's context classloader | (the TCL during startService or whatever it invokes), | i.e. the sar, ejb, ear, etc. urls from the deployment it is a part of. Well, that's an important distinction ;) Yes, I am only interested in the URL pertaining to the deployment (as well as anything "under" it). What I am uncertain of is exactly how to get that information from inside the mbean. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886886#3886886 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886886 |
From: <ad...@jb...> - 2005-07-27 17:59:14
|
Yes, and what I'm saying is you could have | myejbs.jar/ | META-INF/ | ejb-jar.xml | mydomainclassesandmappings.jar | ehcache.jar | myotherjars.jar | hibernate-service.xml | When the MBean in hibernate-service.xml is deployed, it will ask the classloader for the urls in the TCL and get all four jar urls (the main jar and the embedded jars) as possibilities to search. See: http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/mx/loading/RepositoryClassLoader.html#getAllURLs() View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886891#3886891 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886891 |
From: <ste...@jb...> - 2005-07-27 18:04:30
|
Yes, we are saying the same thing in terms of the capaibilities. I am just uncertain how the MBean would "ad...@jb..." wrote : ask the classloader | for the urls in the TCL and get all four jar urls (the main jar and the embedded jars) | as possibilities to search. I'll take a look at that link and see if that helps me see the light. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886893#3886893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886893 |
From: <ad...@jb...> - 2005-07-27 18:14:55
|
Actually, I posted the wrong link: http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/mx/loading/RepositoryClassLoader.html#getClasspath() You would want to use code like: | URL[] urls = null; | ClassLoader cl = Thread.currentThread().getContextClassLoader(); | if (cl instanceof RepositoryClassLoader) | urls = ((RepositoryClassLoader) cl).getClassPath(); | else if (cl instanceof URLClassLoader) | urls = ((URLClassLoader) cl).getURLs(); | else | throw new DeploymentException("Unable to determine urls for classloader " + cl); | // Use the urls here | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886896#3886896 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886896 |
From: <ste...@jb...> - 2005-07-28 04:16:26
|
So coded up this solution and it seems to be working fine. However, I did run into one thing I found initially puzzling, but which might actually be problematic later. So first I need to point out that I am running my initial tests using a locally modified HARDeployer, which simply never injects a "HarUrl". Maybe what I am seeing is a result of that, and all will be good once I switch over to allowing the other deployers to pick this up. Anyway... My testsuite deployment is an ear that looks like: | test.ear/ | test-ejb.jar | test.har | So given this, the classpath entries my code is checking are: 1) the ear itself 2) the har 3) the har file's hibernate-service.xml 4) the ejb-jar The potentially problematic piece is say that I have two SARs bundled into the same top-level deployable, each defining a Hibernate MBean. So basically, each of the two session factories will know about all the classes from his SAR but also about all the classes from the other SAR. Envision a scenario where an enterprise app needs to talk to two different databases. In Hibernate that explicitly means two seperate session factories, which means I'll need two different mbeans defined. The problem is that there is no way to segment which portions of deployment pertain to DB1 access vs which pertain to DB2 access, because it's just a classpath. Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886973#3886973 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886973 |
From: <ad...@jb...> - 2005-07-28 14:45:11
|
How is this situation dealt with in a standalone java application where everything is also in the same classpath? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887074#3887074 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887074 |
From: <ste...@jb...> - 2005-07-28 16:21:46
|
Well, you explicit list the mappings to use :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887095#3887095 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887095 |
From: <ste...@jb...> - 2005-07-28 17:53:42
|
One other thing that has to happen if we do go down this path: we need to add .har as a standard recognized archive extension, so that we don't leave existing users out-to-dry. There have been numerous discussions about attaching listeners/aspects to service lifecycle. A long time ago, one such discussion was to also remove the need for a HARDeployer by simply having a generic way for services to "know about" there deployment url. What ever happened with those discussions? Personally, I think that is a more viable approach simply because it does allow this ability to still have multiple session factories defined within a single deployment (provided each is within it own nested deployment bundle). Short-term couldn't we just introduce an interface like: | public interface DeploymentURLAware { | public void setDeploymentUrl(URL deploymentURL); | } | which services could optionally implement to be notified about its deployment url? The question of course is what is responsible for notifying such mbeans. ServiceConfigurator seems the logical choice but it, unfortunately, knows nothing about DeploymentInfo or deployment urls. Guess it could be done in SubDeployerSupport.create(DI). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887118#3887118 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887118 |
From: <ste...@jb...> - 2005-07-29 14:15:26
|
So I guess something like this is not possible/desireable... I think we need to ditch this attempt to remove the HARDeployer by reading classpath info. Losing the ability to deploy multiple segmented SessionFactories from within the same top-level deployment is unacceptable. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887298#3887298 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887298 |
From: <ste...@jb...> - 2005-07-29 14:34:40
|
So to be completely clear... I totally agree with you that it is completely silly having a ~400 line class (HARDeployer) whose sole resposibility is to set a single MBean attribute (just look at my comments in HARDeployer ;). If there were some other simple way for an MBean to know about the DeploymentInfo (or even just the DeploymentInfo.url) from whence it came, I'd be all for using that instead of a full deplyer. But in my limited knowledge of the AS internals, there does not seem to be such a simple alternate approach. Please, if I am wrong, correct me. In the end, I think the "aggresive scanning" of the deployment classpath entries is very, very good idea. But based on the previous discussion regarding multiple SessionFactoys, I think it makes sense as an option on the MBean rather than as the defacto way in which mappings are discovered. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887304#3887304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887304 |
From: <sco...@jb...> - 2005-07-29 14:54:29
|
The lack of an instant reply does not neccessarily mean lack of interest. An interface is not necessarily needed, and in general is not useful as the service layer deals with mbeans, not instance implementation. It would be that the service exposed such an attribute on the mbean interface. The xmbean deployment already has similar notions for a service that wants to know its MBeanService and ObjectName without having to subclass ServiceMBeanSupport. This is handled via reflection rather than an interface contract as the xmbean container is driven by attributes on descriptor rather than interfaces on the pojo. However, I think this is better handled as an extended service lifecycle event such as init(DeploymentInfo). The DeploymentInfo could be made available to the ServiceController/ServiceConfigurator either explicitly, or via a MainDeployer query if its not already there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887313#3887313 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887313 |
From: <ste...@jb...> - 2005-07-29 15:35:29
|
"sco...@jb..." wrote : The lack of an instant reply does not neccessarily mean lack of interest. Understood. Had simply realized that I had been a bit scatter-brained in some of my responses; just wanted to pull them all together. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887320#3887320 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887320 |
From: <ste...@jb...> - 2005-08-01 16:02:42
|
So here's my thoughts after the weekend. Why not have the MBean have the option of running in what is basically two modes: 1) har-deployment : essentially what we have now. Leave HARDeployer for now until the capability for "an MBean to know about the deployment it came from" gets solidified; once that capability exists, remove the HARDeployer and simply have the MBean grab its DeploymentInfo.url and use that as the HarUrl if it is a .har. 2) auto-detection : if no HarUrl is set, then use functionality similiar to what you have described. I am not certain, though, that the current context classloader approach is the correct one. I think I'd rather use the DeploymentInfo.ucl. I am worried about start/stop calls from somewhere other than the controller. But for now, I am using the exact code you posted since its a PIA to manually locate ones DeploymentInfo. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887725#3887725 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887725 |
From: <sco...@jb...> - 2005-08-01 18:53:28
|
The ServiceMBeanSupport base class now has a getDeploymentInfo() convience method that can be accessed in the start/startService method: | protected void startService() throws Exception | { | DeploymentInfo sdi = getDeploymentInfo(); | | This info is not available until after the create method has returned so it cannot be accessed from create/createService. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887766#3887766 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887766 |
From: <ste...@jb...> - 2005-08-01 19:02:45
|
Cool. So I'll play with changing "mode" #1 above to not rely on having the HarUrl set externally. During startService(), I'll get the DeploymentInfo and see if it's url ends in .har (.har/ too i guess) and if so proceeded exactly as the functionality did before with the HARDeployer. Quick related question. I am working on adding support for Hibernate deployments into the new admin console. One of the difficulties I ran into was trying to locate all "Hibernate deployments" for selection. So currently that code iterates every single deployment on that server :) Would it make sense to have another mbean here that acts as a registry of Hibernate deployments (the mbean registers itself) so that that code can efficiently locate them? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887769#3887769 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887769 |
From: <sco...@jb...> - 2005-08-01 19:14:36
|
Which new admin console? If you have an mbean for every deployment that has a unique jmx attribute, such as type=har, you can query for all such mbeans: | ObjectName query = new ObjectName("*:type=har,*"); | MBeanServer server = ...; | Set matches = server.queryNames(query, null); | Iterator names = matches.iterator(); | while( names.hasNext() ) | { | ObjectName mbean = (ObjectName) names.next(); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887770#3887770 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887770 |
From: <cha...@jb...> - 2005-08-01 19:22:05
|
"sco...@jb..." wrote : Which new admin console? New is always relative... http://jira.jboss.com/jira/browse/JBADMCON View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887771#3887771 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887771 |
From: <ste...@jb...> - 2005-08-01 20:33:00
|
Currently the object-name is completely user-defined. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887782#3887782 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887782 |
From: <sco...@jb...> - 2005-08-01 20:54:00
|
They should only be specifying one attribute value. The structure should be coming from the deployer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887787#3887787 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887787 |
From: <ste...@jb...> - 2005-08-01 21:09:11
|
What deployer :)) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887791#3887791 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887791 |