RE: [JBoss-dev] Directory hot-deploy granularity
Hi,
I've been working on this and have run into a problem that
I hope someone can clear up real quick. I'm trying to get
a list of the EJB's deployed within an EAR. I go through
DeploymentInfo.subDeployments, and it looks like what I
need to do is for each of these sub-deployments, get the
DeploymentInfo instance, get the DeploymentInfo.deployedObject,
and mess around with it. Being new to the code I have no idea
where to look for the EJB's in each subDeployment, but my guess
was to do something like
Collection c = (Collection)server.invoke(di.deployedObject,
getContainers,
new Object[]{},
new String[]{});
where di is an instance of DeploymentInfo, since the
getContainers() method is defined in EjbModuleMBean.
However, the method apparently is not available. So my
questions are:
1. Is the information on the EJB's actually in the containers
collection or should I look somewhere else instead?
2. What method are available to be called on di.deployedObject?
How can I find out? Note that di.deployedObject.toString()
for the deployedObject in question is the following:
jboss.j2ee:service=EjbModule,url=...etc...
Thanks in advance for any answers!
Dani
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 4:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Directory hot-deploy granularity
microwave popcorn -- Wait until 2 seconds between pops
before removing from the microwave.
clear communication is Good,
just go ahead guys,
marc f
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Directory hot-deploy granularity
In principle I think this is a good idea. I'm not 100% sure the possible implementation complexity will be worth the gains... 1. You can already redeploy a subpackage of even a packed .ear by using the jmx console and MainDeployer.redeploy. You can do the same thing with the ant jmx task. Personally I think that using the ant jmx task to deploy/redeploy explicitly is more development-friendly tnan copying to a particular directory. In any case I highly recommend you try this out in various combinations to see what will work... 2. You may need a UnifiedClassLoader per class or to reload substantial parts of the application or be very careful about packaging. At the minimum you will have to keep ejb interfaces and implementations in separate packages so you don't have to reload the servlet clients. With the project I've played with redeploy just a bit with I haven't straightened out how to redeploy just the ejb implementations without the interfaces or depending packages. david jencks On 2002.10.02 13:38:01 -0400 Gredler, Dani wrote: Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Directory hot-deploy granularity
The code you are looking for may be changed extensively by me in the near
future, I'm slowly migrating it to use the mbean framework rather than
duplicate functionality.
In HEAD find the DeploymentInfo for the EJB module and get its list of
mbeans. This list contains the EjbModule mbean and all the containers.
You can figure out which are containers by looking at the object names.
The presence and contents of the mbeans list is not likely to change. What
is in the DeploymentInfo may.
thanks
david jencks
On 2002.10.03 10:35:09 -0400 Gredler, Dani wrote:
Hi,
I've been working on this and have run into a problem that
I hope someone can clear up real quick. I'm trying to get
a list of the EJB's deployed within an EAR. I go through
DeploymentInfo.subDeployments, and it looks like what I
need to do is for each of these sub-deployments, get the
DeploymentInfo instance, get the DeploymentInfo.deployedObject,
and mess around with it. Being new to the code I have no idea
where to look for the EJB's in each subDeployment, but my guess
was to do something like
Collection c = (Collection)server.invoke(di.deployedObject,
getContainers,
new Object[]{},
new String[]{});
where di is an instance of DeploymentInfo, since the
getContainers() method is defined in EjbModuleMBean.
However, the method apparently is not available. So my
questions are:
1. Is the information on the EJB's actually in the containers
collection or should I look somewhere else instead?
2. What method are available to be called on di.deployedObject?
How can I find out? Note that di.deployedObject.toString()
for the deployedObject in question is the following:
jboss.j2ee:service=EjbModule,url=...etc...
Thanks in advance for any answers!
Dani
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 4:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Directory hot-deploy granularity
microwave popcorn -- Wait until 2 seconds between pops
before removing from the microwave.
clear communication is Good,
just go ahead guys,
marc f
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Directory hot-deploy granularity
I think it is a beautiful idea. In fact I would want it to work even with the web packages to redeploy pages instead of the whole jsp enchillada and the whole site. Go ahead with this work and we will generalize to the web layers marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gredler, Dani Sent: Wednesday, October 02, 2002 1:38 PM To: '[EMAIL PROTECTED]' Subject: [JBoss-dev] Directory hot-deploy granularity Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Directory hot-deploy granularity
On Wed, 2 Oct 2002, marc fleury wrote: I think it is a beautiful idea. In fact I would want it to work even with the web packages to redeploy pages instead of the whole jsp enchillada and the whole site. Go ahead with this work and we will generalize to the web layers Hmm. Most(all?) servlet engines check updatedness for each request(and sub-requests). If jboss were to 'pre-compile' the pages, when it received some signal, then this could be a somewhat significant runtime performance win. Of course, if jboss still did a background scan of *all* jsp files, then this would be no win. I vote for this feature, if anyone is actually doing any tallying. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Directory hot-deploy granularity
Hi, I think we have to consider race conditions here. What keeps a deployment scanner from starting in the middle of an update when only some (i.e. inconsistent) changes have occured yet. We might have to somehow lock the directory during changes and unlock it afterwards. But this lowers the degree of automaticity; you would at least have to trigger the redeployment process manually at some appropriate time. Regards, Michael Gredler, Dani wrote: Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Directory hot-deploy granularity
We might have to somehow lock the directory during changes and unlock it afterwards. It's interesting the way Cruise Control deals with the same issue. A time interval could be specified where the deployment scanner would wait to see if there were any more updates before proceeding with the deployment -- kind of like microwave popcorn -- Wait until 2 seconds between pops before removing from the microwave. This could allow batch updates in a fully automatic manner. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, October 02, 2002 3:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Directory hot-deploy granularity Hi, I think we have to consider race conditions here. What keeps a deployment scanner from starting in the middle of an update when only some (i.e. inconsistent) changes have occured yet. We might have to somehow lock the directory during changes and unlock it afterwards. But this lowers the degree of automaticity; you would at least have to trigger the redeployment process manually at some appropriate time. Regards, Michael Gredler, Dani wrote: Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Directory hot-deploy granularity
I'm totally convinced. I really like this approach. Michael Matt Munz wrote: We might have to somehow lock the directory during changes and unlock it afterwards. It's interesting the way Cruise Control deals with the same issue. A time interval could be specified where the deployment scanner would wait to see if there were any more updates before proceeding with the deployment -- kind of like microwave popcorn -- Wait until 2 seconds between pops before removing from the microwave. This could allow batch updates in a fully automatic manner. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, October 02, 2002 3:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Directory hot-deploy granularity Hi, I think we have to consider race conditions here. What keeps a deployment scanner from starting in the middle of an update when only some (i.e. inconsistent) changes have occured yet. We might have to somehow lock the directory during changes and unlock it afterwards. But this lowers the degree of automaticity; you would at least have to trigger the redeployment process manually at some appropriate time. Regards, Michael Gredler, Dani wrote: Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Directory hot-deploy granularity
microwave popcorn -- Wait until 2 seconds between pops before removing from the microwave. clear communication is Good, just go ahead guys, marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
