Re: [VOTE] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
+1 Ted, thanks for the improvements to the release process... Ted Kirby wrote: G 2.1.3 has been released, and there has been no activity in GEP trunk for a week. So, I am putting out GEP 2.1.3 for a vote. Please review and vote on the maintenance release of the Geronimo Eclipse Plugin 2.1.3 RC1. The Eclipse Update Manager site is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/updates/ The deployable zip file is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-deployable.zip The update site zip file is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-updatesite.zip The current svn location is here (revision number 696545): > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.1.3 The future svn location will be here (when approved): > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.1.3 If you would like to review and/or comment on the release notes, they are here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3/PLUGIN_RELEASE-NOTES-2.1.2.txt The install instructions are available at: > http://cwiki.apache.org/confluence/display/GMOxDOC21/How+to+install+Geronimo+Eclipse+Plugin+v2.1.3 In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: > http://cwiki.apache.org/GMOxDOC21/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Please let me know if there are any questions and/or problems. The vote is open for 72 hours and will conclude on Saturday (9/20) at midnight, 12:00 AM EST. [ ] +1 Release Geronimo Eclipse Plugin 2.1.3 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.1.3 -- Thanks, Tim McConnell
[BUILD] trunk: Failed for Revision: 697310
Geronimo Revision: 697310 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 minutes 55 seconds
[INFO] Finished at: Fri Sep 19 21:41:37 EDT 2008
[INFO] Final Memory: 363M/1014M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/logs-2100-tomcat/test.log
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.877
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 32 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deployFAILURE (0:01:06.947) Java
returned: 1
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.967)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.127)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:17.277)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:13.649)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:50.385) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:47.466)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:42.356)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:04.252)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.870)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.267)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.214)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.243)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:42.526)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:48.736)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:49.981)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise
[jira] Commented: (GERONIMODEVTOOLS-517) Can't delete project from defined geronimo server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632912#action_12632912 ] Delos Dai commented on GERONIMODEVTOOLS-517: Yes, this issue just exist in 2.0.1 Thanks for your help! > Can't delete project from defined geronimo server > - > > Key: GERONIMODEVTOOLS-517 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows XP > 2. JDK: ibm jdk 5.0 SR6(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GERONIMODEVTOOLS-517.patch > > > Steps: > 1. Create a new sever in server view > 2. Create an new Dynamic Web Project "testweb" to eclipse > 3. Right click "testweb"->run on server, and then under "Servers" tab , > choose testweb, right > click" remove " this project from defined geronimo server, but no any reponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-516) Fail to create application client in eclipse 3.3.2 with geronimo server adapter 2.0
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632911#action_12632911 ] Delos Dai commented on GERONIMODEVTOOLS-516: This patch is for "geronimo/devtools/eclipse-plugin/branches/2.0.1/plugins/org.apache.geronimo.st.v11.core/plugin.xml" Sorry for the inconvenience. Yes, the patch has been in trunk and 2.1.3. I just found this issue in 2.0.0 > Fail to create application client in eclipse 3.3.2 with geronimo server > adapter 2.0 > > > Key: GERONIMODEVTOOLS-516 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows 2003 Server,XP,ubuntu > 2. JDK: ibm jdk 5.0 SR8(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GeronimoDevtool-516.patch > > > Steps: > 1. Install wasce server adater 2.0 > 2.New an application client ->input name, click "next"->configuration, check > "geronimo deployment", > error launched: > Constrains for geronimo deployment 1.1 have not been met. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
+1 - Looks good to me. In addition to installing and creating and running the sample I also took a quick look at the source and all seems to be in order. Thanks for pulling this together Ted! Joe Ted Kirby wrote: G 2.1.3 has been released, and there has been no activity in GEP trunk for a week. So, I am putting out GEP 2.1.3 for a vote. Please review and vote on the maintenance release of the Geronimo Eclipse Plugin 2.1.3 RC1. The Eclipse Update Manager site is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/updates/ The deployable zip file is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-deployable.zip The update site zip file is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-updatesite.zip The current svn location is here (revision number 696545): > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.1.3 The future svn location will be here (when approved): > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.1.3 If you would like to review and/or comment on the release notes, they are here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3/PLUGIN_RELEASE-NOTES-2.1.2.txt The install instructions are available at: > http://cwiki.apache.org/confluence/display/GMOxDOC21/How+to+install+Geronimo+Eclipse+Plugin+v2.1.3 In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: > http://cwiki.apache.org/GMOxDOC21/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Please let me know if there are any questions and/or problems. The vote is open for 72 hours and will conclude on Saturday (9/20) at midnight, 12:00 AM EST. [ ] +1 Release Geronimo Eclipse Plugin 2.1.3 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.1.3
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
Is it just temporary that the wiki on installing Geronimo Eclipse Plugin 2.1.3 is a child of 2.1.2 rather than a peer? Everything else that I looked at looked fine. Joe Ted Kirby wrote: The vote on GEP 2.1.3 has been started, and this is the associated discussion thread. Fan mail goes here. :-) Ted Kirby
[jira] Commented: (GERONIMODEVTOOLS-518) Update GEP code with new Devtools URL
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632901#action_12632901 ] Ted Kirby commented on GERONIMODEVTOOLS-518: I put work into http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html to make it a generic devtools subproject page. However, it is still a wiki page, with no left nav bar, or news on the bottom. Tim, Ashish and I discussed doc issues in GERONIMODEVTOOLS-461. We went to a wiki page because it was easier to edit. I didn't know how to change http://geronimo.apache.org/development-tools.html before. I know how to do that now. :-) So, I'll change http://geronimo.apache.org/development-tools.html into a generic page, and move it's child pages in GMOxSITE to GMOxDOC20, where I think they belong. They are now old pages that describe how to use GEP 2.0.0. Turning http://geronimo.apache.org/development-tools.html into a generic page will essentially fix the JIRA, as well as keep all previous releases vaild. In terms of moving to GMOxDOC20, maybe Devtools should get its own wiki space. It seems we have maybe 10 pages. The pre-reqs and install page will change for each release, but the other pages may be longer lived. That directory page gives too much press to subprojects, I think. We don't need big buttons at the top of our main page for them. But, they probably deserve more attention than links at the bottom of the left nav bar... I agree Samples and Devtools are important. It is how users/developers can start using the server quickly! We should probably get more links, info and press at the top of our page to get folks started. > Update GEP code with new Devtools URL > - > > Key: GERONIMODEVTOOLS-518 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518 > Project: Geronimo-Devtools > Issue Type: Bug >Affects Versions: 2.1.3, 2.2.0 >Reporter: Ted Kirby >Assignee: Ted Kirby > Fix For: 2.2.0 > > > Recently, the devtools sub-project homepage was changed from > http://geronimo.apache.org/development-tools.html to > http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html. > I have just found some references in the code to the old page that need to be > updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
+1 Installed plugin, setup a server instance to an exiting 2.1.3 Tomcat server, started/stopped through plugin, admin console and support links worked, About Eclipse showed the right info for our feature/plugins, simple web app could be deployed. -Donald Ted Kirby wrote: G 2.1.3 has been released, and there has been no activity in GEP trunk for a week. So, I am putting out GEP 2.1.3 for a vote. Please review and vote on the maintenance release of the Geronimo Eclipse Plugin 2.1.3 RC1. The Eclipse Update Manager site is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/updates/ The deployable zip file is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-deployable.zip The update site zip file is here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-updatesite.zip The current svn location is here (revision number 696545): > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.1.3 The future svn location will be here (when approved): > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.1.3 If you would like to review and/or comment on the release notes, they are here: > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3/PLUGIN_RELEASE-NOTES-2.1.2.txt The install instructions are available at: > http://cwiki.apache.org/confluence/display/GMOxDOC21/How+to+install+Geronimo+Eclipse+Plugin+v2.1.3 In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: > http://cwiki.apache.org/GMOxDOC21/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Please let me know if there are any questions and/or problems. The vote is open for 72 hours and will conclude on Saturday (9/20) at midnight, 12:00 AM EST. [ ] +1 Release Geronimo Eclipse Plugin 2.1.3 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.1.3
Re: Publishing news in Geronimo home page
The following autoexport created content didn't have your updates, so there was nothing that was waiting for an rsync... http://cwiki.apache.org/GMOxSITE/ -Donald Ted Kirby wrote: Good things come to those who wait! :-) Donald and I had a similar discussion about the G2.1.3 news item. The rsync deamon just needs time. Ted On Fri, Sep 19, 2008 at 4:05 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: I have added a "News" entry about upcoming ApacheCon US 2008 to Geronimo wiki by using the "Add News" link in the confluence. When I visit the page http://geronimo.apache.org/news-archive.html in the live site, the entry does not show up. But the page http://cwiki.apache.org/confluence/display/GMOxSITE/News+Archive in the confluence displays the added News entry. What do I need to do so that the News entry shows in the live site? ++Vamsi
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
Not yet, but something to work on after we get GEP 2.1.3 out... -Donald Ted Kirby wrote: I agree with release neutrality. So, GMOxDOC21 does not seem like a good choice! :-) We changed from http://geronimo.apache.org/development-tools.html to http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html so that it could be a wiki page that we could more easily edit. The plan is to keep this page release-neutral. Is there a better wiki space to put this in? On Fri, Sep 19, 2008 at 3:35 PM, Donald Woods <[EMAIL PROTECTED]> wrote: Agree. We can easily change the http://geronimo.apache.org/development-tools.html page to be GEP release neutral... -Donald Ted Kirby wrote: I found GERONIMODEVTOOLS-518 Update GEP code with new Devtools URL, (and fixed it in trunk), but I don't think it's enough to stop the GEP 2.1.3 release. Ted Kirby On Wed, Sep 17, 2008 at 11:53 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: The vote on GEP 2.1.3 has been started, and this is the associated discussion thread. Fan mail goes here. :-) Ted Kirby
Re: Publishing news in Geronimo home page
The Confluence autoexport plugin doesn't seem to be "auto exporting" anymore when a page is changed in any of our spaces I just went into Confluence and ran a manual export of our GMOxSITE space, so the updated news entry should appear once the cron/rsync job runs (not sure how often it runs, but at least once an hour) -Donald Vamsavardhana Reddy wrote: I have added a "News" entry about upcoming ApacheCon US 2008 to Geronimo wiki by using the "Add News" link in the confluence. When I visit the page http://geronimo.apache.org/news-archive.html in the live site, the entry does not show up. But the page http://cwiki.apache.org/confluence/display/GMOxSITE/News+Archive in the confluence displays the added News entry. What do I need to do so that the News entry shows in the live site? ++Vamsi
Re: [ANNOUNCE] Welcome Manu George as a new Geronimo Committer
Congratulations Manu !! Donald Woods wrote: All, The Apache Geronimo PMC is pleased to announce that Manu George has accepted our invitation to become an Apache Geronimo committer. Congratulations Manu and welcome aboard! Thanks, Donald Woods -- Thanks, Tim McConnell
Re: [DISCUSS] URLClassloader problem
Thanks Davanum, I agree Davanum Srinivas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 May i suggest a variant of #1? Help Axis2 folks with a patch that fixes the problem? thanks, dims Tim McConnell wrote: Hi, There is at least one scenario using Axis2 and Geronimo that is causing jarfiles to get locked on Windows such that a deployed WAR cannot be either redeployed or uninstalled. Here is a brief description of the failing scenario: 1. A WAR file containing various Axis2 jarfiles in the /lib directory (axis2-kernel-1.4, axis2-adb-1.4, axis2-spring) is deployed on the Tomcat version of Geronimo 2.1.3 2. Navigate to the deployed app's address to generate the WSDL for the web service 3. Redeploy or uninstall of the WAR will now fail since all the jarfiles in the WAR /lib directory are locked by Windows and cannot be deleted. What appears to be happening is that there are three Axis2 URLClassLoaders in this scenario and at least two of them are creating their own ClassPath and URLClassPath$JarLoader objects that apparently are locking the jarfiles in the /lib directory. I know that Geronimo has the JarFileClassloader and MultiParentClassloader classes to address this problems of this type but unfortunately they don't really come into play here since the Axis2 libraries are embedded in the WAR's /lib directory. I also know that this has been a problem on Windows for a long time (at least 2003 -- see Java Bug ID:4950148) and probably won't be fixed in the JDK in the immediate future if ever. And finally I know that this may not actually be a Geronimo problem but nevertheless appears as just that to the Geronimo end-user(s). Here is what I've tried up to now with varying degree of success: 1. Moved all the jarfiles out of WAR file into Geronimo's shared-lib directory added a dependency to the geronimo-web.xml file. This fortunately does work and provides a fairly simple work-around but still doesn't fix the underlying problem. 2. Tried the corresponding Axis2-1.4.1 jarfiles (that were just recently released) but they didn't fix the problem. 3. I was hoping that by using reflection I could clear out some of the private variable in the ClassLoader to mitigate this problem. But this causes errors in the JVM whenever the private variables (e.g. "classes) are updated via reflection. I wonder if there are other alternatives that I can pursue ?? Kevan has suggested at least two: 1. Ask Axis2 to change their ClassLoader using the same techniques that Geronimo employs with JarFileClassLoader and MultiParentClassLoader 2. Intercept instantiations of URLClassLoader in Geronimo and change them to our own MultiParentClassLoader. I really like this idea since it would be an all-encompassing solution and not specific to just Axis2, but I don't know how difficult this might be. Does anyone have any other suggestions and/or recommendations that I can or should attempt ?? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIymTCgNg6eWEDv1kRApHxAKDsFCKO6Z2fNGooWWkRk0zBox6SfACeNFOg dlUV3fisS0tXTcsAinuLF6c= =bwBS -END PGP SIGNATURE- -- Thanks, Tim McConnell
Re: [DISCUSS] URLClassloader problem
Hi Donald, thanks for the suggestion -- I shall investigate Donald Woods wrote: #2, intercepting all, sounds like the best solution. Is this something AspectJ could handle, via an aspect that uses around() to intercept URLClassLoder construction (but somehow exclude our creation of them) and constructs/returns our MultiParentClassloader instead? To get started, you could use a before() aspect and log an error when URLClassLoaders are created, just to prove that this could work http://www.eclipse.org/aspectj/doc/released/progguide/examples-basic.html -Donald Tim McConnell wrote: Hi, There is at least one scenario using Axis2 and Geronimo that is causing jarfiles to get locked on Windows such that a deployed WAR cannot be either redeployed or uninstalled. Here is a brief description of the failing scenario: 1. A WAR file containing various Axis2 jarfiles in the /lib directory (axis2-kernel-1.4, axis2-adb-1.4, axis2-spring) is deployed on the Tomcat version of Geronimo 2.1.3 2. Navigate to the deployed app's address to generate the WSDL for the web service 3. Redeploy or uninstall of the WAR will now fail since all the jarfiles in the WAR /lib directory are locked by Windows and cannot be deleted. What appears to be happening is that there are three Axis2 URLClassLoaders in this scenario and at least two of them are creating their own ClassPath and URLClassPath$JarLoader objects that apparently are locking the jarfiles in the /lib directory. I know that Geronimo has the JarFileClassloader and MultiParentClassloader classes to address this problems of this type but unfortunately they don't really come into play here since the Axis2 libraries are embedded in the WAR's /lib directory. I also know that this has been a problem on Windows for a long time (at least 2003 -- see Java Bug ID:4950148) and probably won't be fixed in the JDK in the immediate future if ever. And finally I know that this may not actually be a Geronimo problem but nevertheless appears as just that to the Geronimo end-user(s). Here is what I've tried up to now with varying degree of success: 1. Moved all the jarfiles out of WAR file into Geronimo's shared-lib directory added a dependency to the geronimo-web.xml file. This fortunately does work and provides a fairly simple work-around but still doesn't fix the underlying problem. 2. Tried the corresponding Axis2-1.4.1 jarfiles (that were just recently released) but they didn't fix the problem. 3. I was hoping that by using reflection I could clear out some of the private variable in the ClassLoader to mitigate this problem. But this causes errors in the JVM whenever the private variables (e.g. "classes) are updated via reflection. I wonder if there are other alternatives that I can pursue ?? Kevan has suggested at least two: 1. Ask Axis2 to change their ClassLoader using the same techniques that Geronimo employs with JarFileClassLoader and MultiParentClassLoader 2. Intercept instantiations of URLClassLoader in Geronimo and change them to our own MultiParentClassLoader. I really like this idea since it would be an all-encompassing solution and not specific to just Axis2, but I don't know how difficult this might be. Does anyone have any other suggestions and/or recommendations that I can or should attempt ?? -- Thanks, Tim McConnell
Re: [DISCUSS] URLClassloader problem
Hi Jarek, Thanks for the suggestion for actually trying to close the jarfile. It
is not something I considered nor tried, but it is very easy to do so.
Jarek Gawor wrote:
Primarily, this is a problem in Axis2 and it should be fix there no
matter what we do about it (if anything) in Geronimo. But I'm not even
sure what we can do about it in Geronimo. Maybe we can intercept class
loading of "java.net.URLClassLoader" and return our own replacement
for it (right now we have a ClassLoader that extends URLClassLoader
that's its in own package but I think we would need something in the
"java.net" package). So I'm definitely for #1 but I don't know what we
can do about #2.
Btw, did you try closing the JarFile of JarLoader using reflection?
Conceptually, something like:
URLClassLoader classLoader = ...;
for (Object loader : classLoader.ucp.lmap.values()) {
loader.jar.close();
}
Jarek
On Thu, Sep 11, 2008 at 10:40 PM, Tim McConnell <[EMAIL PROTECTED]> wrote:
Hi, There is at least one scenario using Axis2 and Geronimo that is causing
jarfiles to get locked on Windows such that a deployed WAR cannot be either
redeployed or uninstalled. Here is a brief description of the failing
scenario:
1. A WAR file containing various Axis2 jarfiles in the /lib directory
(axis2-kernel-1.4, axis2-adb-1.4, axis2-spring) is deployed on the Tomcat
version of Geronimo 2.1.3
2. Navigate to the deployed app's address to generate the WSDL for the web
service
3. Redeploy or uninstall of the WAR will now fail since all the jarfiles in
the WAR /lib directory are locked by Windows and cannot be deleted.
What appears to be happening is that there are three Axis2 URLClassLoaders
in this scenario and at least two of them are creating their own ClassPath
and URLClassPath$JarLoader objects that apparently are locking the jarfiles
in the /lib directory. I know that Geronimo has the JarFileClassloader and
MultiParentClassloader classes to address this problems of this type but
unfortunately they don't really come into play here since the Axis2
libraries are embedded in the WAR's /lib directory. I also know that this
has been a problem on Windows for a long time (at least 2003 -- see Java Bug
ID:4950148) and probably won't be fixed in the JDK in the immediate future
if ever. And finally I know that this may not actually be a Geronimo problem
but nevertheless appears as just that to the Geronimo end-user(s).
Here is what I've tried up to now with varying degree of success:
1. Moved all the jarfiles out of WAR file into Geronimo's shared-lib
directory added a dependency to the geronimo-web.xml file. This fortunately
does work and provides a fairly simple work-around but still doesn't fix the
underlying problem.
2. Tried the corresponding Axis2-1.4.1 jarfiles (that were just recently
released) but they didn't fix the problem.
3. I was hoping that by using reflection I could clear out some of the
private variable in the ClassLoader to mitigate this problem. But this
causes errors in the JVM whenever the private variables (e.g. "classes) are
updated via reflection.
I wonder if there are other alternatives that I can pursue ?? Kevan has
suggested at least two:
1. Ask Axis2 to change their ClassLoader using the same techniques that
Geronimo employs with JarFileClassLoader and MultiParentClassLoader
2. Intercept instantiations of URLClassLoader in Geronimo and change them to
our own MultiParentClassLoader. I really like this idea since it would be an
all-encompassing solution and not specific to just Axis2, but I don't know
how difficult this might be.
Does anyone have any other suggestions and/or recommendations that I can or
should attempt ??
--
Thanks,
Tim McConnell
--
Thanks,
Tim McConnell
[BUILD] trunk: Failed for Revision: 697190
Geronimo Revision: 697190 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 6 seconds
[INFO] Finished at: Fri Sep 19 15:42:10 EDT 2008
[INFO] Final Memory: 364M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/logs-1500-tomcat/test.log
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:37.595
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 32 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deployFAILURE (0:01:05.561) Java
returned: 1
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:30.391)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:18.985)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:17.222)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:12.481)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:52.918) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:47.412)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:42.950)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:54.444)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:44.128)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.921)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.549)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.737)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:43.107)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.538)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:52.139)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise
Re: Publishing news in Geronimo home page
Good things come to those who wait! :-) Donald and I had a similar discussion about the G2.1.3 news item. The rsync deamon just needs time. Ted On Fri, Sep 19, 2008 at 4:05 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: > I have added a "News" entry about upcoming ApacheCon US 2008 to Geronimo > wiki by using the "Add News" link in the confluence. When I visit the page > http://geronimo.apache.org/news-archive.html in the live site, the entry > does not show up. But the page > http://cwiki.apache.org/confluence/display/GMOxSITE/News+Archive in the > confluence displays the added News entry. What do I need to do so that the > News entry shows in the live site? > > ++Vamsi >
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
I agree with release neutrality. So, GMOxDOC21 does not seem like a good choice! :-) We changed from http://geronimo.apache.org/development-tools.html to http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html so that it could be a wiki page that we could more easily edit. The plan is to keep this page release-neutral. Is there a better wiki space to put this in? On Fri, Sep 19, 2008 at 3:35 PM, Donald Woods <[EMAIL PROTECTED]> wrote: > Agree. We can easily change the > http://geronimo.apache.org/development-tools.html page to be GEP release > neutral... > > -Donald > > > Ted Kirby wrote: >> >> I found GERONIMODEVTOOLS-518 Update GEP code with new Devtools URL, >> (and fixed it in trunk), but I don't think it's enough to stop the GEP >> 2.1.3 release. >> >> Ted Kirby >> >> On Wed, Sep 17, 2008 at 11:53 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: >>> >>> The vote on GEP 2.1.3 has been started, and this is the associated >>> discussion thread. >>> >>> Fan mail goes here. :-) >>> >>> Ted Kirby >>> >> >
[BUILD] branches/2.1: Failed for Revision: 697157
Geronimo Revision: 697157 built with tests included See the full build-1400.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/build-1400.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 35 minutes 4 seconds [INFO] Finished at: Fri Sep 19 14:40:04 EDT 2008 [INFO] Final Memory: 306M/1008M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/logs-1400-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/logs-1400-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 75.78 sec <<< FAILURE! Samples: branches/2.1 = Log: http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/samples-1400.log Build status: OK
Publishing news in Geronimo home page
I have added a "News" entry about upcoming ApacheCon US 2008 to Geronimo wiki by using the "Add News" link in the confluence. When I visit the page http://geronimo.apache.org/news-archive.html in the live site, the entry does not show up. But the page http://cwiki.apache.org/confluence/display/GMOxSITE/News+Archive in the confluence displays the added News entry. What do I need to do so that the News entry shows in the live site? ++Vamsi
Re: Google Analytics
Hi, could someone add me - [EMAIL PROTECTED] ? Thanks Lin On Thu, May 15, 2008 at 2:32 AM, David Blevins <[EMAIL PROTECTED]> wrote: > Setup google analytics on all our spaces and added everyone who's a > committer who I could easily find a gmail address for. > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > You don't need a gmail address, just a google account. So if you're not in > the above list, just get someone in the above list to add your google > account. > > Just visit http://www.google.com/analytics/ to log in and view the data. > It'll be a day or two before we see much of anything. > > -David > >
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
Agree. We can easily change the http://geronimo.apache.org/development-tools.html page to be GEP release neutral... -Donald Ted Kirby wrote: I found GERONIMODEVTOOLS-518 Update GEP code with new Devtools URL, (and fixed it in trunk), but I don't think it's enough to stop the GEP 2.1.3 release. Ted Kirby On Wed, Sep 17, 2008 at 11:53 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: The vote on GEP 2.1.3 has been started, and this is the associated discussion thread. Fan mail goes here. :-) Ted Kirby
[jira] Commented: (GERONIMODEVTOOLS-518) Update GEP code with new Devtools URL
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632787#action_12632787 ] Donald Woods commented on GERONIMODEVTOOLS-518: --- Yep, we need to change /development-tools.html site page to be a generic landing page that provides links off to release specific pages (like for GEP 1.1.x, 2.0.x and 2.1.x) in much the way we do for the server download page. We should also create a new Confluence space for the Devtools subproject, to house our GEP, J2G and future tool docs, instead of carrying them along in the server docs. I'm thinking along the lines of - http://directory.apache.org/ where we give more visibility to our subprojects, like Devtools and Samples. > Update GEP code with new Devtools URL > - > > Key: GERONIMODEVTOOLS-518 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518 > Project: Geronimo-Devtools > Issue Type: Bug >Affects Versions: 2.1.3, 2.2.0 >Reporter: Ted Kirby >Assignee: Ted Kirby > Fix For: 2.2.0 > > > Recently, the devtools sub-project homepage was changed from > http://geronimo.apache.org/development-tools.html to > http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html. > I have just found some references in the code to the old page that need to be > updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
+1 33 hours left in the vote! I think we should have a GEP 2.1.3 for G 2.1.3. Ted Kirby On Wed, Sep 17, 2008 at 11:49 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: > G 2.1.3 has been released, and there has been no activity in GEP trunk > for a week. So, I am putting out GEP 2.1.3 for a vote. > Please review and vote on the maintenance release of the Geronimo > Eclipse Plugin 2.1.3 RC1. > > The Eclipse Update Manager site is here: > > > http://people.apache.org/~tkirby/releases/2.1.3/RC1/updates/ > > The deployable zip file is here: > > > > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-deployable.zip > > The update site zip file is here: > > > > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3//geronimo-eclipse-plugin-2.1.3-updatesite.zip > > The current svn location is here (revision number 696545): > > > > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.1.3 > > The future svn location will be here (when approved): > > > > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.1.3 > > If you would like to review and/or comment on the release notes, they are > here: > > > > http://people.apache.org/~tkirby/releases/2.1.3/RC1/2.1.3/PLUGIN_RELEASE-NOTES-2.1.2.txt > > The install instructions are available at: > > > > http://cwiki.apache.org/confluence/display/GMOxDOC21/How+to+install+Geronimo+Eclipse+Plugin+v2.1.3 > > In an effort to get more people to review and vote I'd recommend going > through this quick but useful tutorial demonstrating some of the > capabilities of the GEP: > > > > http://cwiki.apache.org/GMOxDOC21/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html > > Please let me know if there are any questions and/or problems. > > The vote is open for 72 hours and will conclude on Saturday (9/20) at > midnight, 12:00 AM EST. > > [ ] +1 Release Geronimo Eclipse Plugin 2.1.3 > [ ] +0 No opinion > [ ] -1 Don't release Geronimo Eclipse Plugin 2.1.3 > > -- > Thanks, > Ted Kirby >
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.1.3 (RC1)
I found GERONIMODEVTOOLS-518 Update GEP code with new Devtools URL, (and fixed it in trunk), but I don't think it's enough to stop the GEP 2.1.3 release. Ted Kirby On Wed, Sep 17, 2008 at 11:53 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: > The vote on GEP 2.1.3 has been started, and this is the associated > discussion thread. > > Fan mail goes here. :-) > > Ted Kirby >
Re: Samples for 2.1.2 - one final push
Oh yes .. and one more reason for publishing a regular site would be to conform better with other projects and avoid any special processing when using the maven release process. If we have to do something special to build the javadoc/xref into the samples then I'm not sure how that would get integrated into the maven release process. So, for now I'm trying to get mvn site (depending on the configuration from genesis as much as possible) to generate a usable site so samples can be treated like any other project when released. Joe Joe Bohn wrote: Lin Sun wrote: Joe, thanks for driving this! I think it is okay to remove those if we cannot find a better solution or just document that these are not expected to work in our documentation. Right ... I've been playing with some things here. - Using a slightly modified version of what is checked in I can only get the xrefs & doc included if I build the samples individually. If I attempt a top level build it just creates a whole lot of the xref and javadoc parts and leaves them littered throughout the src tree. It doesn't create the top level index to facilitate navigation. - I also have a lot of local changes to remove all the special reporting entries (and the copy of javadocs/xrefs into the wars too) in the hopes of getting creating a standard maven site using the defaults set in genesis. We could then publish this site. The exercise has been good because it exposed a number of other legal file issues that I've fixed locally. However, I'm still not able to generate a top level site. I'm trying to understand the mvn site generation better so that I can get this working. It probably makes sense to remove the xref and javadoc links from the sample UI anyway (or perhaps just direct them to one common maven site rather than include the specific content in the sample war). The links can't work for all of the samples anyway because some are just jsps with no java content (and hence there is no javadoc or xref generated). I would be in favor of releasing samples too but we need to make sure the samples all work with at least one particular version G server (probably both 2.1.2 and 2.1.3). Some of the samples may not work yet like the javamail one? I've verified all of the samples on both jetty & tomcat on both 2.1.2 and 2.1.3. This includes the javamail and directory sample (which which I've really only validated on 2.1.3 because I was using the directory plugin which cannot be installed on 2.1.2). They all work. The biggest outstanding item after the site generation is getting the doc updated but we can create a release candidate and vote without the doc being complete. ... I've been dragging my feet on the doc (there's always something else to work on :-) ). Lin On Wed, Sep 17, 2008 at 2:09 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: Joe Bohn wrote: - Most of the samples when run include a Geronimo header with links that are supposed to take you to javadocs and xref for that sample. These don't work (and from what I see I'm not sure if they were ever fully functional). So these should probably be removed if I can't find a way to quickly implement them.
Re: Samples for 2.1.2 - one final push
Lin Sun wrote: Joe, thanks for driving this! I think it is okay to remove those if we cannot find a better solution or just document that these are not expected to work in our documentation. Right ... I've been playing with some things here. - Using a slightly modified version of what is checked in I can only get the xrefs & doc included if I build the samples individually. If I attempt a top level build it just creates a whole lot of the xref and javadoc parts and leaves them littered throughout the src tree. It doesn't create the top level index to facilitate navigation. - I also have a lot of local changes to remove all the special reporting entries (and the copy of javadocs/xrefs into the wars too) in the hopes of getting creating a standard maven site using the defaults set in genesis. We could then publish this site. The exercise has been good because it exposed a number of other legal file issues that I've fixed locally. However, I'm still not able to generate a top level site. I'm trying to understand the mvn site generation better so that I can get this working. It probably makes sense to remove the xref and javadoc links from the sample UI anyway (or perhaps just direct them to one common maven site rather than include the specific content in the sample war). The links can't work for all of the samples anyway because some are just jsps with no java content (and hence there is no javadoc or xref generated). I would be in favor of releasing samples too but we need to make sure the samples all work with at least one particular version G server (probably both 2.1.2 and 2.1.3). Some of the samples may not work yet like the javamail one? I've verified all of the samples on both jetty & tomcat on both 2.1.2 and 2.1.3. This includes the javamail and directory sample (which which I've really only validated on 2.1.3 because I was using the directory plugin which cannot be installed on 2.1.2). They all work. The biggest outstanding item after the site generation is getting the doc updated but we can create a release candidate and vote without the doc being complete. ... I've been dragging my feet on the doc (there's always something else to work on :-) ). Lin On Wed, Sep 17, 2008 at 2:09 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: Joe Bohn wrote: - Most of the samples when run include a Geronimo header with links that are supposed to take you to javadocs and xref for that sample. These don't work (and from what I see I'm not sure if they were ever fully functional). So these should probably be removed if I can't find a way to quickly implement them.
[jira] Resolved: (GERONIMODEVTOOLS-517) Can't delete project from defined geronimo server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby resolved GERONIMODEVTOOLS-517. Resolution: Fixed Thanks for the patch, Delos! Applied with rev 697175 to branches/2.0.1 I see this fix was already in trunk. > Can't delete project from defined geronimo server > - > > Key: GERONIMODEVTOOLS-517 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows XP > 2. JDK: ibm jdk 5.0 SR6(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GERONIMODEVTOOLS-517.patch > > > Steps: > 1. Create a new sever in server view > 2. Create an new Dynamic Web Project "testweb" to eclipse > 3. Right click "testweb"->run on server, and then under "Servers" tab , > choose testweb, right > click" remove " this project from defined geronimo server, but no any reponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
On Sep 19, 2008, at 12:05 PM, David Blevins wrote: On Sep 18, 2008, at 3:40 PM, Jay D. McHugh wrote: I would like to be involved too. But, I don't have any experience with either AntHill or Hudson. Has anyone used Continuum? Would that be harder/easier to configure and use than the other two? The first version of GBuild ran a mashup of Continuum/ActiveMQ/ Maven. No GUI aside from the TCK reports though, it just used the backend part of continuum. It ran fine till the machines got hacked (not related to the testing software). Essentially the TCK was divided up into several individual build definitions and each of them were put on a JMS queue. Each of the build agents would pull a build definition from the queue, run it via the continuum backend, then send the results onto a JMS topic. There was another agent listening on the topic who would grab the results, add them to the rest of the results then rerun the report tool. It wouldn't be hard for us to set that up again, we'd just need VMs (the OS kind, not the java kind) on our two boxes so we can get more parallel processing without port conflicts. Anyone know if there are these kind of VMs setup already? Yes. Each box has 4 VM's :-) phoebe (tck01-04) and selene (tck05-08). --kevan
Re: Continuous TCK Testing
On Sep 19, 2008, at 12:26 PM, Donald Woods wrote: Can we really setup "continuous" TCK testing? How long does it take 2 VMs to complete a TCK run? I didn't mean to imply continuous integration-style testing. I think the rate of change on an branch/trunk under active development is likely going to exceed our ability to test every change. Shouldn't running the TCK prereq a Continuous Build first, by moving the automated builds that Jarek runs over to these machines and only run a build when there are svn changes in that branch (instead of a time based approach)? That would only generate builds on active branches (like 2.1 and trunk) while increasing the overall usage of these 2 machines to show that we're really using them. It could, but it's not necessary. I'd be happy to see once a day testing. This isn't about generating load on the boxes -- it's about generating value to the community. Also, which releases of Geronimo would we setup for automated TCK runs? Certainly 2.2 and 2.1 (IMO). We could throw in 2.0 if we have capacity and someone wants to set it up. We've also had requests from other projects to get some time (e.g. CXF). I'd be happy to see this happening, also. --kevan
GBean annotation docs
Didn't see them documented anywhere so I threw up a basic doc using Gianny's commit info and a few code examples. Might be a doc in another space I didn't notice. http://cwiki.apache.org/GMOxDEV/gbean-annotations.html Feel free to expand upon it. -David
[jira] Commented: (GERONIMODEVTOOLS-516) Fail to create application client in eclipse 3.3.2 with geronimo server adapter 2.0
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632755#action_12632755 ] Ted Kirby commented on GERONIMODEVTOOLS-516: This patch seems to be in trunk and 2.1.3. > Fail to create application client in eclipse 3.3.2 with geronimo server > adapter 2.0 > > > Key: GERONIMODEVTOOLS-516 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows 2003 Server,XP,ubuntu > 2. JDK: ibm jdk 5.0 SR8(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GeronimoDevtool-516.patch > > > Steps: > 1. Install wasce server adater 2.0 > 2.New an application client ->input name, click "next"->configuration, check > "geronimo deployment", > error launched: > Constrains for geronimo deployment 1.1 have not been met. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-516) Fail to create application client in eclipse 3.3.2 with geronimo server adapter 2.0
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632753#action_12632753 ] Ted Kirby commented on GERONIMODEVTOOLS-516: Thanks for the patch, Delos! Is this for the 2.0.x server adapter in trunk / branches 2.1.x? I don't know if we plan to do another 2.0.1 GEP release. Also, which plugin.xml file is this patch updating? Please create patches from devtools root. Thanks. > Fail to create application client in eclipse 3.3.2 with geronimo server > adapter 2.0 > > > Key: GERONIMODEVTOOLS-516 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows 2003 Server,XP,ubuntu > 2. JDK: ibm jdk 5.0 SR8(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GeronimoDevtool-516.patch > > > Steps: > 1. Install wasce server adater 2.0 > 2.New an application client ->input name, click "next"->configuration, check > "geronimo deployment", > error launched: > Constrains for geronimo deployment 1.1 have not been met. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Manu George as a new Geronimo Committer
Congrats Manu! Lin On Mon, Sep 15, 2008 at 9:20 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > All, > > The Apache Geronimo PMC is pleased to announce that Manu George has accepted > our invitation to become an Apache Geronimo committer. > > Congratulations Manu and welcome aboard! > > > > Thanks, > Donald Woods >
Re: Samples for 2.1.2 - one final push
Joe, thanks for driving this! I think it is okay to remove those if we cannot find a better solution or just document that these are not expected to work in our documentation. I would be in favor of releasing samples too but we need to make sure the samples all work with at least one particular version G server (probably both 2.1.2 and 2.1.3). Some of the samples may not work yet like the javamail one? Lin On Wed, Sep 17, 2008 at 2:09 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > Joe Bohn wrote: >> - Most of the samples when run include a Geronimo header with links that >> are supposed to take you to javadocs and xref for that sample. These don't >> work (and from what I see I'm not sure if they were ever fully functional). >> So these should probably be removed if I can't find a way to quickly >> implement them.
Re: svn commit: r694978 - in /geronimo/server/trunk: assemblies/geronimo-framework/ assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-jetty6-minimal/ assemblies/geronimo-tomcat6-javaee5/ assembl
Sorry for the resending... I thought my other message didn't get sent... this is something I don't quite like my gmail which didn't update the message sent by me promptly. Lin On Fri, Sep 19, 2008 at 1:07 PM, Lin Sun <[EMAIL PROTECTED]> wrote: > I think if we want to make users easier to build a project, the best > is that we can construct the dependency list automatically for the > user, perhaps at deployment time. This would even save the user from > listing plugin groups as dependencies in various geronimo deployment > plans. Maybe it is worthy while to investigate if it is possible to > do this? > > Lin > > On Wed, Sep 17, 2008 at 6:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: >> David Jencks wrote: >>> >>> On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote: >>> David Jencks wrote: > > On Sep 15, 2008, at 10:45 AM, Joe Bohn wrote: >> >> David Jencks wrote: >>> >>> On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote: Thanks for making these changes David. I think this mostly addresses my concern that plugingroups can be used anywhere plugins are used (it certainly helps now that they are all cars :-) ). So with the subject change ... is it now true what Lin mentioned earlier in the "[DISCUSS] plugingroups - another idea" thread: Lin Sun wrote: > For option 1, I guess I don't understand why we need the > classLoader > attribute. I think for plugin groups, we should not add the > plugin > group itself to the classloader, but we should add the dependencies > to > the classloader. For instance, if we support Joe's scenario, when > a > user specifies a plugin group as a dependency in his deployment > plan, > it would just add the dependencies that the plugin group depends on > to > the project's classloader. Will the dependencies of the plugingroup be added to the project's classloader? That would certainly resolve any concerns. >>> >>> I _think_ they will be in the maven build's classloader but definitely >>> not in the geronimo classloader. While this is inconsistent I don't >>> yet >>> see a reasonable use case for a plugingroup that doesn't have a >>> classloader >>> but does indicate a group of plugins that need to be added to some >>> projects >>> classloader. I needed the new functionality for other purposes so I >>> haven't >>> spent a lot of time thinking about this but a real concrete use case >>> would >>> go a long way for me. >> >> >> The scenario I had in mind is very simple. >> >> 1) A user has decided (for whatever reason) that they need a core >> server built on Geronimo including Jetty & Axis2. >> 2) The user will build multiple web applications and combine them on >> server images as the need arises and so they don't want to include the >> applications themselves in a custom server assembly. >> 2) To address the core server need, the user chooses to assemble their >> own server image with the two universal pre-reqs: the web-jetty and >> webservices-axis2 plugingroups. >> 3) The user then goes about building their web applications and >> generating geronimo plugins for these web apps to ease deployment. They >> want to ensure these applications are installed in the correct server >> configuration so they set the prereqs for the applications to match the >> core >> server image that they had earlier constructed - a prereq on the >> web-jetty >> and webservices-axis2 plugingroups. >> 4) The user will then install the server in the appropriate location(s) >> and deploy combinations of the applications on the as necessary on the >> server instances. >> >> Of course it is more correct to have the applications prereq the >> individual plugins necessary for jetty and axis2 runtimes rather than the >> plugingroups. However, that would mean that the user must understand the >> detailed plugins for building applications but only the plugingroups for >> building server images ... and the whole point of the plugingroups was to >> simplify things for the user so they could deal with higher level >> concepts. >> If that simplification makes sense for assembling a server (a relatively >> infrequent activity) why would it not also make sense for assembling an >> application (a somewhat more frequent activity)? >> >> And yes, I understand (as will the user) that the plugingroups may be >> pulling in more than they really need to run the applications - esp. if >> we >> continue to combine core function, deployers, and console extensions in >> the >> plugingroups. That may be a valid reason to alter the granularity of the >> groups
Re: svn commit: r694978 - in /geronimo/server/trunk: assemblies/geronimo-framework/ assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-jetty6-minimal/ assemblies/geronimo-tomcat6-javaee5/ assembl
I think if we want to make users easier to build a project, the best is that we can construct the dependency list automatically for the user, perhaps at deployment time. This would even save the user from listing plugin groups as dependencies in various geronimo deployment plans. Maybe it is worthy while to investigate if it is possible to do this? Lin On Wed, Sep 17, 2008 at 6:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > David Jencks wrote: >> >> On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote: >> >>> David Jencks wrote: On Sep 15, 2008, at 10:45 AM, Joe Bohn wrote: > > David Jencks wrote: >> >> On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote: >>> >>> Thanks for making these changes David. I think this mostly addresses >>> my concern that plugingroups can be used anywhere plugins are used (it >>> certainly helps now that they are all cars :-) ). >>> >>> So with the subject change ... is it now true what Lin mentioned >>> earlier in the "[DISCUSS] plugingroups - another idea" thread: >>> >>> Lin Sun wrote: >>> > For option 1, I guess I don't understand why we need the >>> > classLoader >>> > attribute. I think for plugin groups, we should not add the >>> > plugin >>> > group itself to the classloader, but we should add the dependencies >>> > to >>> > the classloader. For instance, if we support Joe's scenario, when >>> > a >>> > user specifies a plugin group as a dependency in his deployment >>> > plan, >>> > it would just add the dependencies that the plugin group depends on >>> > to >>> > the project's classloader. >>> >>> Will the dependencies of the plugingroup be added to the project's >>> classloader? That would certainly resolve any concerns. >> >> I _think_ they will be in the maven build's classloader but definitely >> not in the geronimo classloader. While this is inconsistent I don't yet >> see a reasonable use case for a plugingroup that doesn't have a >> classloader >> but does indicate a group of plugins that need to be added to some >> projects >> classloader. I needed the new functionality for other purposes so I >> haven't >> spent a lot of time thinking about this but a real concrete use case >> would >> go a long way for me. > > > The scenario I had in mind is very simple. > > 1) A user has decided (for whatever reason) that they need a core > server built on Geronimo including Jetty & Axis2. > 2) The user will build multiple web applications and combine them on > server images as the need arises and so they don't want to include the > applications themselves in a custom server assembly. > 2) To address the core server need, the user chooses to assemble their > own server image with the two universal pre-reqs: the web-jetty and > webservices-axis2 plugingroups. > 3) The user then goes about building their web applications and > generating geronimo plugins for these web apps to ease deployment. They > want to ensure these applications are installed in the correct server > configuration so they set the prereqs for the applications to match the > core > server image that they had earlier constructed - a prereq on the web-jetty > and webservices-axis2 plugingroups. > 4) The user will then install the server in the appropriate location(s) > and deploy combinations of the applications on the as necessary on the > server instances. > > Of course it is more correct to have the applications prereq the > individual plugins necessary for jetty and axis2 runtimes rather than the > plugingroups. However, that would mean that the user must understand the > detailed plugins for building applications but only the plugingroups for > building server images ... and the whole point of the plugingroups was to > simplify things for the user so they could deal with higher level > concepts. > If that simplification makes sense for assembling a server (a relatively > infrequent activity) why would it not also make sense for assembling an > application (a somewhat more frequent activity)? > > And yes, I understand (as will the user) that the plugingroups may be > pulling in more than they really need to run the applications - esp. if we > continue to combine core function, deployers, and console extensions in > the > plugingroups. That may be a valid reason to alter the granularity of the > groups we are creating. If not, another reason to split things up a > little > finer is to facilitate the construction of servers without deployment > capabilities - but that's really a separate discussion. To me it seems more like you are suggesting plugin groups as a workaround to another problem in the current plugin system, and I don't think yo
[jira] Commented: (GERONIMODEVTOOLS-518) Update GEP code with new Devtools URL
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632742#action_12632742 ] Ted Kirby commented on GERONIMODEVTOOLS-518: I fixed trunk with rev 697150. > Update GEP code with new Devtools URL > - > > Key: GERONIMODEVTOOLS-518 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518 > Project: Geronimo-Devtools > Issue Type: Bug >Affects Versions: 2.1.3, 2.2.0 >Reporter: Ted Kirby >Assignee: Ted Kirby > Fix For: 2.2.0 > > > Recently, the devtools sub-project homepage was changed from > http://geronimo.apache.org/development-tools.html to > http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html. > I have just found some references in the code to the old page that need to be > updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-518) Update GEP code with new Devtools URL
Update GEP code with new Devtools URL - Key: GERONIMODEVTOOLS-518 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-518 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.1.3, 2.2.0 Reporter: Ted Kirby Assignee: Ted Kirby Fix For: 2.2.0 Recently, the devtools sub-project homepage was changed from http://geronimo.apache.org/development-tools.html to http://cwiki.apache.org/GMOxDOC21/apache-geronimo-development-tools-project.html. I have just found some references in the code to the old page that need to be updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
Can we really setup "continuous" TCK testing? How long does it take 2 VMs to complete a TCK run? Shouldn't running the TCK prereq a Continuous Build first, by moving the automated builds that Jarek runs over to these machines and only run a build when there are svn changes in that branch (instead of a time based approach)? That would only generate builds on active branches (like 2.1 and trunk) while increasing the overall usage of these 2 machines to show that we're really using them. Also, which releases of Geronimo would we setup for automated TCK runs? -Donald Kevan Miller wrote: As many of you know, we have two apache.org machines for TCK testing of Geronimo (phoebe and selene). We used the machines for certification of our 2.1.3 release. However, this testing was run manually. It's time to get continuous, automatic TCK testing running on these machines. We had the basic setup running on GBuild machines. IIRC, this was built around AntHill -- Jason Dillon knows it best. There are other testing systems available (e.g. Hudson) which could be used for this task. What do others think? What underlying technology should we use? Who wants to get involved? I think this discussion should be on our dev@ mailing list. TCK should be for test specific discussions. --kevan
Re: Lets use gshell for all startup stuff
Agree that everything should use GShell. The point of G4093 was to make the scripts in the 2.1.x release consistent in how Java was used (some scripts used JRE/JAVA_HOME while others used whatever was on the PATH.) I'm fine in changing this for 2.2, especially given there will only be one way (GShell) for starting/stopping the server, launching the deployer and wsgen tools and for client apps. -Donald David Jencks wrote: Lets change the scripts in bin that don't use gshell to use gshell. Then the helper scripts such as setjavaenv.sh will only be used for starting gshell and I hopefully they won't need most of their current contents. As noted in GERONIMO-4093 I'm not OK with requiring JAVA_HOME to be defined on systems that don't need it, and I took matters into my own hands and restored the old behavior of using "java" if JAVA_HOME is not defined. I'm barely literate in bash so there may well be a better solution. thanks david jencks
Re: Continuous TCK Testing
On Sep 18, 2008, at 3:40 PM, Jay D. McHugh wrote: I would like to be involved too. But, I don't have any experience with either AntHill or Hudson. Has anyone used Continuum? Would that be harder/easier to configure and use than the other two? The first version of GBuild ran a mashup of Continuum/ActiveMQ/Maven. No GUI aside from the TCK reports though, it just used the backend part of continuum. It ran fine till the machines got hacked (not related to the testing software). Essentially the TCK was divided up into several individual build definitions and each of them were put on a JMS queue. Each of the build agents would pull a build definition from the queue, run it via the continuum backend, then send the results onto a JMS topic. There was another agent listening on the topic who would grab the results, add them to the rest of the results then rerun the report tool. It wouldn't be hard for us to set that up again, we'd just need VMs (the OS kind, not the java kind) on our two boxes so we can get more parallel processing without port conflicts. Anyone know if there are these kind of VMs setup already? -David
Re: [BUILD] trunk: Failed for Revision: 697080
I think I broke it, about to start looking for a solution.
thanks
david jencks
On Sep 19, 2008, at 8:14 AM, Donald Woods wrote:
The deployer failures are for all the offline tests, which all fail
with the following -
Exception in thread "main" java.lang.ClassCastException:
org.apache.geronimo.connector.deployment.RARConfigurer cannot be
cast to org.apache.geronimo.deployment.ModuleConfigurer
at
org
.apache
.geronimo
.deployment
.plugin
.jmx
.LocalDeploymentManager
.loadModuleConfigurers(LocalDeploymentManager.java:51)
at
org
.apache
.geronimo
.deployment
.plugin
.jmx.LocalDeploymentManager.(LocalDeploymentManager.java:41)
at
org
.apache
.geronimo
.deployment.cli.ServerConnection.(ServerConnection.java:93)
at
org
.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:
161)
at
org
.apache
.geronimo
.kernel
.util
.MainConfigurationBootstrapper
.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
Not sure which change in the past few weeks caused this.
-Donald
[EMAIL PROTECTED] wrote:
Geronimo Revision: 697080 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 27 seconds
[INFO] Finished at: Fri Sep 19 09:42:51 EDT 2008
[INFO] Final Memory: 375M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/logs-0900-tomcat/test.log
[INFO] Redirecting output to: /home/geronimo/geronimo/trunk/
testsuite/target/selenium/server.log
[INFO] User extensions: /home/geronimo/geronimo/trunk/testsuite/
target/selenium/user-extensions.js
Selenium Server started
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot org.apache.geronimo.assemblies:geronimo-tomcat6-
javaee5:2.2-SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.assemblies:geronimo-tomcat6-
javaee5:2.2-SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.assemblies:geronimo-tomcat6-
javaee5:2.2-SNAPSHOT: checking for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-
SNAPSHOT:provided
[INFO] Using geronimoHome: /home/geronimo/geronimo/trunk/testsuite/
target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: /home/geronimo/.m2/repository/org/apache/geronimo/
assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-
javaee5-2.2-SNAPSHOT-bin.zip into /home/geronimo/geronimo/trunk/
testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: /home/geronimo/geronimo/trunk/
testsuite/target/geronimo-logs/
org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:38.477
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml
to /home/geronimo/.m2/repository/org/apache/geronimo/testsuite/
testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 32 test build(s)
[INFO] [INFO]
---
[INFO] [INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deployFAILURE
(0:01:12.041) Java returned: 1
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS
(0:00:30.213) [INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS
(0:00:19.960) [INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS
(0:00:16.484) [INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS
(0:06:16.309) [INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE
(0:00:50.844) Java returned: 1
[INFO] console-testsuite/basic RUN
[jira] Commented: (GERONIMO-4306) Plugin list won't be updated after installing a new server plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632720#action_12632720 ] Donald Woods commented on GERONIMO-4306: A manual refresh is not user friendly, as how do we convey to the user when they need to refresh? A couple second delay while the list is rebuilt isn't a major problem. Maybe we need to show a status/progress indicator that the list is being rebuilt > Plugin list won't be updated after installing a new server plugin > - > > Key: GERONIMO-4306 > URL: https://issues.apache.org/jira/browse/GERONIMO-4306 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.3 >Reporter: Rex Wang > Fix For: 2.1.4, 2.2 > > Attachments: GERONIMO-4306.patch > > > Steps: > 1. Login web console > 2. Go to "Plugin -> Assemble Server" portlet, and click the button - > "Assemble a server", then get the current plugin list. > 3. Go to "Plugin -> Install Plugins" portlet to install a new plugin > 4. Go back to the "Assemble Server", and click the button, then the list is > not updated. > Proposed fix: > 1. > In "AssemblyListHandler.java", we cached the plugin list in portlet session, > and that won't be updated after installing a new plugin by web console. > If we add codes to refresh the session after installing a plugin in "Install > Plugins" portlet, it seems to solve this problem. But it does not work for > using the gsh to install new plugins. > So, we have to let the AssemblyListHandler load the plugin list each time we > open the portlet. And good news is that I did not see any significant > performance falling. > 2. > And another method to solve this problem is that "ask user to logout and > login back when they install some plugins if they want to see their plugins > list in the 'assemble Server' portlet", but is it acceptable? > If the #1 is more reasonable, I can provide a patch. > Thanks > Rex -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [BUILD] trunk: Failed for Revision: 697080
The deployer failures are for all the offline tests, which all fail with
the following -
Exception in thread "main" java.lang.ClassCastException:
org.apache.geronimo.connector.deployment.RARConfigurer cannot be cast to
org.apache.geronimo.deployment.ModuleConfigurer
at
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.loadModuleConfigurers(LocalDeploymentManager.java:51)
at
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.(LocalDeploymentManager.java:41)
at
org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:93)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
Not sure which change in the past few weeks caused this.
-Donald
[EMAIL PROTECTED] wrote:
Geronimo Revision: 697080 built with tests included
See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/build-0900.log
Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 27 seconds
[INFO] Finished at: Fri Sep 19 09:42:51 EDT 2008
[INFO] Final Memory: 375M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/logs-0900-tomcat/test.log
[INFO] Redirecting output to: /home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:38.477
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 32 test build(s)
[INFO]
[INFO] ---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deployFAILURE (0:01:12.041) Java
returned: 1
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:30.213)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.960)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.484)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:16.309)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:50.844) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:46.805)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.251)
[I
[BUILD] trunk: Failed for Revision: 697080
Geronimo Revision: 697080 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 27 seconds
[INFO] Finished at: Fri Sep 19 09:42:51 EDT 2008
[INFO] Final Memory: 375M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/logs-0900-tomcat/test.log
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions:
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:38.477
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 32 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deployFAILURE (0:01:12.041) Java
returned: 1
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:30.213)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.960)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.484)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:16.309)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:50.844) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:46.805)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.251)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:49.424)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:42.749)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.531)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.856)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.657)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:43.014)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:48.333)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:54.503)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise
Re: svn commit: r694978 - in /geronimo/server/trunk: assemblies/geronimo-framework/ assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-jetty6-minimal/ assemblies/geronimo-tomcat6-javaee5/ assembl
I think if we want to make things easier for our users, it is best to have some automated method to determine what modules should be added on the dependency list automatically, perhaps during deployment time. That way, a user would not need to specify any dependency at all (even save them from listing plugin groups as dependencies). Lin On Wed, Sep 17, 2008 at 6:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > David Jencks wrote: >> >> On Sep 15, 2008, at 11:41 AM, Joe Bohn wrote: >> >>> David Jencks wrote: On Sep 15, 2008, at 10:45 AM, Joe Bohn wrote: > > David Jencks wrote: >> >> On Sep 15, 2008, at 6:18 AM, Joe Bohn wrote: >>> >>> Thanks for making these changes David. I think this mostly addresses >>> my concern that plugingroups can be used anywhere plugins are used (it >>> certainly helps now that they are all cars :-) ). >>> >>> So with the subject change ... is it now true what Lin mentioned >>> earlier in the "[DISCUSS] plugingroups - another idea" thread: >>> >>> Lin Sun wrote: >>> > For option 1, I guess I don't understand why we need the >>> > classLoader >>> > attribute. I think for plugin groups, we should not add the >>> > plugin >>> > group itself to the classloader, but we should add the dependencies >>> > to >>> > the classloader. For instance, if we support Joe's scenario, when >>> > a >>> > user specifies a plugin group as a dependency in his deployment >>> > plan, >>> > it would just add the dependencies that the plugin group depends on >>> > to >>> > the project's classloader. >>> >>> Will the dependencies of the plugingroup be added to the project's >>> classloader? That would certainly resolve any concerns. >> >> I _think_ they will be in the maven build's classloader but definitely >> not in the geronimo classloader. While this is inconsistent I don't yet >> see a reasonable use case for a plugingroup that doesn't have a >> classloader >> but does indicate a group of plugins that need to be added to some >> projects >> classloader. I needed the new functionality for other purposes so I >> haven't >> spent a lot of time thinking about this but a real concrete use case >> would >> go a long way for me. > > > The scenario I had in mind is very simple. > > 1) A user has decided (for whatever reason) that they need a core > server built on Geronimo including Jetty & Axis2. > 2) The user will build multiple web applications and combine them on > server images as the need arises and so they don't want to include the > applications themselves in a custom server assembly. > 2) To address the core server need, the user chooses to assemble their > own server image with the two universal pre-reqs: the web-jetty and > webservices-axis2 plugingroups. > 3) The user then goes about building their web applications and > generating geronimo plugins for these web apps to ease deployment. They > want to ensure these applications are installed in the correct server > configuration so they set the prereqs for the applications to match the > core > server image that they had earlier constructed - a prereq on the web-jetty > and webservices-axis2 plugingroups. > 4) The user will then install the server in the appropriate location(s) > and deploy combinations of the applications on the as necessary on the > server instances. > > Of course it is more correct to have the applications prereq the > individual plugins necessary for jetty and axis2 runtimes rather than the > plugingroups. However, that would mean that the user must understand the > detailed plugins for building applications but only the plugingroups for > building server images ... and the whole point of the plugingroups was to > simplify things for the user so they could deal with higher level > concepts. > If that simplification makes sense for assembling a server (a relatively > infrequent activity) why would it not also make sense for assembling an > application (a somewhat more frequent activity)? > > And yes, I understand (as will the user) that the plugingroups may be > pulling in more than they really need to run the applications - esp. if we > continue to combine core function, deployers, and console extensions in > the > plugingroups. That may be a valid reason to alter the granularity of the > groups we are creating. If not, another reason to split things up a > little > finer is to facilitate the construction of servers without deployment > capabilities - but that's really a separate discussion. To me it seems more like you are suggesting plugin groups as a workaround to another problem in the current plugin system, and I don't think your suggestion will
Re: svn commit: r694978 - in /geronimo/server/trunk: assemblies/geronimo-framework/ assemblies/geronimo-jetty6-javaee5/ assemblies/geronimo-jetty6-minimal/ assemblies/geronimo-tomcat6-javaee5/ assembl
David, thanks a bunch for making the change! Looks good to me.
Lin
On Sat, Sep 13, 2008 at 12:13 PM, <[EMAIL PROTECTED]> wrote:
> Author: djencks
> Date: Sat Sep 13 09:13:58 2008
> New Revision: 694978
>
> URL: http://svn.apache.org/viewvc?rev=694978&view=rev
> Log:
> GERONIMO-4300 allow c-m-p to generate plugins with no classloader,
> dependending on absence of plan
>
> Removed:
>geronimo/server/trunk/plugingroups/client/src/main/plan/
>geronimo/server/trunk/plugingroups/clustering/src/main/plan/
>geronimo/server/trunk/plugingroups/ejb/src/main/plan/
>geronimo/server/trunk/plugingroups/framework/src/main/plan/
>geronimo/server/trunk/plugingroups/jms/src/main/plan/
>geronimo/server/trunk/plugingroups/persistence/src/main/plan/
>geronimo/server/trunk/plugingroups/web-jetty/src/main/plan/
>geronimo/server/trunk/plugingroups/web-tomcat/src/main/plan/
>geronimo/server/trunk/plugingroups/webservices-axis2/src/main/plan/
>geronimo/server/trunk/plugingroups/webservices-cxf/src/main/plan/
> Modified:
>geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
>geronimo/server/trunk/assemblies/geronimo-jetty6-javaee5/pom.xml
>geronimo/server/trunk/assemblies/geronimo-jetty6-minimal/pom.xml
>geronimo/server/trunk/assemblies/geronimo-tomcat6-javaee5/pom.xml
>geronimo/server/trunk/assemblies/geronimo-tomcat6-minimal/pom.xml
>
> geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ArchiveCarMojo.java
>
> geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/PlanProcessorMojo.java
>geronimo/server/trunk/plugingroups/client/pom.xml
>geronimo/server/trunk/plugingroups/clustering/pom.xml
>geronimo/server/trunk/plugingroups/ejb/pom.xml
>geronimo/server/trunk/plugingroups/jms/pom.xml
>geronimo/server/trunk/plugingroups/persistence/pom.xml
>geronimo/server/trunk/plugingroups/web-jetty/pom.xml
>geronimo/server/trunk/plugingroups/web-tomcat/pom.xml
>geronimo/server/trunk/plugingroups/webservices-axis2/pom.xml
>geronimo/server/trunk/plugingroups/webservices-cxf/pom.xml
>
> Modified: geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-framework/pom.xml?rev=694978&r1=694977&r2=694978&view=diff
> ==
> --- geronimo/server/trunk/assemblies/geronimo-framework/pom.xml (original)
> +++ geronimo/server/trunk/assemblies/geronimo-framework/pom.xml Sat Sep 13
> 09:13:58 2008
> @@ -38,85 +38,8 @@
>
>
>
> -org.apache.geronimo.assemblies
> -geronimo-boilerplate
> -${version}
> -
> -
> -
> -org.apache.geronimo.framework
> -gshell-framework
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -gshell-geronimo
> -${version}
> -car
> -
> -
> -
> -
> -
> -org.apache.geronimo.framework
> -gshell-remote
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -j2ee-system
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -client-system
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -rmi-naming
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -plugin
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -j2ee-security
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -server-security-config
> -${version}
> -car
> -
> -
> -
> -org.apache.geronimo.framework
> -shutdown
> +org.apache.geronimo.plugingroups
> +framework
> ${version}
> car
>
>
> Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-javaee5/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-jetty6-javaee5/pom.xml?rev=694978&r1=694977&r2=694978&view=diff
> ==
> --- geronimo/server/trunk/assemblies/geronimo-jetty6-javaee5/pom.xml
> (original)
> +++ geronimo/server/trunk/assemblies/geronimo-jetty6-javaee5/pom.xml Sat Sep
> 13 09:13:58 2008
> @@ -609,108 +609,115 @@
>
>
> org.apache.geronimo.plugingroups
> +framework
> +${ver
Re: GShell update
FYI, I've just started to update the gshell-remote-* and gshell- whisper stuff to integrate with wisdom/spring... so might take a few days before the remote shell commands will work again. It compiles now, but I've yet to actually get a rsh/rsh-server connection working. The plan is to make it work asis with as little changes as possible... then if needed (and probably) refactor to make use of the spring container to allow richer configuration. --jason On Sep 19, 2008, at 7:17 PM, Guillaume Nodet wrote: Doh, find the answer to my last question. The build was disable in idea project did not show whisper. My bad! On Fri, Sep 19, 2008 at 2:13 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Just had a look at the current code, and I want to point a possible problem. Bear with me if I misunderstood something. When a command is created from spring, we have the following bean definition: which means that the SleepCommand is bean created from spring as a singleton. When the command is executed, the bean is populated with the arguments from the command line and executed. It seems to me that the design has a flaw in that it is not thread safe: the same bean will be used to serve multiple commands. Even more annoying, the bean is not reset to a clean state, meaning that command arguments will be kept from one execution to the other if they have not been overriden by the command line. I think a possible and simple workaround would be to create a new instance of the bean each time it is executed. That's what we've done in ServiceMix on the older version of gshell using the OsgiCommandSupport. The createCommand() is called and by default create a new instance of the command to be populated and executed. If a command has specific wiring or injections, it has to override this method and populate the new bean after creation. This is not really clean, but it was working at that time. Also, another unrelated point, where is the whipser stuff now ? I could not find it or any replacement in the svn tree ... [1] http://svn.apache.org/repos/asf/servicemix/smx4/kernel/trunk/gshell/gshell-core/src/main/java/org/apache/geronimo/gshell/support/OsgiCommandSupport.java On Thu, Sep 11, 2008 at 8:17 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Finally got back to hacking on GShell... and have been working on replacing the Plexus container with a Spring container. Today I finally got it working correctly, using maven repository for dependencies. Still got some work left to do to clean up the layout muck and make the help command functional again, but its in progress. Anyways, just a tiny update that things are progressing I'm not sure what is gonna happen with the gshell-rapture/plexus integration... as I get more and more into the gshell-wisdom/spring integration I'm feeling more and more that I should just drop the plexus stuff. We are still using plexus though to load the ArtifactManager used to resolve the GShell applications classpath, though I have hopes that the new Maven Mercury API can be used and requires less Plexus muck to work, but I've not actually tried that yet. Also the current gshell-artifact integration requires most of the Maven 2.1.* artifacts to resolve poms, which I'm tempted to just replace with a wee bit of xstream model stuff to *simulate* the basics needed to resolve an artifacts transitive dependencies... but for now I just use Maven, which inflates the system like 2m... sucky, but it works. So, the main design issue we have right now is what to do with the layout muck... might rip it out, have a flat list of commands and then re- implement the hierarchy... hot sure yet. Anyways... making progress. --jason -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com
[jira] Reopened: (GERONIMO-4306) Plugin list won't be updated after installing a new server plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reopened GERONIMO-4306: --- Assignee: (was: Jarek Gawor) Currently, the plugin or app module list is stored along with PortletSession and it will be expired whenever the PortletSession is expired. We did this on purpose as it is expensive (I can notice the slow down for a few seconds) to get the list from server whenever the page is visited. I'd prefer to have a refresh button (within the portlet) to explicitly for the user to refresh the plugin or app module list whenever the user desires to do so. Otherwise, we'll just retrieve the cached data. Thoughts? Lin > Plugin list won't be updated after installing a new server plugin > - > > Key: GERONIMO-4306 > URL: https://issues.apache.org/jira/browse/GERONIMO-4306 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.3 >Reporter: Rex Wang > Fix For: 2.1.4, 2.2 > > Attachments: GERONIMO-4306.patch > > > Steps: > 1. Login web console > 2. Go to "Plugin -> Assemble Server" portlet, and click the button - > "Assemble a server", then get the current plugin list. > 3. Go to "Plugin -> Install Plugins" portlet to install a new plugin > 4. Go back to the "Assemble Server", and click the button, then the list is > not updated. > Proposed fix: > 1. > In "AssemblyListHandler.java", we cached the plugin list in portlet session, > and that won't be updated after installing a new plugin by web console. > If we add codes to refresh the session after installing a plugin in "Install > Plugins" portlet, it seems to solve this problem. But it does not work for > using the gsh to install new plugins. > So, we have to let the AssemblyListHandler load the plugin list each time we > open the portlet. And good news is that I did not see any significant > performance falling. > 2. > And another method to solve this problem is that "ask user to logout and > login back when they install some plugins if they want to see their plugins > list in the 'assemble Server' portlet", but is it acceptable? > If the #1 is more reasonable, I can provide a patch. > Thanks > Rex -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.1: Failed for Revision: 697056
Geronimo Revision: 697056 built with tests included See the full build-0800.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/build-0800.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 35 minutes 4 seconds [INFO] Finished at: Fri Sep 19 08:42:41 EDT 2008 [INFO] Final Memory: 307M/1016M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/logs-0800-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/logs-0800-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 76.315 sec <<< FAILURE! Samples: branches/2.1 = Log: http://people.apache.org/builds/geronimo/server/binaries/2.1/20080919/samples-0800.log Build status: OK
Re: GShell update
Yup, I know... still need to figure that out actually. Keep in mind I'm not done hacking up this stuff just yet, I hope to solve this problem soon... but before I do that I'm going to re-enable all the other previously disabled stuff (like whisper and remote support) and make sure that works. BTW, I'm glad you are looking at this stuff. I'm currently full steam ahead working on getting spring enabled (and liking it much more than plexus)... but if you have some time to keep reviewing or help out in any other manner I'd really appreciate it! --jason On Sep 19, 2008, at 7:13 PM, Guillaume Nodet wrote: Just had a look at the current code, and I want to point a possible problem. Bear with me if I misunderstood something. When a command is created from spring, we have the following bean definition: which means that the SleepCommand is bean created from spring as a singleton. When the command is executed, the bean is populated with the arguments from the command line and executed. It seems to me that the design has a flaw in that it is not thread safe: the same bean will be used to serve multiple commands. Even more annoying, the bean is not reset to a clean state, meaning that command arguments will be kept from one execution to the other if they have not been overriden by the command line. I think a possible and simple workaround would be to create a new instance of the bean each time it is executed. That's what we've done in ServiceMix on the older version of gshell using the OsgiCommandSupport. The createCommand() is called and by default create a new instance of the command to be populated and executed. If a command has specific wiring or injections, it has to override this method and populate the new bean after creation. This is not really clean, but it was working at that time. Also, another unrelated point, where is the whipser stuff now ? I could not find it or any replacement in the svn tree ... [1] http://svn.apache.org/repos/asf/servicemix/smx4/kernel/trunk/gshell/gshell-core/src/main/java/org/apache/geronimo/gshell/support/OsgiCommandSupport.java On Thu, Sep 11, 2008 at 8:17 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Finally got back to hacking on GShell... and have been working on replacing the Plexus container with a Spring container. Today I finally got it working correctly, using maven repository for dependencies. Still got some work left to do to clean up the layout muck and make the help command functional again, but its in progress. Anyways, just a tiny update that things are progressing I'm not sure what is gonna happen with the gshell-rapture/plexus integration... as I get more and more into the gshell-wisdom/spring integration I'm feeling more and more that I should just drop the plexus stuff. We are still using plexus though to load the ArtifactManager used to resolve the GShell applications classpath, though I have hopes that the new Maven Mercury API can be used and requires less Plexus muck to work, but I've not actually tried that yet. Also the current gshell-artifact integration requires most of the Maven 2.1.* artifacts to resolve poms, which I'm tempted to just replace with a wee bit of xstream model stuff to *simulate* the basics needed to resolve an artifacts transitive dependencies... but for now I just use Maven, which inflates the system like 2m... sucky, but it works. So, the main design issue we have right now is what to do with the layout muck... might rip it out, have a flat list of commands and then re- implement the hierarchy... hot sure yet. Anyways... making progress. --jason -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com
Re: GShell update
Doh, find the answer to my last question. The build was disable in idea project did not show whisper. My bad! On Fri, Sep 19, 2008 at 2:13 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Just had a look at the current code, and I want to point a possible problem. > Bear with me if I misunderstood something. > When a command is created from spring, we have the following bean definition: > > class="org.apache.geronimo.gshell.wisdom.command.CommandImpl"> > > > > class="org.apache.geronimo.gshell.commands.optional.SleepCommand"/> > > > > which means that the SleepCommand is bean created from spring as a singleton. > When the command is executed, the bean is populated with the arguments > from the command line and executed. > It seems to me that the design has a flaw in that it is not thread > safe: the same bean will be used to serve multiple commands. > Even more annoying, the bean is not reset to a clean state, meaning > that command arguments will be kept from one > execution to the other if they have not been overriden by the command line. > > I think a possible and simple workaround would be to create a new > instance of the bean each time it is executed. > That's what we've done in ServiceMix on the older version of gshell > using the OsgiCommandSupport. > The createCommand() is called and by default create a new instance of > the command to be populated and executed. > If a command has specific wiring or injections, it has to override > this method and populate the new bean after creation. > This is not really clean, but it was working at that time. > > Also, another unrelated point, where is the whipser stuff now ? I > could not find it or any replacement in the svn tree ... > > [1] > http://svn.apache.org/repos/asf/servicemix/smx4/kernel/trunk/gshell/gshell-core/src/main/java/org/apache/geronimo/gshell/support/OsgiCommandSupport.java > > On Thu, Sep 11, 2008 at 8:17 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: >> Finally got back to hacking on GShell... and have been working on replacing >> the Plexus container with a Spring container. Today I finally got it >> working correctly, using maven repository for dependencies. >> >> Still got some work left to do to clean up the layout muck and make the help >> command functional again, but its in progress. >> >> Anyways, just a tiny update that things are progressing >> >> I'm not sure what is gonna happen with the gshell-rapture/plexus >> integration... as I get more and more into the gshell-wisdom/spring >> integration I'm feeling more and more that I should just drop the plexus >> stuff. We are still using plexus though to load the ArtifactManager used to >> resolve the GShell applications classpath, though I have hopes that the new >> Maven Mercury API can be used and requires less Plexus muck to work, but >> I've not actually tried that yet. Also the current gshell-artifact >> integration requires most of the Maven 2.1.* artifacts to resolve poms, >> which I'm tempted to just replace with a wee bit of xstream model stuff to >> *simulate* the basics needed to resolve an artifacts transitive >> dependencies... but for now I just use Maven, which inflates the system like >> 2m... sucky, but it works. >> >> So, the main design issue we have right now is what to do with the layout >> muck... might rip it out, have a flat list of commands and then re-implement >> the hierarchy... hot sure yet. >> >> Anyways... making progress. >> >> --jason >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://open.iona.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com
Re: GShell update
Just had a look at the current code, and I want to point a possible problem. Bear with me if I misunderstood something. When a command is created from spring, we have the following bean definition: which means that the SleepCommand is bean created from spring as a singleton. When the command is executed, the bean is populated with the arguments from the command line and executed. It seems to me that the design has a flaw in that it is not thread safe: the same bean will be used to serve multiple commands. Even more annoying, the bean is not reset to a clean state, meaning that command arguments will be kept from one execution to the other if they have not been overriden by the command line. I think a possible and simple workaround would be to create a new instance of the bean each time it is executed. That's what we've done in ServiceMix on the older version of gshell using the OsgiCommandSupport. The createCommand() is called and by default create a new instance of the command to be populated and executed. If a command has specific wiring or injections, it has to override this method and populate the new bean after creation. This is not really clean, but it was working at that time. Also, another unrelated point, where is the whipser stuff now ? I could not find it or any replacement in the svn tree ... [1] http://svn.apache.org/repos/asf/servicemix/smx4/kernel/trunk/gshell/gshell-core/src/main/java/org/apache/geronimo/gshell/support/OsgiCommandSupport.java On Thu, Sep 11, 2008 at 8:17 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > Finally got back to hacking on GShell... and have been working on replacing > the Plexus container with a Spring container. Today I finally got it > working correctly, using maven repository for dependencies. > > Still got some work left to do to clean up the layout muck and make the help > command functional again, but its in progress. > > Anyways, just a tiny update that things are progressing > > I'm not sure what is gonna happen with the gshell-rapture/plexus > integration... as I get more and more into the gshell-wisdom/spring > integration I'm feeling more and more that I should just drop the plexus > stuff. We are still using plexus though to load the ArtifactManager used to > resolve the GShell applications classpath, though I have hopes that the new > Maven Mercury API can be used and requires less Plexus muck to work, but > I've not actually tried that yet. Also the current gshell-artifact > integration requires most of the Maven 2.1.* artifacts to resolve poms, > which I'm tempted to just replace with a wee bit of xstream model stuff to > *simulate* the basics needed to resolve an artifacts transitive > dependencies... but for now I just use Maven, which inflates the system like > 2m... sucky, but it works. > > So, the main design issue we have right now is what to do with the layout > muck... might rip it out, have a flat list of commands and then re-implement > the hierarchy... hot sure yet. > > Anyways... making progress. > > --jason > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com
[jira] Updated: (GERONIMODEVTOOLS-517) Can't delete project from defined geronimo server
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai updated GERONIMODEVTOOLS-517: --- Attachment: GERONIMODEVTOOLS-517.patch Add a null check in canModifyModules() method > Can't delete project from defined geronimo server > - > > Key: GERONIMODEVTOOLS-517 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows XP > 2. JDK: ibm jdk 5.0 SR6(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GERONIMODEVTOOLS-517.patch > > > Steps: > 1. Create a new sever in server view > 2. Create an new Dynamic Web Project "testweb" to eclipse > 3. Right click "testweb"->run on server, and then under "Servers" tab , > choose testweb, right > click" remove " this project from defined geronimo server, but no any reponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-517) Can't delete project from defined geronimo server
Can't delete project from defined geronimo server - Key: GERONIMODEVTOOLS-517 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-517 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: SW: 1. OS: Windows XP 2. JDK: ibm jdk 5.0 SR6(embedded in build) HW: Intel x86 32bit Reporter: Delos Dai Assignee: Tim McConnell Steps: 1. Create a new sever in server view 2. Create an new Dynamic Web Project "testweb" to eclipse 3. Right click "testweb"->run on server, and then under "Servers" tab , choose testweb, right click" remove " this project from defined geronimo server, but no any reponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-516) Fail to create application client in eclipse 3.3.2 with geronimo server adapter 2.0
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai updated GERONIMODEVTOOLS-516: --- Attachment: GeronimoDevtool-516.patch Add a entry of jst.appclient 5.0 in the required facet list > Fail to create application client in eclipse 3.3.2 with geronimo server > adapter 2.0 > > > Key: GERONIMODEVTOOLS-516 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0.0 > Environment: SW: > 1. OS: Windows 2003 Server,XP,ubuntu > 2. JDK: ibm jdk 5.0 SR8(embedded in build) > HW: > Intel x86 32bit >Reporter: Delos Dai >Assignee: Tim McConnell > Attachments: GeronimoDevtool-516.patch > > > Steps: > 1. Install wasce server adater 2.0 > 2.New an application client ->input name, click "next"->configuration, check > "geronimo deployment", > error launched: > Constrains for geronimo deployment 1.1 have not been met. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-516) Fail to create application client in eclipse 3.3.2 with geronimo server adapter 2.0
Fail to create application client in eclipse 3.3.2 with geronimo server adapter 2.0 Key: GERONIMODEVTOOLS-516 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-516 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: SW: 1. OS: Windows 2003 Server,XP,ubuntu 2. JDK: ibm jdk 5.0 SR8(embedded in build) HW: Intel x86 32bit Reporter: Delos Dai Assignee: Tim McConnell Steps: 1. Install wasce server adater 2.0 2.New an application client ->input name, click "next"->configuration, check "geronimo deployment", error launched: Constrains for geronimo deployment 1.1 have not been met. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 696948
Geronimo Revision: 696948 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 40 minutes 17 seconds [INFO] Finished at: Fri Sep 19 03:44:06 EDT 2008 [INFO] Final Memory: 394M/921M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080919/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/75 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/75 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car started in .195s Module 4/75 org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car started in .000s Module 5/75 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 6/75 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car started in .867s Module 7/75 org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car started in .451s Module 8/75 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car started in 1.447s Module 9/75 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car started in .072s Module 10/75 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car started in .000s Module 11/75 org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car started in .000s Module 12/75 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car started in .000s Module 13/75 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car started in .236s Module 14/75 org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car started in .045s Module 15/75 org.apache.geronimo.configs/derby/2.2-SNAPSHOT/car started in .000s Module 16/75 org.apache.geronimo.configs/system-database/2.2-SNAPSHOT/car started in 4.558s Module 17/75 org.apache.geronimo.configs/activemq-broker/2.2-SNAPSHOT/car started in 2.101s Module 18/75 org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car started in .008s Module 19/75 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car started in .000s Module 20/75 org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car 03:49:49,017 WARN [service] Property "Cache" not supported by "Default Stateful Container" 03:49:49,017 WARN [service] Property "Passivator" not supported by "Default Stateful Container" 03:49:49,018 WARN [service] Property "TimeOut" not supported by "Default Stateful Container" 03:49:49,018 WARN [service] Property "PoolSize" not supported by "Default Stateful Container" 03:49:49,018 WARN [service] Property "BulkPassivate" not supported by "Default Stateful Container" started in .957s Module 21/75 org.apache.geronimo.configs/axis/2.2-SNAPSHOT/car started in .140s Module 22/75 org.apache.geronimo.configs/axis2/2.2-SNAPSHOT/car started in .000s Module 23/75 org.apache.geronimo.configs/axis2-ejb/2.2-SNAPSHOT/car started in .000s Module 24/75 org.apache.geronimo.configs/j2ee-corba-yoko/2.2-SNAPSHOT/car started in .859s Module 25/75 org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car started in .004s Module 26/75 org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car started in 2.028s Module 27/75 org.apache.geronimo.config
