[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-tabpanel&focusedCommentId=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: 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 JI
[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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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] [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] [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] 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-tabpanel&focusedCommentId=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] 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-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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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] 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-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.(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"); > Hashtable env = new Hashtable(); > 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) { > Set mbeanNames = mbServerConn.queryNames(new > ObjectName("*:name=MasterRemoteControlJMX,*"), null); > for(Iterator 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-tabpanel&focusedCommentId=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-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-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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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.(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"); > Hashtable env = new Hashtable(); > 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) { > Set mbeanNames = mbServerConn.queryNames(new > ObjectName("*:name=MasterRemoteControlJMX,*"), null); > for(Iterator 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] 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.(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"); > Hashtable env = new Hashtable(); > 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) { > Set mbeanNames = mbServerConn.queryNames(new > ObjectName("*:name=MasterRemoteControlJMX,*"), null); > for(Iterator 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-tabpanel&focusedCommentId=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.(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"); > Hashtable env = new Hashtable(); > 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) { > Set mbeanNames = mbServerConn.queryNames(new > ObjectName("*:name=MasterRemoteControlJMX,*"), null); > for(Iterator 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-tabpanel&focusedCommentId=12922519#action_12922519 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 1024200 o When the modules are packaged in an EAR, additional processing is required to obtain the validation descriptors o Each module has its own ValidatorFactory. So, we need to keep track of the module names too in case of EARs. > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-5221) Add naming support for Validator and ValidatorFactory.
[ https://issues.apache.org/jira/browse/GERONIMO-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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] 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] 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] 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] 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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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] 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] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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] 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] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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-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] 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] 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] 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-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-tabpanel&focusedCommentId=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] 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] 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] 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] 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 --%> > > <%-- Create the connection manually --%> >var="ds" > driver="org.apache.derby.jdbc.EmbeddedDriver" > url="jdbc:derby:${db};create=true" > user="" > password="" > /> > > {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-tabpanel&focusedCommentId=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 --%> > > <%-- Create the connection manually --%> >var="ds" > driver="org.apache.derby.jdbc.EmbeddedDriver" > url="jdbc:derby:${db};create=true" > user="" > password="" > /> > > {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-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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] 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 /*i1*. While tomcat is logging to > /*i1*/var/catalina/logs, Web Access Log Viewer for this instance is > still displaying log entries from the base server (i.e. from > /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] 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] 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] 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-tabpanel&focusedCommentId=12576383#action_12576383 ] Vamsavardhana Reddy commented on GERONIMO-3837: --- Is it desirable to make this configurable on a per application basis? If not, we are done and the JIRA can be closed. > 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-3811) EjbServer portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576071#action_12576071 ] Vamsavardhana Reddy commented on GERONIMO-3811: --- The patch seems to be adding a SystemProperties GBean to j2ee-server config. Can this GBean be added to openejb config instead? > EjbServer portlet > - > > Key: GERONIMO-3811 > URL: https://issues.apache.org/jira/browse/GERONIMO-3811 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: OpenEJB > Environment: All >Reporter: Manu T George > Attachments: g3811_r632068.patch, g3811_r634213.patch, openejb.zip, > screenshot-1.jpg, screenshot-2.jpg > > > A portlet to show information about the OpenEJB container integrated in > Geronimo. It should also allow configuration of some parameters like pool > size etc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3882) Mdb container ids not set during creation.
[ https://issues.apache.org/jira/browse/GERONIMO-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy resolved GERONIMO-3882. --- Resolution: Fixed Assignee: Manu T George (was: Vamsavardhana Reddy) Completed: At revision: 634220 in trunk. Completed: At revision: 634222 in branches\2.1 Thanks Manu for providing the patch. > Mdb container ids not set during creation. > -- > > Key: GERONIMO-3882 > URL: https://issues.apache.org/jira/browse/GERONIMO-3882 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.1, 2.1.1, 2.2 > Environment: All >Reporter: Manu T George >Assignee: Manu T George > Fix For: 2.1.1, 2.2 > > Attachments: g3882_r631981.patch > > > In the OpenEJBSystemGBean we do > ContainerInfo containerInfo = > configurationFactory.configureService(MdbContainerInfo.class) > This uses the default name of the service and so system properties are not > picked up. Change to > ContainerInfo containerInfo = > configurationFactory.configureService(MdbContainerInfo.class, containerName, > null, null, "Container"); > where containerName is the name we create from the RA name -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3882) Mdb container ids not set during creation.
[ https://issues.apache.org/jira/browse/GERONIMO-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned GERONIMO-3882: - Assignee: Vamsavardhana Reddy > Mdb container ids not set during creation. > -- > > Key: GERONIMO-3882 > URL: https://issues.apache.org/jira/browse/GERONIMO-3882 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.1, 2.1.1, 2.2 > Environment: All >Reporter: Manu T George >Assignee: Vamsavardhana Reddy > Fix For: 2.1.1, 2.2 > > Attachments: g3882_r631981.patch > > > In the OpenEJBSystemGBean we do > ContainerInfo containerInfo = > configurationFactory.configureService(MdbContainerInfo.class) > This uses the default name of the service and so system properties are not > picked up. Change to > ContainerInfo containerInfo = > configurationFactory.configureService(MdbContainerInfo.class, containerName, > null, null, "Container"); > where containerName is the name we create from the RA name -- 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-tabpanel&focusedCommentId=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 org.apache.activemq.util.JMSExceptionSupport.cr
[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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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 /*i1*. While tomcat is logging to /*i1*/var/catalina/logs, Web Access Log Viewer for this instance is still displaying log entries from the base server (i.e. from /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] Commented: (GERONIMO-3876) Allow configuring JMX over SSL
[ https://issues.apache.org/jira/browse/GERONIMO-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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] 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-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 --%> > > <%-- Create the connection manually --%> >var="ds" > driver="org.apache.derby.jdbc.EmbeddedDriver" > url="jdbc:derby:${db};create=true" > user="" > password="" > /> > > {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-tabpanel&focusedCommentId=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 --%> > > <%-- Create the connection manually --%> >var="ds" > driver="org.apache.derby.jdbc.EmbeddedDriver" > url="jdbc:derby:${db};create=true" > user="" > password="" > /> > > {code} -- 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 --%> <%-- Create the connection manually --%> {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-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] 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] Commented: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException
[ https://issues.apache.org/jira/browse/GERONIMO-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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.