Re: Welcome Shenghao Fang as a new Geronimo committer
Congratulations Shenghao Fang!! On Thu, Aug 18, 2011 at 7:48 PM, Shawn Jiang genspr...@gmail.com wrote: I'd like to welcome Shenghao Fang on aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account was just created , so you should start seeing some commits from him soon. -- Shawn -- Vamsi
[jira] [Created] (GERONIMO-6073) Rotation and appending of console output when Geronimo is run a windows service
Rotation and appending of console output when Geronimo is run a windows service --- Key: GERONIMO-6073 URL: https://issues.apache.org/jira/browse/GERONIMO-6073 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: commands Affects Versions: 2.2.1, 2.1.7 Environment: Windows Reporter: Vamsavardhana Reddy GERONIMO-4394 provided for running Geronimo as windows service. The console output STDOUT is directed to geronimosrv.out and STDERR is directed to geronimosrv.err. If the server is running for long, these files can grow big requiring the server to be stopped. Also, each time the server is started as service, the files from the previous run are overwritten since the output does not get appended to existing file. So, if a user is interested in the console output from the previous runs, it is lost. So, console output rotation and appending to already existing files should be a good improvement for the Run Geronimo as a Windows service feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032289#comment-13032289 ] Vamsavardhana Reddy commented on GERONIMO-4576: --- I see that 2.2 revs 1097555 and 1097965 are also related to this JIRA. Make persistence exceptions more visible to client -- Key: GERONIMO-4576 URL: https://issues.apache.org/jira/browse/GERONIMO-4576 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.2 Environment: Linux, Windows Reporter: Joe Bohn Priority: Minor Fix For: Wish List See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the original problem. That core problem was resolved. However, upon resolution it was mentioned that it would be beneficial to report more specific failure information back to the client. From GERONIMO-3907: Ralf Baumhof - 06/May/08 06:17 AM Today if have tested the new Geronimo release 2.1.1 (published on 28.04.2008). The problem is now fixed. If the server gets an error on trying a commit, this error is now thrown to the web bean. Exception text: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Root Cause: javax.transaction.TransactionRolledbackException : Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Unfortunately there is no proper root cause attached to the exception. So the cause can only be seen in the server console, but can not be reported to the user. It would be very nice if you could change this in a later release. Thanks for your help. Vincent MATHON - 06/Nov/08 02:03 AM I agree that exceptions on the server side should not be thrown to the client side since such exceptions types might not be known by the client. However, for unit testing purpose, it is useful to attach the root cause to the RollBackException. I have modified a few lines in org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the root cause in case of RollBackException and it works for my unit testing purpose (I have not enough background on the java transaction architecture topic to submit a patch for production). It would be great to define a configuration parameter that permits to provide the root cause to the client and keep the current behaviour that does not by default. Geoff Callender - 22/Dec/08 03:36 AM It's useful for more than unit testing - it's essential to be able to inform the client what's wrong with the request. I've added some examples of this to https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032411#comment-13032411 ] Vamsavardhana Reddy commented on GERONIMO-4576: --- I notice that revs 1097555 and 1097965 are once again masking the original persistence exception and putting a SetRollbackOnlyException() as the cause. To give an example, with rev 1076770 applied in my code, I am getting the following exception report: REPORT-1: org.apache.jasper.JasperException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.transaction.RollbackException: Unable to commit: transaction marked for rollback root cause: openjpa-1.2.2-r422266:898935 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. ... -- With revs 1076770, 1097555 and 1097965 applied in my code, I am getting the following exception report in the same case (notice that the persistence exception is lost): REPORT-2: org.apache.jasper.JasperException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback root cause: javax.transaction.RollbackException: Unable to commit: transaction marked for rollback root cause: org.apache.geronimo.transaction.manager.SetRollbackOnlyException: setRollbackOnly() called. See stacktrace for origin Make persistence exceptions more visible to client -- Key: GERONIMO-4576 URL: https://issues.apache.org/jira/browse/GERONIMO-4576 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Affects Versions: 2.2 Environment: Linux, Windows Reporter: Joe Bohn Priority: Minor Fix For: Wish List See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the original problem. That core problem was resolved. However, upon resolution it was mentioned that it would be beneficial to report more specific failure information back to the client. From GERONIMO-3907: Ralf Baumhof - 06/May/08 06:17 AM Today if have tested the new Geronimo release 2.1.1 (published on 28.04.2008). The problem is now fixed. If the server gets an error on trying a commit, this error is now thrown to the web bean. Exception text: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Root Cause: javax.transaction.TransactionRolledbackException : Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Unfortunately there is no proper root cause attached to the exception. So the cause can only be seen in the server console, but can not be reported to the user. It would be very nice if you could change this in a later release. Thanks for your help. Vincent MATHON - 06/Nov/08 02:03 AM I agree that exceptions on the server side should not be thrown to the client side since such exceptions types might not be known by the client. However, for unit testing purpose, it is useful to attach the root cause to the RollBackException. I have modified a few lines in org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the root cause in case of RollBackException and it works for my unit testing purpose (I have not enough background on the java transaction architecture topic to submit a patch for production). It would be great to define a configuration parameter that permits to provide the root cause to the client and keep the current behaviour that does not by default. Geoff Callender - 22/Dec/08 03:36 AM It's useful for more than unit testing - it's essential to be able to inform the client what's wrong with the request. I've added some examples of this to https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message is automatically generated by JIRA
[jira] [Created] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory --- Key: GERONIMO-5950 URL: https://issues.apache.org/jira/browse/GERONIMO-5950 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
[ https://issues.apache.org/jira/browse/GERONIMO-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5950: -- Description: AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch (https://issues.apache.org/jira/secure/attachment/12478376/AMQ-3121-v412.patch) has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. was: AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805
[jira] [Commented] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
[ https://issues.apache.org/jira/browse/GERONIMO-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029895#comment-13029895 ] Vamsavardhana Reddy commented on GERONIMO-5950: --- Completed: At revision: 1100170 in server/branches/2.1 GERONIMO-5950 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory o Create a customized ActiveMQ 4.1.2 build for Geronimo 2.1.8. Jars changed are activemq-core and activemq-ra. o Update server poms to use this build 4.1.2-G20110506. AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory --- Key: GERONIMO-5950 URL: https://issues.apache.org/jira/browse/GERONIMO-5950 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch (https://issues.apache.org/jira/secure/attachment/12478376/AMQ-3121-v412.patch) has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5950) AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory
[ https://issues.apache.org/jira/browse/GERONIMO-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029901#comment-13029901 ] Vamsavardhana Reddy commented on GERONIMO-5950: --- Completed: At revision: 1100181 in server/branches/2.1 GERONIMO-5950 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory o Update repository pom so that custom activemq-ra jar gets copied over to local maven repo during build AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory --- Key: GERONIMO-5950 URL: https://issues.apache.org/jira/browse/GERONIMO-5950 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 AMQ-3121: Avoid connection creation while creating XAResource if the connection factory is not an xa connection factory Avoid connection creation while creating XAResource if the connection factory is not xa connection factory, also, if it is xa connection, I think that the connection should not be closed as the new created xa resource holds reference to connection. --- When an MDB EJB is deployed in Geronimo 2.1.7, some IOExceptions similar to the following are noticed: 2011-03-17 10:25:05,035 ERROR [TransportConnector] Could not accept connection from /127.0.0.1:48012: java.io.IOException: The transport is not running. java.io.IOException: The transport is not running. at org.apache.activemq.transport.TransportSupport.checkStarted (TransportSupport.java:103) at org.apache.activemq.transport.tcp.TcpTransport.oneway (TcpTransport.java:117) at org.apache.activemq.transport.InactivityMonitor.oneway (InactivityMonitor.java:145) at org.apache.activemq.transport.TransportFilter.oneway (TransportFilter.java:80) at org.apache.activemq.transport.WireFormatNegotiator.oneway (WireFormatNegotiator.java:93) at org.apache.activemq.transport.MutexTransport.oneway (MutexTransport.java:47) at org.apache.activemq.broker.TransportConnection.dispatch (TransportConnection.java:1138) at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:805) at org.apache.activemq.broker.TransportConnection.start (TransportConnection.java:885) at org.apache.activemq.broker.TransportConnector$1.onAccept (TransportConnector.java:148) at org.apache.activemq.transport.tcp.TcpTransportServer.run (TcpTransportServer.java:162) at java.lang.Thread.run(Thread.java:736) This is because the connection used to create xa resources is closed immediately. A fix AMQ-3121-v412.patch (https://issues.apache.org/jira/secure/attachment/12478376/AMQ-3121-v412.patch) has been posted to AMQ JIRA. The issue is resolved by (1) creating the connection only when the factory is XA and (2) caching the connection used to create xa resources and closing it when the resource adapter is stopped. This Geronimo JIRA is created to merge AMQ-3121 into our private build of AMQ and track the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007817#comment-13007817 ] Vamsavardhana Reddy commented on GERONIMO-4184: --- Thanks David. The one doubt I had is if introducing two random bytes along with tmId would break anything. Your comment has clarified that. Essentially the random bytes introduced by fix for GERONIMO-4393 will result in a different tmId each time the server is started and break transaction recovery. (Geronimo server may be immune to this as we use the XidFactoryImpl constructor with tmId as parameter.) How can we make sure that even the generated tmId would be the same for a server instance with subsequent restarts? In-doubt transaction Id's could be reused during server startup --- Key: GERONIMO-4184 URL: https://issues.apache.org/jira/browse/GERONIMO-4184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 Reporter: Kevan Miller Fix For: Wish List Attachments: GERONIM-4184.patch During server restart, we may reuse an Xid for a transaction which is in-doubt. Potentially confusing a resource manager. We need to insure this does not occur. Simple way is to remember the largest Xid in tran log and start with a larger number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006815#comment-13006815 ] Vamsavardhana Reddy commented on GERONIMO-4184: --- GERONIMO-4393 has introduced two random bytes into the baseId to avoid duplication of baseId across multiple JVMs on the same machine. That fix would still not suffice completely as the two random bytes are added to baseId only if the no-argument constructor of XidFactoryImpl is used and Geronimo uses the other constructor that takes byte[] tmId as argument. If we add two random bytes to baseId even in the case of the constructor with tmId, we can minimize the chance of reuse of In-doubt transaction Id's as the baseId would be different on each run of the server. We can even increase the length of random bytes (to say 4 instead of 2) to further reduce the chance of reuse of In-doubt transaction Id's. Any suggestions or comments to this approach? In-doubt transaction Id's could be reused during server startup --- Key: GERONIMO-4184 URL: https://issues.apache.org/jira/browse/GERONIMO-4184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 Reporter: Kevan Miller Fix For: Wish List During server restart, we may reuse an Xid for a transaction which is in-doubt. Potentially confusing a resource manager. We need to insure this does not occur. Simple way is to remember the largest Xid in tran log and start with a larger number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup
[ https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-4184: -- Attachment: GERONIM-4184.patch GERONIM-4184.patch: Add two random bytes entropy even when XidFactoryImpl(byte[]) constructor is used. Patch created against branches\geronimo-txmanager-parent-2.2. In-doubt transaction Id's could be reused during server startup --- Key: GERONIMO-4184 URL: https://issues.apache.org/jira/browse/GERONIMO-4184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4 Reporter: Kevan Miller Fix For: Wish List Attachments: GERONIM-4184.patch During server restart, we may reuse an Xid for a transaction which is in-doubt. Potentially confusing a resource manager. We need to insure this does not occur. Simple way is to remember the largest Xid in tran log and start with a larger number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-5806) SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER
[ https://issues.apache.org/jira/browse/GERONIMO-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992920#comment-12992920 ] Vamsavardhana Reddy commented on GERONIMO-5806: --- Completed: At revision: 1069260 in branches\2.1 Completed: At revision: 1069261 in branches\2.2 SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER Key: GERONIMO-5806 URL: https://issues.apache.org/jira/browse/GERONIMO-5806 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.7, 2.2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8, 2.2.2 Attachments: GERONIMO-5806.patch When a SharedLib GBean is added to a configuration by updating config.xml, the new classes and jars from the shared lib do not get into the configuration's class loader until that GBean instance is created. This results in ClassNotFoundExceptions if another GBean that uses these new classes is loaded ahead of the SharedLib GBean. This can be avoided by setting the priority of SharedLib GBean to GBeanInfo.PRIORITY_CLASSLOADER so that the new classes and jars get added to the classloader and are available immediately for all other GBeans in the configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-5806) SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER
SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER Key: GERONIMO-5806 URL: https://issues.apache.org/jira/browse/GERONIMO-5806 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 2.2.1, 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8, 2.2.2 When a SharedLib GBean is added to a configuration by updating config.xml, the new classes and jars from the shared lib do not get into the configuration's class loader until that GBean instance is created. This results in ClassNotFoundExceptions if another GBean that uses these new classes is loaded ahead of the SharedLib GBean. This can be avoided by setting the priority of SharedLib GBean to GBeanInfo.PRIORITY_CLASSLOADER so that the new classes and jars get added to the classloader and are available immediately for all other GBeans in the configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-5806) SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER
[ https://issues.apache.org/jira/browse/GERONIMO-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5806: -- Attachment: GERONIMO-5806.patch SharedLIb GBean should have priority set to PRIORITY_CLASSLOADER Key: GERONIMO-5806 URL: https://issues.apache.org/jira/browse/GERONIMO-5806 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.7, 2.2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8, 2.2.2 Attachments: GERONIMO-5806.patch When a SharedLib GBean is added to a configuration by updating config.xml, the new classes and jars from the shared lib do not get into the configuration's class loader until that GBean instance is created. This results in ClassNotFoundExceptions if another GBean that uses these new classes is loaded ahead of the SharedLib GBean. This can be avoided by setting the priority of SharedLib GBean to GBeanInfo.PRIORITY_CLASSLOADER so that the new classes and jars get added to the classloader and are available immediately for all other GBeans in the configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980017#action_12980017 ] Vamsavardhana Reddy commented on GERONIMO-5749: --- At revision: 1057539 on branches\2.1 (i.e. 2.1.8-SNAPSHOT). o Added SQL scripts to enable/disable monitoring on Default Server o Added Windows and Unix batch files to execute SQL using ij from Derby o Files will be copied to server's bin directory when the plugin is installed. o Eg. script to enable monitoring: runsql localhost 1527 dbadmin manager enable-monitoring Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat, runsql.sh Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-5355:
--
Affects Version/s: 2.2.1
Fix Version/s: 2.2.2
Completed: At revision: 1058001 in branches\2.2 (i.e. 2.2.2-SNAPSHOT)
o Merging rev 1055305 from 2.1 branch.
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5, 2.2.1
Reporter: Amit Puri
Assignee: Vamsavardhana Reddy
Fix For: 2.1.8, 2.2.2
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978293#action_12978293 ] Vamsavardhana Reddy commented on GERONIMO-5749: --- At revision: 1055843 on branches\2.1 (i.e. 2.1.8-SNAPSHOT). o Added a deployer command to enable/disable stats query snapshot thread for Default Server. Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1055305 - /geronimo/server/branches/2.1/plugins/monitoring/agent-jmx/src/main/java/org/apache/geronimo/monitoring/MasterRemoteControlJMX.java
Yes. I will update the JIRA fix versions to include 2.2.x and 3.0.
On Thu, Jan 6, 2011 at 8:28 PM, Kevan Miller kevan.mil...@gmail.com wrote:
Vamsi,
Seems like this needs to be merged into 2.2 and trunk -- wanted to be sure
that you're planning on doing this...
--kevan
On Jan 5, 2011, at 1:17 AM, vamsic...@apache.org wrote:
Author: vamsic007
Date: Wed Jan 5 06:17:00 2011
New Revision: 1055305
URL: http://svn.apache.org/viewvc?rev=1055305view=rev
Log:
GERONIMO-5355 ClassCastException while starting snapshot (Stat Query) in
Monitoring portlet through java client
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.
Modified:
geronimo/server/branches/2.1/plugins/monitoring/agent-jmx/src/main/java/org/apache/geronimo/monitoring/MasterRemoteControlJMX.java
Modified:
geronimo/server/branches/2.1/plugins/monitoring/agent-jmx/src/main/java/org/apache/geronimo/monitoring/MasterRemoteControlJMX.java
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/monitoring/agent-jmx/src/main/java/org/apache/geronimo/monitoring/MasterRemoteControlJMX.java?rev=1055305r1=1055304r2=1055305view=diff
==
---
geronimo/server/branches/2.1/plugins/monitoring/agent-jmx/src/main/java/org/apache/geronimo/monitoring/MasterRemoteControlJMX.java
(original)
+++
geronimo/server/branches/2.1/plugins/monitoring/agent-jmx/src/main/java/org/apache/geronimo/monitoring/MasterRemoteControlJMX.java
Wed Jan 5 06:17:00 2011
@@ -95,7 +95,10 @@ public class MasterRemoteControlJMX impl
// set up SnaphotDBHelper with the necessary data sources
// Note: do not put this in the constructor...datasources are not
injected by then
+ClassLoader oldCl = null;
try {
+oldCl = Thread.currentThread().getContextClassLoader();
+
Thread.currentThread().setContextClassLoader(MasterRemoteControlJMX.class.getClassLoader());
InitialContext ic = new InitialContext();
activeDS =
(DataSource)ic.lookup(jca:/org.apache.geronimo.plugins/agent-ds/JCAManagedConnectionFactory/jdbc/ActiveDS);
archiveDS =
(DataSource)ic.lookup(jca:/org.apache.geronimo.plugins/agent-ds/JCAManagedConnectionFactory/jdbc/ArchiveDS);
@@ -104,6 +107,8 @@ public class MasterRemoteControlJMX impl
} catch(Exception e) {
log.error(e.getMessage());
e.printStackTrace();
+} finally {
+Thread.currentThread().setContextClassLoader(oldCl);
}
snapshotDBHelper = new SnapshotDBHelper(activeDS, archiveDS);
}
--
Vamsi
[jira] Commented: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978441#action_12978441 ] Vamsavardhana Reddy commented on GERONIMO-5749: --- I have created two sql files enable-monitoring.sql, disable-monitoring.sql and two command scripts runsql.bat, runsql.sh to run the sql by using the org.apache.derby.tools.ij class. I have manually copied these four files over to the bin directory and tested that the script run fine. I am thinking of packaging these files in mconsole-ds project so that they get copied over to the bin directory when the mconsole-ds plugin gets installed. Anybody has any comments on whether this is ok or a suggestion on where to package these four files? Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5749: -- Attachment: runsql.bat disable-monitoring.sql enable-monitoring.sql Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5749: -- Attachment: runsql.sh runsql.bat Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat, runsql.sh Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
[ https://issues.apache.org/jira/browse/GERONIMO-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5749: -- Attachment: (was: runsql.bat) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Attachments: disable-monitoring.sql, enable-monitoring.sql, runsql.bat, runsql.sh Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-5355:
--
Fix Version/s: 2.1.8
Assignee: Vamsavardhana Reddy
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Amit Puri
Assignee: Vamsavardhana Reddy
Fix For: 2.1.8
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12977640#action_12977640
]
Vamsavardhana Reddy commented on GERONIMO-5355:
---
Completed: At revision: 1055305 in branches\2.1 (i.e. 2.1.8-SNAPSHOT).
o Exception is due to a different thread context classloader at play when the
method is invoked through RMI as opposed to invocation through admin console.
Fixed by changing the context classloader for the lookups.
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Amit Puri
Assignee: Vamsavardhana Reddy
Fix For: 2.1.8
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5749) Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer
Command Line utility to enable/disable Monitoring server and Stat query Snapshot thread for DefaultServer - Key: GERONIMO-5749 URL: https://issues.apache.org/jira/browse/GERONIMO-5749 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1.7 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1.8 Currently there is no command line utility to enable/disable Monitoring on Default Server and start/stop of Stats Query snapshot thread. The only way to do these operations is through Monitoring portlet in the admin console. Enable/disable Monitoring is done by changing ENABLED column in SERVERS and GRAPHS tables in MonitoringClientDB. SQL scripts can be provided for this to execute from command line. Start/Stop of snapshot thread is done by calling MasterRemoteControlJMX GBean methods. Ideal place to provide support for this would be through a new deployer command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5355) ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring portlet through java client
[
https://issues.apache.org/jira/browse/GERONIMO-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966444#action_12966444
]
Vamsavardhana Reddy commented on GERONIMO-5355:
---
The exception seems to be due to a
org.tranql.connector.jdbc.TranqlDataSource$SelfReference object getting bound
to the JNDI instead of org.tranql.connector.jdbc.TranqlDataSource. The
TranqlDataSource object is to be obtained by calling getContent() method on the
SelfReference object.
ClassCastException while starting snapshot (Stat Query) in G 215 Monitoring
portlet through java client
---
Key: GERONIMO-5355
URL: https://issues.apache.org/jira/browse/GERONIMO-5355
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Amit Puri
In a java client where MBeanServerConnection is created and invoke
startSnapshot method in Monitoring Portlet of G 215, Stat Query snapshot
started but we can also find ClassCastException.
...
ERROR [MasterRemoteControlJMX]
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
java.lang.ClassCastException:
org.tranql.connector.jdbc.TranqlDataSource$SelfReference incompatible with
javax.sql.DataSource
at
org.apache.geronimo.monitoring.MasterRemoteControlJMX.init(MasterRemoteControlJMX.java:110)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.getMRC(SnapshotProcessor.java:148)
at
org.apache.geronimo.monitoring.snapshot.SnapshotProcessor.takeSnapshot(SnapshotProcessor.java:59)
at
org.apache.geronimo.monitoring.snapshot.SnapshotThread.run(SnapshotThread.java:103)
...
In G 214, this exception does not come while using same java client.
These steps are followed in java client:
1.Creating MBeanServerConnection object
...
MBeanServerConnection mbServerConn;
JMXServiceURL serviceURL = new
JMXServiceURL(service:jmx:rmi:///jndi/rmi://localhost/JMXConnector);
HashtableString, Object env = new HashtableString, Object();
String[] credentials = new String[2];
credentials[0] = system;
credentials[1] = manager;
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, env);
mbServerConn = connector.getMBeanServerConnection();
..
2. Retrieving the mbean name to the agent-car-jmx plugin
..
if(PATH == null) {
SetObjectName mbeanNames = mbServerConn.queryNames(new
ObjectName(*:name=MasterRemoteControlJMX,*), null);
for(IteratorObjectName it = mbeanNames.iterator(); it.hasNext(); ) {
String mbeanName = ((ObjectName)it.next()).getCanonicalName();
if(mbeanName.contains(agent-car-jmx)
mbeanName.contains(MasterRemoteControlJMX) mbeanName.contains(GBean)) {
PATH = mbeanName;
break;
}}
if(PATH == null) {
throw new Exception([ERROR] Required mbean not found: agent-car-jmx);
}}
..
Here I am getting mbean name as
geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1.5/car,j2eeType=GBean,name=MasterRemoteControlJMX
3. Invoking startSnapshot
..
long time = 30;
int days = 2;
mbServerConn.invoke(new ObjectName(PATH),startSnapshot, new Object[] {
time, days }, new String[] { java.lang.Long, java.lang.Integer });
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Bean Validation problems in trunk.
On Thu, Oct 14, 2010 at 9:49 PM, Vamsavardhana Reddy c1vams...@gmail.comwrote: On Thu, Oct 14, 2010 at 8:03 AM, Vamsavardhana Reddy c1vams...@gmail.comwrote: On Wed, Oct 13, 2010 at 11:47 PM, Rick McGuire rick...@gmail.com wrote: The recent changes to the bean validation support appear to be causing failures in both the TCK and the bean validation testsuite. I've tried to do a little problem determination, but I think Vamsi is probably going to need to take a look at this. In the testsuite failures, it looks to me that the validation factory configuration is not getting set up correctly so that not all of the constraints are getting applied in the tests. Many of the failures are just using the default constraint classes. I see that only those constraint classes that are within the same test project are being used in the validation, but the default ones are not. I will take a look at what is happening. As of rev 1005583 (by which the earlier test is reorganized and EJB test is added) the tests are passing. Rev 1005852 is the only other rev that touched plugins\bval, but the change in that rev seems to have not affected the test status. I will investigate further. When I start the server, I see one warning message indicating DefaultConstraints.properties could not be loaded... Starting Geronimo Application Server v3.0-SNAPSHOT [] 42% 10s Starting org.apache.ger...2010-10-20 22:19:07,359 WARN [ConstraintDefaults] cannot find org/apache/bval/jsr303/DefaultConstraints.properties Surely this is causing the tests with default constraints to fail. I see that the classLoader from which the resource is to get loaded is org.eclipse.osgi.internal.baseadaptor.defaultclassloa...@15a4a77 which has a delegate BundleLoader(org.apache.geronimo.framework.geronimo-system_3.0.0.SNAPSHOT) In the case where the tests are passing (before the regression), DefaultConstraints.properties is getting loaded from[BundleClassLoader] org.apache.geronimo.framework.j2ee-security_3.0.0.SNAPSHOT [74] In the TCK, I'm seeing a lot of the same failures where the test was expecting constraint failures and not getting any, so this is probably the same thing. There's at least one other problem with the TCK. A number of tests are getting deploy failures because of errors with the validation.xml. Since these tests actually ARE tests for the invalid XML. this suggests that any parsing errors discovered at deploy time should not be terminal. hmm... I will change the deployment exceptions to log warning messages instead. I have changed the code to log debug messages instead of throwing deployment exceptions. Commited in revision 1022595. This should take care of the TCK tests related to invalid XML. Rick -- Vamsi -- Vamsi -- Vamsi
Re: Bean Validation problems in trunk.
On Wed, Oct 20, 2010 at 10:41 PM, Vamsavardhana Reddy c1vams...@gmail.comwrote: On Thu, Oct 14, 2010 at 9:49 PM, Vamsavardhana Reddy c1vams...@gmail.comwrote: On Thu, Oct 14, 2010 at 8:03 AM, Vamsavardhana Reddy c1vams...@gmail.com wrote: On Wed, Oct 13, 2010 at 11:47 PM, Rick McGuire rick...@gmail.comwrote: The recent changes to the bean validation support appear to be causing failures in both the TCK and the bean validation testsuite. I've tried to do a little problem determination, but I think Vamsi is probably going to need to take a look at this. In the testsuite failures, it looks to me that the validation factory configuration is not getting set up correctly so that not all of the constraints are getting applied in the tests. Many of the failures are just using the default constraint classes. I see that only those constraint classes that are within the same test project are being used in the validation, but the default ones are not. I will take a look at what is happening. As of rev 1005583 (by which the earlier test is reorganized and EJB test is added) the tests are passing. Rev 1005852 is the only other rev that touched plugins\bval, but the change in that rev seems to have not affected the test status. I will investigate further. When I start the server, I see one warning message indicating DefaultConstraints.properties could not be loaded... Forgot to mention that this warning message is logged while loading org.apache.geronimo.configs/remote-deploy-tomcat/3.0-SNAPSHOT/car Starting Geronimo Application Server v3.0-SNAPSHOT [] 42% 10s Starting org.apache.ger...2010-10-20 22:19:07,359 WARN [ConstraintDefaults] cannot find org/apache/bval/jsr303/DefaultConstraints.properties Surely this is causing the tests with default constraints to fail. I see that the classLoader from which the resource is to get loaded is org.eclipse.osgi.internal.baseadaptor.defaultclassloa...@15a4a77 which has a delegate BundleLoader(org.apache.geronimo.framework.geronimo-system_3.0.0.SNAPSHOT) In the case where the tests are passing (before the regression), DefaultConstraints.properties is getting loaded from[BundleClassLoader] org.apache.geronimo.framework.j2ee-security_3.0.0.SNAPSHOT [74] In the TCK, I'm seeing a lot of the same failures where the test was expecting constraint failures and not getting any, so this is probably the same thing. There's at least one other problem with the TCK. A number of tests are getting deploy failures because of errors with the validation.xml. Since these tests actually ARE tests for the invalid XML. this suggests that any parsing errors discovered at deploy time should not be terminal. hmm... I will change the deployment exceptions to log warning messages instead. I have changed the code to log debug messages instead of throwing deployment exceptions. Commited in revision 1022595. This should take care of the TCK tests related to invalid XML. Rick -- Vamsi -- Vamsi -- Vamsi -- Vamsi
Re: Welcome Janet Hong Fang Han as a new committer
Congrats Janet!! On Thu, Oct 21, 2010 at 6:41 AM, Ivan xhh...@gmail.com wrote: I would like to welcome Janet aboard, as she recently accepted the Geronimo PMC invitation to become a committer. Her account was just created this morning (hanhongfang), so you should start seeing some commits from her soon. -- Ivan -- Vamsi
Re: svn commit: r1024516 - /geronimo/server/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java
Missed to commit this one. Thanks Jarek. On Wed, Oct 20, 2010 at 9:43 AM, ga...@apache.org wrote: Author: gawor Date: Wed Oct 20 04:13:07 2010 New Revision: 1024516 URL: http://svn.apache.org/viewvc?rev=1024516view=rev Log: fix build break Modified: geronimo/server/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java Modified: geronimo/server/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java?rev=1024516r1=1024515r2=1024516view=diff == --- geronimo/server/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java (original) +++ geronimo/server/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java Wed Oct 20 04:13:07 2010 @@ -58,7 +58,7 @@ public class PersistenceUnitGBeanTest ex 2.0, SharedCacheMode.NONE, ValidationMode.AUTO, -new ValidatorFactoryGBean(Dummy, bundle, getClass().getClassLoader(), null), +new ValidatorFactoryGBean(Dummy, bundle, getClass().getClassLoader(), null, null), bundle, getClass().getClassLoader()); assertNotNull(gbean.getManagedClassNames()); -- Vamsi
Re: Bean Validation problems in trunk.
On Thu, Oct 14, 2010 at 8:03 AM, Vamsavardhana Reddy c1vams...@gmail.comwrote: On Wed, Oct 13, 2010 at 11:47 PM, Rick McGuire rick...@gmail.com wrote: The recent changes to the bean validation support appear to be causing failures in both the TCK and the bean validation testsuite. I've tried to do a little problem determination, but I think Vamsi is probably going to need to take a look at this. In the testsuite failures, it looks to me that the validation factory configuration is not getting set up correctly so that not all of the constraints are getting applied in the tests. Many of the failures are just using the default constraint classes. I see that only those constraint classes that are within the same test project are being used in the validation, but the default ones are not. I will take a look at what is happening. As of rev 1005583 (by which the earlier test is reorganized and EJB test is added) the tests are passing. Rev 1005852 is the only other rev that touched plugins\bval, but the change in that rev seems to have not affected the test status. I will investigate further. In the TCK, I'm seeing a lot of the same failures where the test was expecting constraint failures and not getting any, so this is probably the same thing. There's at least one other problem with the TCK. A number of tests are getting deploy failures because of errors with the validation.xml. Since these tests actually ARE tests for the invalid XML. this suggests that any parsing errors discovered at deploy time should not be terminal. hmm... I will change the deployment exceptions to log warning messages instead. I have changed the code to log debug messages instead of throwing deployment exceptions. Commited in revision 1022595. This should take care of the TCK tests related to invalid XML. Rick -- Vamsi -- Vamsi
Re: Bean Validation problems in trunk.
On Wed, Oct 13, 2010 at 11:47 PM, Rick McGuire rick...@gmail.com wrote: The recent changes to the bean validation support appear to be causing failures in both the TCK and the bean validation testsuite. I've tried to do a little problem determination, but I think Vamsi is probably going to need to take a look at this. In the testsuite failures, it looks to me that the validation factory configuration is not getting set up correctly so that not all of the constraints are getting applied in the tests. Many of the failures are just using the default constraint classes. I see that only those constraint classes that are within the same test project are being used in the validation, but the default ones are not. I will take a look at what is happening. In the TCK, I'm seeing a lot of the same failures where the test was expecting constraint failures and not getting any, so this is probably the same thing. There's at least one other problem with the TCK. A number of tests are getting deploy failures because of errors with the validation.xml. Since these tests actually ARE tests for the invalid XML. this suggests that any parsing errors discovered at deploy time should not be terminal. hmm... I will change the deployment exceptions to log warning messages instead. Rick -- Vamsi
Is there an OSGI Framework Bundle API for accessing nested archive content?
The ValidatorFactoryGBean uses Bundle.getEntry() to get to META-INF/validation.xml and WEB-INF/validation.xml files in EJB and Web archives. This works fine for standalone modules. When the JAR or WAR is packaged in an EAR file, Bundle.getEntry(war-modulename.war/WEB-INF/validation.xml) gets me to the file as WAR file is exploded and repackaged in the EAR whereas Bundle.getEntry(ejb-modulename.jar/META-INF/validation.xml) does not work since the EJB jar is stored as is in the EAR. One option I can think of is to get the EJB jar entry, store it to a temporary file, open it with Jar APIs to get to META-INF/validation.xml. myapp.ear my-ejb.jar (EJB jar is stored as is) +--META-INF +-- validation.xml +--my-web.war (WAR file is exploded, so WEB-INF is a directory in the repackaged EAR) +--WEB-INF +-- validation.xml Is there any Bundle API that will allow to access the content in the nested archives? Or any other way to get to the file of interest without creating temporary files? -- Vamsi
Re: Is there an OSGI Framework Bundle API for accessing nested archive content?
David, Bundle.getResources() does seem to work, but I am afraid it does not help me in this case as each EJB jar can have its own META-INF/validation.xml and when there are mulitple EJB jars in the EAR, it is not possible to distinguish which URL points to the one I am looking for in particular. On Fri, Oct 8, 2010 at 10:37 PM, David Jencks david_jen...@yahoo.comwrote: I think we've put all the jars or wars that could have this file in them in the bundle class path, so I would expect bundle.getResources() to provide all the possiblilites. I haven't tried it in this context, but it seems to work for something similar -- finding META-INF/resources directories in jars in WEB-INF/lib in wars. thanks david jencks On Oct 8, 2010, at 9:15 AM, Vamsavardhana Reddy wrote: The ValidatorFactoryGBean uses Bundle.getEntry() to get to META-INF/validation.xml and WEB-INF/validation.xml files in EJB and Web archives. This works fine for standalone modules. When the JAR or WAR is packaged in an EAR file, Bundle.getEntry(war-modulename.war/WEB-INF/validation.xml) gets me to the file as WAR file is exploded and repackaged in the EAR whereas Bundle.getEntry(ejb-modulename.jar/META-INF/validation.xml) does not work since the EJB jar is stored as is in the EAR. One option I can think of is to get the EJB jar entry, store it to a temporary file, open it with Jar APIs to get to META-INF/validation.xml. myapp.ear my-ejb.jar (EJB jar is stored as is) +--META-INF +-- validation.xml +--my-web.war (WAR file is exploded, so WEB-INF is a directory in the repackaged EAR) +--WEB-INF +-- validation.xml Is there any Bundle API that will allow to access the content in the nested archives? Or any other way to get to the file of interest without creating temporary files? -- Vamsi -- Vamsi
Re: [DISCUSSION] Bean validation support: handling validation xml parsing errors
In rev 100, I have checked in the code to parse the validation constraint mapping xml's and throw deployment exceptions if there are any errors. [1] http://svn.apache.org/viewvc?rev=100view=rev On Mon, Sep 27, 2010 at 4:18 PM, Vamsavardhana Reddy c1vams...@gmail.comwrote: I am working on GERONIMO-5222 Add support for application validation descriptor support for deployed applications. I have not come across anything in Java EE 6 spec that says what is to be done in the case where there are errors in validation.xml. Current implementation in Geronimo, if validation.xml parsing errors will result in an exception at runtime. I think Geronimo should be throwing deployment time exceptions if validation.xml parsing results in an error. Also, should we extend this to checking the constraint mapping xml files as well (atleast check if the constraint mapping xml files exist in the deployment bundle). What do others think? -- Vamsi -- Vamsi
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915789#action_12915789 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 100 o Throw deployment exception for errors in parsing validation and constraint mapping xml Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: Vamsavardhana Reddy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSSION] Bean validation support: handling validation xml parsing errors
I am working on GERONIMO-5222 Add support for application validation descriptor support for deployed applications. I have not come across anything in Java EE 6 spec that says what is to be done in the case where there are errors in validation.xml. Current implementation in Geronimo, if validation.xml parsing errors will result in an exception at runtime. I think Geronimo should be throwing deployment time exceptions if validation.xml parsing results in an error. Also, should we extend this to checking the constraint mapping xml files as well (atleast check if the constraint mapping xml files exist in the deployment bundle). What do others think? -- Vamsi
http://localhost:8080/console/ is showing directory listing instead of login page
Hi, I built the server from latest trunk (Revision: 1001591. Wow! a million commits to the subversion repo!!) and ran the server from geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT assembly. When I access the URL http://localhost:8080/console/ , I am getting a directory listing instead of the login page!! Anyone else seeing this? Anybody knows what is broken? -- Vamsi
Compilation error in server\trunk\plugins\jetty8\geronimo-jetty8-clustering-wadi
I am getting a compilation error in geronimo-jetty8-clustering-wadi module in trunk. Can someone suggest how to get rid of this error? Thanks. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\G\server\trunk\plugins\jetty8\geronimo-jetty8-clustering-wadi\src\main\java\org\apache\geronimo\jetty8\cluster\ClusteredSessionManager.java:[93,15] [depre cation] getSessionMap() in org.eclipse.jetty.server.session.AbstractSessionManager has been deprecated C:\G\server\trunk\plugins\jetty8\geronimo-jetty8-clustering-wadi\src\main\java\org\apache\geronimo\jetty8\cluster\ClusteredSessionManager.java:[93,15] [depre cation] getSessionMap() in org.eclipse.jetty.server.session.AbstractSessionManager has been deprecated C:\G\server\trunk\plugins\jetty8\geronimo-jetty8-clustering-wadi\src\main\java\org\apache\geronimo\jetty8\cluster\ClusteredSessionManager.java:[148,12] canno t find symbol symbol : constructor Session(long,java.lang.String) location: class org.eclipse.jetty.server.session.AbstractSessionManager.Session -- Vamsi
[jira] Commented: (GERONIMO-5221) Add naming support for Validator and ValidatorFactory.
[ https://issues.apache.org/jira/browse/GERONIMO-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910143#action_12910143 ] Vamsavardhana Reddy commented on GERONIMO-5221: --- At revision: 997732 o DefaultValidator should use configured ValidatorFactory if any Add naming support for Validator and ValidatorFactory. --- Key: GERONIMO-5221 URL: https://issues.apache.org/jira/browse/GERONIMO-5221 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: David Jencks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5221) Add naming support for Validator and ValidatorFactory.
[ https://issues.apache.org/jira/browse/GERONIMO-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910249#action_12910249 ] Vamsavardhana Reddy commented on GERONIMO-5221: --- At revision: 997868 o Cache the factory instance so that a single instance is used per module Add naming support for Validator and ValidatorFactory. --- Key: GERONIMO-5221 URL: https://issues.apache.org/jira/browse/GERONIMO-5221 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: David Jencks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release javamail 1.8.2 provider and mail components. (second attempt)
+1 On Tue, Sep 14, 2010 at 5:13 PM, Rick McGuire rick...@gmail.com wrote: This is a bug fix release to fix a problem with the javamail smtp provider including the BCC recipients as a header in sent messages. The JIRA in question is https://issues.apache.org/jira/browse/GERONIMO-5587 This is a vote for the javamail providers and combined mail jar. This fix did not require an update to the javamail specs. . The 2 components up for vote are: org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.2/geronimo-javamail_1.4-1.8.2-source-release.tar.gz org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.2/geronimo-javamail_1.4-1.8.2-source-release.zip from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-020/ The source repo is: https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.8.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick -- Vamsi
[jira] Commented: (GERONIMO-5607) geronimo-default keystore file not displayed on the administration console
[ https://issues.apache.org/jira/browse/GERONIMO-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909682#action_12909682 ] Vamsavardhana Reddy commented on GERONIMO-5607: --- An 'EMPTY' file in var\security\keystores directory is the culprit. geronimo-default keystore file not displayed on the administration console -- Key: GERONIMO-5607 URL: https://issues.apache.org/jira/browse/GERONIMO-5607 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 3.0 Environment: Windows platform Reporter: maojia Priority: Minor The geronimo-default keystore file is not displayed on the Keystore portlet on the administration console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release javamail 1.8.2 provider and mail components.
I agree with Ivan. We should use JDK1.5 to build the binaries. On Tue, Sep 14, 2010 at 8:25 AM, Ivan xhh...@gmail.com wrote: I am thinking that we should build it by jdk 1.5. 2010/9/14 Kevan Miller kevan.mil...@gmail.com Rick, Source, signature, checksum, build -- all look good. Here's my +1. One note, your source release is: https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.2/geronimo-javamail_1.4-1.8.2-source-release.tar.gz or https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.2/geronimo-javamail_1.4-1.8.2-source-release.zip Your note refers to the source jars that are, IMO, not appropriate as release artifacts. The above artifact (tar.gz) is what I've reviewed and am voting on. --kevan On Sep 10, 2010, at 8:04 AM, Rick McGuire wrote: This is a bug fix release to fix a problem with the javamail smtp provider including the BCC recipients as a header in sent messages. The JIRA in question is https://issues.apache.org/jira/browse/GERONIMO-5587 This is a vote for the javamail providers and combined mail jar. This fix did not require an update to the javamail specs. . The 2 components up for vote are: org/apache/geronimo/javamail/geronimo-javamail_1.4_mail/1.8.2/geronimo-javamail_1.4_mail-1.8.2-sources.jar org/apache/geronimo/javamail/geronimo-javamail_1.4_provider/1.8.2/geronimo-javamail_1.4_provider-1.8.2-sources.jar from the staging repository at: https://repository.apache.org/content/repositories/orgapachegeronimo-008/ The source repo is: https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.8.2/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Rick -- Ivan -- Vamsi
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906936#action_12906936 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 993482 o Support for web applications o ModuleBuilderExtension to add ValidatorFactoryGBean. o Hook the module builder extension to tomcat builder. Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: Vamsavardhana Reddy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Where is ValidatorFactoryBuilder interface?
As part of GERONIMO-5222 Add support for application validation descriptor support for deployed applications, I am trying to process validation.xml in Web and other Java EE modules. I have come across org/apache/bval/jsr303/ConfigurationImpl. But, then it would still require parsing of validation.xml within Geronimo code. Just wanted to check if there is any other API that I have missed out. On Wed, Sep 8, 2010 at 1:42 AM, Donald Woods dwo...@apache.org wrote: Right, one area in the doc that needs updating... For Apache BVal, take a look at - bval-jsr303/src/main/java/org/apache/bval/jsr303/ConfigurationImpl.java Which can hold the constraint mappings as InputStreams and has public ValidatorFactory buildValidatorFactory() You can get a Validator with something like - javax.validation.Configuration configuration = Validation.byProvider( ApacheValidationProvider.class).configure(); Validator validator = configuration.buildValidatorFactory().getValidator(); Are you trying to build a Validator with a Configuration that uses a custom validation.xml? -Donald On 9/7/10 5:57 AM, Rick McGuire wrote: On 9/2/2010 5:33 PM, Vamsavardhana Reddy wrote: Section EE.5.16.2 of Java EE 6 specification says, For the benefit of implementors, we note that the Bean Validation API includes a ValidatorFactoryBuilder interface that can be used to create a ValidatorFactory configured according to the contents of a validation deployment descriptor in the form of a java.io.InputStream.. I don't see it in geronimo-validation_1.0_spec-1.1.jar. Where can I find this ValidatorFactoryBuilder? -- Vamsi The Bean Validation spec does not include ValidatorFactoryBuilder and it is also not part of the TCK. I suspect the mention on the Java EE 6 is obsolete. Rick -- Vamsi
Re: [ANNOUNCE] Welcome Ming Xai Forrest as a new Geronimo PMC member
Congratulations Forrest!! On Wed, Sep 8, 2010 at 1:04 AM, Donald Woods dwo...@apache.org wrote: Please join us in congratulating Forrest as a new member of the Geronimo PMC. In addition to all his work on Samples, Forrest also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Forrest !!! The Apache Geronimo PMC -- Vamsi
Re: [ANNOUNCE] Welcome Xuan Dai Delos as a new Geronimo PMC member
Congratulations Delos!! On Wed, Sep 8, 2010 at 1:02 AM, Donald Woods dwo...@apache.org wrote: Please join us in congratulating Delos as a new member of the Geronimo PMC. In addition to all his work on GEP and Samples, Delos also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Delos !!! The Apache Geronimo PMC -- Vamsi
Re: [ANNOUNCE] Welcome Rex Wang as a new member of the Geronimo PMC
Congrats!! On Tue, Sep 7, 2010 at 6:30 PM, Rick McGuire rick...@gmail.com wrote: Please join us in congratulating as a new member of the Geronimo PMC. In addition to serving as a release manager for the Geronimo 2.1.5 server release, Rex also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratuatlons Rex !!! The Apache Geronimo PMC -- Vamsi
Compilation error in server\trunk\plugins\j2ee\geronimo-web-2.5-builder
Looks like a BigInteger is getting assigned to an int. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project geronimo-web-2.5-builder: Compilation failure C:\G\server\trunk\plugins\j2ee\geronimo-web-2.5-builder\src\main\java\org\apache\geronimo\web25\deployment\WebAppInfoBuilder.java:[95,92] incompatible types found : java.math.BigInteger required: int -- Vamsi
Re: Compilation error in server\trunk\plugins\j2ee\geronimo-web-2.5-builder
The error is gone after building openejb locally. Thanks. On Wed, Sep 8, 2010 at 2:39 AM, David Jencks david_jen...@yahoo.com wrote: I deployed an updated openejb-jee jar yesterday so I'm not sure why you would be seeing this. Can you make sure both halves of the code are up to date locally? thanks david jencks On Sep 7, 2010, at 2:05 PM, Vamsavardhana Reddy wrote: Looks like a BigInteger is getting assigned to an int. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project geronimo-web-2.5-builder: Compilation failure C:\G\server\trunk\plugins\j2ee\geronimo-web-2.5-builder\src\main\java\org\apache\geronimo\web25\deployment\WebAppInfoBuilder.java:[95,92] incompatible types found : java.math.BigInteger required: int -- Vamsi -- Vamsi
[jira] Commented: (GERONIMO-5222) Add support for application validation descriptor support for deployed applications.
[ https://issues.apache.org/jira/browse/GERONIMO-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907037#action_12907037 ] Vamsavardhana Reddy commented on GERONIMO-5222: --- At revision: 993562 o Hook the module builder extension to jetty deployer. Add support for application validation descriptor support for deployed applications. - Key: GERONIMO-5222 URL: https://issues.apache.org/jira/browse/GERONIMO-5222 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Reporter: Rick McGuire Assignee: Vamsavardhana Reddy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5226) Pass container ValidationFactory to the persistance manager when creating an entity manager.
[ https://issues.apache.org/jira/browse/GERONIMO-5226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907045#action_12907045 ] Vamsavardhana Reddy commented on GERONIMO-5226: --- At revision: 993568 o Hook the BValModuleBuilderExtension to openejb deployer. o Add ValidatorFactoryGBean as a parameter to PersistenceUnitGBean constructor. Pass container ValidationFactory to the persistance manager when creating an entity manager. - Key: GERONIMO-5226 URL: https://issues.apache.org/jira/browse/GERONIMO-5226 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Linquan Jiang Shawn as a new Geronimo PMC member
Congrats Shawn!! On Wed, Sep 8, 2010 at 6:15 AM, Ivan xhh...@gmail.com wrote: I would like to welcome Shawn as he recently accepted the Geronimo PMC invitation to join the PMC. We look forward to working with him to maintain oversight of the Geronimo project. Welcome! -- Ivan -- Vamsi
[jira] Commented: (GERONIMO-5228) Add classes for parsing a validation.xml descriptor
[ https://issues.apache.org/jira/browse/GERONIMO-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905543#action_12905543 ] Vamsavardhana Reddy commented on GERONIMO-5228: --- The built-in parser ValidationParser class in Bean Validation API tries to load the specified validation.xml file and constraint mapping files through the classloader API. At least in case of web applications, WEB-INF/validation.xml etc will not be available through web-app's classloader. So, there is definitely some work to be done here though we may use the JAXB generated classes from BVAL. Add classes for parsing a validation.xml descriptor --- Key: GERONIMO-5228 URL: https://issues.apache.org/jira/browse/GERONIMO-5228 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Where is ValidatorFactoryBuilder interface?
Section EE.5.16.2 of Java EE 6 specification says, For the benefit of implementors, we note that the Bean Validation API includes a ValidatorFactoryBuilder interface that can be used to create a ValidatorFactory configured according to the contents of a validation deployment descriptor in the form of a java.io.InputStream.. I don't see it in geronimo-validation_1.0_spec-1.1.jar. Where can I find this ValidatorFactoryBuilder? -- Vamsi
Re: Retrieving the ValidatorFactory JNDI entry for a module context.
Hi Rick,
Isn't javax.faces.validator.beanValidator.ValidatorFactory attribute
required in the ServletContext only when the web app is using JSF? Then the
place where this attribute can be added is in MyFacesModuleBuilderExtension
using a RuntimeCustomizer (similar to JasperServletContextCustomizer that
adds org.apache.tomcat.InstanceManager attribute to ServletContext). By
the time the customize() method is called, the ValidatorFactory is available
in the jndiContext at comp/ValidatorFactory. I will create a patch for
this for you to review.
On Thu, Aug 26, 2010 at 8:56 PM, Rick McGuire rick...@gmail.com wrote:
I'm trying to implement the bean validation feature described in section
EE.6.27 of the Java EE 6 specification. This requires that the web
container set a property named
javax.faces.validator.beanValidator.ValidatorFactory in the
ServletContext. I know where this should be set, but I'm having problems
getting access to the ValidatorFactory instance that I need to satisfy this
requirement.
For example, I've tried adding the following code to TomcatContainer to set
this property:
// now set the module context ValidatorFactory in a context
property.
try {
javax.naming.Context ctx =contextInfo.getJndiContext();
Object validatorFactory
=ctx.lookup(java:comp/ValidatorFactory);
context.getServletContext().setAttribute(javax.faces.validator.beanValidator.ValidatorFactory,validatorFactory);
}catch (NamingException e) {
// ignore. We just don't set the property if it's not
available.
}
This results in a NamingException, which probably means that
contextInfo.getJndiContext() is not the correct place to retrieve this or
the context has not yet been set up correctly. I've also tried using an
InitialContext to do the lookup with the same result. I had a similar
problem with Jetty where I tried using
try {
javax.naming.Context ctx
=integrationContext.getComponentContext();
Object validatorFactory
=ctx.lookup(java:comp/ValidatorFactory);
to lookup the factory. How should I be obtaining this value when setting
up the container?
I have a similar issue with passing the ValidatorFactory when setting up
the JPA provider. The call to createContainerEntityManagerFactory() is made
in constructor of the PersistenceUnitGBean. In that context, how should the
lookup for the ValidatorFactory instance for the module be performed?
Rick
--
Vamsi
Re: Retrieving the ValidatorFactory JNDI entry for a module context.
Ah... the solution seems to be much simpler get rid of the java: in
the lookup!!
On Thu, Aug 26, 2010 at 8:56 PM, Rick McGuire rick...@gmail.com wrote:
I'm trying to implement the bean validation feature described in section
EE.6.27 of the Java EE 6 specification. This requires that the web
container set a property named
javax.faces.validator.beanValidator.ValidatorFactory in the
ServletContext. I know where this should be set, but I'm having problems
getting access to the ValidatorFactory instance that I need to satisfy this
requirement.
For example, I've tried adding the following code to TomcatContainer to set
this property:
// now set the module context ValidatorFactory in a context
property.
try {
javax.naming.Context ctx =contextInfo.getJndiContext();
Object validatorFactory
=ctx.lookup(java:comp/ValidatorFactory);
context.getServletContext().setAttribute(javax.faces.validator.beanValidator.ValidatorFactory,validatorFactory);
}catch (NamingException e) {
// ignore. We just don't set the property if it's not
available.
}
This results in a NamingException, which probably means that
contextInfo.getJndiContext() is not the correct place to retrieve this or
the context has not yet been set up correctly. I've also tried using an
InitialContext to do the lookup with the same result. I had a similar
problem with Jetty where I tried using
try {
javax.naming.Context ctx
=integrationContext.getComponentContext();
Object validatorFactory
=ctx.lookup(java:comp/ValidatorFactory);
to lookup the factory. How should I be obtaining this value when setting
up the container?
I have a similar issue with passing the ValidatorFactory when setting up
the JPA provider. The call to createContainerEntityManagerFactory() is made
in constructor of the PersistenceUnitGBean. In that context, how should the
lookup for the ValidatorFactory instance for the module be performed?
Rick
--
Vamsi
[jira] Updated: (GERONIMO-5227) Add ValidatorFactory to servlet context for JSF usage.
[ https://issues.apache.org/jira/browse/GERONIMO-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5227: -- Attachment: GERONIMO-5227-tomcat.patch GERONIMO-5227-tomcat.patch: Set the javax.faces.validator.beanValidator.ValidatorFactory attribute in ServletContext for Tomcat. Add ValidatorFactory to servlet context for JSF usage. --- Key: GERONIMO-5227 URL: https://issues.apache.org/jira/browse/GERONIMO-5227 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 Attachments: GERONIMO-5227-tomcat.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5227) Add ValidatorFactory to servlet context for JSF usage.
[ https://issues.apache.org/jira/browse/GERONIMO-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-5227: -- Attachment: GERONIMO-5227-jetty.patch GERONIMO-5227-jetty.patch: Set the javax.faces.validator.beanValidator.ValidatorFactory attribute in ServletContext for Jetty. Add ValidatorFactory to servlet context for JSF usage. --- Key: GERONIMO-5227 URL: https://issues.apache.org/jira/browse/GERONIMO-5227 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, naming Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 Attachments: GERONIMO-5227-jetty.patch, GERONIMO-5227-tomcat.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Policy for granting access to Geronimo TCK materials
I agree on dropping the waiting period. On Wed, Aug 11, 2010 at 5:37 PM, Kevan Miller kevan.mil...@gmail.comwrote: All, Our policy for granting access to the Geronimo TCK test harness is described here -- https://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html#GeronimoProjectPolicies-AccesstoTCK The policy describes a 72 hour waiting period when granting non-Geronimo committers read-only access to our TCK test harness. This period was intended to allow the Geronimo PMC time to provide oversight on these requests. Presumably, a PMC member could block someone's request (though this has never occurred and I can't, frankly, imagine a case where we would block someone's request). If we had our preference, our TCK test harness would not be in a private svn. It would instead be publicly readable by all. I would like to remove the 72 hour waiting period from our policy. If an ASF committer requests access to our test harness, I believe we should grant this access immediately. The 72 hour waiting period might have been more meaningful when the Geronimo project maintained and distributed the Sun (now Oracle) TCK. As a reminder, these materials are obtained via an agreement between the ASF and Sun/Oracle. To gain access to these materials, an ASF committer must sign an NDA. We still maintain/distribute the Sun/Oracle TCK for Java EE 5. However, the JCP project is maintaining the newer TCK materials. The JCP does not have a waiting period for granting access to the JCP maintained TCK materials. Comments? Objections? If I don't hear any objections, I'll plan on updating our policy and removing the 72 hour window... --kevan -- Vamsi
Geronimo Server Trunk - Compilation Errors shown in Eclipse workspace
Hi,
After building the Geronimo 3.0 trunk, I see some errors shown in Eclipse
when I import the projects into workspace. The following are few such.
1)
Error: The blank final field parameterTypes may not have been initialized
Source location: Line 82 in
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/GBeanOperation.java
The source line is
private String[] types = (String[])
parameterTypes.toArray(new String[parameterTypes.size()]);
Examining the source indicates that the field parameterTypes is very much
initialized. Also, there is no build error while building the project using
maven.
2)
Error: The method getAllAppenders() is undefined for the type Logger
Source location: Line 342 in
geronimo-pax-logging/src/main/java/org/apache/geronimo/logging/impl/Log4jService.java
The source line is
for (Enumeration e = Logger.getRootLogger().getAllAppenders();
e.hasMoreElements();) {
A similar error is shown with 7 other source lines in the same file
Any idea how to get rid of these errors shown in Eclipse?
I am using Eclipse Platform Version: 3.4.1 Build id: M20080911-1700 on
Windows XP SP3, with Sun JDK 1.6.0_20.
--
Vamsi
Re: Compilation error in OpenEJB :: Builder
The error went away after I built OpenEJB trunk (3.2-SNAPSHOT) locally. Can someone publish the latest OpenEJB 3.2-SNAPSHOT jars to maven repository? Thanks, On Thu, Jul 29, 2010 at 5:20 PM, Vamsavardhana Reddy c1vams...@gmail.comwrote: I am getting a compilation failure in OpenEJB Builder module. Anyone else seeing this error? I am at svn rev 980390. Error message given below... [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\G\server\trunk\plugins\openejb\geronimo-openejb-builder\src\main\java\org\apache\geronimo\openejb\deployment\EjbRefBuilder.java:[128,30] build(org.apache.openejb.jee.JndiConsumer,java.lang.String,java.lang.String) in org.apache.openejb.config.JndiEncInfoBuilder cannot be applied to (org.apache.openejb.jee.JndiConsumer,java.lang.String,java.lang.String,org.apache.openejb.assembler.classic.JndiEncInfo,org.apache.openejb.assembler.classic.JndiEncInfo) -- Vamsi -- Vamsi
Re: [VOTE] External tomcat-parent-6.0.29.0
+1 Delos, you now have the required PMC votes. On Fri, Jul 23, 2010 at 4:58 PM, Delos dait...@gmail.com wrote: This voting is for mavenized tomcat 6.0.29. Following what we did to tomcat 6.0.20, we are using a forked copy of tomcat derived from the tomcat 6.0.29 release, built with maven, with maven dependencies, etc etc. Besides, we also applied some patches which haven't been included in tomcat 6.0.29. Based on tomcat 6.0.29 tag, I also applied another couple of patches: GERONIMO-3451 'Restricted listeners property file not found' error logged during Tomcat server startup GERONIMO-4685 Include patches for revision #790742 Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-028/ svn tag at: http://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-6.0.29.0/ [ ] +1 go for it [ ] 0 [ ] -1 whoa, hold on a minute Vote open 72 hours thanks a lot! -- Best Regards, Delos -- Vamsi
Compilation error in OpenEJB :: Builder
I am getting a compilation failure in OpenEJB Builder module. Anyone else seeing this error? I am at svn rev 980390. Error message given below... [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\G\server\trunk\plugins\openejb\geronimo-openejb-builder\src\main\java\org\apache\geronimo\openejb\deployment\EjbRefBuilder.java:[128,30] build(org.apache.openejb.jee.JndiConsumer,java.lang.String,java.lang.String) in org.apache.openejb.config.JndiEncInfoBuilder cannot be applied to (org.apache.openejb.jee.JndiConsumer,java.lang.String,java.lang.String,org.apache.openejb.assembler.classic.JndiEncInfo,org.apache.openejb.assembler.classic.JndiEncInfo) -- Vamsi
Re: [VOTE] Release new versions of the Geronimo bundle components
My +1.
Thanks Rick, rat:check runs fine with a clean checkout.
On Tue, Jul 20, 2010 at 4:05 PM, Rick McGuire rick...@gmail.com wrote:
Meant to send this to the list, not directly to Vamsi.
On 7/20/2010 2:38 AM, Vamsavardhana Reddy wrote:
I am getting an error with rat:check on Windows XP SP3, maven-2.2.1.
Build output given below.
If you run rat:check after building the code, the rat step is picking up
the velocity.log file that is left over from the plugin that creates the
merged LICENSE and NOTICE files. The rat check passes cleanly if you delete
the velocity.log file or run it against a clean checkout.
Rick
C:\G\bundles\tags\aspectjrt-1.6.8_1mvn rat:check -e
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'rat'.
[INFO]
[INFO] Building Apache Geronimo Bundles: aspectjrt-1.6.8
[INFO]task-segment: [rat:check]
[INFO]
[INFO] [rat:check {execution: default-cli}]
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Too many unapproved licenses: 4
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: Too many unapproved licenses: 4
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.codehaus.mojo.rat.RatCheckException: Too many unapproved
licenses: 4
at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:224)
at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:216)
at
org.codehaus.mojo.rat.RatCheckMojo.execute(RatCheckMojo.java:172)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Jul 20 12:04:30 IST 2010
[INFO] Final Memory: 16M/38M
[INFO]
C:\G\bundles\tags\aspectjrt-1.6.8_1mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530)
Java version: 1.6.0_20
Java home: C:\SUNJDK160\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
On Tue, Jul 13, 2010 at 8:13 PM, Rick McGuire rick...@gmail.commailto:
rick...@gmail.com wrote:
To allow the Geronimo trunk release to upgrade the some of the
components used by the server, I'd like
release new versions of some of the Geronimo bundle components.
This components are versions of external
Geronimo dependencies that have been converted into OSGi jars.
This is a single vote for multiple upgraded bundles used by the
Geronimo 3.0 trunk branch.
The RAT and IANAL plugins have been run against of the projects.
All tag svn versions have been
successfully built.
Vote will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Staging repo
Re: [VOTE] Release new versions of the Geronimo bundle components
I am getting an error with rat:check on Windows XP SP3, maven-2.2.1. Build
output given below.
C:\G\bundles\tags\aspectjrt-1.6.8_1mvn rat:check -e
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'rat'.
[INFO]
[INFO] Building Apache Geronimo Bundles: aspectjrt-1.6.8
[INFO]task-segment: [rat:check]
[INFO]
[INFO] [rat:check {execution: default-cli}]
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Too many unapproved licenses: 4
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: Too many unapproved licenses: 4
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.codehaus.mojo.rat.RatCheckException: Too many unapproved
licenses: 4
at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:224)
at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:216)
at org.codehaus.mojo.rat.RatCheckMojo.execute(RatCheckMojo.java:172)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Jul 20 12:04:30 IST 2010
[INFO] Final Memory: 16M/38M
[INFO]
C:\G\bundles\tags\aspectjrt-1.6.8_1mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530)
Java version: 1.6.0_20
Java home: C:\SUNJDK160\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
On Tue, Jul 13, 2010 at 8:13 PM, Rick McGuire rick...@gmail.com wrote:
To allow the Geronimo trunk release to upgrade the some of the components
used by the server, I'd like
release new versions of some of the Geronimo bundle components. This
components are versions of external
Geronimo dependencies that have been converted into OSGi jars.
This is a single vote for multiple upgraded bundles used by the Geronimo
3.0 trunk branch.
The RAT and IANAL plugins have been run against of the projects. All tag
svn versions have been
successfully built.
Vote will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Staging repo:
https://repository.apache.org/content/repositories/orgapachegeronimo-056/
All source repos are relative to location
https://svn.apache.org/repos/asf/geronimo/bundles/tags
and have the same final element as the artifact name.
The following components are being voted on (the bundles-parent has already
been promoted):
aspectjrt-1.6.8_1
aspectjweaver-1.6.8_1
derby-all-10.6.1.0_1
sxc-jaxb-0.7.3_1
sxc-runtime-0.7.3_1
woodstox-4.0.6_1_1
--
Vamsi
Re: [VOTE] Release Geronimo 2.1.6 - second attempt.
Rick,
I notice that using maven-2.0.9 to build the tag results in the following
build error.
C:\G\server\tags\geronimo-2.1.6mvn install
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.geronimo:geronimo
POM Location: C:\G\server\tags\geronimo-2.1.6\pom.xml
Reason: The POM expression: ${version} could not be evaluated. Reason:
Expression value '${version}' references itself in
'org.apache.geronimo:geronimo:pom:2
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: The POM expression:
${version} could not be evaluated. Reason: Expression value '${version}'
references its
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: The POM
expression: ${version} could not be evaluated. Reason: Expression value
'${version}
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:882)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
Caused by:
org.apache.maven.project.interpolation.ModelInterpolationException: The POM
expression: ${version} could not be evaluated. Reason: Expression valu
at
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal(RegexBasedModelInterpolator.java:172)
at
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:98)
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1016)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878)
... 16 more
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Jul 01 23:50:08 IST 2010
[INFO] Final Memory: 1M/4M
[INFO]
Should we up the allowed maven versions in the root pom?
On Thu, Jul 1, 2010 at 11:48 PM, Rick McGuire rick...@gmail.com wrote:
On 7/1/2010 9:22 AM, Donald Woods wrote:
Has the voting finished? I didn't see a [RESULTS] reply yet...
Sorry, I was waiting for the TCK results, and then got busy on some other
tasks. I probably won't be able to handle finishing up the release until
Tuesday.
Rick
-Donald
On 6/23/10 5:24 AM, Rick McGuire wrote:
A release candidate for Geronimo 2.1.6 has been created and staged.
This version is the same as the previous release candidate except for an
upgrade to the spring framework dependency.
The tag has been created here:
https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6
The staging repo is here:
https://repository.apache.org/content/repositories/orgapachegeronimo-008
The main artifacts up for vote are the source release archives:
https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz
https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip
The distribution artifacts have been copied to a second staging
repository for your convenience:
http://people.apache.org/~rickmcguire/staging-repo/2.1.6/http://people.apache.org/%7Erickmcguire/staging-repo/2.1.6/
We have to verify the binaries pass
Re: [VOTE] Release Geronimo 2.1.6 - second attempt.
+1 On Wed, Jun 23, 2010 at 2:54 PM, Rick McGuire rick...@gmail.com wrote: A release candidate for Geronimo 2.1.6 has been created and staged. This version is the same as the previous release candidate except for an upgrade to the spring framework dependency. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6 The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-008 The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/http://people.apache.org/%7Erickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick -- Vamsi
Re: [VOTE] Release Geronimo 2.1.6
+1 On Fri, Jun 18, 2010 at 10:01 PM, Rick McGuire rick...@gmail.com wrote: A release candidate for Geronimo 2.1.6 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.6/ https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-001/ https://repository.apache.org/content/repositories/orgapachegeronimo-005/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/geronimo/2.1.6/geronimo-2.1.6-source-release.zip https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.zip The distribution artifacts have been copied to a second staging repository for your convenience: http://people.apache.org/~rickmcguire/staging-repo/2.1.6/http://people.apache.org/%7Erickmcguire/staging-repo/2.1.6/ We have to verify the binaries pass the tck, so the vote may be open for longer than the 72-hour minimum. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Rick -- Vamsi
Re: [VOTE] Geronimo 3.0-M1 release - 3rd attempt
Donald,
I am unable to build the tag starting with an empty maven repo. I tried with
Maven-2.2.1 as well as Maven-3.0-beta1. I am using Sun JDK 1.6.0_20. Which
version of Sun JDK and Maven have you used to build the tag?
On Fri, Jun 11, 2010 at 5:43 PM, Donald Woods dwo...@apache.org wrote:
+1 as I think the below issues are acceptable for a milestone release.
Was able to build the tag and start the Tomcat Java EE 6 server.
-Donald
On 6/10/10 4:29 PM, Jarek Gawor wrote:
+0.5
M1 is affected by GERONIMO-5336. All services will most likely bind to
the local loopback device instead of all network devices so you won't
be able to access the console, etc. remotely. That can be fixed by
setting the ServerHostname property to 0.0.0.0 in
var/config/config-substitutions.properties file and also changing the
following in var/config/config.xml:
attribute name=ServerUrltcp://${ServerHostname}:${ActiveMQPort +
PortOffset}/attribute
to
attribute name=ServerUrltcp://localhost:${ActiveMQPort +
PortOffset}/attribute
Otherwise, without the second change an exception will be generated at
server startup by the activemq plugin.
M1 also seems to be affected by GERONIMO-5334. But I only see that
error from time to time.
Jarek
On Wed, Jun 9, 2010 at 4:13 PM, Rick McGuire rick...@gmail.com wrote:
A new 3.0-M1 release candidate is ready for review. The LICENSE problem
has
been corrected and the missed testsuite updates that Jarek noticed have
been
included.
See the JIRA issues here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220
Staged to
https://repository.apache.org/content/repositories/orgapachegeronimo-046/
The main artifacts up for vote are the source release archives
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz
If you vote you should at least examine these and make sure something
plausible builds from them.
The voting will be open a minimum of 72 hours.
[ ] +1 about time to push this out the door
[ ] 0 no opinion
[ ] -1 not this one (please explain why)
Rick
--
Vamsi
Re: [VOTE] Geronimo 3.0-M1 release - 3rd attempt
Ah... missed the bootstrap build step :D . The build seems to run fine now.
Will post again if it fails. Thanks Donald.
On Fri, Jun 11, 2010 at 10:47 PM, Donald Woods dwo...@apache.org wrote:
Those versions on Mac
What problem did you encounter? Did you run the bootstrap build first?
mvn install -Dstage=bootstrap
mvn install
-Donald
On 6/11/10 12:33 PM, Vamsavardhana Reddy wrote:
Donald,
I am unable to build the tag starting with an empty maven repo. I tried
with Maven-2.2.1 as well as Maven-3.0-beta1. I am using Sun JDK
1.6.0_20. Which version of Sun JDK and Maven have you used to build the
tag?
On Fri, Jun 11, 2010 at 5:43 PM, Donald Woods dwo...@apache.org
mailto:dwo...@apache.org wrote:
+1 as I think the below issues are acceptable for a milestone
release.
Was able to build the tag and start the Tomcat Java EE 6 server.
-Donald
On 6/10/10 4:29 PM, Jarek Gawor wrote:
+0.5
M1 is affected by GERONIMO-5336. All services will most likely bind
to
the local loopback device instead of all network devices so you
won't
be able to access the console, etc. remotely. That can be fixed by
setting the ServerHostname property to 0.0.0.0 in
var/config/config-substitutions.properties file and also changing
the
following in var/config/config.xml:
attribute name=ServerUrltcp://${ServerHostname}:${ActiveMQPort
+
PortOffset}/attribute
to
attribute name=ServerUrltcp://localhost:${ActiveMQPort +
PortOffset}/attribute
Otherwise, without the second change an exception will be generated
at
server startup by the activemq plugin.
M1 also seems to be affected by GERONIMO-5334. But I only see that
error from time to time.
Jarek
On Wed, Jun 9, 2010 at 4:13 PM, Rick McGuire rick...@gmail.com
mailto:rick...@gmail.com wrote:
A new 3.0-M1 release candidate is ready for review. The LICENSE
problem has
been corrected and the missed testsuite updates that Jarek
noticed have been
included.
See the JIRA issues here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315090styleName=TextprojectId=10220
Staged to
https://repository.apache.org/content/repositories/orgapachegeronimo-046/
The main artifacts up for vote are the source release archives
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.zip
https://repository.apache.org/content/repositories/orgapachegeronimo-046/org/apache/geronimo/geronimo/3.0-M1/geronimo-3.0-M1-source-release.tar.gz
If you vote you should at least examine these and make sure
something
plausible builds from them.
The voting will be open a minimum of 72 hours.
[ ] +1 about time to push this out the door
[ ] 0 no opinion
[ ] -1 not this one (please explain why)
Rick
--
Vamsi
--
Vamsi
Re: [VOTE] Geronimo jaspi component 1.1
+1 On Thu, May 6, 2010 at 5:01 AM, David Jencks david_jen...@yahoo.com wrote: Please vote for the geronimo-jaspi 1.1 component. The major changes to this release are: - packaged as an osgi bundle - fairly non-functional classloading in 1.0 replaced by Rick's ProviderLocator that actually works in osgi. - dependencies upgraded to use bundleized dependencies. I spent some time trying to get the manifest entries to look reasonable to me. Since this is the first osgi release I put the package-version at 1.0. The import version ranges are _versionpolicy[$(version;==;$(@)),$(version;+;$(@)))/_versionpolicy for everything except the self-imports which are [1.0,1.1). I suppose it would have been better to use this version range for the jaspic spec as well, but I didn't. There's always something. Maybe next time the maven-bundle-plugin will do this for us. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-012/ tag is here: https://svn.apache.org/repos/asf/geronimo/components/jaspi/tags/geronimo-jaspi-1.1/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) thanks david jencks -- Vamsi
Re: [VOTE] transaction manager component 3.0 #2
+1 On Sat, May 8, 2010 at 6:00 AM, David Jencks david_jen...@yahoo.com wrote: Please vote for the geronimo transaction manager component consisting of the transaction manager and connector framework 3.0. The main changes in this release are: - connector 1.6 support - retry support in the transaction manager (not well tested yet). The difference between this and the first release attempt is a fix to handling of heuristic exceptions (GERONIMO-5289https://issues.apache.org/jira/browse/GERONIMO-5289 ) and some more tests, and a little more build cleanup. Due to the retry support the interfaces between these two jars have changed incompatibly, thus the jump to version 3. I've attempted to get reasonable osgi package version ranges in the manifests. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-021/ Tag is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-3.0/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) thanks david jencks -- Vamsi
Re: [VOTE] Release Geronimo Customized Tomcat 7.0.0.0 (Second Try)
On Wed, May 5, 2010 at 7:45 PM, Kevan Miller kevan.mil...@gmail.com wrote: On May 4, 2010, at 1:56 PM, Joe Bohn wrote: +1 (assuming the potential license issue mentioned below is not an issue) I was able to build and run the new tomcat image. The license issue pointed out last time is now resolved but there is one other potential issue. I noticed a number of files under jasper-el that are generated using JJTree JavaCC and so have the following header but no Apache license header. For example: /* Generated By:JJTreeJavaCC: Do not edit this line. ELParser.java */ Some other generated files include both a generated header and which is immediately followed by the Apache license header. This seems a little better to me. However, I see that we have released these without the Apache header in earlier versions (and Tomcat as well) - so I presume there must be some valid justification for not including an Apache License header in these files. Just pointing it out now in case it really needs some attention and has just escaped being noticed until now. Comments? I've certainly noticed them in the past... Machine generated files do not require license headers. So, IMO, these files are fine. I do have a question about the version #. IIUC, we are releasing 7.0.0 prior to the TC community. There may be fixes applied to the Tomcat dev tree prior to their 7.0 release. So, this release may not exactly match the functionality of the tomcat release. Is everyone evaluating that in their decision? --kevan I think there are two many zeros in the version number too. How about we use a version number similar to 6.0.18-G678601 like we have in G 2.x builds? -- Vamsi
Re: [ANNOUNCE] Ashish Jain - Geronimo's newest committer
Congratulations Ashish!! On Mon, Mar 15, 2010 at 3:14 AM, Joe Bohn joe.b...@earthlink.net wrote: All, Please join me in welcoming Ashish Jain as the newest committer on the Apache Geronimo project. The Geronimo PMC is excited that Ashish has accepted our invitation. Congratulations Ashish and keep up the good work! Joe -- Vamsi
Re: Welcome Forrest Ming Xia as a new committer
Congratulations Forrest!! On Tue, Mar 9, 2010 at 7:24 AM, Ivan xhh...@gmail.com wrote: I would like to welcome Forrest aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account (xiaming) was just created, so you should start seeing some commits from him soon. -- Ivan -- Vamsi
Re: [DISCUSS] Prepare Geronimo 2.1.5 release?
Will it be possible to upgrade the openejb version to 3.0.2 (to include the fix for OPENEJB-1005)? This is needed for the Tuscany plugin being developed for Geronimo that is right now using G 2.1.4. On Tue, Feb 2, 2010 at 2:09 PM, Jack Cai greensi...@gmail.com wrote: I'd like to see a new 2.1.5 release! Looking at the JIRAs below, sounds we need a new release of tranql? And we should verify/commit those JIRAs already having patches available so that we include them in the new release too. And also probably upgrade Tomcat to its latest release 6.0.24... Not sure whether people are also interested in upgrading Derby to 10.5.x. -Jack On Tue, Feb 2, 2010 at 4:24 PM, Jack Cai greensi...@gmail.com wrote: Hi Rex, I guess some people prefer plain text mails... Maybe we can create a wiki page for the new release and put the content there.. -Jack On Tue, Feb 2, 2010 at 4:06 PM, Rex Wang rwo...@gmail.com wrote: *Sorry for the BAD format in pure text.. please see the list below: 1. Informix tranql ra stuffs * *(1) patch available, need verify* GERONIMO-5055 Informix tranql XA 1.2 snapshot leads to weird admin console (Ashish Jain Ashish Jain) *(2) patch commintted to tranql trunk, need update geronimo pom to reference 1.2-SNAPSHOT?* GERONIMO-5044 Prepared Statement Cache to be made available in Informix XA tranql RA (Ashish Jain Ashish Jain) GERONIMO-5043 Informix IFX_XASPEC property to be made available to set through Administrative Console (Unassigned Ashish Jain) GERONIMO-5039 Informix Lock Mode Wait property (Unassigned Ashish Jain) *(3) should be easy to update.* GERONIMO-4929 Upgrade to latest tranql wrappers ( David Jencks David Jencks) *2. New feature and improvements (1) patch available, need verify* GERONIMO-5027 Redeploy option for farming (Ashish Jain Ashish Jain) *(2) No patch* GERONIMO-5002 Attribute clusterName required in config-substitution.properties for geronoimo 2.1.5(Unassigned Ashish Jain) *(3) fixes has been in 2.2, won't fix this in 2.1?* GERONIMO-4940 CLONE -Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing (G. 2.1.5) (Gianny Damour Gianny Damour) *3. Bugs * *(1) Patch available, need verify* GERONIMO-4983 In debug mode Properties file login module reurns loginsucceeded as true for non existent users and null password (Ashish Jain Ashish Jain) GERONIMO-4896 Commands to a Secure JMX Connector require the SSL keyStorePassword to be specified on command line (Ashish Jain Kevan Miller) GERONIMO-4892 Farm Deployment Error if deploy more than one applications ( Ashish Jain viola.lu) *(2) No patch* GERONIMO-4959 Remote Deploy Broken on Jetty ( Unassigned Kevan Miller) *3. Can be close or defer* *(1) can not reproduce, will close* GERONIMO-4718 Keystores portlet: Once unlocked for availability, keystore can not be locked (Unassigned Vamsavardhana Reddy) *(2) will defer to 2.1.6-SNAPSHOT if no updates* GERONIMO-4932 Initial Japanese translation (Kan Ogawa Kan Ogawa) GERONIMO-4688 hardcode port in plan.xml of plugin farming(Shawn Jiang Shawn Jiang) GERONIMO-4624 Improve deployment plan documentation (Unassigned Kevan Miller) 2010/2/2 Rex Wang rwo...@gmail.com [DISCUSS] Prepare Geronimo 2.1.5 release? Hi, We've had 80 more important fixes since 2.1.4 release and should get them out to our users. So I think we can start a new release from 2.1 branch. If no one volunteer, I would also like to be a release manager for 2.1.5 release. Since branch 2.1.x does not have genesis 2.x parent, shall I still be according to the old release process? There are still a few jiras that we need to deal with before we can go ahead with the release. Please get them from the bottom of http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.5+Release+Status page And I just made some categories and recorded the status on the jiras as follows, Any comments on this? 1. Informix tranql ra stuffs-- (1) patch available, need verify GERONIMO-5055 Informix tranql XA 1.2 snapshot leads to weird admin console Ashish Jain Ashish Jain (2) patch commintted to tranql trunk, need update geronimo pom to reference 1.2-SNAPSHOT? GERONIMO-5044 Prepared Statement Cache to be made available in Informix XA tranql RA Ashish Jain Ashish Jain GERONIMO-5043 Informix IFX_XASPEC property to be made available to set through Administrative Console Unassigned Ashish Jain GERONIMO-5039 Informix Lock Mode Wait property Unassigned Ashish Jain (3) should be easy to update. GERONIMO-4929 Upgrade to latest tranql wrappers David Jencks
Re: [VOTE] txmanager 2.1.3 2nd try
+1 On Sun, Sep 13, 2009 at 1:28 PM, David Jencks david_jen...@yahoo.comwrote: I fixed the build problem where we weren't building the test jars. I've set up a release candidate for the transaction manager and connector code 2.1.3, needed for geronimo 2.2: https://repository.apache.org/content/repositories/geronimo-staging-012/https://repository.apache.org/content/repositories/geronimo-staging-058/ Site staged at: http://people.apache.org/~djencks/staging-site/maven/components/txmanager/2.1.3/http://people.apache.org/%7Edjencks/staging-site/maven/txmanager/2.1.3/ There are some problems with the site (non-existent extra modules) but I'd rather fix them by hand if necessary than try to decipher how to get the site build to work automatically. This includes mostly some bug fixes in the pooling code that make tying a connection to a thread work. This should make it a lot easier to make cases where you open several connections and then start a user transaction work properly, as they can now share the same managed connection. [ ] +1 release it [ ] 0 dunno [ ] -1 don't release Vote open for 72 hours thanks david jencks -- Vamsi
[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.
Re: ApacheCon '09 Geronimo Track Call for Papers
Just wondering what happens to the proposals submitted through conference web site. On Fri, Jul 17, 2009 at 8:34 AM, Kevan Miller kevan.mil...@gmail.comwrote: This years ApacheCon US Conference (Oakland, CA, USA - Nov 2 to 6 2009) will include a 1/2 day Geronimo Track. This is a call for session proposals. Please have submissions in by Monday 12 Noon EDT. We need to finalize the session contents early next week. Apache Geronimo is a lightweight, flexible, component-based server for building dynamic application server environments. Geronimo plugins can be assembled into a fully compliant Java EE Server. However, it can be easily assembled into a server providing a subset of functionality or a minimal subset required to meet the requirements of a set of applications. In addition to the Apache Geronimo Server, the Geronimo project is also comprised of a number of subprojects: Development Tools, XBean, Yoko, GShell, JavaMail, Connector/Transaction, etc. Potential topics for the Geronimo Track include, but are in no way limited to: * Geronimo architecture, * Systems management, * Custom server assemblies, * Application development and user experiences, * OSGi Blueprint, * Kernel restructuring, * Java EE 6, * etc. Please submit Talk proposals on this mail thread. Each suggestion should include: * Title * Speaker name(s) * Abstract (Short overview of the talk contents) Thanks! Look forward to seeing you at ApacheCon! --kevan -- Vamsi
Re: ApacheCon '09 Geronimo Track Call for Papers
* Title Administering Apache Geronimo 2.x * Speaker name(s) Vamsavardhana Reddy Chillakuru * Abstract (Short overview of the talk contents) Apache Geronimo 2.x is certified Java Enterprise Edition 5.0 container suitable for everything from a development environment to enterprise-level deployments. Geronimo leverages many Apache projects, such as Tomcat, OpenEJB, ActiveMQ, Derby. This session will cover administering Geronimo from two points of view: configuring an existing Geronimo server directly through the powerful web based administration console or editing configuration files, and secondly through Geronimo plugins containing configuration information either used in a custom server assembly or installed into an existing server. Some of the topics covered are: - First steps in getting Geronimo ready for a production environment, - Administering embedded Tomcat, ActiveMQ, Derby. - Managing keys, digital certificates and configuring SSL. - Running a cluster of multiple server instances from the same installation. *Bio: Vamsavardhana Reddy Chillakuru a.k.a. Vamsi is an Advisory Software Engineer working with IBM India Private Limited since 1996 and has over 12 years experience in the IT industry. He is a committer on Apache Geronimo and Apache Tuscany projects and member of the Apache Geronimo PMC. On Mon, Jul 20, 2009 at 10:42 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jul 20, 2009, at 9:33 AM, jean-frederic clere wrote: On 07/20/2009 09:18 AM, Vamsavardhana Reddy wrote: Just wondering what happens to the proposals submitted through conference web site. They can be used too if Geronimo decides to do so. Vamsi, You should post your proposal(s) here, for consideration in the Geronimo track... Will give this some more time... --kevan -- Vamsi
Re: ApacheCon '09 Geronimo Track Call for Papers
* Title Securing Java EE 5.0 Applications with Apache Geronimo * Speaker name(s) Vamsavardhana Reddy Chillakuru * Abstract (Short overview of the talk contents) Security is always a high priority in application development, and with complex applications the task becomes even more daunting. While the Java EE specification, JAAS and JACC provide a step in the right direction, every application server is free to implement container security differently. Apache Geronimo, a JEE 5.0 certified container, enables storing user credentials in a variety of data stores viz., simple text files, a database, an LDAP server and digital certificates. In this session we see how these data stores can be used to configure application security and how the necessary infrastructure can be run in Apache Geronimo itself. The session presents: a) Prerequisites for PropertiesFile, Database, LDAP and CertificatePropertiesFile realms and shows how to create these realms. b) Advanced features like auditing, lockout after repeated failures, prinicipal wrapping, single-sign-on, etc. c) Configuring Web/EJB/EAR application security. After completing this session, the audience will gain knowledge on their choice of data stores for user credentials, create various security realms and deployment plans necessary to secure their applications with Geronimo. * Bio: Vamsavardhana Reddy Chillakuru a.k.a. Vamsi is an Advisory Software Engineer working with IBM India Private Limited since 1996 and has over 12 years experience in the IT industry. He is a committer on Apache Geronimo and Apache Tuscany projects and member of the Apache Geronimo PMC. He received his B.Stat.(Hons.) and M.Stat. degrees from Indian Statistical Institute, Kolkata, India in the years 1994 and 1996 respectively. On Mon, Jul 20, 2009 at 10:42 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jul 20, 2009, at 9:33 AM, jean-frederic clere wrote: On 07/20/2009 09:18 AM, Vamsavardhana Reddy wrote: Just wondering what happens to the proposals submitted through conference web site. They can be used too if Geronimo decides to do so. Vamsi, You should post your proposal(s) here, for consideration in the Geronimo track... Will give this some more time... --kevan -- Vamsi
Re: ApacheCon '09 Geronimo Track Call for Papers
* Title Load balancing and high-availability with Geronimo clusters * Speaker name(s) Vamsavardhana Reddy Chillakuru * Abstract (Short overview of the talk contents) Apache Geronimo 2.x is certified Java Enterprise Edition 5.0 container suitable for everything from a development environment to enterprise-level deployments. Geronimo can be clustered in different ways, for e.g. using clustering capabilities provided by Tomcat, using the WADI integration of Geronimo, etc. This session details on various clustering options available with Geronimo and configuring load-balancing and failover of web applications using mod_jk Apache HTTP Server. After completing this session, the audience will be familiar with the clustering and farming features provided by Geronimo, running multiple instances of Geronimo server from the same installation, preparing their applications for deployment on the cluster and know how to configure Geronimo clusters to suit their needs. *Bio: Vamsavardhana Reddy Chillakuru a.k.a. Vamsi is an Advisory Software Engineer working with IBM India Private Limited since 1996 and has over 12 years experience in the IT industry. He is a committer on Apache Geronimo and Apache Tuscany projects and member of the Apache Geronimo PMC. On Mon, Jul 20, 2009 at 10:42 PM, Kevan Miller kevan.mil...@gmail.comwrote: On Jul 20, 2009, at 9:33 AM, jean-frederic clere wrote: On 07/20/2009 09:18 AM, Vamsavardhana Reddy wrote: Just wondering what happens to the proposals submitted through conference web site. They can be used too if Geronimo decides to do so. Vamsi, You should post your proposal(s) here, for consideration in the Geronimo track... Will give this some more time... --kevan -- Vamsi
Web app clustering with WADI in Geronimo Tomcat 2.1.4 broken?
I am trying to deploy a clustered web application in Geronimo Tomcat 2.1.4. I have added distributable/ in web.xml and clustering-wadi/ in geronimo-web.xml. When I deploy the application, I am getting the following deployment error: xml problem for web app . org.apache.geronimo.common.DeploymentException: xml problem for web app . at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:318) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule(TomcatModuleBuilder.java:207) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:179) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:307) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:227) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors: error: cvc-complex-type.2.4a: Expected elements 'work-...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cluster...@http://geronimo.apache.org/xml/ns/j2ee/application-2.0 web-contai...@http://geronimo.apache.org/xml/ns/naming-1.2 h...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cross-cont...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 disable-cook...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 valve-ch...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 listener-ch...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 tomcat-re...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 mana...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 clus...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 abstract-naming-en...@http://geronimo.apache.org/xml/ns/naming-1.2 ejb-...@http://geronimo.apache.org/xml/ns/naming-1.2 ejb-local-...@http://geronimo.apache.org/xml/ns/naming-1.2 service-...@http://geronimo.apache.org/xml/ns/naming-1.2 resource-...@http://geronimo.apache.org/xml/ns/naming-1.2 resource-env-...@http://geronimo.apache.org/xml/ns/naming-1.2 message-destinat...@http://geronimo.apache.org/xml/ns/naming-1.2 security-realm-n...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 serv...@http://geronimo.apache.org/xml/ns/deployment-1.2 persiste...@http://java.sun.com/xml/ns/persistence' instead of 'clustering-w...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here Descriptor: xml-fragment xmlns:tom=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1; !--web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1; xmlns:app=http://geronimo.apache.org/xml/ns/j2ee/application-2.0-- dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; dep:moduleId dep:groupIdpackt-samples/dep:groupId dep:artifactIdhelloworld-cluster/dep:artifactId dep:version1.0/dep:version dep:typewar/dep:type /dep:moduleId dep:dependencies/ /dep:environment tom:context-root/helloworld-cluster/tom:context-root tom:clustering-wadi/ /xml-fragment at org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:187) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:312) ... 17 more Appears like the deployer is not liking the tag clustering-wadi/. I do have org.apache.geronimo.configs/tomcat6-clustering-wadi/2.1.4/car and org.apache.geronimo.configs/tomcat6-clustering-builder-wadi/2.1.4/car configurations started before deploying the web application. I tried deploying the same application in Geronimo Tomcat 2.2-SNAPSHOT server and got the same error. Is the WADI clustering broken in Geronimo Tomcat 2.1.4 and 2.2-SNAPSHOT? The application deploys and runs as expected in Geronimo Jetty 2.1.4.
[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.
Dependency injection in HttpSessionBindingListener
As part of SCA JavaEE Integration, I am looking at dependency injection into HttpSessionBindingListener's in web apps. HttpSessionBindingListener is different from other listeners in that HttpSessionBindingListener need not be specified in web.xml. HttpSessionBindingListener gets activated automatically when an object of that type (implementing HttpSessionBindingListener actually) is bound to HttpSession. Other listeners are specified in web.xml and their instantiation is done by the web container. Because of this, at deployment time, the web builder does not even know if there is any HttpSessionBindingListener that it should process to support dependency injection. Any thing I am failing to see? Vamsi
Re: Dependency injection in HttpSessionBindingListener
Section 5.4.1 in SCA JEE Integration spec v1.0, the table at line 484 lists HttpSessionBindingListener. Do you think we should get rid of that entry? ++Vamsi On Thu, Dec 11, 2008 at 11:15 PM, David Jencks david_jen...@yahoo.comwrote: Why do you think that HttpSessionBindingListeners should support dependecy injection? They aren't managed objects AFAICT and as you state. Is there something I've overlooked in the spec? thanks david jencks On Dec 11, 2008, at 7:12 AM, Vamsavardhana Reddy wrote: As part of SCA JavaEE Integration, I am looking at dependency injection into HttpSessionBindingListener's in web apps. HttpSessionBindingListener is different from other listeners in that HttpSessionBindingListener need not be specified in web.xml. HttpSessionBindingListener gets activated automatically when an object of that type (implementing HttpSessionBindingListener actually) is bound to HttpSession. Other listeners are specified in web.xml and their instantiation is done by the web container. Because of this, at deployment time, the web builder does not even know if there is any HttpSessionBindingListener that it should process to support dependency injection. Any thing I am failing to see? Vamsi -- Vamsi
Re: java.lang.LinkageError: Class org/apache/xbean/finder/ClassFinder violates loader constraints
Another thing I am noticing is that module.getClassFinder().getClass().getClassLoader() returns configs/j2ee-deployer/2.1.3/car classLoader, whereas ClassFinder.class.getClassLoader() return configs/openejb/2.1.3/car classLoader. On Tue, Nov 18, 2008 at 4:53 PM, Vamsavardhana Reddy [EMAIL PROTECTED]wrote: I am trying to invoke ClassFinder code from TuscanyModuleBuilderExtension I am creating for the Tuscany plugin. I have the following code ClassFinder cf = module.getClassFinder(); ListClass annotatedClasses = cf.findAnnotatedClasses(org.osoa.sca.annotations.Reference.class); The call in the second line above is throwing a LinkageError. Stack trace is given below. java.lang.LinkageError: Class org/apache/xbean/finder/ClassFinder violates loader constraints at org.apache.geronimo.tuscany.TuscanyModuleBuilderExtension.addGBeans(TuscanyModuleBuilderExtension.java:154) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:497) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) My guess is that it is some class loader issue. Any ideas on how to fix this problem? -- Vamsi -- Vamsi
Re: java.lang.LinkageError: Class org/apache/xbean/finder/ClassFinder violates loader constraints
The openejb classloader is getting into the way because of the plugin's dependency on j2ee-corba-yoko/xxx/car. This is a dependency that is not required as of now (may be it will be reuquired if ejb binding is used). Removing this dependency got me past the linkage error. ++Vamsi On Fri, Dec 5, 2008 at 11:30 PM, David Jencks [EMAIL PROTECTED]wrote: I think I ran into this problem while changing trunk to try to use transitive dependencies and introduced the xbean-finder classloader plugin to solve it. I think you'll have to move your development to trunk or backport the fix. Personally I'd use trunk. thanks david jencks On Dec 5, 2008, at 3:27 AM, Vamsavardhana Reddy wrote: Another thing I am noticing is that module.getClassFinder().getClass().getClassLoader() returns configs/j2ee-deployer/2.1.3/car classLoader, whereas ClassFinder.class.getClassLoader() return configs/openejb/2.1.3/car classLoader. On Tue, Nov 18, 2008 at 4:53 PM, Vamsavardhana Reddy [EMAIL PROTECTED]wrote: I am trying to invoke ClassFinder code from TuscanyModuleBuilderExtension I am creating for the Tuscany plugin. I have the following code ClassFinder cf = module.getClassFinder(); ListClass annotatedClasses = cf.findAnnotatedClasses(org.osoa.sca.annotations.Reference.class); The call in the second line above is throwing a LinkageError. Stack trace is given below. java.lang.LinkageError: Class org/apache/xbean/finder/ClassFinder violates loader constraints at org.apache.geronimo.tuscany.TuscanyModuleBuilderExtension.addGBeans(TuscanyModuleBuilderExtension.java:154) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:497) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) My guess is that it is some class loader issue. Any ideas on how to fix this problem? -- Vamsi -- Vamsi -- Vamsi
[jira] Created: (GERONIMO-4446) ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3
ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3 --- Key: GERONIMO-4446 URL: https://issues.apache.org/jira/browse/GERONIMO-4446 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty Affects Versions: 2.1.3, 2.2 Environment: Geronimo Jetty 2.1.3, Windows XP, Sun JDK 1.5.0_13 Reporter: Vamsavardhana Reddy I have a web application with a ServletRequestListener and a ServletRequestAttributeListener. In ServletRequestListener.requestInitialized() I am adding an attribute hellotxt to the servlet request. In ServletRequestAttributeListener.attributeAdded(), I am appending some text to the same attribute. This application deployed in G Tomcat 2.1.3 server, is working as expected and attributeAdded() method is called for hellotxt attribute. If the same application is deployed in G Jetty 2.1.3 server, attributeAdded() method is not getting called for hellotxt attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4446) ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with G Tomcat 2.1.3
[
https://issues.apache.org/jira/browse/GERONIMO-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated GERONIMO-4446:
--
Attachment: helloworld-listener.war
helloworld-listener.war: Sample application to demonstrate the problem.
Deploy the application and access http://localhost:8080/helloworld-listener .
Notice that on G Tomcat 2.1.3, the page displays
{code}
Request initialized. Adding hellotxt attribute...
hellotxt attribute added.
{code}
\\
Notice that on G Jetty 2.1.3, the page displays
{code}
Request initialized. Adding hellotxt attribute...
{code}
ServletRequestAttributeListener does not work with G Jetty 2.1.3, works with
G Tomcat 2.1.3
---
Key: GERONIMO-4446
URL: https://issues.apache.org/jira/browse/GERONIMO-4446
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Jetty
Affects Versions: 2.1.3, 2.2
Environment: Geronimo Jetty 2.1.3, Windows XP, Sun JDK 1.5.0_13
Reporter: Vamsavardhana Reddy
Attachments: helloworld-listener.war
I have a web application with a ServletRequestListener and a
ServletRequestAttributeListener. In
ServletRequestListener.requestInitialized() I am adding an attribute
hellotxt to the servlet request. In
ServletRequestAttributeListener.attributeAdded(), I am appending some text to
the same attribute. This application deployed in G Tomcat 2.1.3 server, is
working as expected and attributeAdded() method is called for hellotxt
attribute. If the same application is deployed in G Jetty 2.1.3 server,
attributeAdded() method is not getting called for hellotxt attribute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Subscribe mail list dev@geronimo.apache.org
On Thu, Dec 4, 2008 at 6:02 PM, Jason Warner [EMAIL PROTECTED] wrote: I'm not sure if we should have a Post a message option. It was my understanding that our mailing list is setup such that your message won't go through unless you are subscribed to the list. If this was the case, we would not have seen the mail that initiated this thread :) I think putting a Post a message option will result in a lot of people attempting to send a message to the list without subscribing first, and being frustrated that their message is never answered. Of course, if I'm wrong about how the list works and you don't need to subscribe first then I'm completely fine with this. Can anyone verify? Thanks! On Thu, Dec 4, 2008 at 1:46 AM, Vamsavardhana Reddy [EMAIL PROTECTED]wrote: I removed the hyperlinks on user@, dev@ and [EMAIL PROTECTED] I have also added a Post a message link to user@ and [EMAIL PROTECTED] ++Vamsi On Thu, Dec 4, 2008 at 11:25 AM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I think the wiki automatically puts a hyperlink on e-mail addresses. We should remove the hyperlinks on the e-mail address and also provide an additional link Send message to [EMAIL PROTECTED] etc., so that users are not confused. If no one has any objections, I will go ahead and update the page. ++Vamsi On Thu, Dec 4, 2008 at 11:02 AM, Jack Cai [EMAIL PROTECTED] wrote: This actually reveals a problem in the instruction page: http://geronimo.apache.org/mailing-lists.html. I was a little confused too when I made the subscription. I'd suggest to remove the hyperlinks of [EMAIL PROTECTED], dev@geronimo.apache.org and [EMAIL PROTECTED], so that users will only click the subscirbe/unsubscribe links. Makes sense? -Jack 2008/12/3 Vamsavardhana Reddy [EMAIL PROTECTED] Send mail to [EMAIL PROTECTED] . ++Vamsi On Wed, Dec 3, 2008 at 11:23 AM, han hongfang [EMAIL PROTECTED]wrote: Hi, I'm interested with Geronimo development and already had Apache CLA signed. I want to subscribe mail list [EMAIL PROTECTED] Thanks! Best regard, Han Hong Fang -- Vamsi -- Vamsi -- Vamsi -- ~Jason Warner -- Vamsi
Re: Tuscany Geronimo integration and the SCA JEE spec
I am able to install the plugin on a clean Geronimo Tomcat v2.1.3 server following the instructions given in the wiki [1]. I have also verified that all samples run as expected. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo ++Vamsi On Wed, Dec 3, 2008 at 12:19 AM, mobyjobs [EMAIL PROTECTED] wrote: Thanks for help. The issue with my setup turned out was wrong tuscany-core version. I was using latest tuscany-core.1.4-SNAPSHOT.jar. As I thought the fix in tuscany-core.1.3.jar submitted in the Jira was also applied to the tuscany branch. But it looks like I needed to change version from 1.4-SNAPSHOT to 1.3 and then change tuscany-core.1.3.jar with the one in Jira. Now I am trying example and to see at least RIM and web bindings are working (which is what I am looking for at this time). -Jamil Kevan Miller wrote: Hi JS, Vamsi generated some doc -- http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo Although it's not working for me, at the moment... Vamsi, do those instructions work for you? More comments below... -- View this message in context: http://www.nabble.com/Tuscany-Geronimo-integration-and-the-SCA-JEE-spec-tp19794900s134p20798460.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- Vamsi
Re: Subscribe mail list dev@geronimo.apache.org
I think the wiki automatically puts a hyperlink on e-mail addresses. We should remove the hyperlinks on the e-mail address and also provide an additional link Send message to [EMAIL PROTECTED] etc., so that users are not confused. If no one has any objections, I will go ahead and update the page. ++Vamsi On Thu, Dec 4, 2008 at 11:02 AM, Jack Cai [EMAIL PROTECTED] wrote: This actually reveals a problem in the instruction page: http://geronimo.apache.org/mailing-lists.html. I was a little confused too when I made the subscription. I'd suggest to remove the hyperlinks of [EMAIL PROTECTED], dev@geronimo.apache.org and [EMAIL PROTECTED], so that users will only click the subscirbe/unsubscribe links. Makes sense? -Jack 2008/12/3 Vamsavardhana Reddy [EMAIL PROTECTED] Send mail to [EMAIL PROTECTED] . ++Vamsi On Wed, Dec 3, 2008 at 11:23 AM, han hongfang [EMAIL PROTECTED]wrote: Hi, I'm interested with Geronimo development and already had Apache CLA signed. I want to subscribe mail list [EMAIL PROTECTED] Thanks! Best regard, Han Hong Fang -- Vamsi -- Vamsi
Re: Subscribe mail list dev@geronimo.apache.org
I removed the hyperlinks on user@, dev@ and [EMAIL PROTECTED] I have also added a Post a message link to user@ and [EMAIL PROTECTED] ++Vamsi On Thu, Dec 4, 2008 at 11:25 AM, Vamsavardhana Reddy [EMAIL PROTECTED]wrote: I think the wiki automatically puts a hyperlink on e-mail addresses. We should remove the hyperlinks on the e-mail address and also provide an additional link Send message to [EMAIL PROTECTED] etc., so that users are not confused. If no one has any objections, I will go ahead and update the page. ++Vamsi On Thu, Dec 4, 2008 at 11:02 AM, Jack Cai [EMAIL PROTECTED] wrote: This actually reveals a problem in the instruction page: http://geronimo.apache.org/mailing-lists.html. I was a little confused too when I made the subscription. I'd suggest to remove the hyperlinks of [EMAIL PROTECTED], dev@geronimo.apache.org and [EMAIL PROTECTED], so that users will only click the subscirbe/unsubscribe links. Makes sense? -Jack 2008/12/3 Vamsavardhana Reddy [EMAIL PROTECTED] Send mail to [EMAIL PROTECTED] . ++Vamsi On Wed, Dec 3, 2008 at 11:23 AM, han hongfang [EMAIL PROTECTED]wrote: Hi, I'm interested with Geronimo development and already had Apache CLA signed. I want to subscribe mail list [EMAIL PROTECTED] Thanks! Best regard, Han Hong Fang -- Vamsi -- Vamsi -- Vamsi
Re: Tuscany Geronimo integration and the SCA JEE spec
On Tue, Dec 2, 2008 at 9:14 PM, Kevan Miller [EMAIL PROTECTED] wrote: Hi JS, Vamsi generated some doc -- http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo Although it's not working for me, at the moment... Vamsi, do those instructions work for you? Yes, those instructions work for me. What is the error you are seeing? More comments below... On Dec 1, 2008, at 12:40 PM, mobyjobs wrote: I tried to install the plug in but seeing missing dependency message (as bellow), not sure what I have missed: C:\geronimo-tomcat6-javaee5-2.1.3\bindeploy --user system --password manager in stall-plugin i:\workspaces\workspaceGME\trunk\tuscanyPlugin\tuscany\tuscany-tomc at\target\tuscany-tomcat-1.0-SNAPSHOT.car Using GERONIMO_BASE: C:\geronimo-tomcat6-javaee5-2.1.3 Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.1.3 Using GERONIMO_TMPDIR: c:\tmp Using JRE_HOME:C:\Program Files\Java\jdk1.5.0_15\jre Checking for status every 1000ms: Installation FAILED: Configuration org.apache.geronimo.plugins/tuscany-tomcat/1.0-SNAPSHOT/car is already installed. Missing dependency: org.apache.geronimo.plugins/tuscany-tomcat/1.0-SNAPSHOT/car I have checked I have all the dependency files in repository; Here are the steps I followed; - Installed geronimo-tomcat6-javaee5-2.1.3-bin to c:\ - changed .m2\settings.xml filed to set repository in geronimo-tomcat6-javaee5-2.1.3 as the default location: i.e. localRepositoryc:/geronimo-tomcat6-javaee5- 2.1.3/repository/; You should not be using the geronimo server's repository in this manner -- it's not intended to be a generic maven repository. Just use the default location for your local maven repository (i.e. .m2\repository). Geronimo will copy the necessary artifacts into the server's repository as needed. Your server is confused because it's trying to install tuscany-tomcat, but there are already artifacts in repository/org/apache/geronimo/plugins/tuscany-tomcat directory. - checkout out code for geronimo plug-in code from https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/ - build the plug-in using 'mvn install' ; build was successful and all the files copied to repository. 3. Deploy plugin using the command g_install_dir\bin\deploy.bat install-plugin tuscany tomcat\target\tuscany-tomcat-1.0-SNAPSHOT.car After building, I'd use the admin console to install the plugin: http://localhost:8080/console/portal/Applications/Plugins Click Show Plugins in selected repository, select Geronimo :: Tuscany Plugin for Geronimo Tomcat and click the install button (scroll down to the bottom of the screen), then click install again. This should installs the Tuscany plugin and dependencies into my 2.1.4-SNAPSHOT server. I will add these instructions to the wiki page. You'll also need the config.xml changes mentioned in http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo Even with these, things don't seem to be working. I can deploy the sample jsp app, but it doesn't seem to be working... Hoping that Vamsi can comment. Are you using Geronimo v2.1.3? That is the version on which I have verified that the instructions work. --kevan -- Vamsi
Re: Subscribe mail list dev@geronimo.apache.org
Send mail to [EMAIL PROTECTED] . ++Vamsi On Wed, Dec 3, 2008 at 11:23 AM, han hongfang [EMAIL PROTECTED] wrote: Hi, I'm interested with Geronimo development and already had Apache CLA signed. I want to subscribe mail list [EMAIL PROTECTED] Thanks! Best regard, Han Hong Fang -- Vamsi
Tuscany Plugin: SCA reference and property injection into EJBs
I am looking at SCA reference and property injection into EJB fields annotated with @Reference and @Property annotations in an SCA enhanced EJB application. I have created a TuscanyModuleBuilderExtension (MBE) that processes the EJB module built by EJBModuleBuilder. What the MBE does for each injection point is to add a ResourceEnvReferenceInfo object to the EnterpriseBeanInfo.JndiEncInfo and add the object to be injected into the bean's context. Essentially it is mimicking how an @Resource EJB annotation is handled by the EJBModuleBuilder. I see that this approach works. But it may not be the right or the best approach. I would like your comments on this approach, point me to any potentail pit falls that I am not seeing right now and suggest any alternatives. ++Vamsi
Tuscany Plugin for Geronimo UPDATE: Reference and property injection in servlets
We have reference and property injection working for servlets. See [1] for instructions for installing the plugin and running a sample application. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo -- Vamsi
