Re: [VOTE] M4 release
+1 David Blevins wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David -- Jeff Genender http://geronimo.apache.org
[jira] Updated: (GERONIMO-555) Write a thread-safe timer/interrupt based transaction timout implementation
[ http://issues.apache.org/jira/browse/GERONIMO-555?page=all ] David Jencks updated GERONIMO-555: -- Fix Version: (was: 1.0) Description: This is a long term research project that will probably take a month of concentrated effort. We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 was: We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 Write a thread-safe timer/interrupt based transaction timout implementation --- Key: GERONIMO-555 URL: http://issues.apache.org/jira/browse/GERONIMO-555 Project: Geronimo Type: New Feature Components: transaction manager Reporter: David Jencks This is a long term research project that will probably take a month of concentrated effort. We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-640) Remove dependency on Sun internals code for URL decoding
[ http://issues.apache.org/jira/browse/GERONIMO-640?page=comments#action_12317610 ] Rick McGuire commented on GERONIMO-640: --- Aaron, I had some discussions about FileURLConnection last week with David Blevins and David Jencks on another issue, and we came to the conclusion that the support this class offers over and above the default file connection protocol was not being used be Geronimo. I've been doing some build and test experiments with this this class removed over the last couple of days and this does appear to be true. If this class really needs repairing, then a better solution would probably be to get rid of it entirely. Remove dependency on Sun internals code for URL decoding Key: GERONIMO-640 URL: http://issues.apache.org/jira/browse/GERONIMO-640 Project: Geronimo Type: Improvement Versions: 1.0-M3 Reporter: Tim Ellison Fix For: 1.0-M5 Attachments: decode-patch.txt [Looking at 1.0-M3 source code] The Geronimo types: org.apache.geronimo.system.url.file.Handler and org.apache.geronimo.system.url.file.FileURLConnection both import and use the Sun non-API type sun.net.www.ParseUtil. It appears that the usage is quite trivial, and can easily be replaced by API calls on URLDecoder. This will remove a JRE-implementation dependency. The only caveat is that simple tests show that URLDecoder decodes 'more' than the ParseUtil, so while both methods will convert a%20b to a b; the URLDecoder will convert a+b to a b whereas ParseUtil leaves it as a+b. Is this difference in decoding behavior expected by Geronimo? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-794) List only installed applications that are not part of Geronimo itself
[ http://issues.apache.org/jira/browse/GERONIMO-794?page=comments#action_12317621 ] Joe Bohn commented on GERONIMO-794: --- Yes, that is what I was thinking we should have. Customers using an application server on a daily basis don't often need to manage the components that are delivered as part of the server itself. So let's eliminate the clutter and only show them their applications. My original recommendation was to split this into two portlets with the one including the system applications minimized.However, I think your recommendation of a filter is a better choice. We can update the current portlets to only display non-system applications by default and include an action on the glass to show all or show system applications. This could act like a toggle that would extend the list to include the system applications or restrict the list to remove system applications (of course the action name would change to something like hide system applications when they are currently being displayed. As for the mechanism to filter the set of applications I think that the package name is a good approach. We might have to include more than just org.apach.geronimo (to catch things like OpenEJB) and we might also have to include some org.apach.geronimo packages (such as samples that we might make available to users). However I think we will be able to provide the filtering based upon a set of criteria and not have to resort to hard coding any application names. List only installed applications that are not part of Geronimo itself - Key: GERONIMO-794 URL: http://issues.apache.org/jira/browse/GERONIMO-794 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Attachments: console.diff A user should only see applications that they installed when accessing the list of installed applications from the admin console. We can still show the system applications but under an additional portet that by default is minimized on the page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-794) List only installed applications that are not part of Geronimo itself
[ http://issues.apache.org/jira/browse/GERONIMO-794?page=comments#action_12317628 ] Joe Bohn commented on GERONIMO-794: --- Just a clarification on my last comment. I was intending to say that we might have to exclude (in the filtered view) more than just org/apache/geronimo for things like OpenEJB and include some org/apache/geronimo names for things like samples that the user might explicitly deploy. List only installed applications that are not part of Geronimo itself - Key: GERONIMO-794 URL: http://issues.apache.org/jira/browse/GERONIMO-794 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Attachments: console.diff A user should only see applications that they installed when accessing the list of installed applications from the admin console. We can still show the system applications but under an additional portet that by default is minimized on the page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
JIRA Issues Fix Version
I'm of the opinion that every JIRA should have a Fix Version. If we don't want to atack it any time soon, let's set the fix version to the maximum possible (currently 1.1 or some time after 1.0. There are two main reasons for this: 1) Bugs without a Fix Version tend to be ignored 2) Only bugs with a Fix Version appear on the JIRA Road Map, and I think it's really valuable to have everything on the road map, even the long-term stuff, so we can look at it when estimating the size of a future release and so on. Accordingly, I'll plan to mark the bug below as Fix Version of 1.1. Likewise, I'm trying to (slowly) work through JIRA and assign fix versions to things, and if you don't like what I put on there for some issue you know about, by all means please change the Fix Version, but please don't remove it entirely. Thanks, Aaron On Thu, 4 Aug 2005, David Jencks (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-555?page=all ] David Jencks updated GERONIMO-555: -- Fix Version: (was: 1.0) Description: This is a long term research project that will probably take a month of concentrated effort. We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 was: We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 Write a thread-safe timer/interrupt based transaction timout implementation --- Key: GERONIMO-555 URL: http://issues.apache.org/jira/browse/GERONIMO-555 Project: Geronimo Type: New Feature Components: transaction manager Reporter: David Jencks This is a long term research project that will probably take a month of concentrated effort. We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Configurations
So I've talked to Alan, David J, and Jeremy at OSCon, and I we've agreed on a strategy for supporting editing of Configurations. The guiding principle is that in the short term we want to support editable Configurations for the benefit of developers and small installations and so on. In the long term, we want to allow the ability to produce and work with frozen configurations for the benefit of larger installations and clusters and so on. Even then the process would typically involve a Configuration development period during which everything was editable, then a freeze followed by an export and import to duplicate machines or nodes. Also, even a frozen configuration must allow certain key properties to be set. For example, a frozen web connnector must still let you edit the network port, so you could install the frozen Configuration to several nodes of a cluster on the same machine yet still change the network port so they don't conflict. So there will have to be some way to indicate a certain subset of properties within the Configuration that are editable even after a freeze. Anyway, there's much mroe to it than that, which I won't go into here, but the path forward looks like this (in order): 1) Allow Configuration editing (change properties, add/remove GBeans, etc.) 2) Allow Configurations to be frozen, allow a version number to be assigned to the Configuration, etc. 3) Allow Configurations to be exported to some intermediate format 4) Allow Configurations to be imported from that format Step #1 is a short-term step that I will work on (mainly of interest to the web console). Jeremy is going to try to get a handle on the specific tasks and changes required for Step #2 (it's a bit more extensive that I outlined there), and then decide whether it should be targeted for 1.0 or what. If he isn't able to get to this in time, then Step #2 will wait until after 1.0. Steps 3-4 will in any case wait until after Step #2. Thanks, Aaron
Re: [VOTE] M4 release
+1 -dain On Aug 3, 2005, at 6:54 PM, David Blevins wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David
[jira] Assigned: (GERONIMO-640) Remove dependency on Sun internals code for URL decoding
[ http://issues.apache.org/jira/browse/GERONIMO-640?page=all ] Alan Cabrera reassigned GERONIMO-640: - Assign To: Alan Cabrera Remove dependency on Sun internals code for URL decoding Key: GERONIMO-640 URL: http://issues.apache.org/jira/browse/GERONIMO-640 Project: Geronimo Type: Improvement Versions: 1.0-M3 Reporter: Tim Ellison Assignee: Alan Cabrera Fix For: 1.0-M5 Attachments: decode-patch.txt [Looking at 1.0-M3 source code] The Geronimo types: org.apache.geronimo.system.url.file.Handler and org.apache.geronimo.system.url.file.FileURLConnection both import and use the Sun non-API type sun.net.www.ParseUtil. It appears that the usage is quite trivial, and can easily be replaced by API calls on URLDecoder. This will remove a JRE-implementation dependency. The only caveat is that simple tests show that URLDecoder decodes 'more' than the ParseUtil, so while both methods will convert a%20b to a b; the URLDecoder will convert a+b to a b whereas ParseUtil leaves it as a+b. Is this difference in decoding behavior expected by Geronimo? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-852) NullPointerException in during deploy
NullPointerException in during deploy - Key: GERONIMO-852 URL: http://issues.apache.org/jira/browse/GERONIMO-852 Project: Geronimo Type: Bug Components: security Versions: 1.0-M5 Reporter: Kevan Miller Priority: Minor Attachments: passwordNPE.patch While playing around with uri syntax for deploy commands, I ran across a NPE during login processing: java.lang.NullPointerException at java.lang.String.init(String.java:166) at org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.login(PropertiesFileLoginModule.java:142) at org.apache.geronimo.security.jaas.JaasLoginService.performServerLogin(JaasLoginService.java:240) at org.apache.geronimo.security.jaas.JaasLoginService$$FastClassByCGLIB$$1b5fde8c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:731) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94) at org.apache.geronimo.security.jaas.JaasLoginServiceMBean$$EnhancerByCGLIB$$5302521b.performServerLogin(generated) at org.apache.geronimo.security.jaas.JaasLoginCoordinator$ServerLoginModule.login(JaasLoginCoordinator.java:230) at org.apache.geronimo.security.jaas.LoginUtils.computeLogin(LoginUtils.java:34) at org.apache.geronimo.security.jaas.JaasLoginCoordinator.login(JaasLoginCoordinator.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607) at javax.security.auth.login.LoginContext.login(LoginContext.java:534) at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:57) at javax.management.remote.rmi.RMIServerImpl$1.run(RMIServerImpl.java:141) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIServerImpl.authenticate(RMIServerImpl.java:137) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) To reproduce, I started an out-of-the-box Geronimo server and attempted a deploy using the following: java -jar deployer.jar deploy your-archive-of-choice When prompted for a userName, enter some name. When prompted for a password, ctrl-c the deployment. You should see the NPE at the Server. Problem is that PasswordCallback.getPassword() can return null. In that case, something like new String(callback.getPassword()) will cause an NPE to be thrown from within the String constructor. The fix is to guard against that case... Same thing could happen in SQLoginModule. I'll post a patch for both, shortly... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-555) Write a thread-safe timer/interrupt based transaction timout implementation
[ http://issues.apache.org/jira/browse/GERONIMO-555?page=all ] Aaron Mulder updated GERONIMO-555: -- Fix Version: Wish List Write a thread-safe timer/interrupt based transaction timout implementation --- Key: GERONIMO-555 URL: http://issues.apache.org/jira/browse/GERONIMO-555 Project: Geronimo Type: New Feature Components: transaction manager Reporter: David Jencks Fix For: Wish List This is a long term research project that will probably take a month of concentrated effort. We should investigate whether it is practical to have a thread safe timer/interrupt based transaction timeout implementation. A non-thread safe implementation was present prior to revision 128441. Among the issues that need to be investigated are the extent to which IO is actually interruptable and what existing drivers do when they are interrupted. For this to work, managed connections that get interrupted during io must be reliably destroyed. We should also investigate to what extent this provides a solution for deadlock resolution. If we decide that this is impractical, we should change the internal time unit for timeouts from milliseconds to seconds as proposed in GERONIMO-550 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-852) NullPointerException in during deploy
[ http://issues.apache.org/jira/browse/GERONIMO-852?page=all ] Kevan Miller updated GERONIMO-852: -- Attachment: passwordNPE.patch Fixes for PropertiesFileLoginModule and SQLLoginModule NullPointerException in during deploy - Key: GERONIMO-852 URL: http://issues.apache.org/jira/browse/GERONIMO-852 Project: Geronimo Type: Bug Components: security Versions: 1.0-M5 Reporter: Kevan Miller Priority: Minor Attachments: passwordNPE.patch While playing around with uri syntax for deploy commands, I ran across a NPE during login processing: java.lang.NullPointerException at java.lang.String.init(String.java:166) at org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.login(PropertiesFileLoginModule.java:142) at org.apache.geronimo.security.jaas.JaasLoginService.performServerLogin(JaasLoginService.java:240) at org.apache.geronimo.security.jaas.JaasLoginService$$FastClassByCGLIB$$1b5fde8c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:731) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94) at org.apache.geronimo.security.jaas.JaasLoginServiceMBean$$EnhancerByCGLIB$$5302521b.performServerLogin(generated) at org.apache.geronimo.security.jaas.JaasLoginCoordinator$ServerLoginModule.login(JaasLoginCoordinator.java:230) at org.apache.geronimo.security.jaas.LoginUtils.computeLogin(LoginUtils.java:34) at org.apache.geronimo.security.jaas.JaasLoginCoordinator.login(JaasLoginCoordinator.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607) at javax.security.auth.login.LoginContext.login(LoginContext.java:534) at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:57) at javax.management.remote.rmi.RMIServerImpl$1.run(RMIServerImpl.java:141) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIServerImpl.authenticate(RMIServerImpl.java:137) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) To reproduce, I started an out-of-the-box Geronimo server and attempted a deploy using the following: java -jar deployer.jar deploy your-archive-of-choice When prompted for a userName, enter some name. When prompted for a password, ctrl-c the deployment. You should see the NPE at the Server. Problem is that PasswordCallback.getPassword() can return null. In that case, something like new String(callback.getPassword()) will cause an NPE to be thrown from within the String constructor. The fix is to guard against that case... Same thing could happen in SQLoginModule. I'll post a patch for both, shortly... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Assigned: (GERONIMO-852) NullPointerException in during deploy
[ http://issues.apache.org/jira/browse/GERONIMO-852?page=all ] Aaron Mulder reassigned GERONIMO-852: - Assign To: Aaron Mulder NullPointerException in during deploy - Key: GERONIMO-852 URL: http://issues.apache.org/jira/browse/GERONIMO-852 Project: Geronimo Type: Bug Components: security Versions: 1.0-M5 Reporter: Kevan Miller Assignee: Aaron Mulder Priority: Minor Attachments: passwordNPE.patch While playing around with uri syntax for deploy commands, I ran across a NPE during login processing: java.lang.NullPointerException at java.lang.String.init(String.java:166) at org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.login(PropertiesFileLoginModule.java:142) at org.apache.geronimo.security.jaas.JaasLoginService.performServerLogin(JaasLoginService.java:240) at org.apache.geronimo.security.jaas.JaasLoginService$$FastClassByCGLIB$$1b5fde8c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:731) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94) at org.apache.geronimo.security.jaas.JaasLoginServiceMBean$$EnhancerByCGLIB$$5302521b.performServerLogin(generated) at org.apache.geronimo.security.jaas.JaasLoginCoordinator$ServerLoginModule.login(JaasLoginCoordinator.java:230) at org.apache.geronimo.security.jaas.LoginUtils.computeLogin(LoginUtils.java:34) at org.apache.geronimo.security.jaas.JaasLoginCoordinator.login(JaasLoginCoordinator.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607) at javax.security.auth.login.LoginContext.login(LoginContext.java:534) at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:57) at javax.management.remote.rmi.RMIServerImpl$1.run(RMIServerImpl.java:141) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIServerImpl.authenticate(RMIServerImpl.java:137) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) To reproduce, I started an out-of-the-box Geronimo server and attempted a deploy using the following: java -jar deployer.jar deploy your-archive-of-choice When prompted for a userName, enter some name. When prompted for a password, ctrl-c the deployment. You should see the NPE at the Server. Problem is that PasswordCallback.getPassword() can return null. In that case, something like new String(callback.getPassword()) will cause an NPE to be thrown from within the String constructor. The fix is to guard against that case... Same thing could happen in SQLoginModule. I'll post a patch for both, shortly... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Resolved: (GERONIMO-852) NullPointerException in during deploy
[ http://issues.apache.org/jira/browse/GERONIMO-852?page=all ] Aaron Mulder resolved GERONIMO-852: --- Fix Version: 1.0-M5 Resolution: Fixed Thanks! I wasn't able to replicate the stack trace (Linux SuSE 9.3), but it still seems wise to guard against it. Added a slightly more extensive patch that potentially allows a legitimately null password, and includes tests. NullPointerException in during deploy - Key: GERONIMO-852 URL: http://issues.apache.org/jira/browse/GERONIMO-852 Project: Geronimo Type: Bug Components: security Versions: 1.0-M5 Reporter: Kevan Miller Assignee: Aaron Mulder Priority: Minor Fix For: 1.0-M5 Attachments: passwordNPE.patch While playing around with uri syntax for deploy commands, I ran across a NPE during login processing: java.lang.NullPointerException at java.lang.String.init(String.java:166) at org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.login(PropertiesFileLoginModule.java:142) at org.apache.geronimo.security.jaas.JaasLoginService.performServerLogin(JaasLoginService.java:240) at org.apache.geronimo.security.jaas.JaasLoginService$$FastClassByCGLIB$$1b5fde8c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:731) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94) at org.apache.geronimo.security.jaas.JaasLoginServiceMBean$$EnhancerByCGLIB$$5302521b.performServerLogin(generated) at org.apache.geronimo.security.jaas.JaasLoginCoordinator$ServerLoginModule.login(JaasLoginCoordinator.java:230) at org.apache.geronimo.security.jaas.LoginUtils.computeLogin(LoginUtils.java:34) at org.apache.geronimo.security.jaas.JaasLoginCoordinator.login(JaasLoginCoordinator.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607) at javax.security.auth.login.LoginContext.login(LoginContext.java:534) at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:57) at javax.management.remote.rmi.RMIServerImpl$1.run(RMIServerImpl.java:141) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIServerImpl.authenticate(RMIServerImpl.java:137) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:534) To reproduce, I started an out-of-the-box Geronimo server and attempted a deploy using the following: java -jar deployer.jar deploy your-archive-of-choice When prompted for a userName, enter some name. When prompted for a password, ctrl-c the deployment. You should see the NPE at the Server. Problem is that PasswordCallback.getPassword() can return null. In that case, something like new String(callback.getPassword()) will cause an NPE to be thrown from within the String constructor. The fix is
Re: [jira] Created: (GERONIMO-843) Move Packaging Plugin from cglib 2.1 to cglib 2.1_2 to be consistent with cglib in Geronimo builds
[EMAIL PROTECTED] wrote: Currently the version number for the packaging plugin is 0.1.1. This seems to be inconsistent with the versioning scheme used for the other plugins. Is this intended? Yes - as part of the bootstrap process for this plugin it needs a non-SNAPSHOT version number. As it is still under development I wanted to give it a number that wouldn't be confused with things that were part of the main release. I noticed the plugin isn't in http://cvs.apache.org/repository/geronimo/plugins/ . When are the geronimo plugins normally deployed to the repo? They should be deployed with the release (stable or unstable). As this plugin was experimental it didn't make sense to post it to the main repo. -- Jeremy
Move console out of sandbox?
At the Geronimo BOF last night there was discussion about moving the web console out of the sandbox and into the main build - general consensus seem to be something was better than nothing :-) Any objection to moving it over? -- Jeremy
Re: Move console out of sandbox?
Not from me... On Aug 4, 2005, at 2:58 PM, Jeremy Boynes wrote: At the Geronimo BOF last night there was discussion about moving the web console out of the sandbox and into the main build - general consensus seem to be something was better than nothing :-) Any objection to moving it over? -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-847) Better error for unmapped resource reference
[ http://issues.apache.org/jira/browse/GERONIMO-847?page=all ] Aaron Mulder updated GERONIMO-847: -- Description: When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said Unable to resolve resource-ref 'jms/TestConnectionFactory'. It looks like there's a good message if you provide an invalid mapping value in geronimo-web.xml, but not a good message if you do not provide any mapping in geronimo-web.xml. was: When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said Unable to resolve resource-ref 'jms/TestConnectionFactory'. I believe a similar change was made eslerwhere recently, just need to track down the specifics. Better error for unmapped resource reference Key: GERONIMO-847 URL: http://issues.apache.org/jira/browse/GERONIMO-847 Project: Geronimo Type: Improvement Components: deployment, naming, web Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.0-M5 When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said Unable to resolve resource-ref 'jms/TestConnectionFactory'. It looks like there's a good message if you provide an invalid mapping value in geronimo-web.xml, but not a good message if you do not provide any mapping in geronimo-web.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move console out of sandbox?
I agree ... something is better than nothing. We can continue to evolve both the externals (portlets, look and feel, etc...) and internals (management APIs, component design, etc...) within geronimo. Geir Magnusson Jr. wrote: Not from me... On Aug 4, 2005, at 2:58 PM, Jeremy Boynes wrote: At the Geronimo BOF last night there was discussion about moving the web console out of the sandbox and into the main build - general consensus seem to be something was better than nothing :-) Any objection to moving it over? -- Jeremy -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Created: (GERONIMO-853) rearrange assembly artifact to include root directory
rearrange assembly artifact to include root directory
-
Key: GERONIMO-853
URL: http://issues.apache.org/jira/browse/GERONIMO-853
Project: Geronimo
Type: Bug
Components: buildsystem
Versions: 1.0-M5
Reporter: David Jencks
Fix For: 1.0-M5
1. Rearrange the assembly artifact so everything inside is in a root directory
geronimo-${version}
2. use maven to build a distro so it's a tar.bz2 etc instead of a jar
3. modify the geronimo deploy maven plugin to expect the new structure
4. modify the assembly plugin to produce the new structure
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
[ http://issues.apache.org/jira/browse/GERONIMO-693?page=comments#action_12317686 ] David Jencks commented on GERONIMO-693: --- I talked to Jason van Zyl who strongly recommends Java Service Wrappers which provides scripts for numerous platfomrs and various kinds of daemon restart functionality. See http://wrapper.tanukisoftware.org/doc/english/history.html Jason uses it with continuum. I suggest we include all the JSW stuff in scripts, including a subdirectory for the JSW jar(s) Need startup scripts in bin directory - Key: GERONIMO-693 URL: http://issues.apache.org/jira/browse/GERONIMO-693 Project: Geronimo Type: New Feature Components: usability Environment: Windows, Linux, Mac OS X Reporter: Erin Mulder Assignee: John Sisson Priority: Minor It would be nice to have obvious startup.sh and startup.bat scripts in the bin directory so that the user doesn't need to look at the README file to figure out how to start the server. (java -jar bin/server.jar isn't hard -- it's just not quite as brainless as a script called startup). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] M4 release
+1 Gianny David Blevins [EMAIL PROTECTED] wrote: The tests are still running on David J's machine and should finish sometime tomorrow. Since voting takes a day or so anyway, let's get started and do them in parallel. Vote: Let's Release these binaries when the tests successfully complete. (http://cvs.apache.org/dist/geronimo/unstable/1.0-M4) Here is my +1. -David
[jira] Created: (GERONIMO-854) Remove unused interop-server-plan.xml
Remove unused interop-server-plan.xml - Key: GERONIMO-854 URL: http://issues.apache.org/jira/browse/GERONIMO-854 Project: Geronimo Type: Task Components: CORBA Versions: 1.0-M4 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.0-M5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-855) CORBA configuration in izpack installer is not used and needs to be updated to configure the CORBA support in OpenEJB
CORBA configuration in izpack installer is not used and needs to be updated to configure the CORBA support in OpenEJB - Key: GERONIMO-855 URL: http://issues.apache.org/jira/browse/GERONIMO-855 Project: Geronimo Type: Task Components: CORBA, installer Versions: 1.0-M4 Reporter: John Sisson Fix For: 1.0-M5 The izpack installer's CORBA configuration seems to be outdated (designed to be used with the now defunct interop plan). The installer needs to be changed to allow configuration of the current CORBA implementation in OpenEJB. Who knows about this? Can someone give an overview of how Corba is configured, started and utilised in the M4 release? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-854) Remove unused interop-server-plan.xml
[ http://issues.apache.org/jira/browse/GERONIMO-854?page=all ] John Sisson resolved GERONIMO-854: -- Resolution: Fixed Fixed. interop-server-plan.xml deleted from HEAD. Remove unused interop-server-plan.xml - Key: GERONIMO-854 URL: http://issues.apache.org/jira/browse/GERONIMO-854 Project: Geronimo Type: Task Components: CORBA Versions: 1.0-M4 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0-M5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-854) Remove unused interop-server-plan.xml
[ http://issues.apache.org/jira/browse/GERONIMO-854?page=all ] John Sisson closed GERONIMO-854: Remove unused interop-server-plan.xml - Key: GERONIMO-854 URL: http://issues.apache.org/jira/browse/GERONIMO-854 Project: Geronimo Type: Task Components: CORBA Versions: 1.0-M4 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0-M5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-843) Move Packaging Plugin from cglib 2.1 to cglib 2.1_2 to be consistent with cglib in Geronimo builds
[ http://issues.apache.org/jira/browse/GERONIMO-843?page=all ] John Sisson resolved GERONIMO-843: -- Resolution: Fixed Fixed in HEAD. Also bumped up plugin version to 0.1.2 Move Packaging Plugin from cglib 2.1 to cglib 2.1_2 to be consistent with cglib in Geronimo builds -- Key: GERONIMO-843 URL: http://issues.apache.org/jira/browse/GERONIMO-843 Project: Geronimo Type: Task Reporter: John Sisson Priority: Minor Fix For: 1.0-M5 Need to update geronimo/plugins/geronimo-packaging-plugin/project.xml to use cglib version 2.1_2 (note the underscore). Do we have anything using the packaging plugin at the moment? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
JMS configuration plans and config.list questions
The org/apache/geronimo/SystemJMS config defines an ActiveMQ resource adapter ( and the DefaultActiveMQConnectionFactory ) , MDBTransferBeanOutQueue and SendReceiveQueue admin objects. Should the two queues be removed ( I assume they were there for testing in the past)? Are we expecting users of the web console ( I haven't played with yet) adding more queues to the org/apache/geronimo/SystemJMS config, or should we be encouraging them to use their own config? If we aren't expecting users to be able to add more queues to the org/apache/geronimo/SystemJMS config, then should the org/apache/geronimo/SystemJMS config be removed from the config.list and replaced with org/apache/geronimo/ActiveMQServer? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
