Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
I just updated the web site, added the new download page that now includes the framework binaries, new software box for 2.1 and news section on the home page. It will take some time till reflected on the live site, for now you can check the dev server to see these changes http://cwiki.apache.org/GMOxSITE/ Cheers! Hernan Kevan Miller wrote: Looks like we have consensus for releasing our binaries. I'll push them out this morning. --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Yay :-) --jason -Original Message- From: Kevan Miller <[EMAIL PROTECTED]> Date: Mon, 18 Feb 2008 08:34:47 To:dev@geronimo.apache.org Subject: Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases Looks like we have consensus for releasing our binaries. I'll push them out this morning. --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Looks like we have consensus for releasing our binaries. I'll push them out this morning. --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 15, 2008, at 12:18 PM, David Jencks wrote: On Feb 15, 2008, at 9:07 AM, Kevan Miller wrote: On Feb 15, 2008, at 11:46 AM, Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED] > wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Sounds like a 2.1.1 fix to me. Will look to hear from others... I'm OK with fixing this in 2.1.1. Did this work in 2.0.2? Can anyone see a way to run our console-testsuite twice, on http:8080 and https:8443? I did test and confirm that this was working on 2.0.2. Been wondering the same thing. Would definitely be good, to get testing on both ports. Good chance that this has been a problem since we switched to the new version of Pluto... I think it would also be good if we could provide a runtime configuration option so the console could only be accessed with https:8443 and possibly on a specific host or virtual host. I'm not sure how to do this without changing the web.xml however. Agreed. --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 15, 2008, at 9:07 AM, Kevan Miller wrote: On Feb 15, 2008, at 11:46 AM, Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Sounds like a 2.1.1 fix to me. Will look to hear from others... I'm OK with fixing this in 2.1.1. Did this work in 2.0.2? Can anyone see a way to run our console-testsuite twice, on http:8080 and https:8443? I think it would also be good if we could provide a runtime configuration option so the console could only be accessed with https: 8443 and possibly on a specific host or virtual host. I'm not sure how to do this without changing the web.xml however. thanks david jencks --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
+1 for continuing the release. Getting 2.1 out the door is an important step that fixes many outstanding issues and is worth releasing. Also, I have a feeling that the fix for this will end up being in Pluto. We are using a pinned version - and there are significant changes between the version of trunk that we stopped at and the current trunk. It very well may be that this issue is already fixed. But if it isn't, I'm sure that with folks from Geronimo working with the people working on Pluto - we'll be able to get it straightened out quickly. Jay Paul McMahan wrote: I share Jarek's concern about the impact of this problem but agree with Joe that there's an adequate (albeit not pretty) workaround. Knowing the full scope of this problem now my +1 still stands. But I wish we had more information about the underlying problem because it might be simple to fix, and worth holding up the release for since I would expect that most users will want to use HTTPS for administration activities. But if the fix involved getting a patch committed into pluto's svn then I think we should postpone that type of activity until Geronimo 2.1.1. Best wishes, Paul On Feb 15, 2008, at 12:39 PM, Joe Bohn wrote: Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Jarek I agree that this is a significant bug but given the current state of the release and the fact that there is a work-around (although I admit that it's hardly perfect) I think it makes sense to fix this in a 2.1.1 release. IMO, this issue makes it all the more important to get 2.1.1 out without delay. Joe
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
I'm fine with waiting to fix this in a 2.1.1 release, as long as we get it out by the end of March. -Donald Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Jarek smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Hi, Thanks for reporting this problem. This is an embarrassing bug. Is the problem already identified? If this is a Geronimo regression, then it seems to me that we need to be improve our testing approach. For instance, along with each bug fix, I would expect the addition of new tests to prevent future regressions. Along with each new features, I would expect good tests proving that the feature works. And I would expect tests to be committed at the same time than source tree changes and not after the fact. If this is not a Geronimo issue, then I think my point still stands. When is 2.1.1 due? If it is in more than in 2 weeks, then I would like a withdraw of 2.1. Thanks, Gianny On 16/02/2008, at 2:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Jarek On Thu, Feb 14, 2008 at 1:30 PM, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On Thu, Feb 14, 2008 at 8:47 AM, Lin Sun <[EMAIL PROTECTED]> wrote: P.S. sorry for trying these late - i just got back from a long long leave... No need to worry. Do whatever you can and your time permits. Even late-runners have something to say and their voice counts. Report any issue you run across so it gets fixed in the upcoming releases if 2.1 is already out. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Fri, Feb 15, 2008 at 8:46 AM, Jarek Gawor <[EMAIL PROTECTED]> wrote: > But, IMHO, this is not just a bug it is a major bug where one of the > important pieces of Geronimo functionality is simply not working on > port 8443. Personally, I would have voted -1 on the release if I > realized the full scope of this bug sooner. But maybe that's just me.. > so I would like to know what other people think about this problem. If > it's just me, that's fine. If not, maybe we should consider > withdrawing the release. Although the admin console is working fine on > port 8080 and maybe that's good enough. I'd not withdraw it. It's what we've got and no matter how beautiful it is - that's how it is now. We could never release Geronimo as there're always bugs. Some important, some not, but since we're all for releasing often I'm for leaving it as it is now and put a note in the RELEASE_NOTES about it. We can work it out in 2.1.1. I just think it's time for 2.1 and see people what we've got so they can see its value. There're other bugs lurking, and 2.1 release will let them show up. I'm still +1 for 2.1. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
I share Jarek's concern about the impact of this problem but agree with Joe that there's an adequate (albeit not pretty) workaround. Knowing the full scope of this problem now my +1 still stands. But I wish we had more information about the underlying problem because it might be simple to fix, and worth holding up the release for since I would expect that most users will want to use HTTPS for administration activities. But if the fix involved getting a patch committed into pluto's svn then I think we should postpone that type of activity until Geronimo 2.1.1. Best wishes, Paul On Feb 15, 2008, at 12:39 PM, Joe Bohn wrote: Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Jarek I agree that this is a significant bug but given the current state of the release and the fact that there is a work-around (although I admit that it's hardly perfect) I think it makes sense to fix this in a 2.1.1 release. IMO, this issue makes it all the more important to get 2.1.1 out without delay. Joe
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Jarek I agree that this is a significant bug but given the current state of the release and the fact that there is a work-around (although I admit that it's hardly perfect) I think it makes sense to fix this in a 2.1.1 release. IMO, this issue makes it all the more important to get 2.1.1 out without delay. Joe
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 15, 2008, at 11:46 AM, Jarek Gawor wrote: On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Sounds like a 2.1.1 fix to me. Will look to hear from others... --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Fri, Feb 15, 2008 at 10:44 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: > Looks like I sent this to the wrong thread: > > This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 > > Hmm this seems bad. I was able to reproduce the problem on port 8443 > only but _all_ portlets failed in this way. So the console is pretty > much unusable on port 8443. Can somebody else verify these findings? > > Yep. Looks like a bug. Don't see this as a security exposure. So, not sure > why you want to discuss here. > > https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the > appropriate location to work on getting this fixed. Do you disagree? But, IMHO, this is not just a bug it is a major bug where one of the important pieces of Geronimo functionality is simply not working on port 8443. Personally, I would have voted -1 on the release if I realized the full scope of this bug sooner. But maybe that's just me.. so I would like to know what other people think about this problem. If it's just me, that's fine. If not, maybe we should consider withdrawing the release. Although the admin console is working fine on port 8080 and maybe that's good enough. Jarek
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 15, 2008, at 10:12 AM, Jarek Gawor wrote: Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Yep. Looks like a bug. Don't see this as a security exposure. So, not sure why you want to discuss here. https://issues.apache.org/jira/browse/GERONIMO-3855 would seem like the appropriate location to work on getting this fixed. Do you disagree? --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Looks like I sent this to the wrong thread: This is about: https://issues.apache.org/jira/browse/GERONIMO-3855 Hmm this seems bad. I was able to reproduce the problem on port 8443 only but _all_ portlets failed in this way. So the console is pretty much unusable on port 8443. Can somebody else verify these findings? Jarek On Thu, Feb 14, 2008 at 1:30 PM, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > On Thu, Feb 14, 2008 at 8:47 AM, Lin Sun <[EMAIL PROTECTED]> wrote: > > > P.S. sorry for trying these late - i just got back from a long long > leave... > > No need to worry. Do whatever you can and your time permits. Even > late-runners have something to say and their voice counts. Report any > issue you run across so it gets fixed in the upcoming releases if 2.1 > is already out. > > Jacek > > -- > Jacek Laskowski > http://www.JacekLaskowski.pl >
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Thu, Feb 14, 2008 at 8:47 AM, Lin Sun <[EMAIL PROTECTED]> wrote: > P.S. sorry for trying these late - i just got back from a long long leave... No need to worry. Do whatever you can and your time permits. Even late-runners have something to say and their voice counts. Report any issue you run across so it gets fixed in the upcoming releases if 2.1 is already out. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Also, I found something interesting with the start-server command. If I issue the start-server command to start the server, then I can shutdown the server using the shutdown.bat or admin console. However, there is no change in the start-server window which it still says "Geronimo Application Server started" and nothing after it. This has been very confusing to me, coz I thought my server is still running after I forgot I've already stopped it earlier on. Is this a known prob? P.S. sorry for trying these late - i just got back from a long long leave... lin On Thu, Feb 14, 2008 at 11:29 AM, Lin Sun <[EMAIL PROTECTED]> wrote: > Ok if I change the default, then I won't be able to shutdown the > server using stop-server (with the correct or wrong credential). In > this case, only shutdown.bat/sh works. > > Lin > > > > On Thu, Feb 14, 2008 at 11:23 AM, Lin Sun <[EMAIL PROTECTED]> wrote: > > No, I didn't change the server defaults... I can try changing the > > defaults and report back. > > > > Lin > > > > > > > > On Thu, Feb 14, 2008 at 11:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote: > > > Lin Sun wrote: > > > > I just downloaded the jee5 tomcat assembly and tried the new > > > > start-server and stop-server commands on winxp. The stop-server > > > > commands shutdown the server with a wrong password! > > > > > > > > C:\working\gt21\bin>stop-server > > > > Stopping Geronimo server: localhost:1099 > > > > Username: system > > > > Password: * > > > > Shutdown request has been issued > > > > > > > > Has anyone seen this? Not sure if stop-server would work remotely... > > > > > > > > > > This sounds like a side effect of the same problem Jarek reported. Did > > > you change the id/pw from the default? If stop-server always uses the > > > default credentials and you did not change the default then it would > > > shut the server down even if you specify incorrect credentials on the > > > command. > > > > > > Joe > > > > > > > > > > > >
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Ok if I change the default, then I won't be able to shutdown the server using stop-server (with the correct or wrong credential). In this case, only shutdown.bat/sh works. Lin On Thu, Feb 14, 2008 at 11:23 AM, Lin Sun <[EMAIL PROTECTED]> wrote: > No, I didn't change the server defaults... I can try changing the > defaults and report back. > > Lin > > > > On Thu, Feb 14, 2008 at 11:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote: > > Lin Sun wrote: > > > I just downloaded the jee5 tomcat assembly and tried the new > > > start-server and stop-server commands on winxp. The stop-server > > > commands shutdown the server with a wrong password! > > > > > > C:\working\gt21\bin>stop-server > > > Stopping Geronimo server: localhost:1099 > > > Username: system > > > Password: * > > > Shutdown request has been issued > > > > > > Has anyone seen this? Not sure if stop-server would work remotely... > > > > > > > This sounds like a side effect of the same problem Jarek reported. Did > > you change the id/pw from the default? If stop-server always uses the > > default credentials and you did not change the default then it would > > shut the server down even if you specify incorrect credentials on the > > command. > > > > Joe > > > > > > >
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
No, I didn't change the server defaults... I can try changing the defaults and report back. Lin On Thu, Feb 14, 2008 at 11:09 AM, Joe Bohn <[EMAIL PROTECTED]> wrote: > Lin Sun wrote: > > I just downloaded the jee5 tomcat assembly and tried the new > > start-server and stop-server commands on winxp. The stop-server > > commands shutdown the server with a wrong password! > > > > C:\working\gt21\bin>stop-server > > Stopping Geronimo server: localhost:1099 > > Username: system > > Password: * > > Shutdown request has been issued > > > > Has anyone seen this? Not sure if stop-server would work remotely... > > > > This sounds like a side effect of the same problem Jarek reported. Did > you change the id/pw from the default? If stop-server always uses the > default credentials and you did not change the default then it would > shut the server down even if you specify incorrect credentials on the > command. > > Joe > > >
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Lin Sun wrote: I just downloaded the jee5 tomcat assembly and tried the new start-server and stop-server commands on winxp. The stop-server commands shutdown the server with a wrong password! C:\working\gt21\bin>stop-server Stopping Geronimo server: localhost:1099 Username: system Password: * Shutdown request has been issued Has anyone seen this? Not sure if stop-server would work remotely... This sounds like a side effect of the same problem Jarek reported. Did you change the id/pw from the default? If stop-server always uses the default credentials and you did not change the default then it would shut the server down even if you specify incorrect credentials on the command. Joe
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
I just downloaded the jee5 tomcat assembly and tried the new start-server and stop-server commands on winxp. The stop-server commands shutdown the server with a wrong password! C:\working\gt21\bin>stop-server Stopping Geronimo server: localhost:1099 Username: system Password: * Shutdown request has been issued Has anyone seen this? Not sure if stop-server would work remotely... Lin On Wed, Feb 13, 2008 at 7:20 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Feb 13, 2008, at 2:46 PM, Jarek Gawor wrote: > > -0.5. > > > > The bin/stop-server command ignores username/password values I provide > > and instead always uses the default credentials (system/manager). > > OK. Well, that's not great, but neither is it a security exposure. > There's always shutdown.sh and the good old kill command. Personally, > I put this in a bug category... > > While on the subject, gsh commands will be our preferred command > structure. Excepting geronimo.sh, I'd be in favor of removing the > deploy/startup/shutdown commands in our future releases. > > > > > > > Also, looks like there is an unnecessary META-INF/ directory under the > > main installation directory. > > K. We can look at that, next release. > > --kevan >
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 13, 2008, at 8:13 PM, Jarek Gawor wrote: On Feb 13, 2008 7:20 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 13, 2008, at 2:46 PM, Jarek Gawor wrote: -0.5. The bin/stop-server command ignores username/password values I provide and instead always uses the default credentials (system/manager). OK. Well, that's not great, but neither is it a security exposure. There's always shutdown.sh and the good old kill command. Personally, I put this in a bug category... Yes, that's right. I did forget about the shutdown.sh command. It works with remote servers too so it can be used instead of stop-server. I'm changing my vote +1 now. Jarek, Can you register your vote change on the [VOTE] thread? Thanks! --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 13, 2008, at 8:13 PM, Jarek Gawor wrote: On Feb 13, 2008 7:20 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 13, 2008, at 2:46 PM, Jarek Gawor wrote: -0.5. The bin/stop-server command ignores username/password values I provide and instead always uses the default credentials (system/manager). OK. Well, that's not great, but neither is it a security exposure. There's always shutdown.sh and the good old kill command. Personally, I put this in a bug category... Yes, that's right. I did forget about the shutdown.sh command. It works with remote servers too so it can be used instead of stop-server. I'm changing my vote +1 now. Cool... While on the subject, gsh commands will be our preferred command structure. Excepting geronimo.sh, I'd be in favor of removing the deploy/startup/shutdown commands in our future releases. Yes, but I think some things in gshell still need to improve. For example, path parsing on Windows does not work as expected (path such as c:\foo.war will fail with a lexical error) or getting exit code of the previous command (at least I couldn't find a way to get it). Didn't know about the Windows path issue. Totally agree that there's improvement needed. Think we agree on the end goal... --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 13, 2008 7:20 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Feb 13, 2008, at 2:46 PM, Jarek Gawor wrote: > > -0.5. > > > > The bin/stop-server command ignores username/password values I provide > > and instead always uses the default credentials (system/manager). > > OK. Well, that's not great, but neither is it a security exposure. > There's always shutdown.sh and the good old kill command. Personally, > I put this in a bug category... Yes, that's right. I did forget about the shutdown.sh command. It works with remote servers too so it can be used instead of stop-server. I'm changing my vote +1 now. > While on the subject, gsh commands will be our preferred command > structure. Excepting geronimo.sh, I'd be in favor of removing the > deploy/startup/shutdown commands in our future releases. Yes, but I think some things in gshell still need to improve. For example, path parsing on Windows does not work as expected (path such as c:\foo.war will fail with a lexical error) or getting exit code of the previous command (at least I couldn't find a way to get it). Jarek
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 13, 2008, at 2:46 PM, Jarek Gawor wrote: -0.5. The bin/stop-server command ignores username/password values I provide and instead always uses the default credentials (system/manager). OK. Well, that's not great, but neither is it a security exposure. There's always shutdown.sh and the good old kill command. Personally, I put this in a bug category... While on the subject, gsh commands will be our preferred command structure. Excepting geronimo.sh, I'd be in favor of removing the deploy/startup/shutdown commands in our future releases. Also, looks like there is an unnecessary META-INF/ directory under the main installation directory. K. We can look at that, next release. --kevan
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
When the server is started using bin\start-server.bat, Ctrl+C to stop the server does not seem to work! ++Vamsi On Feb 11, 2008 9:58 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > > I've downloaded these images and done a few simple tests. I've also run > a number of TCK tests with them (although I have long runs going now to > cover all the tests). So far things look very good. > > One minor problem I noticed is that we are printing INFO messages to the > console. This is especially noticeable when certain actions are > performed on the Admin Console and a number of INFO messages are > displayed in the command line console. I personally would prefer to not > see these messages by changing the default logging level to WARNING or > ERROR as we have done with prior releases. Thoughts? > > I know it's a lot of work to spin a new release candidate so I'm > debating if this issue alone merits creating a new image. > > Joe > >
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Joe Bohn wrote: Another potential issue: When I shut-down the jetty6-javaee5 server from the admin console I hit the following exceptions (I don't get these errors from the command line or via ctrl-C): I created https://issues.apache.org/jira/browse/GERONIMO-3844 for this problem. Joe 13:23:19,474 ERROR [TcpTransportServer] Could not stop service: tcp://0.0.0.0:61616. Reason: java.lang.InterruptedException java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Thread.join(Thread.java:1113) at java.lang.Thread.join(Thread.java:1166) at org.apache.activemq.transport.TransportServerThreadSupport.doStop(TransportServerThreadSupport.java:81) at org.apache.activemq.transport.tcp.TcpTransportServer.doStop(TcpTransportServer.java:219) at org.apache.activemq.util.ServiceSupport.stop(ServiceSupport.java:58) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.TransportConnector.stop(TransportConnector.java:241) at org.apache.geronimo.activemq.TransportConnectorGBeanImpl.doStop(TransportConnectorGBeanImpl.java:135) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1161) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:339) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:316) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView(ServerManagerPortlet.java:74) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Joe Bohn wrote: Kevan Miller wrote: On Feb 11, 2008, at 11:28 AM, Joe Bohn wrote: I've downloaded these images and done a few simple tests. I've also run a number of TCK tests with them (although I have long runs going now to cover all the tests). So far things look very good. One minor problem I noticed is that we are printing INFO messages to the console. This is especially noticeable when certain actions are performed on the Admin Console and a number of INFO messages are displayed in the command line console. I personally would prefer to not see these messages by changing the default logging level to WARNING or ERROR as we have done with prior releases. Thoughts? I know it's a lot of work to spin a new release candidate so I'm debating if this issue alone merits creating a new image. Creating the release does take a bit of effort, but should be mostly a matter of time. The file uploads to Apache took ~ 8 hours, I think. But this was from home. So, was upload limited... We should be past all of the first-time build barriers that I was running into over the weekend. What are the INFO messages? What are the user actions that trigger them? I'm probably OK with INFO messages. We can clean them up in 2.1.1... But rebuilding is not a big issue, if we want to clean them up. Hmm the logging issue might be a red herring. I started to see the info messages after I installed the Artifactory 1.2.5 war file. Some of these messages are from Artifactory itself however after I installed that I also started to see info message from just about all console portlets by simply navigating to them ... such as: 2008-02-11 13:01:29,286 [INFO ] (GeronimoLog.java:79) - Portlet mode 'edit' not found for portletId: '/console-base.ThreadPool!2137960813|0' 2008-02-11 13:01:29,287 [INFO ] (GeronimoLog.java:79) - Portlet mode 'help' not found for portletId: '/console-base.ThreadPool!2137960813|0' I need to dig a bit more. So I think Artifactory registered their own log handler that echoed the messages to both the log and stdout ... hence why they appeared in the console. These messages seems to be useless anyway, so we should probably clean them up sometime. However, they aren't displayed in the console by default and therefore the log messages in the console are not a Geronimo issue. Joe
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Another potential issue: When I shut-down the jetty6-javaee5 server from the admin console I hit the following exceptions (I don't get these errors from the command line or via ctrl-C): 13:23:19,474 ERROR [TcpTransportServer] Could not stop service: tcp://0.0.0.0:61616. Reason: java.lang.InterruptedException java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Thread.join(Thread.java:1113) at java.lang.Thread.join(Thread.java:1166) at org.apache.activemq.transport.TransportServerThreadSupport.doStop(TransportServerThreadSupport.java:81) at org.apache.activemq.transport.tcp.TcpTransportServer.doStop(TcpTransportServer.java:219) at org.apache.activemq.util.ServiceSupport.stop(ServiceSupport.java:58) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.TransportConnector.stop(TransportConnector.java:241) at org.apache.geronimo.activemq.TransportConnectorGBeanImpl.doStop(TransportConnectorGBeanImpl.java:135) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1161) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:339) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:563) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:316) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView(ServerManagerPortlet.java:74) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandl
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
Kevan Miller wrote: On Feb 11, 2008, at 11:28 AM, Joe Bohn wrote: I've downloaded these images and done a few simple tests. I've also run a number of TCK tests with them (although I have long runs going now to cover all the tests). So far things look very good. One minor problem I noticed is that we are printing INFO messages to the console. This is especially noticeable when certain actions are performed on the Admin Console and a number of INFO messages are displayed in the command line console. I personally would prefer to not see these messages by changing the default logging level to WARNING or ERROR as we have done with prior releases. Thoughts? I know it's a lot of work to spin a new release candidate so I'm debating if this issue alone merits creating a new image. Creating the release does take a bit of effort, but should be mostly a matter of time. The file uploads to Apache took ~ 8 hours, I think. But this was from home. So, was upload limited... We should be past all of the first-time build barriers that I was running into over the weekend. What are the INFO messages? What are the user actions that trigger them? I'm probably OK with INFO messages. We can clean them up in 2.1.1... But rebuilding is not a big issue, if we want to clean them up. Hmm the logging issue might be a red herring. I started to see the info messages after I installed the Artifactory 1.2.5 war file. Some of these messages are from Artifactory itself however after I installed that I also started to see info message from just about all console portlets by simply navigating to them ... such as: 2008-02-11 13:01:29,286 [INFO ] (GeronimoLog.java:79) - Portlet mode 'edit' not found for portletId: '/console-base.ThreadPool!2137960813|0' 2008-02-11 13:01:29,287 [INFO ] (GeronimoLog.java:79) - Portlet mode 'help' not found for portletId: '/console-base.ThreadPool!2137960813|0' I need to dig a bit more. Joe
Re: [DISCUSS] Geronimo Server 2.1 and Geronimo TxManager 2.1.1 Releases
On Feb 11, 2008, at 11:28 AM, Joe Bohn wrote: I've downloaded these images and done a few simple tests. I've also run a number of TCK tests with them (although I have long runs going now to cover all the tests). So far things look very good. One minor problem I noticed is that we are printing INFO messages to the console. This is especially noticeable when certain actions are performed on the Admin Console and a number of INFO messages are displayed in the command line console. I personally would prefer to not see these messages by changing the default logging level to WARNING or ERROR as we have done with prior releases. Thoughts? I know it's a lot of work to spin a new release candidate so I'm debating if this issue alone merits creating a new image. Creating the release does take a bit of effort, but should be mostly a matter of time. The file uploads to Apache took ~ 8 hours, I think. But this was from home. So, was upload limited... We should be past all of the first-time build barriers that I was running into over the weekend. What are the INFO messages? What are the user actions that trigger them? I'm probably OK with INFO messages. We can clean them up in 2.1.1... But rebuilding is not a big issue, if we want to clean them up. --kevan
