[jira] [Created] (GERONIMO-6073) Rotation and appending of console output when Geronimo is run a windows service
Rotation and appending of console output when Geronimo is run a windows service --- Key: GERONIMO-6073 URL: https://issues.apache.org/jira/browse/GERONIMO-6073 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: commands Affects Versions: 2.2.1, 2.1.7 Environment: Windows Reporter: Vamsavardhana Reddy GERONIMO-4394 provided for running Geronimo as windows service. The console output STDOUT is directed to geronimosrv.out and STDERR is directed to geronimosrv.err. If the server is running for long, these files can grow big requiring the server to be stopped. Also, each time the server is started as service, the files from the previous run are overwritten since the output does not get appended to existing file. So, if a user is interested in the console output from the previous runs, it is lost. So, console output rotation and appending to already existing files should be a good improvement for the Run Geronimo as a Windows service feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032289#comment-13032289 ] Vamsavardhana Reddy commented on GERONIMO-4576: --- I see that 2.2 revs 1097555 and 1097965 are also related to this JIRA. Make persistence exceptions more visible to client -- Key: GERONIMO-4576 URL: https://issues.apache.org/jira/browse/GERONIMO-4576 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.2 Environment: Linux, Windows Reporter: Joe Bohn Priority: Minor Fix For: Wish List See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the original problem. That core problem was resolved. However, upon resolution it was mentioned that it would be beneficial to report more specific failure information back to the client. From GERONIMO-3907: Ralf Baumhof - 06/May/08 06:17 AM Today if have tested the new Geronimo release 2.1.1 (published on 28.04.2008). The problem is now fixed. If the server gets an error on trying a commit, this error is now thrown to the web bean. Exception text: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Root Cause: javax.transaction.TransactionRolledbackException : Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Unfortunately there is no proper root cause attached to the exception. So the cause can only be seen in the server console, but can not be reported to the user. It would be very nice if you could change this in a later release. Thanks for your help. Vincent MATHON - 06/Nov/08 02:03 AM I agree that exceptions on the server side should not be thrown to the client side since such exceptions types might not be known by the client. However, for unit testing purpose, it is useful to attach the root cause to the RollBackException. I have modified a few lines in org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the root cause in case of RollBackException and it works for my unit testing purpose (I have not enough background on the java transaction architecture topic to submit a patch for production). It would be great to define a configuration parameter that permits to provide the root cause to the client and keep the current behaviour that does not by default. Geoff Callender - 22/Dec/08 03:36 AM It's useful for more than unit testing - it's essential to be able to inform the client what's wrong with the request. I've added some examples of this to https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032411#comment-13032411 ] Vamsavardhana Reddy commented on GERONIMO-4576: --- I notice that revs 1097555 and 1097965 are once again masking the original persistence exception and putting a SetRollbackOnlyException() as the cause. To give an example, with rev 1076770 applied in my code, I am getting the following exception report: REPORT-1: org.apache.jasper.JasperException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.transaction.RollbackException: Unable to commit: transaction marked for rollback root cause: openjpa-1.2.2-r422266:898935 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. ... -- With revs 1076770, 1097555 and 1097965 applied in my code, I am getting the following exception report in the same case (notice that the persistence exception is lost): REPORT-2: org.apache.jasper.JasperException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.transaction.RollbackException: Unable to commit: transaction marked for rollback root cause: org.apache.geronimo.transaction.manager.SetRollbackOnlyException: setRollbackOnly() called. See stacktrace for origin Make persistence exceptions more visible to client -- Key: GERONIMO-4576 URL: https://issues.apache.org/jira/browse/GERONIMO-4576 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.2 Environment: Linux, Windows Reporter: Joe Bohn Priority: Minor Fix For: Wish List See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the original problem. That core problem was resolved. However, upon resolution it was mentioned that it would be beneficial to report more specific failure information back to the client. From GERONIMO-3907: Ralf Baumhof - 06/May/08 06:17 AM Today if have tested the new Geronimo release 2.1.1 (published on 28.04.2008). The problem is now fixed. If the server gets an error on trying a commit, this error is now thrown to the web bean. Exception text: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Root Cause: javax.transaction.TransactionRolledbackException : Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Unfortunately there is no proper root cause attached to the exception. So the cause can only be seen in the server console, but can not be reported to the user. It would be very nice if you could change this in a later release. Thanks for your help. Vincent MATHON - 06/Nov/08 02:03 AM I agree that exceptions on the server side should not be thrown to the client side since such exceptions types might not be known by the client. However, for unit testing purpose, it is useful to attach the root cause to the RollBackException. I have modified a few lines in org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the root cause in case of RollBackException and it works for my unit testing purpose (I have not enough background on the java transaction architecture topic to submit a patch for production). It would be great to define a configuration parameter that permits to provide the root cause to the client and keep the current behaviour that does not by default. Geoff Callender - 22/Dec/08 03:36 AM It's useful for more than unit testing - it's essential to be able to inform the client what's wrong with the request. I've added some examples of this to https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message is automatically generated by
[jira] [Created] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory --- Key: GERONIMO-5950 URL: https://issues.apache.org/jira/browse/GERONIMO-5950 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
[ https://issues.apache.org/jira/browse/GERONIMO-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5950: -- Description: AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch (https://issues.apache.org/jira/secure/attachment/12478376/AMQ-3121-v412.patch) has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. was: AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805)
[jira] [Commented] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
[ https://issues.apache.org/jira/browse/GERONIMO-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029895#comment-13029895 ] Vamsavardhana Reddy commented on GERONIMO-5950: --- Completed: At revision: 1100170 in server/branches/2.1 GERONIMO-5950 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory o Create a customized ActiveMQ 4.1.2 build for Geronimo 2.1.8. Jars changed are activemq-core and activemq-ra. o Update server poms to use this build 4.1.2-G20110506. AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory --- Key: GERONIMO-5950 URL: https://issues.apache.org/jira/browse/GERONIMO-5950 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch (https://issues.apache.org/jira/secure/attachment/12478376/AMQ-3121-v412.patch) has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
[ https://issues.apache.org/jira/browse/GERONIMO-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029901#comment-13029901 ] Vamsavardhana Reddy commented on GERONIMO-5950: --- Completed: At revision: 1100181 in server/branches/2.1 GERONIMO-5950 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory o Update repository pom so that custom activemq-ra jar gets copied over to local maven repo during build AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory --- Key: GERONIMO-5950 URL: https://issues.apache.org/jira/browse/GERONIMO-5950 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch (https://issues.apache.org/jira/secure/attachment/12478376/AMQ-3121-v412.patch) has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007817#comment-13007817 ] Vamsavardhana Reddy commented on GERONIMO-4184: --- Thanks David. The one doubt I had is if introducing two random bytes along with tmId would break anything. Your comment has clarified that. Essentially the random bytes introduced by fix for GERONIMO-4393 will result in a different tmId each time the server is started and break transaction recovery. (Geronimo server may be immune to this as we use the XidFactoryImpl constructor with tmId as parameter.) How can we make sure that even the generated tmId would be the same for a server instance with subsequent restarts? In-doubt transaction Id's could be reused during server startup --- Key: GERONIMO-4184 URL: https://issues.apache.org/jira/browse/GERONIMO-4184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 Reporter: Kevan Miller Fix For: Wish List Attachments: GERONIM-4184.patch During server restart, we may reuse an Xid for a transaction which is in-doubt. Potentially confusing a resource manager. We need to insure this does not occur. Simple way is to remember the largest Xid in tran log and start with a larger number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006815#comment-13006815 ] Vamsavardhana Reddy commented on GERONIMO-4184: --- GERONIMO-4393 has introduced two random bytes into the baseId to avoid duplication of baseId across multiple JVMs on the same machine. That fix would still not suffice completely as the two random bytes are added to baseId only if the no-argument constructor of XidFactoryImpl is used and Geronimo uses the other constructor that takes byte[] tmId as argument. If we add two random bytes to baseId even in the case of the constructor with tmId, we can minimize the chance of reuse of In-doubt transaction Id's as the baseId would be different on each run of the server. We can even increase the length of random bytes (to say 4 instead of 2) to further reduce the chance of reuse of In-doubt transaction Id's. Any suggestions or comments to this approach? In-doubt transaction Id's could be reused during server startup --- Key: GERONIMO-4184 URL: https://issues.apache.org/jira/browse/GERONIMO-4184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 Reporter: Kevan Miller Fix For: Wish List During server restart, we may reuse an Xid for a transaction which is in-doubt. Potentially confusing a resource manager. We need to insure this does not occur. Simple way is to remember the largest Xid in tran log and start with a larger number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-4184: -- Attachment: GERONIM-4184.patch GERONIM-4184.patch: Add two random bytes entropy even when XidFactoryImpl(byte[]) constructor is used. Patch created against branches\geronimo-txmanager-parent-2.2. In-doubt transaction Id's could be reused during server startup --- Key: GERONIMO-4184 URL: https://issues.apache.org/jira/browse/GERONIMO-4184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 Reporter: Kevan Miller Fix For: Wish List Attachments: GERONIM-4184.patch During server restart, we may reuse an Xid for a transaction which is in-doubt. Potentially confusing a resource manager. We need to insure this does not occur. Simple way is to remember the largest Xid in tran log and start with a larger number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-5806) SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER
[ https://issues.apache.org/jira/browse/GERONIMO-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992920#comment-12992920 ] Vamsavardhana Reddy commented on GERONIMO-5806: --- Completed: At revision: 1069260 in branches\2.1 Completed: At revision: 1069261 in branches\2.2 SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER Key: GERONIMO-5806 URL: https://issues.apache.org/jira/browse/GERONIMO-5806 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.7, 2.2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8, 2.2.2 Attachments: GERONIMO-5806.patch When a SharedLib GBean is added to a configuration by updating config.xml, the new classes and jars from the shared lib do not get into the configuration's class loader until that GBean instance is created. This results in ClassNotFoundExceptions if another GBean that uses these new classes is loaded ahead of the SharedLib GBean. This can be avoided by setting the priority of SharedLib GBean to GBeanInfo.PRIORITY_CLASSLOADER so that the new classes and jars get added to the classloader and are available immediately for all other GBeans in the configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-5806) SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER
SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER Key: GERONIMO-5806 URL: https://issues.apache.org/jira/browse/GERONIMO-5806 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 2.2.1, 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8, 2.2.2 When a SharedLib GBean is added to a configuration by updating config.xml, the new classes and jars from the shared lib do not get into the configuration's class loader until that GBean instance is created. This results in ClassNotFoundExceptions if another GBean that uses these new classes is loaded ahead of the SharedLib GBean. This can be avoided by setting the priority of SharedLib GBean to GBeanInfo.PRIORITY_CLASSLOADER so that the new classes and jars get added to the classloader and are available immediately for all other GBeans in the configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-5806) SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER
[ https://issues.apache.org/jira/browse/GERONIMO-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5806: -- Attachment: GERONIMO-5806.patch SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER Key: GERONIMO-5806 URL: https://issues.apache.org/jira/browse/GERONIMO-5806 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.7, 2.2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8, 2.2.2 Attachments: GERONIMO-5806.patch When a SharedLib GBean is added to a configuration by updating config.xml, the new classes and jars from the shared lib do not get into the configuration's class loader until that GBean instance is created. This results in ClassNotFoundExceptions if another GBean that uses these new classes is loaded ahead of the SharedLib GBean. This can be avoided by setting the priority of SharedLib GBean to GBeanInfo.PRIORITY_CLASSLOADER so that the new classes and jars get added to the classloader and are available immediately for all other GBeans in the configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980017#action_12980017 ] Vamsavardhana Reddy commented on GERONIMO-5749: --- At revision: 1057539 on branches\2.1 (i.e. 2.1.8-SNAPSHOT). o Added SQL scripts to enable/disable monitoring on Default Server o Added Windows and Unix batch files to execute SQL using ij from Derby o Files will be copied to server's bin directory when the plugin is installed. o Eg. script to enable monitoring: runsql localhost 1527 dbadmin manager enable-monitoring Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat, runsql.sh Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-5355:
--
Affects Version/s: 2.2.1
Fix Version/s: 2.2.2
Completed: At revision: 1058001 in branches\2.2 (i.e. 2.2.2-SNAPSHOT)
o Merging rev 1055305 from 2.1 branch.
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5, 2.2.1
Reporter: Amit Puri
Assignee: Vamsavardhana Reddy
Fix For: 2.1.8, 2.2.2
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978293#action_12978293 ] Vamsavardhana Reddy commented on GERONIMO-5749: --- At revision: 1055843 on branches\2.1 (i.e. 2.1.8-SNAPSHOT). o Added a deployer command to enable/disable stats query snapshot thread for Default Server. Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978441#action_12978441 ] Vamsavardhana Reddy commented on GERONIMO-5749: --- I have created two sql files enable-monitoring.sql, disable-monitoring.sql and two command scripts runsql.bat, runsql.sh to run the sql by using the org.apache.derby.tools.ij class. I have manually copied these four files over to the bin directory and tested that the script run fine. I am thinking of packaging these files in mconsole-ds project so that they get copied over to the bin directory when the mconsole-ds plugin gets installed. Anybody has any comments on whether this is ok or a suggestion on where to package these four files? Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5749: -- Attachment: runsql.bat disable-monitoring.sql enable-monitoring.sql Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5749: -- Attachment: runsql.sh runsql.bat Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat, runsql.sh Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5749: -- Attachment: (was: runsql.bat) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat, runsql.sh Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-5355:
--
Fix Version/s: 2.1.8
Assignee: Vamsavardhana Reddy
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Amit Puri
Assignee: Vamsavardhana Reddy
Fix For: 2.1.8
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12977640#action_12977640
]
Vamsavardhana Reddy commented on GERONIMO-5355:
---
Completed: At revision: 1055305 in branches\2.1 (i.e. 2.1.8-SNAPSHOT).
o Exception is due to a different thread context classloader at play when the
method is invoked through RMI as opposed to invocation through admin console.
Fixed by changing the context classloader for the lookups.
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Amit Puri
Assignee: Vamsavardhana Reddy
Fix For: 2.1.8
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966444#action_12966444
]
Vamsavardhana Reddy commented on GERONIMO-5355:
---
The exception seems to be due to a
org.tranql.connector.jdbc.TranqlDataSource$SelfReference object getting bound
to the JNDI instead of org.tranql.connector.jdbc.TranqlDataSource. The
TranqlDataSource object is to be obtained by calling getContent() method on the
SelfReference object.
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Amit Puri
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915789#action_12915789 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 100 o Throw deployment exception for errors in parsing validation and constraint mapping xml Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: Vamsavardhana Reddy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5221) Add naming support for Validator and ValidatorFactory.
[ https://issues.apache.org/jira/browse/GERONIMO-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910143#action_12910143 ] Vamsavardhana Reddy commented on GERONIMO-5221: --- At revision: 997732 o DefaultValidator should use configured ValidatorFactory if any Add naming support for Validator and ValidatorFactory. --- Key: GERONIMO-5221 URL: https://issues.apache.org/jira/browse/GERONIMO-5221 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: David Jencks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5221) Add naming support for Validator and ValidatorFactory.
[ https://issues.apache.org/jira/browse/GERONIMO-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910249#action_12910249 ] Vamsavardhana Reddy commented on GERONIMO-5221: --- At revision: 997868 o Cache the factory instance so that a single instance is used per module Add naming support for Validator and ValidatorFactory. --- Key: GERONIMO-5221 URL: https://issues.apache.org/jira/browse/GERONIMO-5221 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: David Jencks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5607) geronimo-default keystore file not displayed on the administration console
[ https://issues.apache.org/jira/browse/GERONIMO-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909682#action_12909682 ] Vamsavardhana Reddy commented on GERONIMO-5607: --- An 'EMPTY' file in var\security\keystores directory is the culprit. geronimo-default keystore file not displayed on the administration console -- Key: GERONIMO-5607 URL: https://issues.apache.org/jira/browse/GERONIMO-5607 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 3.0 Environment: Windows platform Reporter: maojia Priority: Minor The geronimo-default keystore file is not displayed on the Keystore portlet on the administration console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906936#action_12906936 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 993482 o Support for web applications o ModuleBuilderExtension to add ValidatorFactoryGBean. o Hook the module builder extension to tomcat builder. Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: Vamsavardhana Reddy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907037#action_12907037 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 993562 o Hook the module builder extension to jetty deployer. Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: Vamsavardhana Reddy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5226) Pass container ValidationFactory to the persistance manager when creating an entity manager.
[ https://issues.apache.org/jira/browse/GERONIMO-5226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907045#action_12907045 ] Vamsavardhana Reddy commented on GERONIMO-5226: --- At revision: 993568 o Hook the BValModuleBuilderExtension to openejb deployer. o Add ValidatorFactoryGBean as a parameter to PersistenceUnitGBean constructor. Pass container ValidationFactory to the persistance manager when creating an entity manager. - Key: GERONIMO-5226 URL: https://issues.apache.org/jira/browse/GERONIMO-5226 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5228) Add classes for parsing a validation.xml descriptor
[ https://issues.apache.org/jira/browse/GERONIMO-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905543#action_12905543 ] Vamsavardhana Reddy commented on GERONIMO-5228: --- The built-in parser ValidationParser class in Bean Validation API tries to load the specified validation.xml file and constraint mapping files through the classloader API. At least in case of web applications, WEB-INF/validation.xml etc will not be available through web-app's classloader. So, there is definitely some work to be done here though we may use the JAXB generated classes from BVAL. Add classes for parsing a validation.xml descriptor --- Key: GERONIMO-5228 URL: https://issues.apache.org/jira/browse/GERONIMO-5228 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5227) Add ValidatorFactory to servlet context for JSF usage.
[ https://issues.apache.org/jira/browse/GERONIMO-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5227: -- Attachment: GERONIMO-5227-tomcat.patch GERONIMO-5227-tomcat.patch: Set the javax.faces.validator.beanValidator.ValidatorFactory attribute in ServletContext for Tomcat. Add ValidatorFactory to servlet context for JSF usage. --- Key: GERONIMO-5227 URL: https://issues.apache.org/jira/browse/GERONIMO-5227 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 Attachments: GERONIMO-5227-tomcat.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5227) Add ValidatorFactory to servlet context for JSF usage.
[ https://issues.apache.org/jira/browse/GERONIMO-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5227: -- Attachment: GERONIMO-5227-jetty.patch GERONIMO-5227-jetty.patch: Set the javax.faces.validator.beanValidator.ValidatorFactory attribute in ServletContext for Jetty. Add ValidatorFactory to servlet context for JSF usage. --- Key: GERONIMO-5227 URL: https://issues.apache.org/jira/browse/GERONIMO-5227 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 Attachments: GERONIMO-5227-jetty.patch, GERONIMO-5227-tomcat.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4834) artifact aliasing does not seem to work for configuration id's
artifact aliasing does not seem to work for configuration id's -- Key: GERONIMO-4834 URL: https://issues.apache.org/jira/browse/GERONIMO-4834 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: core Affects Versions: 2.1.4 Reporter: Vamsavardhana Reddy Fix For: 2.1.5, 2.2 Artifact aliasing does not seem to work for configuration ids. I have encountered the following problem while trying to change the JPA provider from OpenJPA to TopLink. I have created a configuration o.a.g.configs/toplink/2.1.4/car to replace openjpa car. I have added the following line in artifact_aliases.properties: org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/toplink/2.1.4/car But when I start the server, openjpa//car is getting started as openejb//car has a dependency on openjpa//car. Ideally I would expect toplink//car to be used by openejb//car because of the aliasing above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4718) Keystores portlet: Once unlocked for availability, keystore can not be locked
Keystores portlet: Once unlocked for availability, keystore can not be locked - Key: GERONIMO-4718 URL: https://issues.apache.org/jira/browse/GERONIMO-4718 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.4 Reporter: Vamsavardhana Reddy Fix For: 2.1.5 Attempting to lock the keystore for availability is displaying the following message in the server console. 2009-06-29 08:23:07,265 ERROR [MultiPagePortlet] Unrecognized portlet action 'lockKeystore' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4446) ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3
ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3 --- Key: GERONIMO-4446 URL: https://issues.apache.org/jira/browse/GERONIMO-4446 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty Affects Versions: 2.1.3, 2.2 Environment: Geronimo Jetty 2.1.3, Windows XP, Sun JDK 1.5.0_13 Reporter: Vamsavardhana Reddy I have a web application with a ServletRequestListener and a ServletRequestAttributeListener. In ServletRequestListener.requestInitialized() I am adding an attribute hellotxt to the servlet request. In ServletRequestAttributeListener.attributeAdded(), I am appending some text to the same attribute. This application deployed in G Tomcat 2.1.3 server, is working as expected and attributeAdded() method is called for hellotxt attribute. If the same application is deployed in G Jetty 2.1.3 server, attributeAdded() method is not getting called for hellotxt attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4446) ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3
[
https://issues.apache.org/jira/browse/GERONIMO-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-4446:
--
Attachment: helloworld-listener.war
helloworld-listener.war: Sample application to demonstrate the problem.
Deploy the application and access http://localhost:8080/helloworld-listener .
Notice that on G Tomcat 2.1.3, the page displays
{code}
Request initialized. Adding hellotxt attribute...
hellotxt attribute added.
{code}
\\
Notice that on G Jetty 2.1.3, the page displays
{code}
Request initialized. Adding hellotxt attribute...
{code}
ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with
G Tomcat 2.1.3
---
Key: GERONIMO-4446
URL: https://issues.apache.org/jira/browse/GERONIMO-4446
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Jetty
Affects Versions: 2.1.3, 2.2
Environment: Geronimo Jetty 2.1.3, Windows XP, Sun JDK 1.5.0_13
Reporter: Vamsavardhana Reddy
Attachments: helloworld-listener.war
I have a web application with a ServletRequestListener and a
ServletRequestAttributeListener. In
ServletRequestListener.requestInitialized() I am adding an attribute
hellotxt to the servlet request. In
ServletRequestAttributeListener.attributeAdded(), I am appending some text to
the same attribute. This application deployed in G Tomcat 2.1.3 server, is
working as expected and attributeAdded() method is called for hellotxt
attribute. If the same application is deployed in G Jetty 2.1.3 server,
attributeAdded() method is not getting called for hellotxt attribute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4367) default-subject does not work with EJB security
[
https://issues.apache.org/jira/browse/GERONIMO-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-4367:
--
Comment: was deleted
default-subject does not work with EJB security
---
Key: GERONIMO-4367
URL: https://issues.apache.org/jira/browse/GERONIMO-4367
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.1.3, 2.2
Reporter: Vamsavardhana Reddy
Fix For: 2.2
Attachments: GERONIMO-4367-testcase.zip
The default-subject does not seem to work with EJB security. I have verified
this in the following scenario:
I have a stateless bean BankBean1 as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
public class BankBean1 implements Bank {
@RolesAllowed({customer, bank})
public Double getBalance(Integer account) {
return data.get(account);
}
@RolesAllowed({bank})
public Double creditAccount(Integer account, Double amt) {
...
return value;
}
@RolesAllowed({bank})
public Double debitAccount(Integer account, Double amt) {
...
return value;
}
}
I have a second stateless bean BankBean2 that has a reference injected to
BankBean1 and uses @RunAs as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
@RunAs(value = bank)
public class BankBean2 implements Bank2 {
@EJB
private Bank bank; // BankBean1 gets injected here.
public Double getBalance(Integer account) {
return bank.getBalance(account);
}
public Double creditAccount(Integer account, Double amt) {
return bank.creditAccount(account, amt);
}
public Double debitAccount(Integer account, Double amt) {
return bank.debitAccount(account, amt);
}
}
In the security mapping in openejb-jar.xml, if I specify a run-as-subject for
bank role, BankBean2 is able to invoke BankBean1 as per that run-as-subject
specified. But if I don't specify a run-as-subject, but only use a
default-subject, BankBean2 is unable to invoke BankBean1 as per the
default-subject specified.
Also see
http://www.nabble.com/How-is-the-default-subject-used-in-EJB-security--td20021936s134.html#a20021936
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645752#action_12645752 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- addComponentContextLocator.diff committed at revision: 712114 helloworld-servlet.diff committed at revision: 712115 Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: add-jms-sca-binding.diff, addComponentContextLocator.diff, asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, helloworld-jsp.diff, helloworld-jsp.war, helloworld-jsp2.diff, helloworld-service.diff, helloworld-servlet.diff, helloworld-web.diff, implementation-web-runtime.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645219#action_12645219 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- implementation-web-runtime.diff committed in rev 711562 and 711569. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: add-jms-sca-binding.diff, asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, helloworld-jsp.diff, helloworld-jsp.war, helloworld-jsp2.diff, helloworld-service.diff, helloworld-web.diff, implementation-web-runtime.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645255#action_12645255 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- helloworld-jsp application committed in rev711604. helloworld-web.diff committed in rev711608. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: add-jms-sca-binding.diff, asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, helloworld-jsp.diff, helloworld-jsp.war, helloworld-jsp2.diff, helloworld-service.diff, helloworld-web.diff, implementation-web-runtime.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4338) Update Geronimo Jetty ServletHost to account for G3609 changes
[ https://issues.apache.org/jira/browse/GERONIMO-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-4338. - Resolution: Fixed Completed: At revision: 711230 Update Geronimo Jetty ServletHost to account for G3609 changes -- Key: GERONIMO-4338 URL: https://issues.apache.org/jira/browse/GERONIMO-4338 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Rev 601149 GERONIMO-3609 Better fix for supplying jndi on forwarded calls as well as for servlet listeners dropped the API org.apache.geronimo.jetty6.handler.ComponentContextHandler.getChildHandlerByClass() as AbstractImmutableHandler no longer extends AbstractHandlerContainer. This requires corresponding changes to Geronimo Jetty ServletHost in Tuscany plugin. This JIRA is created to keep track of the required changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12642195#action_12642195 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- The helloworld-service.diff applied in rev707405. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: add-jms-sca-binding.diff, asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, helloworld-jsp.diff, helloworld-service.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-4343: -- Attachment: helloworld-jsp.war helloworld-jsp.war: After applying helloworld-jsp.diff, the project is not building properly. I am noticing that the war file has improper structure. [ERROR] BUILD ERROR [INFO] [INFO] Artifact does not contain any legal files: helloworld-jsp.war Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: add-jms-sca-binding.diff, asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, helloworld-jsp.diff, helloworld-jsp.war, helloworld-service.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4367) default-subject does not work with EJB security
default-subject does not work with EJB security
---
Key: GERONIMO-4367
URL: https://issues.apache.org/jira/browse/GERONIMO-4367
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: security
Affects Versions: 2.1.3, 2.2
Reporter: Vamsavardhana Reddy
Fix For: 2.2
The default-subject does not seem to work with EJB security. I have verified
this in the following scenario:
I have a stateless bean BankBean1 as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
public class BankBean1 implements Bank {
@RolesAllowed({customer, bank})
public Double getBalance(Integer account) {
return data.get(account);
}
@RolesAllowed({bank})
public Double creditAccount(Integer account, Double amt) {
...
return value;
}
@RolesAllowed({bank})
public Double debitAccount(Integer account, Double amt) {
...
return value;
}
}
I have a second stateless bean BankBean2 that has a reference injected to
BankBean1 and uses @RunAs as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
@RunAs(value = bank)
public class BankBean2 implements Bank2 {
@EJB
private Bank bank; // BankBean1 gets injected here.
public Double getBalance(Integer account) {
return bank.getBalance(account);
}
public Double creditAccount(Integer account, Double amt) {
return bank.creditAccount(account, amt);
}
public Double debitAccount(Integer account, Double amt) {
return bank.debitAccount(account, amt);
}
}
In the security mapping in openejb-jar.xml, if I specify a run-as-subject for
bank role, BankBean2 is able to invoke BankBean1 as per that run-as-subject
specified. But if I don't specify a run-as-subject, but only use a
default-subject, BankBean2 is unable to invoke BankBean1 as per the
default-subject specified.
Also see
http://www.nabble.com/How-is-the-default-subject-used-in-EJB-security--td20021936s134.html#a20021936
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4367) default-subject does not work with EJB security
[
https://issues.apache.org/jira/browse/GERONIMO-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-4367:
--
Attachment: GERONIMO-4367-testcase.zip
GERONIMO-4367-testcase.zip has the necessary files to verify this issue.
Instructions are in README.TXT in the archive.
default-subject does not work with EJB security
---
Key: GERONIMO-4367
URL: https://issues.apache.org/jira/browse/GERONIMO-4367
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.1.3, 2.2
Reporter: Vamsavardhana Reddy
Fix For: 2.2
Attachments: GERONIMO-4367-testcase.zip
The default-subject does not seem to work with EJB security. I have verified
this in the following scenario:
I have a stateless bean BankBean1 as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
public class BankBean1 implements Bank {
@RolesAllowed({customer, bank})
public Double getBalance(Integer account) {
return data.get(account);
}
@RolesAllowed({bank})
public Double creditAccount(Integer account, Double amt) {
...
return value;
}
@RolesAllowed({bank})
public Double debitAccount(Integer account, Double amt) {
...
return value;
}
}
I have a second stateless bean BankBean2 that has a reference injected to
BankBean1 and uses @RunAs as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
@RunAs(value = bank)
public class BankBean2 implements Bank2 {
@EJB
private Bank bank; // BankBean1 gets injected here.
public Double getBalance(Integer account) {
return bank.getBalance(account);
}
public Double creditAccount(Integer account, Double amt) {
return bank.creditAccount(account, amt);
}
public Double debitAccount(Integer account, Double amt) {
return bank.debitAccount(account, amt);
}
}
In the security mapping in openejb-jar.xml, if I specify a run-as-subject for
bank role, BankBean2 is able to invoke BankBean1 as per that run-as-subject
specified. But if I don't specify a run-as-subject, but only use a
default-subject, BankBean2 is unable to invoke BankBean1 as per the
default-subject specified.
Also see
http://www.nabble.com/How-is-the-default-subject-used-in-EJB-security--td20021936s134.html#a20021936
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638836#action_12638836 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- add-jms-sca-binding.diff applied in rev 703773. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: add-jms-sca-binding.diff, asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638510#action_12638510 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- up-to-tuscany-1.4-snapshot.diff applied in rev 703354. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: asm.diff, GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637816#action_12637816 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- tuscany-xsd-dependency.diff applied in rev 702746. Thanks Ant. Regarding the Tuscany SNAPSHOTs, should we stick to 1.3 branch or the trunk (i.e. 1.4-SNAPSHOT)? Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: tuscany-xsd-dependency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637890#action_12637890 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- wsdlgen-depenency.diff applied in rev 702817. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: GeronimoServletHost1.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637901#action_12637901 ] Vamsavardhana Reddy commented on GERONIMO-4343: --- GeronimoServletHost2.diff applied in rev 702838. Tuscany Geronimo plugin bring up Key: GERONIMO-4343 URL: https://issues.apache.org/jira/browse/GERONIMO-4343 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: ant elder Attachments: GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, wsdlgen-depenency.diff JIRA to cover getting the Tuscany Geronimo Plugin working again with the latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4338) Update Geronimo Jetty ServletHost to account for G3609 changes
Update Geronimo Jetty ServletHost to account for G3609 changes -- Key: GERONIMO-4338 URL: https://issues.apache.org/jira/browse/GERONIMO-4338 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Rev 601149 GERONIMO-3609 Better fix for supplying jndi on forwarded calls as well as for servlet listeners dropped the API org.apache.geronimo.jetty6.handler.ComponentContextHandler.getChildHandlerByClass() as AbstractImmutableHandler no longer extends AbstractHandlerContainer. This requires corresponding changes to Geronimo Jetty ServletHost in Tuscany plugin. This JIRA is created to keep track of the required changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DAYTRADER-61) trying to build Daytrader trunk fails with FATAL ERROR
[ https://issues.apache.org/jira/browse/DAYTRADER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631679#action_12631679 ] Vamsavardhana Reddy commented on DAYTRADER-61: -- Try https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.3/repository/ trying to build Daytrader trunk fails with FATAL ERROR -- Key: DAYTRADER-61 URL: https://issues.apache.org/jira/browse/DAYTRADER-61 Project: DayTrader Issue Type: Bug Components: buildsystem Reporter: ant elder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned GERONIMO-3876: - Assignee: (was: Vamsavardhana Reddy) Not getting time to look at this recently :(. If someone else wants to build on top of what I have done so far and take it further before I find time again, please do so. Kevan, This feature would require a change to the existing interfaces which my break backward compatibility with prior 2.1.x versions. Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: management, security Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Fix For: 2.2 Attachments: GERONIMO-3876-B.patch, GERONIMO-3876.patch Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3864) Security warning about installation a certificate from a CA claiming to represent: Me
[ https://issues.apache.org/jira/browse/GERONIMO-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3864: -- Attachment: GERONIMO-3864-new.patch GERONIMO-3864.patch seems to have some formatting changes too. Please use GERONIMO-3864-new.patch instead. Security warning about installation a certificate from a CA claiming to represent: Me - Key: GERONIMO-3864 URL: https://issues.apache.org/jira/browse/GERONIMO-3864 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Environment: C:\geronimo-tomcat6-javaee5-2.1 Mon 02/18/2008 23:53:25.17 ver Microsoft Windows XP [Version 5.1.2600] C:\geronimo-tomcat6-javaee5-2.1 Mon 02/18/2008 23:53:27.43 java -version java version 1.6.0_03 Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing) C:\geronimo-tomcat6-javaee5-2.1 Mon 02/18/2008 23:53:30.79 echo %JAVA_HOME% c:\apps\java6 Reporter: Jacek Laskowski Assignee: Jarek Gawor Attachments: GERONIMO-3864-new.patch, GERONIMO-3864.patch, screenshot-1.jpg When you start geronimo-tomcat6-javaee5-2.1 on Windows XP with Java SE 6 you'll get a security warning about installation a certificate from a CA claiming to represent: Me. It doesn't show up with geronimo-jetty6-javaee5-2.1. See the attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3984) Keystores portlet - Unlock keystore page shows wrong label on submit button
[ https://issues.apache.org/jira/browse/GERONIMO-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3984. - Resolution: Fixed Fix Version/s: 2.1.2 Fixed. Will leave it up to others who can translate do the translation and fill in consolebase_zh.properties. Keystores portlet - Unlock keystore page shows wrong label on submit button --- Key: GERONIMO-3984 URL: https://issues.apache.org/jira/browse/GERONIMO-3984 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.1.2, 2.1.x, 2.2 Attachments: GERONIMO-3984.patch The submit button has label 'Unlock Private Key' instead of 'Unlock Keystore'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3984) Keystores portlet - Unlock keystore page shows wrong label on submit button
Keystores portlet - Unlock keystore page shows wrong label on submit button --- Key: GERONIMO-3984 URL: https://issues.apache.org/jira/browse/GERONIMO-3984 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.1.x, 2.2 The submit button has label 'Unlock Private Key' instead of 'Unlock Keystore'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3984) Keystores portlet - Unlock keystore page shows wrong label on submit button
[ https://issues.apache.org/jira/browse/GERONIMO-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3984: -- Attachment: GERONIMO-3984.patch GERONIMO-3984.patch: Patches unlockKeystore.jsp and consolebase.properties. Can someone tell me what to do about consolebase_zh.properties? Keystores portlet - Unlock keystore page shows wrong label on submit button --- Key: GERONIMO-3984 URL: https://issues.apache.org/jira/browse/GERONIMO-3984 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.1.x, 2.2 Attachments: GERONIMO-3984.patch The submit button has label 'Unlock Private Key' instead of 'Unlock Keystore'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3984) Keystores portlet - Unlock keystore page shows wrong label on submit button
[ https://issues.apache.org/jira/browse/GERONIMO-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591917#action_12591917 ] Vamsavardhana Reddy commented on GERONIMO-3984: --- Completed: At revision: 651153 in branches\2.1 Completed: At revision: 651154 in trunk (2.2) Should this be considered for 2.1.1 too? Still need to know what to do with consolebase_zh.properties :( Keystores portlet - Unlock keystore page shows wrong label on submit button --- Key: GERONIMO-3984 URL: https://issues.apache.org/jira/browse/GERONIMO-3984 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.1.x, 2.2 Attachments: GERONIMO-3984.patch The submit button has label 'Unlock Private Key' instead of 'Unlock Keystore'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3955) Typo
[ https://issues.apache.org/jira/browse/GERONIMO-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3955: -- Issue Type: Bug (was: Improvement) Typo Key: GERONIMO-3955 URL: https://issues.apache.org/jira/browse/GERONIMO-3955 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.x, 2.2 Reporter: Afranio Moraes Assignee: Joseph Leong Priority: Trivial Fix For: 2.1.x, 2.2 Attachments: GERONIMO-3955.patch Typo in console after editing keystores: Keysore 'keystore.jks' is now edit locked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3955) Typo
[ https://issues.apache.org/jira/browse/GERONIMO-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3955. - Resolution: Fixed Completed: At revision: 648130 in branches\2.1 Completed: At revision: 648129 in trunk Thanks for the patch Joseph Leong. Typo Key: GERONIMO-3955 URL: https://issues.apache.org/jira/browse/GERONIMO-3955 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.x, 2.2 Reporter: Afranio Moraes Assignee: Joseph Leong Priority: Trivial Fix For: 2.1.x, 2.2 Attachments: GERONIMO-3955.patch Typo in console after editing keystores: Keysore 'keystore.jks' is now edit locked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3837) allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3837. - Resolution: Fixed Added doc at http://cwiki.apache.org/confluence/display/GMOxDEV/Configure+allowLinking+for+Tomcat+contexts allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo --- Key: GERONIMO-3837 URL: https://issues.apache.org/jira/browse/GERONIMO-3837 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.x, 2.1, 2.2 Environment: G 2.0.2 Tomcat on Linux Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1, 2.2 Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Configuring this attribute through Geronimo is not possible currently. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3819) Update JMS Resources Portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583013#action_12583013 ] Vamsavardhana Reddy commented on GERONIMO-3819: --- Anish, The patch seems to have some formatting changes (which are not relevant to the issue). Can you submit another one without these formatting changes? Update JMS Resources Portlet Key: GERONIMO-3819 URL: https://issues.apache.org/jira/browse/GERONIMO-3819 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Reporter: Anish Pathadan Assignee: Anish Pathadan Fix For: 2.1.1, 2.2 Attachments: Browse Messages.jpg, JMS Resource Portlet_Main.jpg, JMSResource_portlet_1.0.patch, JMSResource_portlet_1.1.patch, Send Message.jpg Update the JMS Resources portlet to include the following information from the JMS Provider 1.Count of messages send to each queue/topic ,pending messages 2.Option to send messages to messages to particular queues/topics 3.Purge messages from queues/topics 4.Browse and send messages to queues/topics -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
[
https://issues.apache.org/jira/browse/GERONIMO-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582628#action_12582628
]
Vamsavardhana Reddy commented on GERONIMO-3875:
---
At revision: 641794 in branches\2.1
At revision: 641795 in trunk
o Enables using DB portlet for databases with connection pools defined.
Enabling authentication for Derby renders DB Viewer portlet unusable for all
db's except SystemDatabase
---
Key: GERONIMO-3875
URL: https://issues.apache.org/jira/browse/GERONIMO-3875
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1, 2.1.1, 2.2
Environment: Win XP, G 2.1 Tomcat
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3875.patch
After enabling authentication for Derby, I am noticing that DB Viewer
portlet is unable to work with any database other that SystemDatabase.
listTables.jsp has the following code:
{code}
%-- Datasource --%
c:if test=${ds == null}
%-- Create the connection manually --%
sql:setDataSource
var=ds
driver=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:${db};create=true
user=
password=
/
/c:if
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
[
https://issues.apache.org/jira/browse/GERONIMO-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-3875:
--
Assignee: (was: Vamsavardhana Reddy)
I don't think I will get a chance, before branching for 2.1.1, to work on
enabling collection of userid/password from console for creation of new
databases and databases without connection pools defined.
Unassigning so that someone else can pickup where I left off in case it can be
made into 2.1.1.
Enabling authentication for Derby renders DB Viewer portlet unusable for all
db's except SystemDatabase
---
Key: GERONIMO-3875
URL: https://issues.apache.org/jira/browse/GERONIMO-3875
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1, 2.1.1, 2.2
Environment: Win XP, G 2.1 Tomcat
Reporter: Vamsavardhana Reddy
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3875.patch
After enabling authentication for Derby, I am noticing that DB Viewer
portlet is unable to work with any database other that SystemDatabase.
listTables.jsp has the following code:
{code}
%-- Datasource --%
c:if test=${ds == null}
%-- Create the connection manually --%
sql:setDataSource
var=ds
driver=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:${db};create=true
user=
password=
/
/c:if
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3876: -- Fix Version/s: (was: 2.1.1) Removing 2.1.1 from fix versions as this will become a compatibility issue given that it may require introducing a new plugin with JMXConnector!! See http://www.mail-archive.com/dev@geronimo.apache.org/msg58458.html Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: management, security Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.2 Attachments: GERONIMO-3876-B.patch, GERONIMO-3876.patch Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3901) Security Realms portlet - encoding option missing for Properties File Realm
[ https://issues.apache.org/jira/browse/GERONIMO-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned GERONIMO-3901: - Assignee: Vamsavardhana Reddy Security Realms portlet - encoding option missing for Properties File Realm - Key: GERONIMO-3901 URL: https://issues.apache.org/jira/browse/GERONIMO-3901 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 encoding option missing for Properties File Realm. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3901) Security Realms portlet - encoding option missing for Properties File Realm
[ https://issues.apache.org/jira/browse/GERONIMO-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3901. - Resolution: Fixed Completed: At revision: 641804 in branches\2.1 Completed: At revision: 641805 in trunk Security Realms portlet - encoding option missing for Properties File Realm - Key: GERONIMO-3901 URL: https://issues.apache.org/jira/browse/GERONIMO-3901 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 encoding option missing for Properties File Realm. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy resolved GERONIMO-3806.
---
Resolution: Fixed
Fix Version/s: 2.0.x
Assignee: Manu T George (was: Vamsavardhana Reddy)
Applied patches submitted by Manu and Toby.
Completed: At revision: 639953 in trunk
Completed: At revision: 639955 in branches\2.1
Completed: At revision: 639957 in branches\2.0
Please verify and close the JIRA.
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: Manu T George
Priority: Minor
Fix For: 2.0.x, 2.1.1, 2.2
Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806-r639837.patch
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3936) Make changes to openejb gbeans so that they can be modified at runtime
[ https://issues.apache.org/jira/browse/GERONIMO-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581252#action_12581252 ] Vamsavardhana Reddy commented on GERONIMO-3936: --- Can you see if changing infoBuilder.addAttribute(properties, Properties.class, true); to infoBuilder.addAttribute(properties, Properties.class, true, true); in the current EjbContainer class helps to prevent changing it into an interface and introducing EjbContainerGBean. Make changes to openejb gbeans so that they can be modified at runtime -- Key: GERONIMO-3936 URL: https://issues.apache.org/jira/browse/GERONIMO-3936 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.2 Environment: All Reporter: Manu T George Assignee: Manu T George Fix For: 2.2 Attachments: g3936_r639236.patch Extract interfaces from the EjbContainer GBean so that values can be set at runtime. At runtime you need to set attributes on a dynamic proxy for it to get saved. So the EjbContainerGBean has been refactored to implement an EjbContainer interface. Also a properties attribute has been added to the OpenEjbSystemGbean. Initial approach implemented was to add multiple MdbContainerGbeans for each MdbContainer created but it keeps on adding entries to config.xml. Also adding too many gbeans to existing configurations is not a good design as I understand from advice given in the ML -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-106) Problem when Geronimo 2.1 server is started using start-server
Problem when Geronimo 2.1 server is started using start-server Key: GSHELL-106 URL: https://issues.apache.org/jira/browse/GSHELL-106 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.0-alpha-1 Environment: Win XP, G Tomcat 2.1 Reporter: Vamsavardhana Reddy Assignee: Jason Dillon On Windows XP, if I start a Geronimo Tomcat 2.1 server using bin\start-server from a command prompt, I am noticing that the server can not be shutdown using Control+C. So, I am using Admin Console to shutdown the server. But it does not return to command prompt unless I kill the java process from Windows Task Manager. Jarek says, As a workaround, you can start gshell with -T false option and then control-c worked fine while running the server in foreground. See http://www.mail-archive.com/dev@geronimo.apache.org/msg57308.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy reassigned GERONIMO-3806:
-
Assignee: Vamsavardhana Reddy
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2, 2.1, 2.1.1, 2.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: Vamsavardhana Reddy
Priority: Minor
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3806-2.0.2.patch, GERONIMO-3806-r639837.patch
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3876: -- Attachment: GERONIMO-3876-B.patch GERONIMO-3876-B.patch: Start the JMX server asynchronously when SSL is configured. Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: management, security Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 Attachments: GERONIMO-3876-B.patch, GERONIMO-3876.patch Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3392) CA Helper App - Unable to find HTTPS Connector configured for ClientAuth
[ https://issues.apache.org/jira/browse/GERONIMO-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3392: -- Affects Version/s: 2.2 2.0.x Fix Version/s: (was: 2.1.1) 2.2 Assignee: (was: Vamsavardhana Reddy) CA Helper App - Unable to find HTTPS Connector configured for ClientAuth Key: GERONIMO-3392 URL: https://issues.apache.org/jira/browse/GERONIMO-3392 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x, 2.2 Environment: G 2.0 Tomcat Reporter: Vamsavardhana Reddy Fix For: 2.0.x, 2.2 The CA Helper application is unable to find HTTPS Connector configured for ClientAuth. This is because the new Tomcat HTTPS Connector GBeans no longer implement TomcatSecureConnector and so AbstractNameQuery(SecureConnector.class.getName()) will not help fetch Tomcat SSL Connectors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3879) Web Access Log Viewer problems in multiple server instances scenario
[ https://issues.apache.org/jira/browse/GERONIMO-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3879. - Resolution: Fixed Completed: At revision: 638985 in trunk. Completed: At revision: 638994 in branches\2.1 Web Access Log Viewer problems in multiple server instances scenario Key: GERONIMO-3879 URL: https://issues.apache.org/jira/browse/GERONIMO-3879 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.2 Environment: G 2.1 Tomcat Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 I am noticing this with G 2.1 Tomcat. May be applicable to G 2.1 Jetty distribution too. I have created a second server instance with name *i1* by copying the var directory to g_home/*i1*. While tomcat is logging to g_home/*i1*/var/catalina/logs, Web Access Log Viewer for this instance is still displaying log entries from the base server (i.e. from g_home/var/catalina/logs)!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3901) Security Realms portlet - encoding option missing for Properties File Realm
Security Realms portlet - encoding option missing for Properties File Realm - Key: GERONIMO-3901 URL: https://issues.apache.org/jira/browse/GERONIMO-3901 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 encoding option missing for Properties File Realm. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3891) Derby Log Viewer portlet - ignores all search criteria
Derby Log Viewer portlet - ignores all search criteria -- Key: GERONIMO-3891 URL: https://issues.apache.org/jira/browse/GERONIMO-3891 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1, 2.1.1, 2.2 Environment: Win XP, G 2.1 Tomcat Reporter: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 Derby Log Viewer portlet ignores all search criteria. Always displays the last 10 lines from the log. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3819) Update JMS Resources Portlet
[
https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573702#action_12573702
]
Vamsavardhana Reddy commented on GERONIMO-3819:
---
Anish,
A few comments on the patch. Use proper source code formatting (no tabs etc.),
add svn properties for the newly added files. Use resource bundles for all
field names shown in the JSPs.
Also, I am getting an exception when I shutdown the server after sending
messages to a topic. stack trace is given below.
{code}
17:11:06,406 WARN [[/activemq]] Cannot serialize session attribute javax.portle
t.p./activemq.JMSWizard!1082939780|0?messages for session 77583B5E383183289B0443
5198BFD4D2
java.io.NotSerializableException: org.apache.activemq.command.ActiveMQTextMessag
e
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.util.ArrayList.writeObject(ArrayList.java:569)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:91
7)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:13
39)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.jav
a:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at org.apache.catalina.session.StandardSession.writeObject(StandardSessi
on.java:1515)
at org.apache.catalina.session.StandardSession.writeObjectData(StandardS
ession.java:959)
at org.apache.catalina.session.StandardManager.doUnload(StandardManager.
java:517)
at org.apache.catalina.session.StandardManager.unload(StandardManager.ja
va:463)
at org.apache.catalina.session.StandardManager.stop(StandardManager.java
:667)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:45
31)
at org.apache.geronimo.tomcat.GeronimoStandardContext.kill(GeronimoStand
ardContext.java:238)
at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContai
ner.java:370)
at org.apache.geronimo.tomcat.TomcatWebAppContext.doStop(TomcatWebAppCon
text.java:529)
at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean
Instance.java:1161)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(
GBeanInstanceState.java:339)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:188)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown
Hook.run(KernelConfigurationManager.java:316)
at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi
cKernel.java:668)
at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav
a:645)
at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper$1.run(M
ainConfigurationBootstrapper.java:76)
17:11:16,125 WARN [ActiveMQManagedConnection] Connection failed: javax.jms.JMSE
xception: java.io.EOFException
17:11:16,125 WARN [GeronimoConnectionEventListener] connectionErrorOccurred cal
led with null
javax.jms.JMSException: java.io.EOFException
at
[jira] Commented: (GERONIMODEVTOOLS-287) Unable to download a G 2.0 server while creating new Server Runtime using Eclipse Plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573417#action_12573417 ] Vamsavardhana Reddy commented on GERONIMODEVTOOLS-287: -- The same problem is observed with G 2.1 servers too!! Unable to download a G 2.0 server while creating new Server Runtime using Eclipse Plugin Key: GERONIMODEVTOOLS-287 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-287 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.1.0, 2.1.x Environment: Win XP Reporter: Vamsavardhana Reddy Assignee: Tim McConnell Fix For: 2.1.0, 2.1.x While adding a Geronimo 2.0 Runtime, the option to download Geronimo server using *Download and Install* button does not seem to work. It comes back with an error The specified directory does not exist.!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-287) Unable to download a G 2.0 server while creating new Server Runtime using Eclipse Plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573436#action_12573436 ] Vamsavardhana Reddy commented on GERONIMODEVTOOLS-287: -- Incase of G2.1, the urls used in site.xml are wrong (runtimes/geronimo-tomcat6-jee5-2.1.0-bin.zip instead of ../../2.1/geronimo-tomcat6-javaee5-2.1-bin.zip) and after installing G, the plugin is looking for wrong directory (geronimo-tomcat6-jee5-2.1.0 instead of geronimo-tomcat6-javaee5-2.1) Unable to download a G 2.0 server while creating new Server Runtime using Eclipse Plugin Key: GERONIMODEVTOOLS-287 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-287 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.1.0, 2.1.x Environment: Win XP Reporter: Vamsavardhana Reddy Assignee: Tim McConnell Fix For: 2.1.0, 2.1.x While adding a Geronimo 2.0 Runtime, the option to download Geronimo server using *Download and Install* button does not seem to work. It comes back with an error The specified directory does not exist.!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3879) Web Access Log Viewer problems in multiple server instances scenario
Web Access Log Viewer problems in multiple server instances scenario Key: GERONIMO-3879 URL: https://issues.apache.org/jira/browse/GERONIMO-3879 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1, 2.2 Environment: G 2.1 Tomcat Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.1, 2.2 I am noticing this with G 2.1 Tomcat. May be applicable to G 2.1 Jetty distribution too. I have created a second server instance with name *i1* by copying the var directory to g_home/*i1*. While tomcat is logging to g_home/*i1*/var/catalina/logs, Web Access Log Viewer for this instance is still displaying log entries from the base server (i.e. from g_home/var/catalina/logs)!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3876) Allow configuring JMX over SSL
Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: management, security Affects Versions: 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.2 Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3876: -- Attachment: GERONIMO-3876.patch GERONIMO-3876.patch: Patch created against tags\2.1.0, but applies fine to trunk (2.2) Allow configuring JMX over SSL -- Key: GERONIMO-3876 URL: https://issues.apache.org/jira/browse/GERONIMO-3876 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: management, security Affects Versions: 2.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.2 Attachments: GERONIMO-3876.patch Currently JMX connections to Geronimo or non-SSL and Geronimo does not provide configuring SSL for JMX connections. It may be useful to provide configuration for JMX connections over SSL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3876) Allow configuring JMX over SSL
[
https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572675#action_12572675
]
Vamsavardhana Reddy commented on GERONIMO-3876:
---
To test, start jconsole using the following command:
{code}
jconsole
-J-Djavax.net.ssl.keyStore=\ac\geronimo-tomcat6-javaee5-2.1\var\security\keystores\geronimo-default
-J-Djavax.net.ssl.keyStorePassword=secret
-J-Djavax.net.ssl.trustStore=\ac\geronimo-tomcat6-javaee5-2.1\var\security\keystores\geronimo-default
-J-Djavax.net.ssl.trustStorePassword=secret
{code}
Use the JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector
You will still have to supply username and password: system/manager
Allow configuring JMX over SSL
--
Key: GERONIMO-3876
URL: https://issues.apache.org/jira/browse/GERONIMO-3876
Project: Geronimo
Issue Type: New Feature
Security Level: public(Regular issues)
Components: management, security
Affects Versions: 2.2
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: 2.2
Attachments: GERONIMO-3876.patch
Currently JMX connections to Geronimo or non-SSL and Geronimo does not
provide configuring SSL for JMX connections. It may be useful to provide
configuration for JMX connections over SSL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
Enabling authentication for Derby renders DB Viewer portlet unusable for all
db's except SystemDatabase
---
Key: GERONIMO-3875
URL: https://issues.apache.org/jira/browse/GERONIMO-3875
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: console
Affects Versions: 2.1, 2.1.1, 2.2
Environment: Win XP, G 2.1 Tomcat
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: 2.1.1, 2.2
After enabling authentication for Derby, I am noticing that DB Viewer portlet
is unable to work with any database other that SystemDatabase.
listTables.jsp has the following code:
{code}
%-- Datasource --%
c:if test=${ds == null}
%-- Create the connection manually --%
sql:setDataSource
var=ds
driver=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:${db};create=true
user=
password=
/
/c:if
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
[
https://issues.apache.org/jira/browse/GERONIMO-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12571930#action_12571930
]
Vamsavardhana Reddy commented on GERONIMO-3875:
---
Option 1: We can search in the connection pools to see if we can obtain a data
source matching the database name. Will not work for creating new databases
from console. Will not work for databases with no associated DatabasePools.
May not work properly if there is more than one Database Pool with same
database name.
Option 2: Require the user to enter credentials for db authentication, say once
per session.
Enabling authentication for Derby renders DB Viewer portlet unusable for all
db's except SystemDatabase
---
Key: GERONIMO-3875
URL: https://issues.apache.org/jira/browse/GERONIMO-3875
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1, 2.1.1, 2.2
Environment: Win XP, G 2.1 Tomcat
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: 2.1.1, 2.2
After enabling authentication for Derby, I am noticing that DB Viewer
portlet is unable to work with any database other that SystemDatabase.
listTables.jsp has the following code:
{code}
%-- Datasource --%
c:if test=${ds == null}
%-- Create the connection manually --%
sql:setDataSource
var=ds
driver=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:${db};create=true
user=
password=
/
/c:if
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3875) Enabling authentication for Derby renders DB Viewer portlet unusable for all db's except SystemDatabase
[
https://issues.apache.org/jira/browse/GERONIMO-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-3875:
--
Attachment: GERONIMO-3875.patch
GERONIMO-3875.patch: Crude implementation of Option1 from above. Patch created
against branches\2.1.
Comments? Suggestions??
Enabling authentication for Derby renders DB Viewer portlet unusable for all
db's except SystemDatabase
---
Key: GERONIMO-3875
URL: https://issues.apache.org/jira/browse/GERONIMO-3875
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1, 2.1.1, 2.2
Environment: Win XP, G 2.1 Tomcat
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: 2.1.1, 2.2
Attachments: GERONIMO-3875.patch
After enabling authentication for Derby, I am noticing that DB Viewer
portlet is unable to work with any database other that SystemDatabase.
listTables.jsp has the following code:
{code}
%-- Datasource --%
c:if test=${ds == null}
%-- Create the connection manually --%
sql:setDataSource
var=ds
driver=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:${db};create=true
user=
password=
/
/c:if
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3806) CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar
[
https://issues.apache.org/jira/browse/GERONIMO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy reassigned GERONIMO-3806:
-
Assignee: Manu T George (was: Vamsavardhana Reddy)
CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB
jar
-
Key: GERONIMO-3806
URL: https://issues.apache.org/jira/browse/GERONIMO-3806
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0.2
Environment: Windows XP SP2
Reporter: toby cabot
Assignee: Manu T George
Priority: Minor
Attachments: bug3806-patch.txt
During deployment of one of my EJB jar files in my EAR, I get the following
WARN messages:
{code}
14:29:37,425 WARN [AdminObjectRefBuilder] Failed to build reference to Admin
object reference [jms/UnsequencedDestination, jms/MailQueue,
jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue,
jms/SequencedDestination, jms/InboundIntegrationQueue,
jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in
deployment descriptor missing.
14:29:37,440 WARN [ResourceRefBuilder] Failed to build reference to resource
reference [jms/ConnectionFactory, jms/QueueConnectionFactory,
mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason -
corresponding entry in deployment descriptor missing.
{code}
This occurs at the point in the following point in the stack:
{code}
AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
{code}
The specDD that is passed in is a XML fragment for a specific session bean.
However, the plan that is passed in contains all the resource-ref and
resource-env-ref elements in the openejb-jar.xml plan. Therefore, the
refMap variable does not get completely emptied out, since the specific
session bean will only contain a subset of the resource-env-refs that are
defined in the plan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-286) Project deleted from workspace is not removed from the Server
Project deleted from workspace is not removed from the Server - Key: GERONIMODEVTOOLS-286 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-286 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0, 2.1.x Environment: Win XP, G 2.1-SNAPSHOT Reporter: Vamsavardhana Reddy Assignee: Tim McConnell Fix For: 2.1.0, 2.1.x I have created a new dynamic web project and used Run on Server to run it on a G 2.1 server defined using Eclipse Plugin. Upon deleting the project the from workspace, the application deployed on the server is not undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-287) Unable to download a G 2.0 server while creating new Server Runtime using Eclipse Plugin
Unable to download a G 2.0 server while creating new Server Runtime using Eclipse Plugin Key: GERONIMODEVTOOLS-287 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-287 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.1.0, 2.1.x Environment: Win XP Reporter: Vamsavardhana Reddy Assignee: Tim McConnell Fix For: 2.1.0, 2.1.x While adding a Geronimo 2.0 Runtime, the option to download Geronimo server using *Download and Install* button does not seem to work. It comes back with an error The specified directory does not exist.!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException
[ https://issues.apache.org/jira/browse/GERONIMO-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569070#action_12569070 ] Vamsavardhana Reddy commented on GERONIMO-3815: --- GERONIMO-3815-3.debug.patch seems to result in compilation errors. Should it be callerSubject instead of currentSubject in getCurrentPrincpal()? ContextManager.getCurrentContext() throws NullPointerException -- Key: GERONIMO-3815 URL: https://issues.apache.org/jira/browse/GERONIMO-3815 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1 Attachments: GERONIMO-3815-2.debug.patch, GERONIMO-3815-3.debug.patch, GERONIMO-3815.debug.patch ContextManager.getCurrentContext() is throwing a NullPointerException. This is observed only when there is heavy load on the application. Most likely it is a threading issue where one thread is unregistering the subject while another is executing getCurrentContext(). Excerpt from stacktrace given below. Caused by: java.lang.NullPointerException at org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:197) at org.apache.geronimo.openejb.GeronimoSecurityService.isCallerAuthorized(GeronimoSecurityService.java:101) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:142) at org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267) at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy16.create(Unknown Source) ... 53 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3837) allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567835#action_12567835 ] Vamsavardhana Reddy commented on GERONIMO-3837: --- Completed: At revision: 620623 in trunk (2.2) Completed: At revision: 620626 in branches\2.1 Completed: At revision: 620627 in branches\2.0 o Enabling this attribute per server instance using a system property org.apache.geronimo.tomcat.GeronimoStandardContext.allowLinking allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo --- Key: GERONIMO-3837 URL: https://issues.apache.org/jira/browse/GERONIMO-3837 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.x, 2.1, 2.2 Environment: G 2.0.2 Tomcat on Linux Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1, 2.2 Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Configuring this attribute through Geronimo is not possible currently. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3837) allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3837: -- Description: Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Configuring this attribute through Geronimo is not possible currently. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html was: Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html Summary: allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo (was: allowLinking) allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo --- Key: GERONIMO-3837 URL: https://issues.apache.org/jira/browse/GERONIMO-3837 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.x, 2.1, 2.2 Environment: G 2.0.2 Tomcat on Linux Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1, 2.2 Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Configuring this attribute through Geronimo is not possible currently. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3837) allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567826#action_12567826 ] Vamsavardhana Reddy commented on GERONIMO-3837: --- http://tomcat.apache.org/tomcat-6.0-doc/config/context.html If the value of this flag is true, symlinks will be allowed inside the web application, pointing to resources outside the web application base path. If not specified, the default value of the flag is false. NOTE: This flag MUST NOT be set to true on the Windows platform (or any other OS which does not have a case sensitive filesystem), as it will disable case sensitivity checks, allowing JSP source code disclosure, among other security problems. allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo --- Key: GERONIMO-3837 URL: https://issues.apache.org/jira/browse/GERONIMO-3837 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.x, 2.1, 2.2 Environment: G 2.0.2 Tomcat on Linux Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1, 2.2 Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Configuring this attribute through Geronimo is not possible currently. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3837) allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567774#action_12567774 ] Vamsavardhana Reddy commented on GERONIMO-3837: --- This allowLinking attribute can be enabled on a per application basis. However it would require a tomcat specific element in geronimo-web.xml. This would mean a schema change (argh... that hurts) and requires modifications to deployment code. We can provide enabling this attribute per server instance for G 2.0.x and G 2.1.x Tomcat servers using a system property org.apache.geronimo.tomcat.GeronimoStandardContext.allowLinking as it would require minimal changes to code and won't come in the way of compatibility. If there is a necessity to enable this attribute on a per application basis, then we can introduce an allow-linking element in geronimo-web.xml from G 2.2 which will override any default value set using the system property above. Any comments? Suggestions? Any pit falls that I am not seeing? allowLinking Tomcat atttibute in StandardContext not configurable through Geronimo --- Key: GERONIMO-3837 URL: https://issues.apache.org/jira/browse/GERONIMO-3837 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.x, 2.1, 2.2 Environment: G 2.0.2 Tomcat on Linux Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1, 2.2 Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Configuring this attribute through Geronimo is not possible currently. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3837) allowLinking
allowLinking Key: GERONIMO-3837 URL: https://issues.apache.org/jira/browse/GERONIMO-3837 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.x, 2.1, 2.2 Environment: G 2.0.2 Tomcat on Linux Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1, 2.2 Tomcat provides an allowLinking attribute in the StandardContext which when set to true will enable tomcat running on Linux platform to serve paths associated with the symbolic links. Link to a query posted on user-list is given below. http://www.mail-archive.com/[EMAIL PROTECTED]/msg08509.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2682) Sending a message throws a SendFailedException
[
https://issues.apache.org/jira/browse/GERONIMO-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567414#action_12567414
]
Vamsavardhana Reddy commented on GERONIMO-2682:
---
Looks like the connection to smtp server could not be established. Are you
able to use the same smtp server to send mail from any other mail software?
Sending a message throws a SendFailedException
--
Key: GERONIMO-2682
URL: https://issues.apache.org/jira/browse/GERONIMO-2682
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: mail
Affects Versions: 2.0.x
Reporter: Geist Alexander
Fix For: 2.0.x
// Get system properties
Properties props = System.getProperties();
// Setup mail server
props.put(mail.smtp.host, Settings.smtpServer);
props.put(mail.imap.partialfetch, false);
props.put(mail.smtp.auth, true);
Authenticator auth = new Authenticator()
{
protected PasswordAuthentication getPasswordAuthentication()
{
return new PasswordAuthentication(Settings.user, Settings.key);
}
};
return Session.getDefaultInstance(props, auth);
The method was used to get the session. It works.
Next step is to build and to send the message.
// Define message
MimeMessage message = new MimeMessage(mailParam.getSession());
// Set the from address
message.setFrom(new InternetAddress(Settings.from));
// Empfänger
message.addRecipient(Message.RecipientType.TO, new
InternetAddress(mailParam.getMailAddress()));
// Set the subject
message.setSubject(Subject);
BodyPart messageBodyPart = new MimeBodyPart();
String text =
getEmailText(mailParam.getXmgKey(),mailParam.getXlgKey(),
mailParam.getDate());
messageBodyPart.setContent(text, text/html);
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(messageBodyPart);
// Put parts in message
message.setContent(multipart);
// Send message
Transport.send(message);
Transport.send(message) is throwing this Exception
javax.mail.SendFailedException: Send failure (javax.mail.MessagingException:
Connection error (java.net.ConnectException: Connection refused: connect))
at javax.mail.Transport.send(Transport.java:163)
at javax.mail.Transport.send(Transport.java:48)
at keygen.main.MailSender.sendMail(MailSender.java:44)
at keygen.main.MailSender.main(MailSender.java:112)
Caused by: javax.mail.MessagingException: Connection error
(java.net.ConnectException: Connection refused: connect)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:403)
at javax.mail.Service.connect(Service.java:254)
at javax.mail.Service.connect(Service.java:85)
at javax.mail.Service.connect(Service.java:70)
at javax.mail.Transport.send(Transport.java:94)
... 3 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.init(Socket.java:366)
at java.net.Socket.init(Socket.java:239)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.getConnectedSocket(SMTPTransport.java:1091)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.getConnection(SMTPTransport.java:851)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:380)
... 7 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException
ContextManager.getCurrentContext() throws NullPointerException -- Key: GERONIMO-3815 URL: https://issues.apache.org/jira/browse/GERONIMO-3815 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1 ContextManager.getCurrentContext() is throwing a NullPointerException. This is observed only when there is heavy load on the application. Most likely it is a threading issue where one thread is unregistering the subject while another is executing getCurrentContext(). Excerpt from stacktrace given below. Caused by: java.lang.NullPointerException at org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:197) at org.apache.geronimo.openejb.GeronimoSecurityService.isCallerAuthorized(GeronimoSecurityService.java:101) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:142) at org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267) at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy16.create(Unknown Source) ... 53 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3392) CA Helper App - Unable to find HTTPS Connector configured for ClientAuth
[ https://issues.apache.org/jira/browse/GERONIMO-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3392: -- Fix Version/s: (was: 2.1) 2.1.1 CA Helper App - Unable to find HTTPS Connector configured for ClientAuth Key: GERONIMO-3392 URL: https://issues.apache.org/jira/browse/GERONIMO-3392 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0 Environment: G 2.0 Tomcat Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1.1 The CA Helper application is unable to find HTTPS Connector configured for ClientAuth. This is because the new Tomcat HTTPS Connector GBeans no longer implement TomcatSecureConnector and so AbstractNameQuery(SecureConnector.class.getName()) will not help fetch Tomcat SSL Connectors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
