[jira] Commented: (AMQ-736) Broker is not delivering all messages to slow consumer
[ https://issues.apache.org/activemq/browse/AMQ-736?page=comments#action_36232 ] james strachan commented on AMQ-736: Have committed your test case - many thanks for that - its here... https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/bugs/SlowConsumerTest.java I made one or two minor changes (using a name local to the test case for the queue to avoid tests treading on each others toes and failing rather than hanging if enough messages are not returned in time). The test case works fine on OS X - both before my changes and after them - before applying your patch to fix the test case. Will investigate further Broker is not delivering all messages to slow consumer -- Key: AMQ-736 URL: https://issues.apache.org/activemq/browse/AMQ-736 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: Linux/Windows Java 1.5.0_06 Reporter: Danielius Jurna Priority: Critical Attachments: SlowConsumerTest.java, slowConsumer.patch When producer produces more messages than consumer can handle, after some time some messages are not delivered to the consumer (they are just skipped). To get those messages from the broker, you need to reconnect the consumer. It seems that this bug only occures if message persistance is turned on in the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-522) get ProxyConnectorTest to work
[ https://issues.apache.org/activemq/browse/AMQ-522?page=all ] james strachan updated AMQ-522: --- Version: 4.0 get ProxyConnectorTest to work -- Key: AMQ-522 URL: https://issues.apache.org/activemq/browse/AMQ-522 Project: ActiveMQ Type: Bug Components: Test Cases Versions: 4.0 Environment: Linux, jdk 1.5 Reporter: Fritz Oconer Assignee: Adrian Co Running this test case hangs in iago.simulalabs.com. The test log file is empty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-610) fix the test case FanoutTransportBrokerTest which is failing now due to the fix for AMQ-607 by making the open of the socket occur in the start() method
[ https://issues.apache.org/activemq/browse/AMQ-610?page=all ] james strachan updated AMQ-610: --- Version: 4.0 fix the test case FanoutTransportBrokerTest which is failing now due to the fix for AMQ-607 by making the open of the socket occur in the start() method Key: AMQ-610 URL: https://issues.apache.org/activemq/browse/AMQ-610 Project: ActiveMQ Type: Bug Components: Test Cases Versions: 4.0 Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-665) Error while using management interface on messages with binary data.
[ https://issues.apache.org/activemq/browse/AMQ-665?page=all ] james strachan updated AMQ-665: --- Version: 4.0 Error while using management interface on messages with binary data. Key: AMQ-665 URL: https://issues.apache.org/activemq/browse/AMQ-665 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Bruce Mitchener Priority: Minor I'm sending binary data through STOMP (with a content-length header). When I go into jconsole and try to use 'browse' to view the message, I get this exception on the server side: javax.management.openmbean.OpenDataException: Argument's element itemValues[7]=[EMAIL PROTECTED] is not a valid value for this item (itemName=BodyPreview,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.Byte;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.Byte))). at javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:145) at javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:190) at org.apache.activemq.broker.jmx.OpenTypeSupport.convert(OpenTypeSupport.java:253) at org.apache.activemq.broker.jmx.DestinationView.browse(DestinationView.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1341) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:782) 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-626) fix test cases MultipleTestsWithSpring*Test which seem to fail due to another test keeping a broker/journal open
[ https://issues.apache.org/activemq/browse/AMQ-626?page=all ] james strachan updated AMQ-626: --- Version: 4.0 fix test cases MultipleTestsWithSpring*Test which seem to fail due to another test keeping a broker/journal open Key: AMQ-626 URL: https://issues.apache.org/activemq/browse/AMQ-626 Project: ActiveMQ Type: Bug Components: Test Cases Versions: 4.0 Reporter: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-682) several functions spelled wrong, impairs code readability
[ https://issues.apache.org/activemq/browse/AMQ-682?page=all ] james strachan updated AMQ-682: --- Version: 4.0 several functions spelled wrong, impairs code readability - Key: AMQ-682 URL: https://issues.apache.org/activemq/browse/AMQ-682 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Andrew Lusk Priority: Trivial Original Estimate: 1 hour Remaining: 1 hour In the OpenWire marshalling code / scripts for Java, s/Unmarsal/Unmarshal/. In OpenWireFormat.java, WireFormatNegotiator.java, and OpenWireFormatFactory.java, s/negociat/negotiate/. Nitpicks, yes, but the cause of some wasted time looking around for functions that didn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-539) TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkUsingTcpTest FAILED
[ https://issues.apache.org/activemq/browse/AMQ-539?page=all ] james strachan updated AMQ-539: --- Version: 4.0 TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkUsingTcpTest FAILED Key: AMQ-539 URL: https://issues.apache.org/activemq/browse/AMQ-539 Project: ActiveMQ Type: Bug Components: Test Cases Versions: 4.0 Reporter: Hiram Chirino -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
When sending patches please tick the Patch Attached checkbox in JIRA
We now have a custom JIRA field to indicate issues which have attached patches. Please if you are submitting a patch can you check this box as it will help us to prioritise your issue. I've updated the contribution guide to reflect this http://activemq.org/site/contributing.html -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (AMQ-711) commit() should not be called while in auto-commit mode
[ https://issues.apache.org/activemq/browse/AMQ-711?page=all ] Hiram Chirino resolved AMQ-711: --- Fix Version: 4.0.1 4.1 Resolution: Fixed Applied patch.. Thanks Niklas! commit() should not be called while in auto-commit mode --- Key: AMQ-711 URL: https://issues.apache.org/activemq/browse/AMQ-711 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 RC2, 4.0 RC3 Environment: Windows NT SQLServer with jtds driver. Reporter: Niklas Käck Fix For: 4.1, 4.0.1 Attachments: activemq.xml Original Estimate: 1 day Remaining: 1 day Unable to startup Broker Service. ERROR BrokerService - Failed to start ActiveMQ JMS Message Broker. Reason: java.io.IOException: commit() should not be called while in auto-commit mode. Stacktrace: java.io.IOException: commit() should not be called while in auto-commit mode. at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:42) at org.apache.activemq.store.jdbc.TransactionContext.close(TransactionContext.java:125) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.createAdapter(JDBCPersistenceAdapter.java:253) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getAdapter(JDBCPersistenceAdapter.java:213) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:139) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:215) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:907) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:867) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:453) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:362) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:43) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1058 ) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:158) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:48) at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:40) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56) at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:81) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:46) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:64) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:49) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:45) 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.activemq.console.Main.runTaskClass(Main.java:135) at org.apache.activemq.console.Main.main(Main.java:67) Caused by: java.sql.SQLException: commit() should not be called while in auto-commit mode. at net.sourceforge.jtds.jdbc.ConnectionJDBC2.commit(ConnectionJDBC2.java:1878) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:203) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:203) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199) at
[jira] Commented: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36239 ]
David Jencks commented on AMQ-731:
--
Resin's tx implementation is wrong. suspend is only supposed to remove the
thread/tx association, not change what resources are enrolled in the tx.
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at com.caucho.jca.WorkThread.run(WorkThread.java:99)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
at java.lang.Thread.run(Thread.java:595)
Note that the ackType is a poison ack. This shouldn't be the case as the
configuration (below) on the resource adapter and the managed connection
[jira] Commented: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36240 ]
Christopher G. Stach II commented on AMQ-731:
-
How would a single connection be used for multiple transaction branches if end
is never called with TMSUSPEND?
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at com.caucho.jca.WorkThread.run(WorkThread.java:99)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
at java.lang.Thread.run(Thread.java:595)
Note that the ackType is a poison ack. This shouldn't be the case as the
configuration (below) on the resource adapter and the managed connection
factory both specify
[jira] Updated: (GERONIMO-1523) Openejb corba class is included (serialized) in all enc contexts
[ http://issues.apache.org/jira/browse/GERONIMO-1523?page=all ] David Jencks updated GERONIMO-1523: --- Fix Version: 1.1 not sure when, but this got ported to 1.1 and new 1.2 Openejb corba class is included (serialized) in all enc contexts Key: GERONIMO-1523 URL: http://issues.apache.org/jira/browse/GERONIMO-1523 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.2, 1.1 If you build a configuration for a j2ee module while the openejb deployer config is loaded, the enc context will include a serialized CORBAHandleDelegate$HandleDelegateReferece. Then the enc won't deserialize unless the openejb-core jar is in the classpath. This sorta impedes smaller servers. I'm going to instead use the look it up from a gbean trick we use the the orb and resources so all that gets serialized is a geronimo naming reference class and an object name. This will modify at least methods/fields EarContext, EarConfigBuilder, AppClientModuleBuilder, and OpenEJBReferenceBuilder, EJBReferenceBuilder, and RefContext. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem comiting on trunk...
On 6/4/06, Jason Dillon [EMAIL PROTECTED] wrote: snip subversion/libsvn_client/commit.c:873: (apr_err=175002) svn: Commit failed (details follow): subversion/libsvn_ra_dav/util.c:296: (apr_err=175002) svn: MKACTIVITY of '/repos/asf/!svn/act/2d4850ad-6c15-0410-93f7- d4cfeea00f44': 403 Forbidden (http://svn.apache.org) subversion/clients/cmdline/util.c:407: (apr_err=175002) svn: Your commit message was left in a temporary file: subversion/clients/cmdline/util.c:407: (apr_err=175002) svn:'/Users/jason/ws/apache/geronimo/trunk/svn-commit.2.tmp' /snip ... I'm not really even sure what that svn error message is trying to tell me, short of a 403 Forbidden... Possibly that the change wasn't discussed so the server rejected it ;) Serious now. It might've been because you attempted to commit your changes to http://svn.apache.org rather than https://svn.apache.org. It's a shot in the dark so take it with a pinch of salt ;) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: I think groupIds in m2 build need improvement
Hi Dave, I don't have preference for anything wrt the naming so I'm +0 for the change if it suits you. We'll see how it goes once the conversion's done. At the moment I think we should rather focus on achieving the final result (and to be honest the change doesn't buy us much) but don't want to hinder introducing it only because I haven't completely grasped it yet. Jacek On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks -- Jacek Laskowski http://www.laskowski.net.pl
Re: [Vote: RTC] needed for eclipse plugin
On 6/5/06, John Sisson [EMAIL PROTECTED] wrote: The three votes did not comply with the patched and tested requirement of the RTC rules. Correct (that's the topic of another thread to change it). Those RTC rules were established by Ken, the PMC Chair. The PMC Chair has the power to establish new rules and procedures ( see http://www.apache.org/foundation/how-it-works.html#pmc ) and I don't believe the PMC should/can change the rules that were established by the PMC Chair without the PMC Chair's agreement. Also, Greg Stein (ASF Chairman) also mentioned that we should discuss making changes official with Ken.. http://marc.theaimsgroup.com/?l=geronimo-devm=114850042818334w=2 Thanks for the explanation. It seems I need to spend some time to get it. John Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Problem comiting on trunk...
Possibly that the change wasn't discussed so the server rejected it ;) Um... ya... does the community expect that all changes, even the most trivial need to be discussed, agreed up, documented in triplicate and faxed to the four corners of the earth. Hope not... else we are not going to get much done. ;-) Serious now. It might've been because you attempted to commit your changes to http://svn.apache.org rather than https://svn.apache.org. It's a shot in the dark so take it with a pinch of salt ;) I think you are right, I must have checked out the tree w/http not https. Thanks :-) --jason
Re: Problem comiting on trunk...
On 6/5/06, Jason Dillon [EMAIL PROTECTED] wrote: Um... ya... does the community expect that all changes, even the most trivial need to be discussed, agreed up, documented in triplicate and faxed to the four corners of the earth. Hope not... else we are not going to get much done. ;-) Well, it's personal matter which change is trival and which is not, isn't it? So, your last resort would be to *not* introduce trivial changes ;) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Problem comiting on trunk...
Well, it's personal matter which change is trival and which is not, isn't it? So, your last resort would be to *not* introduce trivial changes ;) I guess... I think we need to change minotaur refs to people... as infra has stated that the CNAME for the service should be used instead of the hostname, which I am in complete agreement with. So, do we need to vote on this? Or should we just change it? --jason
Re: Retrotranslator KICKS ASS!!!
On 6/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Do you happen to know of any examples where Retrotranslation fails? There were some incremental errors getting JAXB2 to work which both the JAXB2 RI team and Taras (the founder of retrotranslator) helped fix. Certainly most things like generics, enums, annotations, reflection and java-util-concurrent all work fine now. There could be a gap here or there - such as AFAIK there is no backport of the new UUID class. So I'd recommend folks run their unit tests on the backported code just to be sure things all work. -- James --- http://radio.weblogs.com/0112098/
Re: Retrotranslator KICKS ASS!!!
The only problem is when one wants to introspect generic arguments. This is the main problem that happened with jaxb2. For example in the following construct, ListMyBean the MyBean type is not available at runtime. When using JAXB2 RI, you have to generate your beans with additional informations in annotations so that this information can be retrieved. Of course, this also applies to JAXWS (which uses JAXB2 marshalling) James Strachan wrote: On 6/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Do you happen to know of any examples where Retrotranslation fails? There were some incremental errors getting JAXB2 to work which both the JAXB2 RI team and Taras (the founder of retrotranslator) helped fix. Certainly most things like generics, enums, annotations, reflection and java-util-concurrent all work fine now. There could be a gap here or there - such as AFAIK there is no backport of the new UUID class. AFAIK, the UUID has been backported and is available in 1.0.4 release of retrotranslator (at least). Cheers, Guillaume Nodet So I'd recommend folks run their unit tests on the backported code just to be sure things all work.
Re: Retrotranslator KICKS ASS!!!
BTW Guillaume pointed me to this thread on IRC - there's a limitation and workaround when using JAXB2 RI http://sourceforge.net/forum/forum.php?thread_id=1493919forum_id=513539 On 6/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: The only problem is when one wants to introspect generic arguments. This is the main problem that happened with jaxb2. For example in the following construct, ListMyBean the MyBean type is not available at runtime. When using JAXB2 RI, you have to generate your beans with additional informations in annotations so that this information can be retrieved. Of course, this also applies to JAXWS (which uses JAXB2 marshalling) James Strachan wrote: On 6/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Do you happen to know of any examples where Retrotranslation fails? There were some incremental errors getting JAXB2 to work which both the JAXB2 RI team and Taras (the founder of retrotranslator) helped fix. Certainly most things like generics, enums, annotations, reflection and java-util-concurrent all work fine now. There could be a gap here or there - such as AFAIK there is no backport of the new UUID class. AFAIK, the UUID has been backported and is available in 1.0.4 release of retrotranslator (at least). Cheers, Guillaume Nodet So I'd recommend folks run their unit tests on the backported code just to be sure things all work. -- James --- http://radio.weblogs.com/0112098/
Unassigned Patches: week of 06-05-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1700 - Web Console prints a stack trace when attempting to deploy an application that is already deployed. Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 6 2006 - GERONIMO-1783 - Welcome application i18n Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started Apr 28 2006 - GERONIMO-1813 - When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory
Re: Unassigned Patches: week of 06-05-2006
Anyone know how this report is setup? I'd love a similar report for ActiveMQ and ServiceMix to help us get patches applied ASAP On 6/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1700 - Web Console prints a stack trace when attempting to deploy an application that is already deployed. Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 6 2006 - GERONIMO-1783 - Welcome application i18n Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started Apr 28 2006 - GERONIMO-1813 - When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-2082) [m2] stax dependencies are all wrong
[ http://issues.apache.org/jira/browse/GERONIMO-2082?page=comments#action_12414748 ] Anita Kulshreshtha commented on GERONIMO-2082: -- I have tested jetty-builder with only xmlbeans as a dependency using the above -- xbean-2.0.0.pom -- and removing stax from xmlbeans-maven-plugin-2.0.pom (effect is same as installing the above jar) and it works. However I am curious, if a dependency is missing from my plugin o.a.g.plugins, maven gives an error listing my plugin in the path, i.e. Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT When an excluded dependency of xmlbeans-maven-plugin is missing, it gives the following message : Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty-builder:jar:1.2-SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev ! [m2] stax dependencies are all wrong Key: GERONIMO-2082 URL: http://issues.apache.org/jira/browse/GERONIMO-2082 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.2 Attachments: geronimo-no-stax.diff, openejb-no-stax.diff, xbean-2.0.0.pom, xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar The dependencies for xmlbeans and the maven xmlbeans plugins are all wrong. xmlbeans pom needs to depend on stax-api, see http://jira.codehaus.org/browse/MEV-406 xmlbeans plugin needs to have stax-api and stax dependencies removed, see http://jira.codehaus.org/browse/MXMLBEANS-19 At this point we can remove all stax and stax-api dependencies from our (and openejb) poms. I'll attach the modified xmlbeans pom, the modified plugin, and the patches to remove all stax mentions from our poms. I'd appreciate some verification of my results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Results of testing Gianny's TranQL Performance Improvements for CMP entity beans
Hi Matt, Thanks for posting these results :) Matt Hogstrom wrote: Gianny, I applied your changes to fix the double execution. It looks like the modifications you made overall improved performance by about 10% (from 1445 to 1591). However, I still see the double execution of the SQL for the Quote bean. So we can still eek out some extra performance. The best number on the servers I tested has been about 2000 so we're almost there :) When you say double execution, do you mean: 1. SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?; followed by 2. SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? as reported under the *With TranQL Changes:* section? If yes, then I am not sure how this can be fixed without caching. The first query maps to the findByPrimaryKey method. After its execution, the transactional cache is being flushed as all the methods of QuoteEJB have a CMT set to Required and PingServlet2EntityLocal does not demarcate tx. As a consequence, the transactional cache is now empty. The second query maps to a row-fault event when getDataBean is invoked. There is a row-fault because the transactional cache is empty. With caching of CMP across transactions, the row-fault event does not happen: the cache is queried and a record is found. Here are the stats from the testing I did tonight. *Before TranQL Change:* 06/04/200622:02:25 IWL0060I Page throughput = *1445.272 /s* This data is already in the JIRA. *With TranQL Changes:* 06/04/200622:50:45 IWL0060I Page throughput = *1591.233 /s* snip *With TranQL CMP Caching Option:* 06/04/200623:01:09 IWL0060I Page throughput = *1988.110* /s These are the queries that are being executed while caching is enabled. Note the difference between the queries. I'm not sure why this is. The first query, 973 exec, is a row-fault query. The second query maps to findByPrimaryKey; it is the result of a transformation of SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ? to fetch a group of fields at the same time than the primary key. In this case, the group to be prefetched is pretty simple: all the QuoteEJB CMP fields. However, the engine can fetch a graph of objects in a single pass. Thanks, Gianny Number of executions = 973 Number of compilations = 1 Total execution time (sec.ms) = 0.052875 Total user cpu time (sec.ms) = 0.015625 Total system cpu time (sec.ms) = 0.015625 Statement text = SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Number of executions = 221945 Number of compilations = 1 Total execution time (sec.ms) = 12.888160 Total user cpu time (sec.ms) = 9.843750 Total system cpu time (sec.ms) = 1.515625 Statement text = SELECT Q.symbol, Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Matt
Re: I think groupIds in m2 build need improvement
I guess the other consideration is for people outside our project that want to pick up piece parts (like the Tx manager). Please remember that not all OSes will be able to tolerate super long file names and these will go into the repo. I know there is some head room but were stealing it from the users. David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks
M2 : Dependency woes
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been removed
or have a different version available at repo1.maven.org/maven2. What
is the best way to handle this? If I do not exclude, I get the error
pasted below :
dependency
groupIdspringframework/groupId
artifactIdspring/artifactId
version${wadiSpringVersion}/version
exclusions
exclusion
groupIdjavax.mail/groupId
artifactIdmail/artifactId
/exclusion
exclusion
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
/exclusion
exclusion
groupIdjavax.resource/groupId
artifactIdconnector/artifactId
/exclusion
/exclusions
/dependency
Thanks
Anita
Missing:
--
1) javax.resource:connector:jar:1.0
Try downloading the file manually from:
http://java.sun.com/j2ee/connector/download.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.resource
-DartifactId=connector \
-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.resource:connector:jar:1.0
2) javax.activation:activation:jar:1.0.2
Try downloading the file manually from:
http://java.sun.com/products/javabeans/glasgow/jaf.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.activation
-DartifactId=activation \
-Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
5) javax.activation:activation:jar:1.0.2
3) javax.transaction:jta:jar:1.0.1B
Try downloading the file manually from:
http://java.sun.com/products/jta
Then, install it using the command:
mvn install:install-file -DgroupId=javax.transaction
-DartifactId=jta \
-Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-remoting:jar:1.2.5
4) org.springframework:spring-dao:jar:1.2.5
5) javax.transaction:jta:jar:1.0.1B
4) javax.mail:mail:jar:1.3.2
Try downloading the file manually from:
http://java.sun.com/products/javamail/downloads/index.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.mail -DartifactId=mail \
-Dversion=1.3.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
--
4 required artifacts are missing.
for artifact:
org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
maven2-central (http://repo1.maven.org/maven2),
codehaus-dist (http://dist.codehaus.org),
Apache CVS (http://people.apache.org/maven-snapshot-repository),
maven1-ibiblio (http://www.ibiblio.org/maven),
snapshots (http://snapshots.maven.codehaus.org/maven2),
apache-cvs (http://cvs.apache.org/repository)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 1 second
[INFO] Finished at: Mon Jun 05 08:47:08 EDT 2006
[INFO] Final Memory: 7M/14M
[INFO] --
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Problem comiting on trunk...
On Jun 5, 2006, at 3:08 AM, Jason Dillon wrote: Well, it's personal matter which change is trival and which is not, isn't it? So, your last resort would be to *not* introduce trivial changes ;) I guess... I think we need to change minotaur refs to people... as infra has stated that the CNAME for the service should be used instead of the hostname, which I am in complete agreement with. So, do we need to vote on this? Or should we just change it? Hi Jason, I think this is a bug -- we should not be using hostnames. There will be problems when/if minotaur is changed or resources are rehosted. You are fixing current function, not adding new capabilities. I think that's a useful metric... There are fixes, however, which I think should probably be reviewed. That's why I think some guidelines are needed to help us make this decisions without spending more time discussing whether a review is needed, than an actual review would have taken... ;-) --kevan
Re: M2 : Dependency woes
Hi Anita,
The license which Sun distributes its binary packages under doesn't provide
for redistribution, preventing Maven from making these packages available
as it does for other packages. The solution is to download the JAR(s) from
java.sun.com and install them locally using 'mvn install:install-file'.
See http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html for
details.
HTH,
Ian
It's better to be hated for who you are
than loved for who you are not
Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078
anita
kulshreshtha
[EMAIL PROTECTED] To
com dev@geronimo.apache.org
cc
06/05/2006 09:09
AMSubject
M2 : Dependency woes
Please respond to
[EMAIL PROTECTED]
he.org
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been removed
or have a different version available at repo1.maven.org/maven2. What
is the best way to handle this? If I do not exclude, I get the error
pasted below :
dependency
groupIdspringframework/groupId
artifactIdspring/artifactId
version${wadiSpringVersion}/version
exclusions
exclusion
groupIdjavax.mail/groupId
artifactIdmail/artifactId
/exclusion
exclusion
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
/exclusion
exclusion
groupIdjavax.resource/groupId
artifactIdconnector/artifactId
/exclusion
/exclusions
/dependency
Thanks
Anita
Missing:
--
1) javax.resource:connector:jar:1.0
Try downloading the file manually from:
http://java.sun.com/j2ee/connector/download.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.resource
-DartifactId=connector \
-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.resource:connector:jar:1.0
2) javax.activation:activation:jar:1.0.2
Try downloading the file manually from:
http://java.sun.com/products/javabeans/glasgow/jaf.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.activation
-DartifactId=activation \
-Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
5) javax.activation:activation:jar:1.0.2
3) javax.transaction:jta:jar:1.0.1B
Try downloading the file manually from:
http://java.sun.com/products/jta
Then, install it using the command:
mvn install:install-file -DgroupId=javax.transaction
-DartifactId=jta \
-Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-remoting:jar:1.2.5
4) org.springframework:spring-dao:jar:1.2.5
5) javax.transaction:jta:jar:1.0.1B
4) javax.mail:mail:jar:1.3.2
Try downloading the file manually from:
http://java.sun.com/products/javamail/downloads/index.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.mail -DartifactId=mail \
-Dversion=1.3.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
Re: Results of testing Gianny's TranQL Performance Improvements for CMP entity beans
Inline Gianny Damour wrote: Hi Matt, Thanks for posting these results :) Matt Hogstrom wrote: Gianny, I applied your changes to fix the double execution. It looks like the modifications you made overall improved performance by about 10% (from 1445 to 1591). However, I still see the double execution of the SQL for the Quote bean. So we can still eek out some extra performance. The best number on the servers I tested has been about 2000 so we're almost there :) When you say double execution, do you mean: 1. SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?; followed by 2. SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? as reported under the *With TranQL Changes:* section? If yes, then I am not sure how this can be fixed without caching. The first query maps to the findByPrimaryKey method. After its execution, the transactional cache is being flushed as all the methods of QuoteEJB have a CMT set to Required and PingServlet2EntityLocal does not demarcate tx. As a consequence, the transactional cache is now empty. The second query maps to a row-fault event when getDataBean is invoked. There is a row-fault because the transactional cache is empty. Perhaps the naive approach would be to define a set of columns to be faulted in when the FBK is initially executed and save those values in the transactional cache. Subsequent attempts to retrive the columns would be serviced from the Tx Cache and not result in another SQL to the DB. This is how WebSphere and WebLogic do it I think. So in the case of our implementation we would define the default behaviour to select all columns. If someone wanted to limit the columns selected (like BEA does when they publish SPECj results) then only the requested columns are fetched. I expect regardless of how we proceed we'll not be able to make further changes to 1.1 but I'd like to entertain this for TranQL 1.3.1 and perhaps a quick 1.1.1 turnaround. With caching of CMP across transactions, the row-fault event does not happen: the cache is queried and a record is found. Here are the stats from the testing I did tonight. *Before TranQL Change:* 06/04/200622:02:25 IWL0060I Page throughput = *1445.272 /s* This data is already in the JIRA. *With TranQL Changes:* 06/04/200622:50:45 IWL0060I Page throughput = *1591.233 /s* snip *With TranQL CMP Caching Option:* 06/04/200623:01:09 IWL0060I Page throughput = *1988.110* /s These are the queries that are being executed while caching is enabled. Note the difference between the queries. I'm not sure why this is. The first query, 973 exec, is a row-fault query. The second query maps to findByPrimaryKey; it is the result of a transformation of SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ? to fetch a group of fields at the same time than the primary key. In this case, the group to be prefetched is pretty simple: all the QuoteEJB CMP fields. However, the engine can fetch a graph of objects in a single pass. Thanks, Gianny Number of executions = 973 Number of compilations = 1 Total execution time (sec.ms) = 0.052875 Total user cpu time (sec.ms) = 0.015625 Total system cpu time (sec.ms) = 0.015625 Statement text = SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Number of executions = 221945 Number of compilations = 1 Total execution time (sec.ms) = 12.888160 Total user cpu time (sec.ms) = 9.843750 Total system cpu time (sec.ms) = 1.515625 Statement text = SELECT Q.symbol, Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Matt
[jira] Resolved: (AMQ-736) Broker is not delivering all messages to slow consumer
[ https://issues.apache.org/activemq/browse/AMQ-736?page=all ] james strachan resolved AMQ-736: Fix Version: 4.0.1 Resolution: Fixed Patch and test case applied - many thanks! Broker is not delivering all messages to slow consumer -- Key: AMQ-736 URL: https://issues.apache.org/activemq/browse/AMQ-736 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: Linux/Windows Java 1.5.0_06 Reporter: Danielius Jurna Priority: Critical Fix For: 4.0.1 Attachments: SlowConsumerTest.java, slowConsumer.patch When producer produces more messages than consumer can handle, after some time some messages are not delivered to the consumer (they are just skipped). To get those messages from the broker, you need to reconnect the consumer. It seems that this bug only occures if message persistance is turned on in the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Unassigned Patches: week of 06-05-2006
On Jun 5, 2006, at 7:11 AM, James Strachan wrote: Anyone know how this report is setup? I'd love a similar report for ActiveMQ and ServiceMix to help us get patches applied ASAP Hi James, They are nice. David Blevins created the scripts. You can find them here -- https:// svn.apache.org/repos/asf/geronimo/gbuild/stan/jirareports The scripts are run as cron jobs on one of the GBuild machines (stan.gbuild.org). I expect we can add some activemq jobs, also... --kevan On 6/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler- factory element is wrong for DB2 or Oracle db Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1700 - Web Console prints a stack trace when attempting to deploy an application that is already deployed. Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 6 2006 - GERONIMO-1783 - Welcome application i18n Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started Apr 28 2006 - GERONIMO-1813 - When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory -- James --- http://radio.weblogs.com/0112098/
Re: M2 : Dependency woes
The mail dependency should probably be replaced with the
geronimo-spec-javamail jar file.
Rick
anita kulshreshtha wrote:
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been removed
or have a different version available at repo1.maven.org/maven2. What
is the best way to handle this? If I do not exclude, I get the error
pasted below :
dependency
groupIdspringframework/groupId
artifactIdspring/artifactId
version${wadiSpringVersion}/version
exclusions
exclusion
groupIdjavax.mail/groupId
artifactIdmail/artifactId
/exclusion
exclusion
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
/exclusion
exclusion
groupIdjavax.resource/groupId
artifactIdconnector/artifactId
/exclusion
/exclusions
/dependency
Thanks
Anita
Missing:
--
1) javax.resource:connector:jar:1.0
Try downloading the file manually from:
http://java.sun.com/j2ee/connector/download.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.resource
-DartifactId=connector \
-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.resource:connector:jar:1.0
2) javax.activation:activation:jar:1.0.2
Try downloading the file manually from:
http://java.sun.com/products/javabeans/glasgow/jaf.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.activation
-DartifactId=activation \
-Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
5) javax.activation:activation:jar:1.0.2
3) javax.transaction:jta:jar:1.0.1B
Try downloading the file manually from:
http://java.sun.com/products/jta
Then, install it using the command:
mvn install:install-file -DgroupId=javax.transaction
-DartifactId=jta \
-Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-remoting:jar:1.2.5
4) org.springframework:spring-dao:jar:1.2.5
5) javax.transaction:jta:jar:1.0.1B
4) javax.mail:mail:jar:1.3.2
Try downloading the file manually from:
http://java.sun.com/products/javamail/downloads/index.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.mail -DartifactId=mail \
-Dversion=1.3.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
--
4 required artifacts are missing.
for artifact:
org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
maven2-central (http://repo1.maven.org/maven2),
codehaus-dist (http://dist.codehaus.org),
Apache CVS (http://people.apache.org/maven-snapshot-repository),
maven1-ibiblio (http://www.ibiblio.org/maven),
snapshots (http://snapshots.maven.codehaus.org/maven2),
apache-cvs (http://cvs.apache.org/repository)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 1 second
[INFO] Finished at: Mon Jun 05 08:47:08 EDT 2006
[INFO] Final Memory: 7M/14M
[INFO] --
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Updated: (AMQ-736) Broker is not delivering all messages to slow consumer
[ https://issues.apache.org/activemq/browse/AMQ-736?page=all ] james strachan updated AMQ-736: --- Patch Info: [Patch Available] added patch available flag Broker is not delivering all messages to slow consumer -- Key: AMQ-736 URL: https://issues.apache.org/activemq/browse/AMQ-736 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: Linux/Windows Java 1.5.0_06 Reporter: Danielius Jurna Priority: Critical Fix For: 4.0.1 Attachments: SlowConsumerTest.java, slowConsumer.patch When producer produces more messages than consumer can handle, after some time some messages are not delivered to the consumer (they are just skipped). To get those messages from the broker, you need to reconnect the consumer. It seems that this bug only occures if message persistance is turned on in the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] Release 4.0 of ActiveMQ
Hi Folks, After the customary 72 hour voting rule, the vote passes with 7 +1s: +1 Hiram Chirino +1 Guillaume Nodet +1 Bruce Snyder +1 Adrian Co +1 Jonas Lim +1 James Strachan +1 Fritz Oconer We will now get incubator pmc approval before going final with the release. -- Regards, Hiram
[jira] Created: (GERONIMO-2084) The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation
The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation Key: GERONIMO-2084 URL: http://issues.apache.org/jira/browse/GERONIMO-2084 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: transaction manager Reporter: Guillaume Nodet When integrating the Geronimo transaction manager, all threads have to call the TransactionContextManager.newUnspecifiedTransactionContext() to be able to begin a transaction by using the TransactionContextManager.newBeanTransactionContext which is called when using the UserTransaction. This is done by geronimo modules, but when using the transaction layer outside of geronimo, this requirement ties the project to geronimo implementation, or a need to wrap it. This could be easily avoided with the attached patch, which create a context is none exist for the current thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2084) The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation
[ http://issues.apache.org/jira/browse/GERONIMO-2084?page=all ] Guillaume Nodet updated GERONIMO-2084: -- Attachment: GERONIMO-2084.patch This patch allows the TransactionContextManager to be used from unmanaged threads The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation Key: GERONIMO-2084 URL: http://issues.apache.org/jira/browse/GERONIMO-2084 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: transaction manager Reporter: Guillaume Nodet Attachments: GERONIMO-2084.patch When integrating the Geronimo transaction manager, all threads have to call the TransactionContextManager.newUnspecifiedTransactionContext() to be able to begin a transaction by using the TransactionContextManager.newBeanTransactionContext which is called when using the UserTransaction. This is done by geronimo modules, but when using the transaction layer outside of geronimo, this requirement ties the project to geronimo implementation, or a need to wrap it. This could be easily avoided with the attached patch, which create a context is none exist for the current thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Unassigned Patches: week of 06-05-2006
On 6/5/06, Kevan Miller [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 7:11 AM, James Strachan wrote: Anyone know how this report is setup? I'd love a similar report for ActiveMQ and ServiceMix to help us get patches applied ASAP Hi James, They are nice. David Blevins created the scripts. You can find them here -- https:// svn.apache.org/repos/asf/geronimo/gbuild/stan/jirareports The scripts are run as cron jobs on one of the GBuild machines (stan.gbuild.org). I expect we can add some activemq jobs, also... Great thanks! I've just added a couple of trivial scripts for ActiveMQ and ServiceMix - though am not sure if these trivial shell scripts in gbuild fall under the Geronimo ReviewThenCommit? If there's an issue I can always move them into the ActiveMQ and ServiceMix repos. -- James --- http://radio.weblogs.com/0112098/
Re: M2 : Dependency woes
On Jun 5, 2006, at 6:09 AM, anita kulshreshtha wrote:
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been
removed
or have a different version available at repo1.maven.org/maven2. What
is the best way to handle this? If I do not exclude, I get the error
pasted below :
AARRGGGH!. We need to remove the broken wadi integration. jetty
does not need wadi nor spring.
thanks
david jencks
dependency
groupIdspringframework/groupId
artifactIdspring/artifactId
version${wadiSpringVersion}/version
exclusions
exclusion
groupIdjavax.mail/groupId
artifactIdmail/artifactId
/exclusion
exclusion
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
/exclusion
exclusion
groupIdjavax.resource/groupId
artifactIdconnector/artifactId
/exclusion
/exclusions
/dependency
Thanks
Anita
Missing:
--
1) javax.resource:connector:jar:1.0
Try downloading the file manually from:
http://java.sun.com/j2ee/connector/download.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.resource
-DartifactId=connector \
-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.resource:connector:jar:1.0
2) javax.activation:activation:jar:1.0.2
Try downloading the file manually from:
http://java.sun.com/products/javabeans/glasgow/jaf.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.activation
-DartifactId=activation \
-Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
5) javax.activation:activation:jar:1.0.2
3) javax.transaction:jta:jar:1.0.1B
Try downloading the file manually from:
http://java.sun.com/products/jta
Then, install it using the command:
mvn install:install-file -DgroupId=javax.transaction
-DartifactId=jta \
-Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-remoting:jar:1.2.5
4) org.springframework:spring-dao:jar:1.2.5
5) javax.transaction:jta:jar:1.0.1B
4) javax.mail:mail:jar:1.3.2
Try downloading the file manually from:
http://java.sun.com/products/javamail/downloads/index.html
Then, install it using the command:
mvn install:install-file -DgroupId=javax.mail -
DartifactId=mail \
-Dversion=1.3.2 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
2) org.springframework:spring:jar:1.2.5
3) org.springframework:spring-support:jar:1.2.5
4) javax.mail:mail:jar:1.3.2
--
4 required artifacts are missing.
for artifact:
org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
maven2-central (http://repo1.maven.org/maven2),
codehaus-dist (http://dist.codehaus.org),
Apache CVS (http://people.apache.org/maven-snapshot-repository),
maven1-ibiblio (http://www.ibiblio.org/maven),
snapshots (http://snapshots.maven.codehaus.org/maven2),
apache-cvs (http://cvs.apache.org/repository)
[INFO]
--
--
[INFO] For more information, run Maven with the -e switch
[INFO]
--
--
[INFO] Total time: 1 minute 1 second
[INFO] Finished at: Mon Jun 05 08:47:08 EDT 2006
[INFO] Final Memory: 7M/14M
[INFO] --
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Commented: (GERONIMO-2083) Use howl-logger-1.0.1-1.jar
[ http://issues.apache.org/jira/browse/GERONIMO-2083?page=comments#action_12414773 ] David Jencks commented on GERONIMO-2083: Maven is not processing any upload requests at the moment, the codehaus outage continues to be a disaster. I'm backpedalling to released version 0.1.11 Use howl-logger-1.0.1-1.jar --- Key: GERONIMO-2083 URL: http://issues.apache.org/jira/browse/GERONIMO-2083 Project: Geronimo Type: Bug Security: public(Regular issues) Components: dependencies Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 I figures out the m2 howl build and created an upload request http://jira.codehaus.org/browse/MAVENUPLOAD-930. When this completes we can change the howl dependency to groupIdorg.objectweb.howl/groupId artifactIdhowl-logger/artifactId version1.0.1-1/version Hopefully this will occur before 1.1 :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2085) Provide a TransactionManager implementation on top of TransactionContextManager
Provide a TransactionManager implementation on top of TransactionContextManager --- Key: GERONIMO-2085 URL: http://issues.apache.org/jira/browse/GERONIMO-2085 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: transaction manager Reporter: Guillaume Nodet When integrating geronimo transaction manager in other projects, the main class to use is the TransactionContextManager, but this class does not implement the JTA specified TransactionManager, even though it provides the exact features. This uncesseraly ties the project to Geronimo transaction manager implementation. We could easily provide a wrapper implementing TM on top of TCM, or put the TCM features inside the TransactionManagerImpl. I'm willingfull to provide a patch, but which way is the best ? The first one (wrapper) obviously is the one that requires the least amount of changes, but it would lead to two implementations of TM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
james strachan reassigned AMQ-732:
--
Assign To: Hiram Chirino
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation overflowing into next logFile=0
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager
[jira] Assigned: (AMQ-678) MessageCleanup fails with mysql 4.1.x
[ https://issues.apache.org/activemq/browse/AMQ-678?page=all ] james strachan reassigned AMQ-678: -- Assign To: Hiram Chirino MessageCleanup fails with mysql 4.1.x - Key: AMQ-678 URL: https://issues.apache.org/activemq/browse/AMQ-678 Project: ActiveMQ Type: Bug Components: Message Store Versions: 4.0 M4 Reporter: Paul Focke Assignee: Hiram Chirino Priority: Minor Attachments: deleteOldMessages.patch When ActiveMQ does a message cleanup using mysql-4.1 for jdbc persistence an error occurs. ActiveMQ complains that the connection is already closed. The nested exception however is an EOFException. The exception is thrown by DefaultJDBCAdapter.doDeleteOldMessages(DefaultJDBCAdapter.java:544). I poked around I found that the sql statement it produces causes mysql to crash. It even causes mysqld to crash when entered in the mysql client console, so this is not a Connector/J issue. Here is the statement DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND EXPIRATION1144326387433) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER) It can be found in Statements.java:220. I have tested this under mysql 4.1.12, 4.1.13 5.0.18. The exceptions were only thrown in mysql 4.1. 5.0 behaved as would be expected. Possible solutions would be : - rewrite the delete statement so that it doesn't kill mysqld : - I had a quick look into rewriting the statement but I haven't found how - change the current delete into a select id from ... (this works) and delete records 1 by 1 using the resultSet ( which really sucks when there are lots of messages to be deleted ) - not use mysql-4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-732) Infinite recovery loop.
[
https://issues.apache.org/activemq/browse/AMQ-732?page=comments#action_36235 ]
Hiram Chirino commented on AMQ-732:
---
How big were the messages? Can the shiped example producer and consumer in the
examples directory reproduce the issue?
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation overflowing into next logFile=0
[ main]
Re: I think groupIds in m2 build need improvement
Here's the discussion on why we had to change the groupIds http://www.mail-archive.com/dev@geronimo.apache.org/msg19426.html And here's the JIRA that restructured the POMs and gave those groupIds. http://issues.apache.org/jira/browse/GERONIMO-1755 I hope I understood what David is saying correctly. I guess I'm okay with renaming configs as modules but I think we are better off keeping separate groupIds for each major branch under geronimo root. In the m2 repo, this would then be analogous to keeping the jars, cars, etc separate in the current m2 repo. If we had the same groupId (o.a.g), then all the artifacts from modules, configs, apps, plugins etc would end up together in one dir in the repo (o.a.g) o/a/g/geronimo-kernel (module artifact) o/a/g/geronimo-deployment-plugin (plugin artifact) o/a/g/welcome-jetty (config artifact) Now, maybe this is not such a bad thing but I hope some resident M2 gurus can weigh in on this too. Cheers Prasad On 6/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I guess the other consideration is for people outside our project that want to pick up piece parts (like the Tx manager). Please remember that not all OSes will be able to tolerate super long file names and these will go into the repo. I know there is some head room but were stealing it from the users. David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks
[jira] Commented: (GERONIMO-2081) Concurrency problems in Daytrader or AMQ
[ http://issues.apache.org/jira/browse/GERONIMO-2081?page=comments#action_12414781 ] David Jencks commented on GERONIMO-2081: Connections closed in queue servlet in rev 411811 (forgot the jira number there) topic servlet fixed in rev 411836 Concurrency problems in Daytrader or AMQ Key: GERONIMO-2081 URL: http://issues.apache.org/jira/browse/GERONIMO-2081 Project: Geronimo Type: Bug Security: public(Regular issues) Components: sample apps Versions: 1.1 Reporter: David Jencks Assignee: Hiram Chirino Fix For: 1.1 Brian Noll found a bunch of ConcurrentModificationException problems when running daytrader PingServlet2MDBQueue under mutltithread load. These are due either to PingServlet2MDBQueue sharing a connection between all 50+ threads or activemq not allowing such connection sharing. I'm going to remove the connection sharing in daytrader and ask Hiram to figure out if AMQ needs more synchronization. Here's the stack trace Brian got, showing at least 2 concurrency problems: 18:35:41,171 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...):exception posting message to TradeBrokerQueue destination 18:35:41,172 ERROR [Log] Error: PingServlet2MDBQueue.doGet(...): error java.util.ConcurrentModificationException java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) at java.util.AbstractList$Itr.next(AbstractList.java:419) at java.util.AbstractCollection.remove(AbstractCollection.java:254) at org.activemq.TransactionContext.removeSession(TransactionContext.java:116) at org.activemq.ra.RATransactionContext.removeSession(RATransactionContext.java:57) at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466) at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447) at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87) at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76) at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2MDBQueue.doGet(PingServlet2MDBQueue.java:127) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) at java.util.AbstractList$Itr.next(AbstractList.java:419) at java.util.AbstractCollection.remove(AbstractCollection.java:254) at org.activemq.TransactionContext.removeSession(TransactionContext.java:116) at org.activemq.ra.RATransactionContext.removeSession(RATransactionContext.java:57) at org.activemq.ActiveMQSession.doClose(ActiveMQSession.java:466) at org.activemq.ActiveMQSession.close(ActiveMQSession.java:447) at org.activemq.ra.JMSSessionProxy.cleanup(JMSSessionProxy.java:87) at org.activemq.ra.JMSSessionProxy.close(JMSSessionProxy.java:76) at
Re: Unassigned Patches: week of 06-05-2006
On 6/5/06, James Strachan [EMAIL PROTECTED] wrote: I've just added a couple of trivial scripts for ActiveMQ and ServiceMix - though am not sure if these trivial shell scripts in gbuild fall under the Geronimo ReviewThenCommit? If there's an issue I can always move them into the ActiveMQ and ServiceMix repos. Well, I don't want to be a PITA, but as you know THE board was quite picky about it and until it's changed we need to vote each and every change unless it's a bug (which is not in this case). That's my understanding. Sorry! On the other hand if it's so trivial, getting 3x+1 won't be any problem ;) James Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unassigned Patches: week of 06-05-2006
On 6/5/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 6/5/06, James Strachan [EMAIL PROTECTED] wrote: I've just added a couple of trivial scripts for ActiveMQ and ServiceMix - though am not sure if these trivial shell scripts in gbuild fall under the Geronimo ReviewThenCommit? If there's an issue I can always move them into the ActiveMQ and ServiceMix repos. Well, I don't want to be a PITA, but as you know THE board was quite picky about it and until it's changed we need to vote each and every change unless it's a bug (which is not in this case). That's my understanding. Sorry! On the other hand if it's so trivial, getting 3x+1 won't be any problem ;) Given that these 2 shell scripts have nothing to do with Geronimo at all - its maybe best if I moved them out of the gbuild SVN area and put them in the activemq and servicemix repos instead. Apologies for the noise. -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36237 ]
Christopher G. Stach II commented on AMQ-731:
-
Comparing Resin's and Geronmio's TransactionManagerImpl suspend methods,
Geronimo's doesn't even suspend the transaction. The test case I have could
probably never work, and it's no wonder that none of the AMQ developers have
come across this if testing is only done with Geronimo.
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at com.caucho.jca.WorkThread.run(WorkThread.java:99)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
at java.lang.Thread.run(Thread.java:595)
Re: Tracking progress of merging dead-1.2 branch into trunk
On Jun 5, 2006, at 9:42 AM, Jacek Laskowski wrote: On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: You can see what you (or someone else :-) did in dead-1.2 with e.g. grep djencks all_changes.log I think there are 329 changes (I did about 43). I propose that as we merge, verify the changes have already been merged, or decide they are obsolete we change the start of the line to Merged Comments? No comments so far, but I guess it can only mean we're all so happy with your proposal we can't speak/write anything ;) It does help me and am going to use/review it. Thanks! Do you think it's worth to apply the m2 patches given the revolutionary approach taken in 1.1? I'd appreciate Anita's and Prasad's comment on it. My understanding is that the patches I've been applying from GERONIMO-2071 are the port of the m2 work done previously on dead-1.2, so this effort is already well underway. After I went through the work I did personally in dead-1.2 I was planning to go through again and mark the dead-1.2 m2 work merged. Is this OK with everyone? thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unassigned Patches: week of 06-05-2006
On Jun 5, 2006, at 9:41 AM, James Strachan wrote: On 6/5/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 6/5/06, James Strachan [EMAIL PROTECTED] wrote: I've just added a couple of trivial scripts for ActiveMQ and ServiceMix - though am not sure if these trivial shell scripts in gbuild fall under the Geronimo ReviewThenCommit? If there's an issue I can always move them into the ActiveMQ and ServiceMix repos. Well, I don't want to be a PITA, but as you know THE board was quite picky about it and until it's changed we need to vote each and every change unless it's a bug (which is not in this case). That's my understanding. Sorry! On the other hand if it's so trivial, getting 3x+1 won't be any problem ;) Given that these 2 shell scripts have nothing to do with Geronimo at all - its maybe best if I moved them out of the gbuild SVN area and put them in the activemq and servicemix repos instead. Apologies for the noise. My opinion is that these scripts form documentation of geronimo and related projects and thus do not need RTC. It certainly is not clear to me how I would apply such a change locally and test it, since IIUC it is designed to be run by a cron job on a particular machine. thanks david jencks -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36238 ]
Christopher G. Stach II commented on AMQ-731:
-
Resin's TransactionImpl.suspend() method, which doesn't exist in Geronimo,
calls XAResource.end(Xid, XAResource.TMSUSPEND),
WrapperNamedXAResource.end(Xid, int) line: 51 in the above stack trace.
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at com.caucho.jca.WorkThread.run(WorkThread.java:99)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
at java.lang.Thread.run(Thread.java:595)
Note that the ackType is a poison ack. This shouldn't be the case as the
Re: Tracking progress of merging dead-1.2 branch into trunk
+1. The m2 work in dead-1.2 included modules, deployment-plugin and all the apps. They all passed tests too. We can consider the m2 work from dead-1.2 merged when we have got these building and testing successfully into new trunk. Cheers Prasad On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 9:42 AM, Jacek Laskowski wrote: On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: You can see what you (or someone else :-) did in dead-1.2 with e.g. grep djencks all_changes.log I think there are 329 changes (I did about 43). I propose that as we merge, verify the changes have already been merged, or decide they are obsolete we change the start of the line to Merged Comments? No comments so far, but I guess it can only mean we're all so happy with your proposal we can't speak/write anything ;) It does help me and am going to use/review it. Thanks! Do you think it's worth to apply the m2 patches given the revolutionary approach taken in 1.1? I'd appreciate Anita's and Prasad's comment on it. My understanding is that the patches I've been applying from GERONIMO-2071 are the port of the m2 work done previously on dead-1.2, so this effort is already well underway. After I went through the work I did personally in dead-1.2 I was planning to go through again and mark the dead-1.2 m2 work merged. Is this OK with everyone? thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
RE: Please try out the upgrade jar
Hi David, The dependency tags for the the module ID of the server wide datasource in the Geronimo-web.xml were not required for 1.0, so it is unnatural for user to know they are required for 1.1. If the upgrader tool doesnt indicate that, user will just have to go figure that out by luck. One a second thought, I dont quite understand why we need to have the datasource as the dependency in 1.1 while we dont need it as the dependency in 1.0. The Geronimo-web.xml already has the ref-name and resource-link information within the resource-ref tags. Thanks, Lin -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:01 AM To: dev@geronimo.apache.org Subject: Re: Please try out the upgrade jar On Jun 1, 2006, at 7:56 PM, Song Scorpio wrote: I just tried the new upgrade.jar within server runtime, context-priority-classloader element is gone. But there's still no datasource dependency, which will cause failure of application deployment.. Do you think the upgrade tool should insert comments into every plan about likely problems such as this one about datasources? Since it's possible to resolve a resource-ref without a plan entry if the resource-ref uses the same name as the datasource plan, we'd have to look at the j2ee deployment descriptors to be sure whether or not a jndi ref was present. Looking into dds is beyond what I think the upgrade tool should be doing. However, adding comments always would be pretty easy to do, I didn't think to do it however. thanks david jencks 2006/6/2, Donald Woods [EMAIL PROTECTED]: How old is the upgrade.jar you are using? Noticed that your generated plan still has the old context-priority-classloader element in it. -Donald Zhang Song wrote: For an application which is using datasource, we should manually add dependency to deployment plan upgraded by the tool. The plan upgraded by the tool is following: - # web-app xmlns =* http://geronimo.apache.org/xml/ns/j2ee/web-1.0*; xmlns:naming =*http://geronimo.apache.org/xml/ns/naming-1.1*; xmlns:sec= * http://geronimo.apache.org/xml/ns/security-1.1*; xmlns:sys= *http://geronimo.apache.org/xml/ns/deployment-1.1* - # sys:environment - # sys:moduleId sys:groupIdSample/ sys:groupId sys:artifactIdEMPdemo/ sys:artifactId sys:version1.1/ sys:version sys:typecar/ sys:type /sys:moduleId sys:dependencies / sys:hidden-classes / sys:non-overridable-classes / /sys:environment context-root/EMPdemo/ context-root context-priority-classloaderfalse /context-priority-classloader - # naming:resource-ref naming:ref-namejdbc/DataSource /naming:ref-name naming:resource-linkSystemDatasource /naming:resource-link /naming:resource-ref /web-app But this upgraded plan will cause following error during deployment: -- Error: Unable to distribute EMPdemo-1.0.war: Unable to resolve resource reference 'jdbc/DataSource' (Could not find resource 'jdbc/EmployeeDatasource'. Perhaps it has not yet been configured, or your application does not have a dependency declared for that resource module?) -- After I add datasource's module reference to the upgraded plan, that application can be deployed successfully. -- - # sys:environment - # sys:moduleId sys:groupIdSample/ sys:groupId sys:artifactIdEMPdemo/ sys:artifactId sys:version1.1/ sys:version sys:typecar/ sys:type /sys:moduleId - # sys:dependencies - # sys:dependency sys:groupIdSample/ sys:groupId sys:artifactIdEmployeeDatasource /sys:artifactId sys:version1.1/ sys:version sys:typecar/ sys:type /sys:dependency /sys:dependencies sys:hidden-classes / sys:non-overridable-classes / /sys:environment context-root/EMPdemo/ context-root context-priority-classloaderfalse /context-priority-classloader - # naming:resource-ref naming:ref-namejdbc/DataSource /naming:ref-name naming:resource-linkjdbc/EmployeeDatasource /naming:resource-link /naming:resource-ref /web-app -- Could the upgrade tool add some comments to plan or give a warning to user when processing with datasource?
[jira] Updated: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=all ] Prasad Kashyap updated GERONIMO-2071: - Attachment: deployment-plugin.patch The deployment-plugin.patch (later used by magicGball tests) Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=all ] Prasad Kashyap updated GERONIMO-2071: - Attachment: applications.patch applications.patch does not include the console and magicGball reorg. It also configures surefire in the geronimo/pom.xml to skip tests (for now). Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RTC] Tag new specs for Geronimo v1.1 release
I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: [RTC] Tag new specs for Geronimo v1.1 release
+1 Jacek On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Tag new specs for Geronimo v1.1 release
+1, assuming that these are only for the specs that have actually changed since 1.0. thanks david jencks On Jun 5, 2006, at 12:29 PM, Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: [RTC] Tag new specs for Geronimo v1.1 release
+1 Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: [RTC] Tag new specs for Geronimo v1.1 release
+1 to make the new 1.1 tag On Jun 5, 2006, at 12:33 PM, David Jencks wrote: +1, assuming that these are only for the specs that have actually changed since 1.0. David, I don't believe we can do that unless we reorganize the tree such that every spec has a separate trunk, branches, and tags sub directories, so they can be versioned independently. I fine with making that change, but I believe that is a different topic of discussion. -dain
[jira] Commented: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36241 ]
David Jencks commented on AMQ-731:
--
I assume you mean mutliple jta transactions rather than multiple branches of a
single jta transaction. In this case something else such as the connector
framework is responsible for delisting the connection(s) from the first tx and
enlisting them in the 2nd tx. IIRC this is stated rather unclearly in the jta
spec and slightly more clearly but in terms of c programming in the xa spec.
In geronimo we normally don't do this. The only time you can change
transactions with suspend/resume is going into an ejb RequiresNew method and in
this case we just give you new connections. There is an experimental way of
delisting connections and reusing them in the new transaction, but AFAIK no one
has ever used it. What are the circumstances that lead Resin to suspend/resume?
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
Re: [RTC] Tag new specs for Geronimo v1.1 release
+1 --jason -Original Message- From: Alan D. Cabrera [EMAIL PROTECTED] Date: Mon, 05 Jun 2006 12:29:11 To:Geronimo dev@geronimo.apache.org Subject: [RTC] Tag new specs for Geronimo v1.1 release I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
[jira] Updated: (GERONIMO-2084) The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation
[ http://issues.apache.org/jira/browse/GERONIMO-2084?page=all ] Guillaume Nodet updated GERONIMO-2084: -- Attachment: GERONIMO-2084-bis.patch This patch will work better (the previous one would fail when resuming a transaction in an unmanaged thread) The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation Key: GERONIMO-2084 URL: http://issues.apache.org/jira/browse/GERONIMO-2084 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: transaction manager Reporter: Guillaume Nodet Attachments: GERONIMO-2084-bis.patch, GERONIMO-2084.patch When integrating the Geronimo transaction manager, all threads have to call the TransactionContextManager.newUnspecifiedTransactionContext() to be able to begin a transaction by using the TransactionContextManager.newBeanTransactionContext which is called when using the UserTransaction. This is done by geronimo modules, but when using the transaction layer outside of geronimo, this requirement ties the project to geronimo implementation, or a need to wrap it. This could be easily avoided with the attached patch, which create a context is none exist for the current thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36242 ]
Christopher G. Stach II commented on AMQ-731:
-
It could be multiple transactions or multiple branches. For example, a single
database connection can support X number of concurrent transactions as well as
Y number of branches within each transaction. I assume that since Resin is the
application server, the transaction manager, and the JCA container, it is
calling end on the enlisted XAResources.
Check out the stack trace above. JBoss TreeCache is calling suspend on the TM
to do some work outside of the transaction (TreeCache.suspend() line: 101). We
use Hibernate's connection after_statement release mode, which is appropriate
for connections using JTA.
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at
Re: Tracking progress of merging dead-1.2 branch into trunk
+1. More inline.. --- Prasad Kashyap [EMAIL PROTECTED] wrote: +1. The m2 work in dead-1.2 included modules, deployment-plugin and all the apps. They all passed tests too. We can consider the m2 work from dead-1.2 merged when we have got these building and testing successfully into new trunk. Cheers Prasad On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 9:42 AM, Jacek Laskowski wrote: On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: You can see what you (or someone else :-) did in dead-1.2 with e.g. grep djencks all_changes.log I think there are 329 changes (I did about 43). I propose that as we merge, verify the changes have already been merged, or decide they are obsolete we change the start of the line to Merged Comments? No comments so far, but I guess it can only mean we're all so happy with your proposal we can't speak/write anything ;) It does help me and am going to use/review it. Thanks! Do you think it's worth to apply the m2 patches given the revolutionary approach taken in 1.1? I'd appreciate Anita's and Prasad's comment on it. All the modules patches are already committed. Some modules are not included in the new trunk, e.g. spring, session etc! The deployment-plugin and applications patches are waiting to be applied. We need to fix few tests again. Thanks Anita My understanding is that the patches I've been applying from GERONIMO-2071 are the port of the m2 work done previously on dead-1.2, so this effort is already well underway. After I went through the work I did personally in dead-1.2 I was planning to go through again and mark the dead-1.2 m2 work merged. Is this OK with everyone? thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (AMQ-731) Redeliveries don't work with resource adapter and Jencks
[ https://issues.apache.org/activemq/browse/AMQ-731?page=all ]
Christopher G. Stach II updated AMQ-731:
Attachment: amq-txcontext.patch
This simple patch fixes the whole problem.
Redeliveries don't work with resource adapter and Jencks
Key: AMQ-731
URL: https://issues.apache.org/activemq/browse/AMQ-731
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0
Environment: Sun JDK 1.5.0_06, Jencks 1.1.3, AMQ 4.0, Resin Pro 3.0.14
Reporter: Christopher G. Stach II
Attachments: amq-txcontext.patch
During a rollback in a JTA transaction, this exception is generated a few
times:
org.apache.activemq.broker.AbstractConnection.serviceException Async
error occurred: javax.jms.JMSException: Could not correlate
acknowledgment with dispatched message: MessageAck {commandId = 137,
responseRequired = false, ackType = 1, consumerId =
ID:xxx-2276-1148335783189-2:5:-1:2, firstMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with
dispatched message: MessageAck {commandId = 137, responseRequired =
false, ackType = 1, consumerId = ID:xxx-2276-1148335783189-2:5:-1:2,
firstMessageId = ID:xxx-2276-1148335783189-2:1:1:1:2, lastMessageId =
ID:xxx-2276-1148335783189-2:1:1:1:2, destination = queue://xxxQueue,
transactionId = null, messageCount = 1}
at
org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:175)
at
org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:233)
at
org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:362)
at
org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:176)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:78)
at
org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:356)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:178)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1655)
at
org.apache.activemq.ActiveMQSession$2.afterRollback(ActiveMQSession.java:720)
at
org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:134)
at
org.apache.activemq.TransactionContext.rollback(TransactionContext.java:409)
at
org.apache.activemq.ra.LocalAndXATransaction.rollback(LocalAndXATransaction.java:126)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:78)
at
com.caucho.transaction.TransactionImpl.rollbackInt(TransactionImpl.java:787)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:560)
at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at com.caucho.jca.WorkThread.run(WorkThread.java:99)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:490)
at com.caucho.util.ThreadPool.run(ThreadPool.java:423)
at java.lang.Thread.run(Thread.java:595)
Note that the ackType is a poison ack. This shouldn't be the case as the
configuration (below) on the resource adapter and the managed connection
factory both specify 9 redeliveries.
Re: I think groupIds in m2 build need improvement
I don't think we want to use org.apache.geronimo for everything... but, I also don't think that we need to worry about the groupId's right now. Once we completely move to m2, we will want to rearrange our codebase and at that time I think we may want to introduce one or two additional groupId's to keep the repo organized. I think it is premature to be talking about changing groupId's right now. --jason On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? I think that we should keep everything org.apache.geronimo. Having a byzantine group id hierarchy will only confuse those poor souls that want to use our artifacts. Regards, Alan
Moving the ActiveMQ gbean modules into the geronimo source tree.
Howdy Folks, I was planing to work on a patch that takes that gbean related modules in ActiveMQ puts them in geronimo. I just wanted to make sure that there are no objections to this. Those gbean modules are mostly just gbean related glue code which I think make more sense living in Geronimo. No one else outside of the geronimo project is interested in the activemq gbean modules. Once that part is done, then I'll start to work on merging/modifying the port to activemq 4.x that was done the 1.2-dead branch. -- Regards, Hiram
Re: I think groupIds in m2 build need improvement
Jason Dillon wrote: I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case? but, I also don't think that we need to worry about the groupId's right now. Once we completely move to m2, we will want to rearrange our codebase and at that time I think we may want to introduce one or two additional groupId's to keep the repo organized. I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting. Regards, Alan On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? I think that we should keep everything org.apache.geronimo. Having a byzantine group id hierarchy will only confuse those poor souls that want to use our artifacts. Regards, Alan
Re: [RTC] Tag new specs for Geronimo v1.1 release
The specs that have actually changed will get their version incremented. The root POM that's shared by all the modules will also get its version incremented. Regards, Alan David Jencks wrote: +1, assuming that these are only for the specs that have actually changed since 1.0. thanks david jencks On Jun 5, 2006, at 12:29 PM, Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: [RTC] Tag new specs for Geronimo v1.1 release
+1 Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: M2 : j2ee-corba configuration
It's in the CORBA spec jar. Regards, Alan anita kulshreshtha wrote: Hi, Where will I find o.omg.CSI.EstablishContext class ? I am getting the following while building j2ee-corba configuration : Thanks Anita ... 24 more === [INFO] [ERROR] BUILD ERROR [INFO] [INFO] java.lang.reflect.InvocationTargetException org/omg/CSI/EstablishContext [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Thu Jun 01 08:41:59 EDT 2006 [INFO] Final Memory: 14M/25M [INFO] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: I think groupIds in m2 build need improvement
I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case? Sure, I believe that we will eventually get G split up into a few smaller chunks. Probably, one tree of modules, that represents the very core of G, none of the J2EE bits at all. Then another that provides the J2EE behaviors and then another that provides different flavors of J2EE bits that can be plugged in. org.apache.geronimo = core org.apache.geronimo.j2ee = j2ee ... Maven groupId's are very useful to organize components that work together. So, for example, if you just needed the basic core to run your non-j2ee application on, then you would know that you just need all of the org.apache.geronimo artifacts, and you would know that something is starting to creep in if org.apache.geronimo.j2ee start to pop up. BTW, I do not believe that groupId's need to be 100% related to the package names of classes that they contain either. They should be mostly related though... I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting. The reason why I think that it is premature is that we have not really even begun to discus how to best restructure the source tree. I do believe that we really should do this once we move to m2. The current structure was designed around how m1 worked and the limitations of how the reactor found projects. Now that m2 has a better view on how this works, we are free to nest modules into more domain specific groups. While we could re-groupId now, we will probably end up doing it again once we've restructured w/m2... so, I think that it would probably have less impact to delay any major groupId changes until we get m2 support in place. --jason
Anschluss - CORBA specs new home
I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? Regards, Alan
Re: I think groupIds in m2 build need improvement
We already use a separate groupId for specs. (o.a.g.specs). We have to decide between having some 5 top level groupIds under o.a.g versus having all artifacts for modules, configs, specs, samples, under the same groupId. I am beginning to think, seeing the latter in the repo is more confusing. o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) Cheers Prasad On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Jason Dillon wrote: I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case? but, I also don't think that we need to worry about the groupId's right now. Once we completely move to m2, we will want to rearrange our codebase and at that time I think we may want to introduce one or two additional groupId's to keep the repo organized. I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting. Regards, Alan On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? I think that we should keep everything org.apache.geronimo. Having a byzantine group id hierarchy will only confuse those poor souls that want to use our artifacts. Regards, Alan
[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414854 ] David Jencks commented on GERONIMO-2071: Applied 5 june 2006 applications.patch in rev 411916. However, I had to merge the pom.xml by hand, and: - did not skip tests - left the m2-plugins building after modules Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Moving the ActiveMQ gbean modules into the geronimo source tree.
On 6/5/06, Jason Dillon [EMAIL PROTECTED] wrote: I think that is fine, as long as we get the activemq folks here (like you), to help us keep these gbeans in sync with the latest activemq. +1 * * * Completely unrelated... well sorta... I really think we should think about using activemq for all cluster or inter-geronimo node communication. Even if user wants to use another jms for their app, G would still use activemq as its messaging backbone. Btw... I love activemq... so maybe I'm biased. lol! It does have some nice stuff in it. But lets not go that crazy... Perhaps we just start be defining our clustering requirements as nice set of interfaces that the default implementation using some ultra fast messaging like ActiveMQ! :) Regards, Hiram --jason On 6/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy Folks, I was planing to work on a patch that takes that gbean related modules in ActiveMQ puts them in geronimo. I just wanted to make sure that there are no objections to this. Those gbean modules are mostly just gbean related glue code which I think make more sense living in Geronimo. No one else outside of the geronimo project is interested in the activemq gbean modules. Once that part is done, then I'll start to work on merging/modifying the port to activemq 4.x that was done the 1.2-dead branch. -- Regards, Hiram -- Regards, Hiram
Re: I think groupIds in m2 build need improvement
o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
Re: Moving the ActiveMQ gbean modules into the geronimo source tree.
Hiram, I think that's a good idea since that code is so closely tied to geronimo and can easily be affected by changes to it. Case in point is that I recently debugged a problem in the geronimo console due to changes in 1.1 and ended up needing to patch the AMQ gbean code. I created JIRAs in both Geronimo and AMQ since I knew that this code is really in a cross section between the two projects. By the way, the patch I mentioned still needs to be applied so that connectors can be created from the 1.1 console: https://issues.apache.org/activemq/browse/AMQ-727 Also, there's a patch that prevents new connectors from being lost across server restarts: http://issues.apache.org/jira/browse/GERONIMO-1451 Best wishes, Paul On 6/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy Folks, I was planing to work on a patch that takes that gbean related modules in ActiveMQ puts them in geronimo. I just wanted to make sure that there are no objections to this. Those gbean modules are mostly just gbean related glue code which I think make more sense living in Geronimo. No one else outside of the geronimo project is interested in the activemq gbean modules. Once that part is done, then I'll start to work on merging/modifying the port to activemq 4.x that was done the 1.2-dead branch. -- Regards, Hiram
Re: [RTC] Tag new specs for Geronimo v1.1 release
On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: The specs that have actually changed will get their version incremented. The root POM that's shared by all the modules will also get its version incremented. We just need to be careful that a mvn deploy at the root does not rebuild and redeploy over previously deployed releases. Regards, Alan David Jencks wrote: +1, assuming that these are only for the specs that have actually changed since 1.0. thanks david jencks On Jun 5, 2006, at 12:29 PM, Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan -- Regards, Hiram
Re: Moving the ActiveMQ gbean modules into the geronimo source tree.
Thanks Paul.. I'll put that on my dish too. On 6/5/06, Paul McMahan [EMAIL PROTECTED] wrote: Hiram, I think that's a good idea since that code is so closely tied to geronimo and can easily be affected by changes to it. Case in point is that I recently debugged a problem in the geronimo console due to changes in 1.1 and ended up needing to patch the AMQ gbean code. I created JIRAs in both Geronimo and AMQ since I knew that this code is really in a cross section between the two projects. By the way, the patch I mentioned still needs to be applied so that connectors can be created from the 1.1 console: https://issues.apache.org/activemq/browse/AMQ-727 Also, there's a patch that prevents new connectors from being lost across server restarts: http://issues.apache.org/jira/browse/GERONIMO-1451 Best wishes, Paul On 6/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy Folks, I was planing to work on a patch that takes that gbean related modules in ActiveMQ puts them in geronimo. I just wanted to make sure that there are no objections to this. Those gbean modules are mostly just gbean related glue code which I think make more sense living in Geronimo. No one else outside of the geronimo project is interested in the activemq gbean modules. Once that part is done, then I'll start to work on merging/modifying the port to activemq 4.x that was done the 1.2-dead branch. -- Regards, Hiram -- Regards, Hiram
Re: I think groupIds in m2 build need improvement
I find it a PITA when the groupId doesn't match the Java package name for jar files. For modules (FKA configs), I don't have any opinion. For assemblies, I think we should use o.a.g. -dain On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
Re: Anschluss - CORBA specs new home
On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that it's time that we, Yoko, take responsibility for the CORBA spec jars. After Geronimo releases v1.1, let's plan on moving them over to Yoko. Thoughts? I'm leaning towards +1, but what would that mean to Geronimo? Will you wipe out specs/corba completely and transfer the bits to Yoko? What else? Alan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. I like this with the exception that I want to be clear that o.a.g.xxx really means the groupId is org.apache.geronimo I agree with jason that we may want to add more groupIds in the future, but I think the above proposal is good for what we have now and allows for extension. thanks david jencks --jason
Re: [RTC] Tag new specs for Geronimo v1.1 release
AFAIK, all specs poms have been changed and even specs with no code changed have been upgraded with a minor release to reflect the pom change. These changes were mainly about unneeded transitive dependencies. So I think all specs should be re-released. Cheers, Guillaume Nodet Hiram Chirino wrote: On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: The specs that have actually changed will get their version incremented. The root POM that's shared by all the modules will also get its version incremented. We just need to be careful that a mvn deploy at the root does not rebuild and redeploy over previously deployed releases. Regards, Alan David Jencks wrote: +1, assuming that these are only for the specs that have actually changed since 1.0. thanks david jencks On Jun 5, 2006, at 12:29 PM, Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:32 PM, Dain Sundstrom wrote: I find it a PITA when the groupId doesn't match the Java package name for jar files. For modules (FKA configs), I don't have any opinion. For assemblies, I think we should use o.a.g. Can you be more specific? What do you want the transaction jar groupId to be? o.a.g or o.a.g.transaction? I'm waffling but I guess I agree that shorter is better for the assemblies, I would prefer o.a.g rather than o.a.g.assemblies thanks david jencks -dain On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
Re: [RTC] Tag new specs for Geronimo v1.1 release
On Jun 5, 2006, at 2:37 PM, Guillaume Nodet wrote: AFAIK, all specs poms have been changed and even specs with no code changed have been upgraded with a minor release to reflect the pom change. These changes were mainly about unneeded transitive dependencies. So I think all specs should be re-released. If there are dependency improvements I definitely agree a new release is needed. I am glad to hear of this :-) thanks david jencks Cheers, Guillaume Nodet Hiram Chirino wrote: On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: The specs that have actually changed will get their version incremented. The root POM that's shared by all the modules will also get its version incremented. We just need to be careful that a mvn deploy at the root does not rebuild and redeploy over previously deployed releases. Regards, Alan David Jencks wrote: +1, assuming that these are only for the specs that have actually changed since 1.0. thanks david jencks On Jun 5, 2006, at 12:29 PM, Alan D. Cabrera wrote: I would like to make a new tag, v1.1, for the specs release. This is in preparation for the Geronimo v1.1 release. Regards, Alan
Re: Moving the ActiveMQ gbean modules into the geronimo source tree.
+1, I think this is a good idea. Do you think the minimal rar we are building should move to amq? We might not be the only ones who would like it :-) thanks david jencks On Jun 5, 2006, at 1:41 PM, Hiram Chirino wrote: Howdy Folks, I was planing to work on a patch that takes that gbean related modules in ActiveMQ puts them in geronimo. I just wanted to make sure that there are no objections to this. Those gbean modules are mostly just gbean related glue code which I think make more sense living in Geronimo. No one else outside of the geronimo project is interested in the activemq gbean modules. Once that part is done, then I'll start to work on merging/modifying the port to activemq 4.x that was done the 1.2-dead branch. -- Regards, Hiram
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:41 PM, David Jencks wrote: On Jun 5, 2006, at 2:32 PM, Dain Sundstrom wrote: I find it a PITA when the groupId doesn't match the Java package name for jar files. For modules (FKA configs), I don't have any opinion. For assemblies, I think we should use o.a.g. Can you be more specific? What do you want the transaction jar groupId to be? o.a.g or o.a.g.transaction? Yes, that was confusing. Sorry o.a.g is cool... I am most concerned about the groupId being the first part of package name. Said another way, I don't want to see o.a.g.foo on a jar containing the class o.a.g.bar.Stuff. -dain I'm waffling but I guess I agree that shorter is better for the assemblies, I would prefer o.a.g rather than o.a.g.assemblies thanks david jencks -dain On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414870 ] David Jencks commented on GERONIMO-2071: Moved console parts into a new applications/console directory for better m2 build: fixed m1 build so it works with the new locations. This was also done in dead-1.2, although I suspect by a different method since there appear to be 2 copies of the console parts there. rev 411927. Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Anschluss - CORBA specs new home
On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: +1 as long as geronimo continues to build :-) Second that! :-) +1 for the change if the above statement is in effect. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Moving the ActiveMQ gbean modules into the geronimo source tree.
Hi David, Not really. We are already building a rar, its the 'general purpose' we throw all our dependencies in it so that it will work in most app servers kinda rar. I think I'll let customized rars be the job of integrators or app servers. I think that this makes sense since it will not help the ActiveMQ standalone distribution footprint if we try to ship a customized rar version per app server that is out there. On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: +1, I think this is a good idea. Do you think the minimal rar we are building should move to amq? We might not be the only ones who would like it :-) thanks david jencks On Jun 5, 2006, at 1:41 PM, Hiram Chirino wrote: Howdy Folks, I was planing to work on a patch that takes that gbean related modules in ActiveMQ puts them in geronimo. I just wanted to make sure that there are no objections to this. Those gbean modules are mostly just gbean related glue code which I think make more sense living in Geronimo. No one else outside of the geronimo project is interested in the activemq gbean modules. Once that part is done, then I'll start to work on merging/modifying the port to activemq 4.x that was done the 1.2-dead branch. -- Regards, Hiram -- Regards, Hiram
Re: [RTC] Tag new specs for Geronimo v1.1 release
Hiram Chirino wrote: On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: The specs that have actually changed will get their version incremented. The root POM that's shared by all the modules will also get its version incremented. We just need to be careful that a mvn deploy at the root does not rebuild and redeploy over previously deployed releases. Ahh. That was the problem that I was trying to remember. Thanks! I shall hand deploy only those projects that have changed. Regards, Alan
[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414879 ] David Jencks commented on GERONIMO-2071: prasad, the deployment-plugin patch seems to have about 5 copies of each file in it. Can you try again to produce a patch with only one copy of each file? Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RTC] ActiveMQ GBean modules
Howdy folks,
Here's a patch that brings in the activemq gbean modules into
geronimo. It's partly what was in activemq 4.x and integrated into
geronimo 1.2-dead merged with the changes in the 3.x branch.
It compiles at least and looks like a reasonable start. Once further
integration work gets done we may need to tweak a little more. here's
my +1 got get this committed. I guess I just need 3 more.
Index: modules/activemq-gbean/project.properties
===
--- modules/activemq-gbean/project.properties (revision 0)
+++ modules/activemq-gbean/project.properties (revision 0)
@@ -0,0 +1,3 @@
+# ---
+# Build Properties
+# ---
Property changes on: modules/activemq-gbean/project.properties
___
Name: svn:executable
+ *
Index: modules/activemq-gbean/project.xml
===
--- modules/activemq-gbean/project.xml (revision 0)
+++ modules/activemq-gbean/project.xml (revision 0)
@@ -0,0 +1,104 @@
+?xml version=1.0 encoding=ISO-8859-1?
+!--
+
+Copyright 2004 The Apache Software Foundation
+
+Licensed under the Apache License, Version 2.0 (the License);
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an AS IS BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+--
+!-- $Rev: 356052 $ $Date: 2005-12-11 16:41:20 -0600 (Sun, 11 Dec 2005) $ --
+!DOCTYPE project
+project
+pomVersion3/pomVersion
+extend../../etc/project.xml/extend
+
+nameGeronimo :: ActiveMQ :: GBeans/name
+idgeronimo-activemq-gbean/id
+shortDescriptionActiveMQ Geronimo / GBean support/shortDescription
+descriptionActiveMQ GBeans used for integration into Apache
Geronimo/description
+
+!-- --
+!-- Dependencies --
+!-- --
+dependencies
+
+ dependency
+groupIdincubator-activemq/groupId
+artifactIdactivemq-core/artifactId
+version4.0-SNAPSHOT/version
+ /dependency
+
+ dependency
+groupIdincubator-activemq/groupId
+artifactIdactiveio-core/artifactId
+version3.0-SNAPSHOT/version
+ /dependency
+
+ dependency
+groupIdgeronimo/groupId
+artifactIdgeronimo-activemq-gbean-management/artifactId
+version${pom.currentVersion}/version
+ /dependency
+
+ dependency
+groupIdgeronimo/groupId
+artifactIdgeronimo-kernel/artifactId
+version${pom.currentVersion}/version
+ /dependency
+
+ dependency
+groupIdgeronimo/groupId
+artifactIdgeronimo-system/artifactId
+version${pom.currentVersion}/version
+ /dependency
+
+ dependency
+groupIdgeronimo/groupId
+artifactIdgeronimo-management/artifactId
+version${pom.currentVersion}/version
+ /dependency
+
+ dependency
+groupIdgeronimo/groupId
+artifactIdgeronimo-j2ee/artifactId
+version${pom.currentVersion}/version
+ /dependency
+
+ dependency
+groupIdmx4j/groupId
+artifactIdmx4j/artifactId
+version${mx4j_version}/version
+ /dependency
+
+ dependency
+groupIdcommons-logging/groupId
+artifactIdcommons-logging/artifactId
+version${commons_logging_version}/version
+urlhttp://jakarta.apache.org/commons/logging//url
+ /dependency
+
+
+/dependencies
+
+!-- this module is using m2 directory layout --
+build
+sourceDirectory${basedir}/src/main/java/sourceDirectory
+
unitTestSourceDirectory${basedir}/src/main/test/unitTestSourceDirectory
+
+unitTest
+includes
+include**/*Test.java/include
+/includes
+/unitTest
+/build
+
+/project
Property changes on: modules/activemq-gbean/project.xml
___
Name: svn:executable
+ *
Index:
modules/activemq-gbean/src/test/java/org/apache/activemq/gbean/ConnectorTest.java
===
---
modules/activemq-gbean/src/test/java/org/apache/activemq/gbean/ConnectorTest.java
(revision
0)
+++
modules/activemq-gbean/src/test/java/org/apache/activemq/gbean/ConnectorTest.java
(revision
0)
@@ -0,0 +1,61 @@
+/**
+ *
+ * Copyright 2005-2006 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the
[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414880 ] David Jencks commented on GERONIMO-2071: Copied the magic gball files to their locations in the big applications.patch and add the poms. Commented out the reference to deployment plugin, it doesn't exist yet. Left m1 version in place, I don't want to write an m1 build for this :-) rev 411947 Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RTC] ActiveMQ GBean modules
On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote: Howdy folks, Here's a patch that brings in the activemq gbean modules into geronimo. It's partly what was in activemq 4.x and integrated into geronimo 1.2-dead merged with the changes in the 3.x branch. It compiles at least and looks like a reasonable start. Once further integration work gets done we may need to tweak a little more. here's my +1 got get this committed. I guess I just need 3 more. I'd find it a lot easier to review, apply, and test this patch if you attached it to a jira entry. Is there any chance of you coming up with a pom.xml for the m2 build? thanks david jencks
[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414882 ] David Jencks commented on GERONIMO-2071: Extracted the poms and classpath.properties for console from big applications.patch.zip. This should bring complete application patching per the patches as of today. (this assertion could use some checking :-) rev 411954. Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-13) NPE when the location inside classpath tag can not be resolved
NPE when the location inside classpath tag can not be resolved Key: XBEAN-13 URL: http://issues.apache.org/jira/browse/XBEAN-13 Project: XBean Type: Bug Components: server Versions: 2.4 Reporter: Guillaume Nodet Assigned to: Guillaume Nodet Fix For: 2.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
