Re: RELEASE-NOTES-1.1
Guess the exception output could be enhanced to include: - the module that failed to load (in case you were using the silent output option which doesn't list the modules being loaded) - clear statement that the server will now be shutdown because of this error - hint of how to fix the problem, like editing config.xml Instead of the current output of - >Module 24/24 hello/1.1/war Exception in thread "main" java.lang.AssertionError: Expected one match for pattern ".", but got 0 matches >at >org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:331) I agree that you can't just automatically remove the offending application, but maybe a configuration option to "continue on error" would be useful while you are developing your app, so you can then undeploy or redeploy the offending app... -Donald Gianny Damour wrote: Hi Donald, There are very good points. How would you expect the server to behave in such scenarios? Currently the server will simply shut-down and, to some extent, I think that this is a safe behaviour. Thanks, Gianny Donald Woods wrote: What happens in the case that the files no longer exist on the next server startup? Two scenarios I'm worried about: 1) files were loaded from an NFS/Samba/SMB share which has become disconnected 2) Eclipse users who deploy the app into the server, test it, stop the server and then delete the project and files from Eclipse -Donald Aaron Mulder wrote: On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote: I am trying to learn what the in-place deployment mean and how to use it. My understanding was that users can update the hot deploy files (for example, update one jsp file) in the Geronimo_home\deploy directory and server will redeploy the change automatically. This was not working in 1.0, as users need to replace the entire directory in the Geronimo_home\deploy directory. That should be true in both 1.0 and 1.1 (if not, I guess it's a bug). But in 1.1, there is a separate option, which is to not copy your files to the hot deploy directory at all, but instead use the deploy tool with a special option to enable an in-place deployment. This means that instead of copying your files into the server directory at all, it will deploy and access them from wherever they currently are. Thanks, Aaron But after reading your note below, I think I am lost. Please advise. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Thursday, June 08, 2006 7:23 PM To: [email protected] Subject: Re: RELEASE-NOTES-1.1 - We should add a point about in-place deployment. "Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree." smime.p7s Description: S/MIME Cryptographic Signature
Re: RELEASE-NOTES-1.1
Hi Donald, There are very good points. How would you expect the server to behave in such scenarios? Currently the server will simply shut-down and, to some extent, I think that this is a safe behaviour. Thanks, Gianny Donald Woods wrote: What happens in the case that the files no longer exist on the next server startup? Two scenarios I'm worried about: 1) files were loaded from an NFS/Samba/SMB share which has become disconnected 2) Eclipse users who deploy the app into the server, test it, stop the server and then delete the project and files from Eclipse -Donald Aaron Mulder wrote: On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote: I am trying to learn what the in-place deployment mean and how to use it. My understanding was that users can update the hot deploy files (for example, update one jsp file) in the Geronimo_home\deploy directory and server will redeploy the change automatically. This was not working in 1.0, as users need to replace the entire directory in the Geronimo_home\deploy directory. That should be true in both 1.0 and 1.1 (if not, I guess it's a bug). But in 1.1, there is a separate option, which is to not copy your files to the hot deploy directory at all, but instead use the deploy tool with a special option to enable an in-place deployment. This means that instead of copying your files into the server directory at all, it will deploy and access them from wherever they currently are. Thanks, Aaron But after reading your note below, I think I am lost. Please advise. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Thursday, June 08, 2006 7:23 PM To: [email protected] Subject: Re: RELEASE-NOTES-1.1 - We should add a point about in-place deployment. "Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree."
Re: RELEASE-NOTES-1.1
On Jun 13, 2006, at 3:11 PM, Donald Woods wrote: 2) Eclipse users who deploy the app into the server, test it, stop the server and then delete the project and files from Eclipse Won't be an issue. For apps running resources directly from the workspace/project, these apps will be deployed to a separate config- store and will be non-persistant. -sachin
RE: RELEASE-NOTES-1.1
Good point! I shutdown the server and renamed the hello directory. Then start the server afterwards. I saw the following exception when server attempted to start the hello module. I didn't see Geronimo server started at the end but luckily all the important module seemed to be started before my little hello module, which is the last in var\config\config.xml file. Module 24/24 hello/1.1/war Exception in threa d "main" java.lang.AssertionError: Expected one match for pattern ".", but got 0 matches at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanDa ta(ConfigurationUtil.java:331) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:359) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java(Inlined Compil ed Code)) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java(Compiled Code)) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java(Inlined Compiled Code)) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java(Compiled Code)) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java(I nlined Compiled Code)) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java(Compiled Code)) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java(Compiled Code)) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$Enhan cerByCGLIB$$f05707cd.startConfiguration() at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:297) at org.apache.geronimo.system.main.Daemon.(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) I guess this error can be improved in the future releases, but for 1.1 user needs to be good aware of what inPlace means before they use it for 1.1. I hope this is less of a problem for scenario #2, as I am not aware of the in-place option to deploy a project in Eclipse/WTP but Sachin can certainly correct me as I haven't tried the 1.1 version of the Eclipse plugins yet. Lin -Original Message- From: Donald Woods [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 3:12 PM To: [email protected] Subject: Re: RELEASE-NOTES-1.1 What happens in the case that the files no longer exist on the next server startup? Two scenarios I'm worried about: 1) files were loaded from an NFS/Samba/SMB share which has become disconnected 2) Eclipse users who deploy the app into the server, test it, stop the server and then delete the project and files from Eclipse -Donald Aaron Mulder wrote: > On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote: > >> I am trying to learn what the in-place deployment mean and how to use it. >> My understanding was that users can update the hot deploy files (for >> example, update one jsp file) in the Geronimo_home\deploy directory and >> server will redeploy the change automatically. This was not working in >> 1.0, as users need to replace the entire directory in the >> Geronimo_home\deploy directory. > > > That should be true in both 1.0 and 1.1 (if not, I guess it's a bug). > > But in 1.1, there is a separate option, which is to not copy your > files to the hot deploy directory at all, but instead use the deploy > tool with a special option to enable an in-place deployment. This > means that instead of copying your files into the server directory at > all, it will deploy and access them from wherever they currently are. > > Thanks, >Aaron > >> But after reading your note below, I think I am lost. Please advise. >> >> Lin >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron >> Mulder >> Sent: Thursday, June 08, 2006 7:23 PM >> To: [email protected] >> Subject: Re: RELEASE-NOTES-1.1 >> >> - We should add a point about in-place deployment. "Geronimo >> supports in-place deployment, which means an archive or directory can >> be deployed without being copied into the Geronimo directory tree." >> >> >> >> > >
Re: RELEASE-NOTES-1.1
What happens in the case that the files no longer exist on the next server startup? Two scenarios I'm worried about: 1) files were loaded from an NFS/Samba/SMB share which has become disconnected 2) Eclipse users who deploy the app into the server, test it, stop the server and then delete the project and files from Eclipse -Donald Aaron Mulder wrote: On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote: I am trying to learn what the in-place deployment mean and how to use it. My understanding was that users can update the hot deploy files (for example, update one jsp file) in the Geronimo_home\deploy directory and server will redeploy the change automatically. This was not working in 1.0, as users need to replace the entire directory in the Geronimo_home\deploy directory. That should be true in both 1.0 and 1.1 (if not, I guess it's a bug). But in 1.1, there is a separate option, which is to not copy your files to the hot deploy directory at all, but instead use the deploy tool with a special option to enable an in-place deployment. This means that instead of copying your files into the server directory at all, it will deploy and access them from wherever they currently are. Thanks, Aaron But after reading your note below, I think I am lost. Please advise. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Thursday, June 08, 2006 7:23 PM To: [email protected] Subject: Re: RELEASE-NOTES-1.1 - We should add a point about in-place deployment. "Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree." smime.p7s Description: S/MIME Cryptographic Signature
Re: RELEASE-NOTES-1.1
On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote: I am trying to learn what the in-place deployment mean and how to use it. My understanding was that users can update the hot deploy files (for example, update one jsp file) in the Geronimo_home\deploy directory and server will redeploy the change automatically. This was not working in 1.0, as users need to replace the entire directory in the Geronimo_home\deploy directory. That should be true in both 1.0 and 1.1 (if not, I guess it's a bug). But in 1.1, there is a separate option, which is to not copy your files to the hot deploy directory at all, but instead use the deploy tool with a special option to enable an in-place deployment. This means that instead of copying your files into the server directory at all, it will deploy and access them from wherever they currently are. Thanks, Aaron But after reading your note below, I think I am lost. Please advise. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Thursday, June 08, 2006 7:23 PM To: [email protected] Subject: Re: RELEASE-NOTES-1.1 - We should add a point about in-place deployment. "Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree."
RE: RELEASE-NOTES-1.1
Hi Aaron, I am trying to learn what the in-place deployment mean and how to use it. My understanding was that users can update the hot deploy files (for example, update one jsp file) in the Geronimo_home\deploy directory and server will redeploy the change automatically. This was not working in 1.0, as users need to replace the entire directory in the Geronimo_home\deploy directory. But after reading your note below, I think I am lost. Please advise. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Thursday, June 08, 2006 7:23 PM To: [email protected] Subject: Re: RELEASE-NOTES-1.1 - We should add a point about in-place deployment. "Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree."
Re: RELEASE-NOTES-1.1
Dave Colasurdo wrote: 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. Seems that 3 of the items above are missing from the release notes in the 1.1 rc1 build? These are now in (http://cwiki.apache.org/confluence/display/GMOxDOC11/RELEASE-NOTES-1.1.TXT). May need to elaborate more the last three or four bullets in the "Significant Changes Since the 1.0 Release" section. Suggestions/comments? 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Didn't see any references/links to the "plan upgrade tool" in the 1.1 rc1 release notes? It is now included in the "Significant Changes Since the 1.0 Release" section. Cheers! Hernan Thanks -Dave-
Re: RELEASE-NOTES-1.1
2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. Seems that 3 of the items above are missing from the release notes in the 1.1 rc1 build? 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Didn't see any references/links to the "plan upgrade tool" in the 1.1 rc1 release notes? Thanks -Dave-
Re: RELEASE-NOTES-1.1
I'd like to second Erin's comment about the "Deploying Applications" section. The following command will not work, I promise. /bin/java -jar deployer.jar help [command] I also agree that Java 5 compatibility should be emphasized -- perhaps "Geronimo is certified on Sun's JDK 1.4.2, but aside from the CORBA features, it should run well on any 1.4.2 or 1.5 JVM." I also think it's worth mentioning the "login" command in the Deploying applications section. In the significant changes section: - We should add plugins. "Geronimo applications, server features, and integrated products can be distributed as Geronimo plugins. Plugins are easy to install, automatically download any dependencies, and do not require server restarts." Perhaps a separate point for server cloning. "Using the plugin infrastructure, applications or modules can be copied from one Geronimo installation to another (from developer to developer, test to production, etc.)." - For the console point, let's add "JMS resource configuration" - The hot deploy exclusion for the repository is not correct. Hot deployed files are copied into the repository like anything else. - For the Little G point, the grammar is wrong. "Little-G, a minimal, small footprint, Tomcat and Jetty configurations are available." - We should add a point about in-place deployment. "Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree." In the overall project status, I think we need to list initial Java EE 5 support as a major goal of the next release. In the Jira section, I think all the entries should be word-wrapped at 77 characters or so. Thanks, Aaron On 6/8/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: Dave Colasurdo wrote: > Hernan Cunico wrote: > >> Dave Colasurdo wrote: >> >>> Hernan Cunico wrote: >>> Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan >>> >>> Thanks Hernan! A few comments: >>> >>> 1) In section "Installing and Starting Geronimo" >>> >>> Suspect the geronimo.sh reference should be ./geronimo.sh >> >> >> I did not include the ./ because I specified the full path. Having the >> full path do you still need to specify the ./ ? >> >>> > Nope. It works fine with the full path. > >>> 2) In section "Significant Changes" >>> >>> -Shared Library Support >>> -Statement Cache for JDBC drivers >>> -Dynamic Plugin support >>> -In-place deployment of exploded applications >>> -Dependent Package Upgrades (Tomcat, Jetty, etc.) >> >> >> DONE. >> >>> > Thanks > >>> 3)Also, probably want a new section on "Migrating applications from >>> previous releases" that references the existence of the Upgrade tool >>> that David J has created (and Lin is documenting) and any other major >>> differences that existing users will need to know. It should link to >>> any other migration documentation that we have. >> >> >> Is that doc already available, I couldn't find the pointer on the dev >> list. >> >>> > > http://www.mail-archive.com/[email protected]/msg03519.html AHA! I was looking at the wrong thread :) Thanks Dave Cheers! Hernan > > >>> Thanks >>> -Dave- >>> >> Thanks for the comments. >> >> Cheers! >> Hernan >> >> >
Re: RELEASE-NOTES-1.1
Dave Colasurdo wrote: Hernan Cunico wrote: Dave Colasurdo wrote: Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section "Installing and Starting Geronimo" Suspect the geronimo.sh reference should be ./geronimo.sh I did not include the ./ because I specified the full path. Having the full path do you still need to specify the ./ ? Nope. It works fine with the full path. 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. Thanks 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Is that doc already available, I couldn't find the pointer on the dev list. http://www.mail-archive.com/[email protected]/msg03519.html AHA! I was looking at the wrong thread :) Thanks Dave Cheers! Hernan Thanks -Dave- Thanks for the comments. Cheers! Hernan
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: Dave Colasurdo wrote: Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section "Installing and Starting Geronimo" Suspect the geronimo.sh reference should be ./geronimo.sh I did not include the ./ because I specified the full path. Having the full path do you still need to specify the ./ ? Nope. It works fine with the full path. 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. Thanks 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Is that doc already available, I couldn't find the pointer on the dev list. http://www.mail-archive.com/[email protected]/msg03519.html Thanks -Dave- Thanks for the comments. Cheers! Hernan
Re: RELEASE-NOTES-1.1
Dave Colasurdo wrote: Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section "Installing and Starting Geronimo" Suspect the geronimo.sh reference should be ./geronimo.sh I did not include the ./ because I specified the full path. Having the full path do you still need to specify the ./ ? 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) DONE. 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Is that doc already available, I couldn't find the pointer on the dev list. Thanks -Dave- Thanks for the comments. Cheers! Hernan
Re: RELEASE-NOTES-1.1
Erin Mulder wrote: Hernan Cunico wrote: I updated the release notes and it is ready for your review Looks good! A few comments: 1) Under system requirements, I think it should mention that Geronimo will run fine on Java 5 out of the box, and offer the caveats that it is only J2EE-certified on 1.4 and that in particular, you will need to run under 1.4 if you enable CORBA support. Could you work on a line or two to reword this section? Not too sure how to word it as we are telling we certified for 1.4 but it works fine with Java 5 2) Under "Administration Console Security Configuration", it should mention that the username/password can be changed within the console itself. e.g. "This can be changed through the console (in the "Security -> Console Realm" section) or by editing /var.." DONE 3) Looks like there's a typo in the "Deploying Applications" section. It says "/bin/java -jar." instead of just "java -jar." Where is the typo? you mean we should not mention the directory here? 4) In that same section, perhaps worth mentioning that you can run the login command in the deployer tool and not have to enter the password over and over. It's kind of a minor detail, but constant retyping of passwords could ruin the deployment experience for people. DONE. Login is a nice feature while testing although for production users may want to keep more control on the actual user deploying the apps. 5) Under "Choice of Web container", it sounds a little open-ended to say "Please download the binary appropriate for your environment." People will wonder what it is that makes one or the other appropriate for their environment. Not sure how to say it better, but perhaps indicate that choosing one at random is fine if you or your company don't already have a preference? This is pretty much untouched from the previous release notes. I rephrased it a little bit but still is lacking of a good speech for choosing one container over the other. We have the same problem in the documentation, any ideas on how to better articulate the "pros and cons"? Cheers, Erin Thanks for the comments. Cheers! Hernan
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section "Installing and Starting Geronimo" Suspect the geronimo.sh reference should be ./geronimo.sh 2) In section "Significant Changes" -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) 3)Also, probably want a new section on "Migrating applications from previous releases" that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Thanks -Dave-
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: > I updated the release notes and it is ready for your review Looks good! A few comments: 1) Under system requirements, I think it should mention that Geronimo will run fine on Java 5 out of the box, and offer the caveats that it is only J2EE-certified on 1.4 and that in particular, you will need to run under 1.4 if you enable CORBA support. 2) Under "Administration Console Security Configuration", it should mention that the username/password can be changed within the console itself. e.g. "This can be changed through the console (in the "Security -> Console Realm" section) or by editing /var.." 3) Looks like there's a typo in the "Deploying Applications" section. It says "/bin/java -jar." instead of just "java -jar." 4) In that same section, perhaps worth mentioning that you can run the login command in the deployer tool and not have to enter the password over and over. It's kind of a minor detail, but constant retyping of passwords could ruin the deployment experience for people. 5) Under "Choice of Web container", it sounds a little open-ended to say "Please download the binary appropriate for your environment." People will wonder what it is that makes one or the other appropriate for their environment. Not sure how to say it better, but perhaps indicate that choosing one at random is fine if you or your company don't already have a preference? Cheers, Erin
Re: RELEASE-NOTES-1.1
Thanks for bringing this together Hernan. Let's get this kicked around over the weekend. Hernan Cunico wrote: Hi All, I put the RELEASE-NOTES-1.1 available on confluence so it will be easier for you to provide some input. It is based on the previous version and it needs a lot of work. Here are some of the areas where I'm hoping to gather and summarize your feedback * Future Road Map at a Glance * Significant Changes Since the 1.0 release * Overall Project Status * Significant Missing Features * Known issues Some of these will get more complete as we get closer to a release candidate but I will really like to start seeing your feedback earlier :) I also need your comments for the overall summary of changes that will go into the documentation, I can not include it if you do not provide input. Here is the link to the v1.1 documentation. http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation Cheers! Hernan
