Re: [VOTE] geronimo-jpa_2.0_spec first early access release
+1 David Jencks wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[jira] Updated: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMO-4485: Attachment: sysdb-portlets.patch Port the GERONIMO-4474 patch for V2.1 - Key: GERONIMO-4485 URL: https://issues.apache.org/jira/browse/GERONIMO-4485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Reporter: Kan Ogawa Assignee: Kan Ogawa Priority: Minor Fix For: 2.1.4 Attachments: console-base-portlets.patch, console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, plancreator-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch Target release should be 2.2, if you can attach the patches by Jan. 7th. If you would like to see this in 2.1.4, then please attach additional patches created from that branch and we'll try to get them in after we wrap up the 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1
[ https://issues.apache.org/jira/browse/GERONIMO-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMO-4485: Attachment: (was: sysdb-portlets.patch) Port the GERONIMO-4474 patch for V2.1 - Key: GERONIMO-4485 URL: https://issues.apache.org/jira/browse/GERONIMO-4485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Reporter: Kan Ogawa Assignee: Kan Ogawa Priority: Minor Fix For: 2.1.4 Attachments: console-base-portlets.patch, console-portal-driver.patch, debugviews-portlets.patch, mconsole-jetty.patch, mconsole-tomcat.patch, mconsole-war.patch, plancreator-console-jetty.patch, plancreator-console-tomcat.patch, plancreator-portlets.patch, plugin-portlets.patch, sysdb-portlets.patch Target release should be 2.2, if you can attach the patches by Jan. 7th. If you would like to see this in 2.1.4, then please attach additional patches created from that branch and we'll try to get them in after we wrap up the 2.2 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: git, hg or bzr for G development?
On Jan 28, 2009, at 12:47 AM, Jason Dillon wrote: On Jan 28, 2009, at 1:47 AM, Kevan Miller wrote: There are some usages of GIT that would not fit well into an Apache project. For instance, I would not want to see project members using GIT as a private means of sharing code updates. Ultimately, code needs to get into our svn repo -- that's where we should be sharing code. Why do you have a problem with users sharing code via their own GIT repos? I guess I can kinda see your concern, but I'd expect folks with significant changes to the codebase to want to share their GIT repos with others *before* pushing those changes back into SVN. Right. So, I wouldn't want a few people to decide to implement some new function, start sharing code (privately amongst themselves), and then dump it into svn. IIUC, GIT makes this pretty easy to do. Currently, this sort of activity would happen in an svn sandbox or via patches posted to a Jira. In either case the collaboration and work should be public. I want to make sure we maintain this. Jay's example of a security-related patch is a very compelling example as to why sharing code directly via GIT instead of SVN can be a good idea at times. Sure. I'm not denying that GIT has potential advantages. I'll point out that we can share security patches, already. Certainly not as easily as GIT *could*, but it's not that hard, either... Also, the code sharing occurs publicly within the security community. So, all members of the security team can participate. We'd also require some kind of access control on any GIT-based code sharing that occurs. Until *everyone* is using GIT and we have community policies governing its usage, svn and our mailing lists are where we need to be collaborating. Why does *everyone* need to use GIT? IMO it is just a tool, some folks might prefer BZR, HG or SVK, making use of the features/ advantages that each tool provides. I don't see why there would ever need to be a point where *everyone* is on the same tool since ATM the underlying authoritative and definitive location for the codebase is the ASF SVN. Let me explain what I meant by that... Until we have community policy that governs our usage of GIT, I think GIT should not be used to share code between members of our community. Until then, use it as a tool to improve your local development -- just like you might use SVK (I'm not familiar with BZR or HG). If GIT improves your productivity, that's fantastic. However, if you and Joe start sharing GIT to privately share code (merging between your two GIT repos), then I'd be concerned. Just like I'd be concerned if you and Joe were privately sharing code patches. Does that make sense? If you and Joe are sharing code in an SVN sandbox, via patches in JIRA, or via patches in community mailing list emails, then everyone in the community can participate. That sort of openness needs to be maintained with any usage of GIT within the community. * * * I really don't see what the harm is that you seem worried about. I'm not sure that we need any policies governing its usage either, no more than we need guidelines on how some one uses /bin/vi or notepad.exe, unless you mean the content not the tool, and in that case I think the general docs we have on that is sufficient. IMO GIT allows for a much more flexible development model, and I really don't see why we'd want to take away that flexibly with tape (of the red kind). Maintaining open communication is my only concern. That's the only red tape that I'm putting on the process. I'm not saying this can't be fixed. Just that we'd have to work out the issues... As always, I'd like to hear from others in the community... It might be useful if you could let others know how you're using GIT. --kevan
Issue with Geronimo and VRaptor
I’m using Geronimo 2.1.3. Well, I have a Web Java Project with the frameworks VRaptor 2.5 and Tiles 2.0.6. When I try to upload MyProject.war, I have the following message from Geronimo console: “Failed to load servlet class org.vraptor.VRaptorServlet”. I did another test changing the order of the web.xml putting the Servlet Tiles declaration firstly than the Vraptor’s. So the Geronimo’s console returned to me “Failed to load TilesServlet”. So I tried to restart the Geronimo Server. Doing this, sometimes I can upload and sometimes I can’t. I don’t know what’s happening. All the times I have the same issue message returned. I saw the Log and Geronimo doesn't find the class VraptorServlet or TilesServlet, but everything is in the classpath of the project. Could someone help me? Thanks. -- View this message in context: http://www.nabble.com/Issue-with-Geronimo-and-VRaptor-tp21728411s134p21728411.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Issue with Geronimo and VRaptor
On Jan 29, 2009, at 9:53 AM, thiago.bueno wrote: I’m using Geronimo 2.1.3. Well, I have a Web Java Project with the frameworks VRaptor 2.5 and Tiles 2.0.6. When I try to upload MyProject.war, I have the following message from Geronimo console: “Failed to load servlet class org.vraptor.VRaptorServlet”. I did another test changing the order of the web.xml putting the Servlet Tiles declaration firstly than the Vraptor’s. So the Geronimo’s console returned to me “Failed to load TilesServlet”. So I tried to restart the Geronimo Server. Doing this, sometimes I can upload and sometimes I can’t. I don’t know what’s happening. All the times I have the same issue message returned. I saw the Log and Geronimo doesn't find the class VraptorServlet or TilesServlet, but everything is in the classpath of the project. Could someone help me? Thanks. Please don't post the same question in both our dev and user mailing lists. The user list is most appropriate for this type of question... --kevan
Java EE 6 Specification Public Review
As you are probably aware, the Java EE 6 Specification has been released for public review -- http://jcp.org/en/jsr/detail?id=316 --kevan
Re: [VOTE] geronimo-jpa_2.0_spec first early access release
David, While searching the JSR-317 draft for direction regarding early access naming, I found that the notice (page 2) includes the clauses below, notably item iii. Does clause iii need to be added to the NOTICE in the EA jar? Also, should the Geronimo EA NOTICE use JPA 2.0 EARLY ACCESS instead of simply JPA 2.0 in order to meet clause ii? jsr-317 draft NOTICE ... 2.Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii)is clearly and prominently marked with the word UNTESTED or EARLY ACCESS or INCOMPATIBLE or UNSTABLE or BETA in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii)includes the following notice: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. /jsr-317 draft -Jeremy On Wed, Jan 28, 2009 at 4:25 PM, David Jencks david_jen...@yahoo.comwrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [VOTE] geronimo-jpa_2.0_spec first early access release
+1 Jcek Laskowski wrote: +1 Jacek On Wed, Jan 28, 2009 at 11:25 PM, David Jencks david_jen...@yahoo.com wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. -- Thanks, Dan Becker
Re: [VOTE] geronimo-jpa_2.0_spec first early access release
-1 Agree with Jeremy that we need to include the required notice in the jar. -Donald Jeremy Bauer wrote: David, While searching the JSR-317 draft for direction regarding early access naming, I found that the notice (page 2) includes the clauses below, notably item iii. Does clause iii need to be added to the NOTICE in the EA jar? Also, should the Geronimo EA NOTICE use JPA 2.0 EARLY ACCESS instead of simply JPA 2.0 in order to meet clause ii? jsr-317 draft NOTICE ... 2.Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii)is clearly and prominently marked with the word UNTESTED or EARLY ACCESS or INCOMPATIBLE or UNSTABLE or BETA in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii)includes the following notice: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. /jsr-317 draft -Jeremy On Wed, Jan 28, 2009 at 4:25 PM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[CANCELLED] Re: [VOTE] geronimo-jpa_2.0_spec first early access release
Looks like a problem. I sent a note to legal-discuss about (iii). I'll work on setting up a new release candidate. thanks david jencks On Jan 29, 2009, at 7:46 AM, Jeremy Bauer wrote: David, While searching the JSR-317 draft for direction regarding early access naming, I found that the notice (page 2) includes the clauses below, notably item iii. Does clause iii need to be added to the NOTICE in the EA jar? Also, should the Geronimo EA NOTICE use JPA 2.0 EARLY ACCESS instead of simply JPA 2.0 in order to meet clause ii? jsr-317 draft NOTICE ... 2.Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii)is clearly and prominently marked with the word UNTESTED or EARLY ACCESS or INCOMPATIBLE or UNSTABLE or BETA in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii)includes the following notice: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. /jsr-317 draft -Jeremy On Wed, Jan 28, 2009 at 4:25 PM, David Jencks david_jen...@yahoo.com wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [CANCELLED] Re: [VOTE] geronimo-jpa_2.0_spec first early access release
On legal-discuss, Geir indicated he would try to get (iii) removed which might mean this vote could resume. Does anyone think we need to name the version (or artifactID) differently based on (ii)? thanks david jencks On Jan 29, 2009, at 9:33 AM, David Jencks wrote: Looks like a problem. I sent a note to legal-discuss about (iii). I'll work on setting up a new release candidate. thanks david jencks On Jan 29, 2009, at 7:46 AM, Jeremy Bauer wrote: David, While searching the JSR-317 draft for direction regarding early access naming, I found that the notice (page 2) includes the clauses below, notably item iii. Does clause iii need to be added to the NOTICE in the EA jar? Also, should the Geronimo EA NOTICE use JPA 2.0 EARLY ACCESS instead of simply JPA 2.0 in order to meet clause ii? jsr-317 draft NOTICE ... 2.Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii)is clearly and prominently marked with the word UNTESTED or EARLY ACCESS or INCOMPATIBLE or UNSTABLE or BETA in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii)includes the following notice: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. /jsr-317 draft -Jeremy On Wed, Jan 28, 2009 at 4:25 PM, David Jencks david_jen...@yahoo.com wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
Re: [CANCELLED] Re: [VOTE] geronimo-jpa_2.0_spec first early access release
No, as our naming matches what Sun used for their EA jars of the JAXWS 2.1 API - http://download.java.net/maven/1/javax.xml.ws/jars/ -Donald David Jencks wrote: On legal-discuss, Geir indicated he would try to get (iii) removed which might mean this vote could resume. Does anyone think we need to name the version (or artifactID) differently based on (ii)? thanks david jencks On Jan 29, 2009, at 9:33 AM, David Jencks wrote: Looks like a problem. I sent a note to legal-discuss about (iii). I'll work on setting up a new release candidate. thanks david jencks On Jan 29, 2009, at 7:46 AM, Jeremy Bauer wrote: David, While searching the JSR-317 draft for direction regarding early access naming, I found that the notice (page 2) includes the clauses below, notably item iii. Does clause iii need to be added to the NOTICE in the EA jar? Also, should the Geronimo EA NOTICE use JPA 2.0 EARLY ACCESS instead of simply JPA 2.0 in order to meet clause ii? jsr-317 draft NOTICE ... 2.Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation: (i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (ii)is clearly and prominently marked with the word UNTESTED or EARLY ACCESS or INCOMPATIBLE or UNSTABLE or BETA in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and (iii)includes the following notice: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. /jsr-317 draft -Jeremy On Wed, Jan 28, 2009 at 4:25 PM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: I've been working with the OpenJPA project to develop the jpa 2.0 spec jar in our spec repository. They are ready for their first early access milestone release. I've staged the release here: http://people.apache.org/~djencks/staging-repo/specs/geronimo-jpa_2.0_spec/org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.0-EA-1/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.0_spec-1.0-EA-1 I haven't staged the site. I don't think its necessary for a early access release, but will reconsider on request. I ran rat on the project, and the autochecking thinks the legal files are ok. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks david jencks
[jira] Resolved: (GERONIMO-4507) Admin console should honor the priority of user agent's language setting
[ https://issues.apache.org/jira/browse/GERONIMO-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-4507. Resolution: Fixed Applied patch from Kan Ogawa to branches/2.1 (2.1.4-SNAPSHOT) as Rev738979. Admin console should honor the priority of user agent's language setting Key: GERONIMO-4507 URL: https://issues.apache.org/jira/browse/GERONIMO-4507 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3, 2.2 Environment: All Reporter: Jack Cai Assignee: Donald Woods Priority: Minor Fix For: 2.1.4, 2.2 Attachments: locale-priority.patch, locale-priority_fix.patch, locale-priority_V21.patch See discussion: http://www.nabble.com/Geronimo-Console-tp21369352s134p21383628.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-156) Disable system bell by default
Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine updated GSHELL-156: - Attachment: nobell.patch This is a simple patch to disable the bell globally by default. An alternative would be to have a system prop so that someone could override this and enable it, although I am not sure why anyone would want to. Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668766#action_12668766 ] Jason Dillon commented on GSHELL-156: - I'm tempted to leave it in there just to annoy windows users, *nix and Mac OSX (which is a *nix system btw) don't disregard the bell, its just easier to configure if its on or off. I suggest you a) switch to a real operating system or b) google how to disable the bell from your cmd.exe (or whatever console app you are using). Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668773#action_12668773 ] Chris Custine commented on GSHELL-156: -- I hear you, I'm a Mac. ;-) I was just trying to fix this in ServiceMix 4 kernel (https://issues.apache.org/activemq/browse/SMX4KNL-137) but now I looked closer and you are right about the terminals, some just have audible bell switched off by default. I'm fine with closing this as won't fix if you want to leave it as is. Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release XBean 3.5 - rc2
Thank you to those that already voted. It would be nice to get one or two more folks to review the release. If there are no more comments I'll plan to close the vote tomorrow, 1/30. Thanks, Joe Joe Bohn wrote: I uploaded a second distribution of XBean 3.5 which should include the NOTICE/LICENSE files in all the appropriate places (I hope). The same changes are present in this candidate that were present in the last one: * SocketAddress factory example for Alex [1] * XBEAN-111 Only register Converters with the VM when requested [2] * Make dependencies optional [3] * XBEAN-114 generify xbean-naming [4] * XBEAN-115 Fix rebind of entry added using deepBind [5] * XBEAN-115 similar fix to for WritableContext for consistency [6] * try to follow apache policy and not deploy timestamped snapshots [7] * Fix classloader name when throwing a CNFE [8] * Let the tests pass on non-MacOS OSes [9] * XBEAN-120 Search for semi-annotated classes in inheritance tree (as if @Inherited's applied) [10] * XBEAN-120 Search for semi-annotated classes in inheritance tree (as if @Inherited's applied) [11] * update copyright years to include 2009 [12] * add a siteId property to assist in release [13] Please help validate this release. I'm a little concerned about xbean-spring as I noticed some errors fly by during the release process but everything eventually passed successfully. I'll start validating this in a Geronimo server image but at the moment it will only utilize xbean-naming 3.5. The staging repository is available at http://people.apache.org/~jbohn/staging-repo/xbean/ and the tag is available at http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.5/ I've run the rat tool to validate license headers. Please review and vote: [ ] +1 Release XBean 3.5 [ ] -1 Do not, because ... The vote will be open for 72 hours or longer as necessary to validate the images and get sufficient participation in the vote. [1] http://svn.apache.org/viewvc?view=revrevision=689356 [2] http://svn.apache.org/viewvc?view=revrevision=703580 [3] http://svn.apache.org/viewvc?view=revrevision=705314 [4] http://svn.apache.org/viewvc?view=revrevision=707161 [5] http://svn.apache.org/viewvc?view=revrevision=707227 [6] http://svn.apache.org/viewvc?view=revrevision=707230 [7] http://svn.apache.org/viewvc?view=revrevision=707719 [8] http://svn.apache.org/viewvc?view=revrevision=725706 [9] http://svn.apache.org/viewvc?view=revrevision=729545 [10] http://svn.apache.org/viewvc?view=revrevision=729546 [11] http://svn.apache.org/viewvc?view=revrevision=731945 [12] http://svn.apache.org/viewvc?view=revrevision=737042 [13] http://svn.apache.org/viewvc?view=revrevision=737184 Thanks, Joe
