Re: ActiveMQ.DLQ
hi, It's the destination name for the dead letter queue. You can have a consumer listen to this queue and should be able to get the message(if any) off the DLQ . Regards, Jonas Christopher_Ong wrote: May I know what is ActiveMQ.DLQ?
[jira] Created: (SM-696) Add an operation to the EndpointMBean to allow testing the endpoint through jmx
Add an operation to the EndpointMBean to allow testing the endpoint through jmx --- Key: SM-696 URL: https://issues.apache.org/activemq/browse/SM-696 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Affects Versions: 3.0 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.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: (SM-696) Add an operation to the EndpointMBean to allow testing the endpoint through jmx
[ https://issues.apache.org/activemq/browse/SM-696?page=comments#action_37137 ] Guillaume Nodet commented on SM-696: Author: gnodet Date: Mon Oct 9 16:07:27 2006 New Revision: 454546 URL: http://svn.apache.org/viewvc?view=revrev=454546 Log: SM-696: Add an operation to the EndpointMBean to allow testing the endpoint through jmx Added: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/util/QNameUtil.java Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/Endpoint.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/EndpointMBean.java Add an operation to the EndpointMBean to allow testing the endpoint through jmx --- Key: SM-696 URL: https://issues.apache.org/activemq/browse/SM-696 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Affects Versions: 3.0 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.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-961) Problem with subscription passing with network of brokers in AMQ 4.0.2
[ https://issues.apache.org/activemq/browse/AMQ-961?page=all ] Holger Bruch updated AMQ-961: - Attachment: RestartDFBOnResume.diff Might relate to the problem I encountered in http://www.nabble.com/Failover-and-DemandForwardingBridge-tf2383410.html#a6642973. Apparently, the DemandForwardingBridge does not resume correctly after a network interruption. For me, the attached patch worked, but I'm not aware of any side effects, so please check. Problem with subscription passing with network of brokers in AMQ 4.0.2 -- Key: AMQ-961 URL: https://issues.apache.org/activemq/browse/AMQ-961 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Kevin Yaussy Priority: Critical Attachments: RestartDFBOnResume.diff There's an occasional problem with subscription propagation when using a network of brokers. Test scenario uses ConsumerTool and PublisherTool in examples area of distribution. 1) Start broker A (has a network connection to broker B) 2) Start broker B (has a network connection to broker A) 3) start consumer C against broker A, on FOO 4) start publisher P against broker B, on FOO Messages do not flow to consumer C. In the broker B log, there's no indication it got any subscriptions from broker A. Again, this is occasional. I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine. There's an obvious difference in one of the threads that hopefully will bring light to the problem. I've not gone into the code yet to try and find the issue, but figured I would open this issue first. Stack trace of broker A when subscriptions did NOT pass, and message flow is broken: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8 e2ff000..0x8e2ff8f0] at java.lang.Object.wait(Native Method) - waiting on 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179) - locked 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport .java:830) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid geSupport.java:329) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport .java:130) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Stack trace of broker A when everything works correctly: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) 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
Re: Message Expiry
Hi, Hmm - which version of ActiveMQ are you using? The message should have expired and should not be consumed after the timetolive has elapsed. You can try looking on some of the test cases and see if you can reproduce the issue: ie. https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/JmsSendReceiveWithMessageExpirationTest.java btw, I tested this using trunk and appears to work ok :) Regards, Jonas Christopher_Ong wrote: I set the timetolive for a message as 1s and y after that period, the msg still remain there? Shouldn't be it wil automatically been deleted or send to dead msg queue?
Re: Maven Build Failed in WADI Clustering Module
I have a successful build at revision 454340. Try running mvn -U . This is what I ran when I ended up hitting compilation problems most recently. VamsiOn 10/9/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi All,It looks there is an error in Geronimo Maven build in revision 454313.It gives following error when buildinggeronimo-clustering-wadi module./home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[72,38] package org.codehaus.wadi.servicespace does not exist/home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[73,38] package org.codehaus.wadi.servicespace does not exist/home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[74,44] package org.codehaus.wadi.servicespace.basic does not exist/home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[104,12] cannot resolve symbolsymbol: class BasicServiceSpacelocation: class org.apache.geronimo.clustering.wadi.BasicWADISessionManager/home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[121,27] cannot resolve symbolsymbol: class BasicServiceSpacelocation: class org.apache.geronimo.clustering.wadi.BasicWADISessionManager/home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[121,49] cannot resolve symbolsymbol: class ServiceSpaceNamelocation: class org.apache.geronimo.clustering.wadi.BasicWADISessionManager/home/lsf/Lasantha/Work/Geronimo/Test/server/modules/geronimo-clustering-wadi/src/main/java/org/apache/geronimo/clustering/wadi/BasicWADISessionManager.java:[182,55] cannot resolve symbolsymbol: class ServiceNamelocation: class org.apache.geronimo.clustering.wadi.BasicWADISessionManager[INFO] [INFO] Traceorg.apache.maven.BuildFailureException: Compilation failureatorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555)atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle (DefaultLifecycleExecutor.java:475)atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.java:306)atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140)at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)at org.apache.maven.cli.MavenCli.main (MavenCli.java:256)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)atsun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)atorg.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)atorg.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)at org.codehaus.classworlds.Launcher.main(Launcher.java:375)Caused by: org.apache.maven.plugin.CompilationFailureException :Compilation failureatorg.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505)atorg.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111)at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)atorg.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)Thanks, Lasantha Ranaweera
Re: Clover plugin
Jason Dillon [EMAIL PROTECTED] wrote: Why? If we turn clover back on, then these classes will need to be copied to target/clover/classes anyways.What is the problem with Eclipse?Currently if we use 'target' as the default output folder in eclipse, the schemaorg_apache_xmlbeans classes are lost. We are manually adding target/clover/classes as 'classes folder' to the BuildPath for *-builder modules. If clover is not particular about this location, we could use a neutral name like xmlbeans-classes. WDYS? Thanks Anita--jasonOn Oct 8, 2006, at 6:01 AM, anita kulshreshtha wrote: I would like to copy xmlbeans classes to target/xmlbeans-classes instead of target/clover/classes. This directory will be used by Eclipse. We are currently using target/clover/classes for this purpose.thanksAnitaJason Dillon [EMAIL PROTECTED] wrote: That and clover caused to many problems... but there is a new version of the plugin out, need to revisit.--jasonOn Oct 6, 2006, at 8:31 AM, Prasad Kashyap wrote: Hi Anita, The clover plugin is used to get test coverage on our modules. Eg: http://geronimo.apache.org/maven/server/modules/geronimo-activation/ clover/index.html But I don't see the maven-clover-plugin being executed along with the other reports in the genesis' project-config. I don't know where it it is being called from. Cheers Prasad On 10/6/06, anita kulshreshtha wrote: The *-builder modules are copying schemaorg_apache_xmlbeans classes to target/clover/classes. I was trying to import *-builder in eclipse. Eclipse is not handing these classes properly and I am getting ".can not be resolved" errors. This needs to be fixed. Thanks Anita - Original Message From: Jacek Laskowski To: dev@geronimo.apache.org Sent: Friday, October 6, 2006 9:40:35 AM Subject: Re: Clover plugin On 10/6/06, anita kulshreshtha wrote: Oops! I should have stated the question more clearly. I do mean how it is being used in Geronimo? I can't find any reference to clover plugin in poms (as a report) so unless someone runs it via mvn clover:instrument clover:clover it's not used at all. Why? Jacek -- Jacek Laskowski http://www.laskowski.net.pl Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail.
[jira] Commented: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2
[ https://issues.apache.org/activemq/browse/AMQ-961?page=comments#action_37133 ] Kevin Yaussy commented on AMQ-961: -- Thanks. I will apply this patch and try it out. Problem with subscription passing with network of brokers in AMQ 4.0.2 -- Key: AMQ-961 URL: https://issues.apache.org/activemq/browse/AMQ-961 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Kevin Yaussy Priority: Critical Attachments: RestartDFBOnResume.diff There's an occasional problem with subscription propagation when using a network of brokers. Test scenario uses ConsumerTool and PublisherTool in examples area of distribution. 1) Start broker A (has a network connection to broker B) 2) Start broker B (has a network connection to broker A) 3) start consumer C against broker A, on FOO 4) start publisher P against broker B, on FOO Messages do not flow to consumer C. In the broker B log, there's no indication it got any subscriptions from broker A. Again, this is occasional. I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine. There's an obvious difference in one of the threads that hopefully will bring light to the problem. I've not gone into the code yet to try and find the issue, but figured I would open this issue first. Stack trace of broker A when subscriptions did NOT pass, and message flow is broken: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8 e2ff000..0x8e2ff8f0] at java.lang.Object.wait(Native Method) - waiting on 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179) - locked 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport .java:830) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid geSupport.java:329) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport .java:130) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Stack trace of broker A when everything works correctly: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) 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] Created: (GERONIMO-2477) NPE in JCAResourceImpl
NPE in JCAResourceImpl -- Key: GERONIMO-2477 URL: http://issues.apache.org/jira/browse/GERONIMO-2477 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Fix For: 1.2 The NPE is thrown while running jconsole. To reproduce click on JCAResource. Geronimo Application Server started 19:43:00,156 WARN [MBeanGBeanBridge] Exception while getting attribute adminObjects javax.management.ReflectionException: null nested exception is java.lang.NullPointerExcept ion java.lang.NullPointerException at org.apache.geronimo.j2ee.management.impl.Util.getObjectNames(Util.java:33) at org.apache.geronimo.connector.JCAResourceImpl.getAdminObjects(JCAResourceImpl.j ava:106) at org.apache.geronimo.connector.JCAResourceImpl$$FastClassByCGLIB$$f01e0455.invok e(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.ja va:38) at org.apache.geronimo.gbean.runtime.GBeanAttribute.getValue(GBeanAttribute.java:3 85) at org.apache.geronimo.gbean.runtime.GBeanInstance.getAttribute(GBeanInstance.java :681) at org.apache.geronimo.kernel.basic.BasicKernel.getAttribute(BasicKernel.java:178) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.getAttribute(MBeanGBeanBridge.j ava:118) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.getAttributes(MBeanGBeanBridge. java:143) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.getAttributes(InvokerMBea nServerInterceptor.java:302) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBea nServerInterceptor.java:125) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.getAttributes(SecurityMB eanServerInterceptor.java:92) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBea nServerInterceptor.java:125) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBea nServerInterceptor.java:125) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.getAttributes( ContextClassLoaderMBeanServerInterceptor.java:225) at mx4j.server.MX4JMBeanServer.getAttributes(MX4JMBeanServer.java:1003) at mx4j.remote.rmi.RMIConnectionInvoker.getAttributes(RMIConnectionInvoker.java:18 8) at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25) at java.lang.reflect.Method.invoke(Method.java:324) -- 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: (AMQ-963) Segmentation Fault in apache::activemq::protocol::openwire::OpenWireMarshaller::unmarshalMap
Segmentation Fault in
apache::activemq::protocol::openwire::OpenWireMarshaller::unmarshalMap
Key: AMQ-963
URL: https://issues.apache.org/activemq/browse/AMQ-963
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.2
Environment: Suse linux 64Bit
Reporter: Tomas Lebovic
Segmentation Fault:
I keep recieving a segmentation fault here is the gdb output.
apache::activemq::protocol::openwire::OpenWireMarshaller::unmarshalMap
(this=value optimized out, mode=value optimized out,
istream=Cannot access memory at address 0x69
) at basic_string.h:249
249 { return _M_dataplus._M_p; }
If you need more information let me know and i will try and gather some more.
--
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: (GERONIMO-2477) NPE in JCAResourceImpl
[
http://issues.apache.org/jira/browse/GERONIMO-2477?page=comments#action_12440889
]
Anita Kulshreshtha commented on GERONIMO-2477:
--
This is due to a cut-paste error in getAdminObjectInstances():
.
return (JCAAdminObject[]) adminObjects.toArray(new
JCAAdminObject[{color:red}connectionFactories{color}.size()]);
Fixed in rev 454370.
NPE in JCAResourceImpl
--
Key: GERONIMO-2477
URL: http://issues.apache.org/jira/browse/GERONIMO-2477
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 1.2
Environment: All
Reporter: Anita Kulshreshtha
Assigned To: Anita Kulshreshtha
Priority: Minor
Fix For: 1.2
The NPE is thrown while running jconsole. To reproduce click on
JCAResource.
Geronimo Application Server started
19:43:00,156 WARN [MBeanGBeanBridge] Exception while getting attribute
adminObjects
javax.management.ReflectionException: null nested exception is
java.lang.NullPointerExcept
ion
java.lang.NullPointerException
at
org.apache.geronimo.j2ee.management.impl.Util.getObjectNames(Util.java:33)
at
org.apache.geronimo.connector.JCAResourceImpl.getAdminObjects(JCAResourceImpl.j
ava:106)
at
org.apache.geronimo.connector.JCAResourceImpl$$FastClassByCGLIB$$f01e0455.invok
e(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.ja
va:38)
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.getValue(GBeanAttribute.java:3
85)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.getAttribute(GBeanInstance.java
:681)
at
org.apache.geronimo.kernel.basic.BasicKernel.getAttribute(BasicKernel.java:178)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.getAttribute(MBeanGBeanBridge.j
ava:118)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.getAttributes(MBeanGBeanBridge.
java:143)
at
mx4j.server.interceptor.InvokerMBeanServerInterceptor.getAttributes(InvokerMBea
nServerInterceptor.java:302)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBea
nServerInterceptor.java:125)
at
mx4j.server.interceptor.SecurityMBeanServerInterceptor.getAttributes(SecurityMB
eanServerInterceptor.java:92)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBea
nServerInterceptor.java:125)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBea
nServerInterceptor.java:125)
at
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.getAttributes(
ContextClassLoaderMBeanServerInterceptor.java:225)
at
mx4j.server.MX4JMBeanServer.getAttributes(MX4JMBeanServer.java:1003)
at
mx4j.remote.rmi.RMIConnectionInvoker.getAttributes(RMIConnectionInvoker.java:18
8)
at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja
va:25)
at java.lang.reflect.Method.invoke(Method.java:324)
--
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: (AMQ-964) Fix documentation to show Maven2 usage
Fix documentation to show Maven2 usage -- Key: AMQ-964 URL: https://issues.apache.org/activemq/browse/AMQ-964 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 4.0.2 Reporter: Bernhard Wellhöfer Several pages under http://www.activemq.org discuss how to compile, test, run ... ActiveMQ using Maven 1. Please enhance these pages (e.g. http://www.activemq.org/site/getting-started.html) how to use Maven2. -- 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-961) Problem with subscription passing with network of brokers in AMQ 4.0.2
[ https://issues.apache.org/activemq/browse/AMQ-961?page=comments#action_37134 ] Kevin Yaussy commented on AMQ-961: -- This does appear to fix the problem. I'd had a similar problem with AMQ 4.0.1, reported in AMQ-776, which I had fixed. But, for the second part of that problem, the original patch did not work. This issue and the second part of AMQ-776, are fixed now by your patch. I'll update AMQ-776, too. Problem with subscription passing with network of brokers in AMQ 4.0.2 -- Key: AMQ-961 URL: https://issues.apache.org/activemq/browse/AMQ-961 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Kevin Yaussy Priority: Critical Attachments: RestartDFBOnResume.diff There's an occasional problem with subscription propagation when using a network of brokers. Test scenario uses ConsumerTool and PublisherTool in examples area of distribution. 1) Start broker A (has a network connection to broker B) 2) Start broker B (has a network connection to broker A) 3) start consumer C against broker A, on FOO 4) start publisher P against broker B, on FOO Messages do not flow to consumer C. In the broker B log, there's no indication it got any subscriptions from broker A. Again, this is occasional. I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine. There's an obvious difference in one of the threads that hopefully will bring light to the problem. I've not gone into the code yet to try and find the issue, but figured I would open this issue first. Stack trace of broker A when subscriptions did NOT pass, and message flow is broken: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8 e2ff000..0x8e2ff8f0] at java.lang.Object.wait(Native Method) - waiting on 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179) - locked 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport .java:830) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid geSupport.java:329) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport .java:130) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Stack trace of broker A when everything works correctly: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) 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
Re: dojo in Geronimo (long)
Jason Dillon wrote: I've done this more times than I'd like to remember, even from a web app... lemme know if you want a code snip. A code snip would be great - Being able to initiate the built in dojo build would be much simpler that parsing and rebuilding the javascript code myself. Jay
[jira] Commented: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=comments#action_37135 ] Kevin Yaussy commented on AMQ-776: -- Hiram, With help from Holger Bruch on AMQ-961, this issue I think can be resolved. For AMQ 4.0.2, apply the ConduitBridge patch, which fixes the first part of this issue. Apply Holger's patch from AMQ-961 to DemandForwardingBridgeSupport. That fixes the issue from AMQ-961, but also the second part of this issue. ConduitBridge can malfunction when first of a set of consumers goes away Key: AMQ-776 URL: https://issues.apache.org/activemq/browse/AMQ-776 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Reporter: Kevin Yaussy Assigned To: Rob Davies Priority: Critical Fix For: 4.0.3 Attachments: ConduitBridge.patch, DemandForwardingBridgeSupport.patch When the following scenario is followed, any of the subsequent consumers will stop receiving messages. I've reproduced this using the ConsumerTool, and ProducerTool supplied in the example area of the distribution. +++ Start Broker A Start Broker B Start Consumer 1, connecting to Broker B, consuming FOO Start Consumer 2, connecting to Broker B, consuming FOO Start Publisher, connecting to Broker A, publishing FOO Ctl-C out of Consumer 1 Consumer 2 stops receiving messages +++ Seems to me that ConduitBridge is supposed to track all consumers for a given subscription, by way of DemandSubscription. It is seeding DemandSubscription with the originating consumer, but when subsequent consumers are added, the ConduitBridge::addToAlreadyInterestedConsumers re-adds the original subscriber to the DemandSubscription's map - so the map only ever has the original subscription. I've attached a patch. Hope the change is good. -- 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: http endpoint activation ordering
gnodet wrote:
Endpoints order should be kept inside an SU.
Could you raise a JIRA for that, it should be easy
to fix by replacing the used map implementation by
an ordered map.
In fact, endpoints are stored in a HashMap with keys generated by
EndpointSupport class and which are Strings that look like :
{namespace}servicename:endpointname
using an ordered map won't solve anything as you've got no indication of
ordering except the natural order, and I don't know if we can safely prefix
the key string with the order number or even use an object as a key as the
string is used to build destination for routing.
Fabrice
--
View this message in context:
http://www.nabble.com/http-endpoint-activation-ordering-tf2395343.html#a6718919
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: http endpoint activation ordering
But if we use a LinkedHashMap, the map keeps the
order of keys as they were inserted:
This linked list defines the iteration ordering,
which is normally the order in which keys were
inserted into the map.
So it should be safe to use this implementation.
The map does not sort on key values like a TreeMap does.
On 10/9/06, Fabrice Dewasmes [EMAIL PROTECTED] wrote:
gnodet wrote:
Endpoints order should be kept inside an SU.
Could you raise a JIRA for that, it should be easy
to fix by replacing the used map implementation by
an ordered map.
In fact, endpoints are stored in a HashMap with keys generated by
EndpointSupport class and which are Strings that look like :
{namespace}servicename:endpointname
using an ordered map won't solve anything as you've got no indication of
ordering except the natural order, and I don't know if we can safely prefix
the key string with the order number or even use an object as a key as the
string is used to build destination for routing.
Fabrice
--
View this message in context:
http://www.nabble.com/http-endpoint-activation-ordering-tf2395343.html#a6718919
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
[jira] Created: (SM-694) problem packaging multiple service unit dependant from the same component
problem packaging multiple service unit dependant from the same component - Key: SM-694 URL: https://issues.apache.org/activemq/browse/SM-694 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Reporter: Raffaele Spazzoli I have a problem packaging multiple service unit dependant from the same component using the dependency way in pom. The same doesn't happen if I use the propertycomponentName way. If I package more than one (with only one is ok) serviceunit that use the same component in the same service assembly I receive the following error: [INFO] [jbi:generate-jbi-service-assembly-descriptor] [INFO] Generating jbi.xml [INFO] Determining component name for service unit su4 [INFO] Determining component name for service unit su6 [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The service unit su6 does not have a dependency which is packaged as a jbi-component or a project property 'componentName' [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The service unit su6 does not have a dependency which is packaged as a jbi-component or a project property 'componentName' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: The service unit su6 does not have a dependency which is packaged as a jbi-component or a project property 'componentName' at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMojo.getComponentName(GenerateServiceAssemblyDescriptorMojo.java:271) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMojo.generateJbiDescriptor(GenerateServiceAssemblyDescriptorMojo.java:172) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceAssemblyDescriptorMojo.execute(GenerateServiceAssemblyDescriptorMojo.java:116) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more the error message is not true because the service unit does decleare a dependecy to a jbi-component. If I switch back to the property way so that I have one serviceunit using dependency and one or more useyng the property way it works. -- 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
Patches in RTC (Geronimo - 2006-10-09)
Geronimo - Monday, October 9, 2006 4 Patches in RTC [GERONIMO-1277] Change group-id to org.apache.geronimo - Assignee: Jason Dillon - Reporter: Dain Sundstrom - Created: Sat Dec 03 02:55:12 PST 2005 - Updated: Sun Oct 01 15:38:21 PDT 2006 - Votes: 1 1 David Jencks - http://issues.apache.org/jira/browse/GERONIMO-1277 [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 14:54:17 PDT 2006 - Updated: Fri Sep 29 09:07:27 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMO-2409] Provide config/module aliasing ability - Assignee: David Jencks - Reporter: David Jencks - Created: Fri Sep 15 15:36:59 PDT 2006 - Updated: Mon Sep 25 10:14:18 PDT 2006 - Votes: 3 1 Gianny Damour 2 Jeff Genender 3 Joe Bohn - http://issues.apache.org/jira/browse/GERONIMO-2409 [GERONIMO-2413] Add a Certification Authority (CA) portlet to Geronimo console - Assignee: Unassigned - Reporter: Vamsavardhana Reddy - Created: Mon Sep 18 20:12:08 PDT 2006 - Updated: Thu Oct 05 22:46:15 PDT 2006 - Votes: 1 1 Donald Woods - http://issues.apache.org/jira/browse/GERONIMO-2413 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the Begin RTC Review link under the Available Workflow Actions of the JIRA page. If you do not see your vote here, click the Vote link under the Operations section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm
snapshot repository
I see that geronimo 1.2 snapshot artifacts are published at: http://people.apache.org/repo/m2-snapshot-repository/ However, the configs aren't published at that location apparently(?) due to this portion of trunk/pom.xml being commented out @1279 !-- NOTE: Probably do not want to publish these to the repo... Or do we? moduleconfigs/module moduleassemblies/module -- If the configs were also published then we could install the ASF generated plugins in snapshot builds. I think this will become important as more of the server gets componentized as plugins. Are there any concerns with uncommenting moduleconfigs/module from the above and then publishing the configs in the snapshot repo (assuming that's the right way to go about this)? Also, after uncommenting I'll need to figure out how to publish the artifacts. Any pointers or advice how to do that would be appreciated. Thanks, Paul
[jira] Updated: (SM-692) http endpoint activation ordering
[ https://issues.apache.org/activemq/browse/SM-692?page=all ] Fabrice Dewasmes updated SM-692: Attachment: patch_ordering.txt I've provided a simple patch for ServiceUnit. It adds an arraylist that mirrors the map. When calling getEndpoints it the arraylist that is returned and thus activation appends in the right order. I'm not that satisfied with this as it's always armful to maintain two collections mirroring each other. http endpoint activation ordering - Key: SM-692 URL: https://issues.apache.org/activemq/browse/SM-692 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0 Reporter: Fabrice Dewasmes Priority: Minor Attachments: patch_ordering.txt when you use two http endpoints in the same service unit, you have no idea of which one will be activated first. in the case of one endpoint proxying another, if consumer is activated first, the WSDL is not correctly generated as it relies on the proxied endpoint WSDL. ordering of http endpoint can solve this. Another approach could be to make the consumer endpoint wait for the targeted provider to be available and then resume activation. -- 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: snapshot repository
I have always thought that we should publish the configs and assemblies. thanks david jencks On Oct 9, 2006, at 10:12 AM, Paul McMahan wrote: I see that geronimo 1.2 snapshot artifacts are published at: http://people.apache.org/repo/m2-snapshot-repository/ However, the configs aren't published at that location apparently(?) due to this portion of trunk/pom.xml being commented out @1279 !-- NOTE: Probably do not want to publish these to the repo... Or do we? moduleconfigs/module moduleassemblies/module -- If the configs were also published then we could install the ASF generated plugins in snapshot builds. I think this will become important as more of the server gets componentized as plugins. Are there any concerns with uncommenting moduleconfigs/module from the above and then publishing the configs in the snapshot repo (assuming that's the right way to go about this)? Also, after uncommenting I'll need to figure out how to publish the artifacts. Any pointers or advice how to do that would be appreciated. Thanks, Paul
Re: snapshot repository
I'm definitely in favor of publishing the configs. Without this it's difficult if not impossible to attempt to install any 1.2-snapshot plugin because dependencies cannot be fulfilled. Joe Paul McMahan wrote: I see that geronimo 1.2 snapshot artifacts are published at: http://people.apache.org/repo/m2-snapshot-repository/ However, the configs aren't published at that location apparently(?) due to this portion of trunk/pom.xml being commented out @1279 !-- NOTE: Probably do not want to publish these to the repo... Or do we? moduleconfigs/module moduleassemblies/module -- If the configs were also published then we could install the ASF generated plugins in snapshot builds. I think this will become important as more of the server gets componentized as plugins. Are there any concerns with uncommenting moduleconfigs/module from the above and then publishing the configs in the snapshot repo (assuming that's the right way to go about this)? Also, after uncommenting I'll need to figure out how to publish the artifacts. Any pointers or advice how to do that would be appreciated. Thanks, Paul
Wiki : Developing Geronimo in Eclipse
Hi, I would like to add a page to wiki with instructions for configuring eclipse for Geronimo development. What is an appropriate location for it? I will be using 'Developing Geronimo in Eclipse' as the title. It will be very small (20-25 lines) compared to its M1 counterpart. Suggestions?ThanksAnita Stay in the know. Pulse on the new Yahoo.com. Check it out.
Re: micro-G modules(configs)
On Oct 6, 2006, at 10:37 AM, Joe Bohn wrote: I couldn't quite decide what to call it either which is why I'm using the term geronimo-framework for the assembly. But I'm certainly open to other opinions. I don't envision this being something that the casual user would pick up directly. I image that we would still ship the full j2ee assembly and possibly even the minimal assembly. Micro-G would be available for more sophisticated users that wanted to build a custom image and for vendors who might pick up Micro-G, build their own custom image, and then add their own software for redistribution/sale. Framework makes sense as I think that is where people wanted to go with Geronimo based on my recollection from many e-mails and conversations. I'll pop in my 2c here given Joe's comments above. What makes sense in my twisted mind is that Micro-G provides the core wiring framework to build a server (as joe indicated). From that we install plugins to assemble a server. The question then becomes how would a user consume this? and perhaps we need to define the groups of users that Geronimo would appeal to. Here is my quick hit list: J2EE developers - these folks are interested in a server that they can use to develop and deploy J2EE applications. They are not really concerned about the plumbing of the server but are more interested in consuming ready made things like Eclipse, Geronimo, etc. to build an application. Application Developer - May not want all the gizmos of J2EE / JEE but is definitely interested in things like Servlets and Spring. They would like a server that is sized for their needs and includes the components they need for their applications to run. People that use Tomcat + other stuff fall into this category. System Developers - these folks are more in tune with the server and its various pieces. They might be interested in the Geronimo Tx Manager or other piece parts of the server. They are willing to write GBeans and other Geronimo specific artifacts to accomplish their goals. They probably want the ability to create custom server configurations. ISV's - Pretty much the same as System Developers but might have targetted deployment environments like Kiosks or embedded devices. They want to build and distribute Applications and will use Geronimo as their core runtime infrastructure. They are probably more interested in stability than innovation as their distributing applications. There are probably lots more user types but I think the above covers the spectrum pretty broadly. With that said, how do we meet their needs? If I were in their shoes I would like to be able download either pre- built server configurations (J2EE certified) or build a custom assembly. In order to allow both I wonder if it makes sense to introduce the concept of server templates. Here is what I mean: Since every assembly we make now is hand turned we could make the configuration simpler so a user could express their intended server configuration through an XML file and we provide a generic assembler that would read this template, resolve dependencies and spit out a binary server config that could be distributed (downloaded as a server). The template would allow for command line building of the server such that a user would not need to interactively build it (GShell ?) This means that there would be a distribution of Geronimo that included micro-G along with all the gorp we normally build. The gorp would be in a repository format (like plugins or the same) so that a user could use templates to build a server without being network connected if they so chose). So we would make the following available for distribution: Geronimo J(2)EE certified (1.4 / 5.0, etc.) Tomcat / Jetty Minimal Tomcat / Jetty Micro-G (all components to build yur own custom server). So in effect, the J(2)EE and Minimal servers would simply be templates that happen to build server assemblies. Of these, the Geronimo team certifies the J2EE one. Anyway, should I put these ideas on the cwiki for discussion / clarification? It sounds that this is the general direction we're headed in and is rather unique. If we agree in concept it would be good to get our web page updated to reflect these goals (vision) of the project so people can see where we're going and get involved if they're interested. thoughts? The thinking above is really a comglomeration of lots of discussion on the list. Matt Hogstrom [EMAIL PROTECTED]
Re: How to settup a plugin site?
On 10/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Could you give a quick email to explain how to set up a plugin site, what is needed, directory and xml layouts? Just like a Maven 2 repo, except with a geronimo-plugins.xml in the root directory. The only files that are actually used by the current plugin installer are the actual archives in question, the maven-metadata.xml files that list the available versions for each artifact, and the geronimo-plugins.xml in the root. Note that many plugins require separate JARs, which can either be on the same site or loaded from a secondary repo like ibiblio, but for versionless dependencies it's going to take the most recent version of the artifact in question from the first site that has any matching version at all. Thanks, Aaron
Re: How to settup a plugin site?
Ok...thanks...I'll give it a shot. Jeff Aaron Mulder wrote: On 10/9/06, Jeff Genender [EMAIL PROTECTED] wrote: Could you give a quick email to explain how to set up a plugin site, what is needed, directory and xml layouts? Just like a Maven 2 repo, except with a geronimo-plugins.xml in the root directory. The only files that are actually used by the current plugin installer are the actual archives in question, the maven-metadata.xml files that list the available versions for each artifact, and the geronimo-plugins.xml in the root. Note that many plugins require separate JARs, which can either be on the same site or loaded from a secondary repo like ibiblio, but for versionless dependencies it's going to take the most recent version of the artifact in question from the first site that has any matching version at all. Thanks, Aaron
Re: micro-G modules(configs)
On 10/5/06, David Jencks [EMAIL PROTECTED] wrote: Online-deployer is empty just like the rest of the configs that are servers. It relies on manifest classpath and the configuration it contains. IIRC online-deployer.car is the same file as deployer.jar. I guess you're right that a little more might be good. I was figuring that being able to add plugins might be enough. What connects to the plugin installer? Ah, OK. We need the command-line deploy tool (which I gather means online-deployer as well as j2ee-security, and perhaps per Joe's comment j2ee-deployer). The actual plugin installer is located in the system module which I think is in rmi-naming, and IIRC the deploy tool just uses the remote Kernel proxy thingy to talk to the plugin installer, but I'd have to look to be sure. It may be that j2ee-deployer is not required in order to use the search-plugins and install-plugins commands but would be required in order to use the other commands. But it may also be that JSR-88 isn't in the class path without e.g. j2ee-deployer and therefore the classes used by the deploy tool couldn't be located and it would die. If that's the case, we may just be able to shift some of the JAR dependencies around to avoid needing the full j2ee-deployer... Thanks, Aaron
Re: micro-G modules(configs)
On Oct 9, 2006, at 12:55 PM, Aaron Mulder wrote: On 10/5/06, David Jencks [EMAIL PROTECTED] wrote: Online-deployer is empty just like the rest of the configs that are servers. It relies on manifest classpath and the configuration it contains. IIRC online-deployer.car is the same file as deployer.jar. I guess you're right that a little more might be good. I was figuring that being able to add plugins might be enough. What connects to the plugin installer? Ah, OK. We need the command-line deploy tool (which I gather means online-deployer as well as j2ee-security, and perhaps per Joe's comment j2ee-deployer). The actual plugin installer is located in the system module which I think is in rmi-naming, and IIRC the deploy tool just uses the remote Kernel proxy thingy to talk to the plugin installer, but I'd have to look to be sure. It may be that j2ee-deployer is not required in order to use the search-plugins and install-plugins commands but would be required in order to use the other commands. But it may also be that JSR-88 isn't in the class path without e.g. j2ee-deployer and therefore the classes used by the deploy tool couldn't be located and it would die. If that's the case, we may just be able to shift some of the JAR dependencies around to avoid needing the full j2ee-deployer... We _really_ shouldn't need to start j2ee-deployer in order to do any of this. If there really are problems and the solutions aren't obvious please start opening jiras for them. thanks david jencks Thanks, Aaron
Apache Directory for Geronimo
Hi All, is there any plan to bring back to Geronimo the Directory Server? Having to install it afterwards every time is kind of annoying. Is it too heavy to include? Cheers! Hernan
Re: http endpoint activation ordering
OK I will provide another patch tomorrow morning.
Thanks
Fabrice
gnodet wrote:
But if we use a LinkedHashMap, the map keeps the
order of keys as they were inserted:
This linked list defines the iteration ordering,
which is normally the order in which keys were
inserted into the map.
So it should be safe to use this implementation.
The map does not sort on key values like a TreeMap does.
On 10/9/06, Fabrice Dewasmes [EMAIL PROTECTED] wrote:
gnodet wrote:
Endpoints order should be kept inside an SU.
Could you raise a JIRA for that, it should be easy
to fix by replacing the used map implementation by
an ordered map.
In fact, endpoints are stored in a HashMap with keys generated by
EndpointSupport class and which are Strings that look like :
{namespace}servicename:endpointname
using an ordered map won't solve anything as you've got no indication of
ordering except the natural order, and I don't know if we can safely
prefix
the key string with the order number or even use an object as a key as
the
string is used to build destination for routing.
Fabrice
--
View this message in context:
http://www.nabble.com/http-endpoint-activation-ordering-tf2395343.html#a6718919
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
--
View this message in context:
http://www.nabble.com/http-endpoint-activation-ordering-tf2395343.html#a6723223
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: How to settup a plugin site?
On 10/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: Just like a Maven 2 repo, except with a geronimo-plugins.xml in the root directory. The only files that are actually used by the current plugin installer are the actual archives in question, the maven-metadata.xml files that list the available versions for each artifact, and the geronimo-plugins.xml in the root. Note that many plugins require separate JARs, which can either be on the same site or loaded from a secondary repo like ibiblio, but for versionless dependencies it's going to take the most recent version of the artifact in question from the first site that has any matching version at all. Is there a documentation page for it? If not, I'd like to create one, but I wonder where it should go. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: How to settup a plugin site?
Jacek, This would be great! Jeff Jacek Laskowski wrote: On 10/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: Just like a Maven 2 repo, except with a geronimo-plugins.xml in the root directory. The only files that are actually used by the current plugin installer are the actual archives in question, the maven-metadata.xml files that list the available versions for each artifact, and the geronimo-plugins.xml in the root. Note that many plugins require separate JARs, which can either be on the same site or loaded from a secondary repo like ibiblio, but for versionless dependencies it's going to take the most recent version of the artifact in question from the first site that has any matching version at all. Is there a documentation page for it? If not, I'd like to create one, but I wonder where it should go. Jacek
Re: How to settup a plugin site?
Hey Jacek, thanks for jumping in on this one, it's very much needed ;-) how does the Apache Geronimo Development space sound to you? ( http://cwiki.apache.org/GMOxDEV ) We'll have to work on reorganizing the space's home page though. Cheers! Hernan Jacek Laskowski wrote: On 10/9/06, Aaron Mulder [EMAIL PROTECTED] wrote: Just like a Maven 2 repo, except with a geronimo-plugins.xml in the root directory. The only files that are actually used by the current plugin installer are the actual archives in question, the maven-metadata.xml files that list the available versions for each artifact, and the geronimo-plugins.xml in the root. Note that many plugins require separate JARs, which can either be on the same site or loaded from a secondary repo like ibiblio, but for versionless dependencies it's going to take the most recent version of the artifact in question from the first site that has any matching version at all. Is there a documentation page for it? If not, I'd like to create one, but I wonder where it should go. Jacek
Re: Clover plugin
Unfortunately clover is very picky about the location, which is why I had to add those hacks to get clover working.--jasonOn Oct 9, 2006, at 5:26 AM, anita kulshreshtha wrote:Jason Dillon [EMAIL PROTECTED] wrote: Why? If we turn clover back on, then these classes will need to be copied to target/clover/classes anyways.What is the problem with Eclipse?Currently if we use 'target' as the default output folder in eclipse, the schemaorg_apache_xmlbeans classes are lost. We are manually adding target/clover/classes as 'classes folder' to the BuildPath for *-builder modules. If clover is not particular about this location, we could use a neutral name like xmlbeans-classes. WDYS? Thanks Anita--jasonOn Oct 8, 2006, at 6:01 AM, anita kulshreshtha wrote: I would like to copy xmlbeans classes to target/xmlbeans-classes instead of target/clover/classes. This directory will be used by Eclipse. We are currently using target/clover/classes for this purpose.thanksAnitaJason Dillon [EMAIL PROTECTED] wrote: That and clover caused to many problems... but there is a new version of the plugin out, need to revisit.--jasonOn Oct 6, 2006, at 8:31 AM, Prasad Kashyap wrote: Hi Anita, The clover plugin is used to get test coverage on our modules. Eg: http://geronimo.apache.org/maven/server/modules/geronimo-activation/ clover/index.html But I don't see the maven-clover-plugin being executed along with the other reports in the genesis' project-config. I don't know where it it is being called from. Cheers Prasad On 10/6/06, anita kulshreshtha wrote: The *-builder modules are copying schemaorg_apache_xmlbeans classes to target/clover/classes. I was trying to import *-builder in eclipse. Eclipse is not handing these classes properly and I am getting ".can not be resolved" errors. This needs to be fixed. Thanks Anita - Original Message From: Jacek Laskowski To: dev@geronimo.apache.org Sent: Friday, October 6, 2006 9:40:35 AM Subject: Re: Clover plugin On 10/6/06, anita kulshreshtha wrote: Oops! I should have stated the question more clearly. I do mean how it is being used in Geronimo? I can't find any reference to clover plugin in poms (as a report) so unless someone runs it via mvn clover:instrument clover:clover it's not used at all. Why? Jacek -- Jacek Laskowski http://www.laskowski.net.pl Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail.
[jira] Created: (GERONIMO-2478) ContextForwardServlet should have a registration mechanism
ContextForwardServlet should have a registration mechanism -- Key: GERONIMO-2478 URL: http://issues.apache.org/jira/browse/GERONIMO-2478 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Reporter: Aaron Mulder Fix For: 1.1.2, 1.2 Currently the ContextForwardServlet must be deployed separately for each URL path to redirect. This does not work well for plugins, nor will it work well for a more fine-grained console composed of multiple optional bits of functionality. Instead, the ContextForwardServlet should listen on a single path (say, /portlet-resources) and then have a registration mechanism that lets you add sub-mappings dynamically (/portlet-resources/foo/* - web app 1 and /portlet-resources/bar/* - web app 2). Presumably something where it has a collection of GBeans and each web app that wants to register some forward with the console deploys one or more instances of the web app. -- 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: snapshot repository
I think its fine to enable the configs for snapshot deployment, but probably not the assemblies... they are way too big. --jason On Oct 9, 2006, at 8:12 AM, Paul McMahan wrote: I see that geronimo 1.2 snapshot artifacts are published at: http://people.apache.org/repo/m2-snapshot-repository/ However, the configs aren't published at that location apparently(?) due to this portion of trunk/pom.xml being commented out @1279 !-- NOTE: Probably do not want to publish these to the repo... Or do we? moduleconfigs/module moduleassemblies/module -- If the configs were also published then we could install the ASF generated plugins in snapshot builds. I think this will become important as more of the server gets componentized as plugins. Are there any concerns with uncommenting moduleconfigs/module from the above and then publishing the configs in the snapshot repo (assuming that's the right way to go about this)? Also, after uncommenting I'll need to figure out how to publish the artifacts. Any pointers or advice how to do that would be appreciated. Thanks, Paul
Re: snapshot repository
FYI, the car plugin was not configured to run any default goals in the deploy phase. I'm about to fix and deploy a volley of config snaps. --jason On Oct 9, 2006, at 8:12 AM, Paul McMahan wrote: I see that geronimo 1.2 snapshot artifacts are published at: http://people.apache.org/repo/m2-snapshot-repository/ However, the configs aren't published at that location apparently(?) due to this portion of trunk/pom.xml being commented out @1279 !-- NOTE: Probably do not want to publish these to the repo... Or do we? moduleconfigs/module moduleassemblies/module -- If the configs were also published then we could install the ASF generated plugins in snapshot builds. I think this will become important as more of the server gets componentized as plugins. Are there any concerns with uncommenting moduleconfigs/module from the above and then publishing the configs in the snapshot repo (assuming that's the right way to go about this)? Also, after uncommenting I'll need to figure out how to publish the artifacts. Any pointers or advice how to do that would be appreciated. Thanks, Paul
[jira] Created: (GERONIMO-2479) j2ee remote ejb clients should look for localhost not 0.0.0.0 by default
j2ee remote ejb clients should look for localhost not 0.0.0.0 by default -- Key: GERONIMO-2479 URL: http://issues.apache.org/jira/browse/GERONIMO-2479 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 The OpenEjbClientRemoteRefBuilder is misconfigured to try to connect to 0.0.0.0 which doesn't make sense. Change to localhost. -- 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: snapshot repository
Ugh, some configs are kinda biggish :-( Not sure that infra is going to be happy if we publish snaps of these very often. --jason On Oct 9, 2006, at 8:12 AM, Paul McMahan wrote: I see that geronimo 1.2 snapshot artifacts are published at: http://people.apache.org/repo/m2-snapshot-repository/ However, the configs aren't published at that location apparently(?) due to this portion of trunk/pom.xml being commented out @1279 !-- NOTE: Probably do not want to publish these to the repo... Or do we? moduleconfigs/module moduleassemblies/module -- If the configs were also published then we could install the ASF generated plugins in snapshot builds. I think this will become important as more of the server gets componentized as plugins. Are there any concerns with uncommenting moduleconfigs/module from the above and then publishing the configs in the snapshot repo (assuming that's the right way to go about this)? Also, after uncommenting I'll need to figure out how to publish the artifacts. Any pointers or advice how to do that would be appreciated. Thanks, Paul
[jira] Created: (GERONIMO-2480) Plugin installer status sticks on Searching for X at Y while downloading
Plugin installer status sticks on Searching for X at Y while downloading -- Key: GERONIMO-2480 URL: http://issues.apache.org/jira/browse/GERONIMO-2480 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 1.1.1 Reporter: Aaron Mulder Fix For: 1.1.2, 1.2 The plugin installer should show status Downloading X from Y during a download, but it seems to get stuck on the previous Searching for... message while showing the download percentage. -- 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: (SM-695) Dynamic HTTP provider endpoint
Dynamic HTTP provider endpoint -- Key: SM-695 URL: https://issues.apache.org/activemq/browse/SM-695 Project: ServiceMix Issue Type: New Feature Components: servicemix-http Affects Versions: 3.0 Reporter: James Lorenzen Priority: Minor It would be benficial to add functionaility to the HTTP BC to allow consumers to specify the provider locationURI through a NormalizedMessage property. Please see this thread for related information: http://www.nabble.com/http-endpoint-in-provider-mode%3A-dynamic-destination--tf1413771.html#a6721824 Our team plans on adding some code to the HTTP BC that first looks to see if the NormalizedMessage contains a specific property containing the value for the destination. Therefore a consumer could create a new NormalizedMessage and call setProperty to set the destination URI. If the HTTP BC detects this property he routes the request to this URI; otherwise it continues as normal and uses the locationURI specified in the xbean.xml file. We plan on making and testing this change in the next couple of days. After which we will reply back with the modifications. -- 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
[ANNOUNCE] Welcom Prasad Kashyap as our newest committer
All, We're pleased to let you know that we have a new committer in our midst. Prasad Kashyap has recently accepted an invitation to join the Geronimo project. Prasad has been active on Geronimo for quite some time and has provided numerous patches for the Maven2 build as well as automated testing. He has been very helpful to users and developers, alike. We're confident that Prasad will be a great addition to the project. Welcome Prasad! Matt Hogstrom [EMAIL PROTECTED]
[XBEAN] xbean-spring-2.6.jar incompatible with Spring 2.0 release
Folks, I think there is some incompatibility of Xbeans with the Spring 2.0 version just released last week. It looks like org.springframework.beans.factory.support.ReaderContext was moved to org.springframework.beans.parsing.ReaderContext . This is causing NoClassDefFoundErrors when trying to run the new release of Spring. Just to let you know.
Re: [ANNOUNCE] Welcom Prasad Kashyap as our newest committer
Congratulations Prasad. --vamsiOn 10/10/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All,We're pleased to let you know that we have a new committer in ourmidst.Prasad Kashyap has recently accepted an invitation to jointhe Geronimo project.Prasad has been active on Geronimo for quite some time and has provided numerous patches for the Maven2 build aswell as automated testing.He has been very helpful to users anddevelopers, alike.We're confident that Prasad will be a great addition to the project. Welcome Prasad!Matt Hogstrom[EMAIL PROTECTED]
Re: [ANNOUNCE] Welcom Prasad Kashyap as our newest committer
Congrats Prasad! Regards, Alan On Oct 9, 2006, at 8:07 PM, Matt Hogstrom wrote: All, We're pleased to let you know that we have a new committer in our midst. Prasad Kashyap has recently accepted an invitation to join the Geronimo project. Prasad has been active on Geronimo for quite some time and has provided numerous patches for the Maven2 build as well as automated testing. He has been very helpful to users and developers, alike. We're confident that Prasad will be a great addition to the project. Welcome Prasad! Matt Hogstrom [EMAIL PROTECTED]
Re: [ANNOUNCE] Welcom Prasad Kashyap as our newest committer
Congrats Prasad -dain On Oct 9, 2006, at 10:07 PM, Matt Hogstrom wrote: All, We're pleased to let you know that we have a new committer in our midst. Prasad Kashyap has recently accepted an invitation to join the Geronimo project. Prasad has been active on Geronimo for quite some time and has provided numerous patches for the Maven2 build as well as automated testing. He has been very helpful to users and developers, alike. We're confident that Prasad will be a great addition to the project. Welcome Prasad! Matt Hogstrom [EMAIL PROTECTED]
[jira] Resolved: (SM-696) Add an operation to the EndpointMBean to allow testing the endpoint through jmx
[ https://issues.apache.org/activemq/browse/SM-696?page=all ] Guillaume Nodet resolved SM-696. Resolution: Fixed Author: gnodet Date: Mon Oct 9 20:55:25 2006 New Revision: 454600 URL: http://svn.apache.org/viewvc?view=revrev=454600 Log: SM-696: Add an operation to the EndpointMBean to allow testing the endpoint through jmx Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/Endpoint.java Add an operation to the EndpointMBean to allow testing the endpoint through jmx --- Key: SM-696 URL: https://issues.apache.org/activemq/browse/SM-696 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Affects Versions: 3.0 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.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
[Results] Priorities for 1.2
The results are in! We had a good number of respondents, and the results are quite clear. Last night I spent a few hours tallying the results and analyzing them. There was a very clean ordering from the most popular to the least. Additionally, the features clearly fell into categories. Top --- These features were easily visually separated from the others. They tended to have a lot of #1 ranking and almost no low rankings. Additionally, these are the most clearly defined, have several people working on them, and are already mostly complete. This the feature set that will define the 1.2 release. Full Java 5 support (really is certification on Java 5) - Dain, Jencks and Rick OpenJPA integration - Blevins and Jencks Yoko ORB support - Rick and Jencks Global JNDI - Dain and Jencks Some support These features had a few very few 1-2 rankings, but many 3-5 rankings. Additionally, the also had a a few lower half rankings. Additionally, Console usability improvements and More server modularization via plugins are improvements and not features. I do not believe that anyone is working in Console extensibility or OpenEJB 3.0 integration with @Stateless with an eye for inclusion in 1.2 and these features are likely to be quite destabilizing. Therefor, they will not be included in the 1.2 release. Console usability improvements Console extensibility More server modularization via plugins OpenEJB 3.0 integration with @Stateless Little Support -- These features had a small amount of support noted buy a single vote for a top 3 ranking, and normally a supporting vote for a top 5 ranking (except CMP which only had a single #2 vote). Therefor, I think these features are best demonstrated via a plugin or branch to gather more support before they are included in any release. More out of the box samples Geronimo OSGi bundle GShell integration CMP improvements No Support -- These features had no rankings in the top half (1-7). JAF 1.1 Jetspeed integration -dain.
Re: [Results] Priorities for 1.2
For those that are interested, here is the raw data: http://cwiki.apache.org/GMOxDEV/priorities-12-results.html -dain On 10/9/06, Dain Sundstrom [EMAIL PROTECTED] wrote: The results are in! We had a good number of respondents, and the results are quite clear. Last night I spent a few hours tallying the results and analyzing them. There was a very clean ordering from the most popular to the least. Additionally, the features clearly fell into categories. Top --- These features were easily visually separated from the others. They tended to have a lot of #1 ranking and almost no low rankings. Additionally, these are the most clearly defined, have several people working on them, and are already mostly complete. This the feature set that will define the 1.2 release. Full Java 5 support (really is certification on Java 5) - Dain, Jencks and Rick OpenJPA integration - Blevins and Jencks Yoko ORB support - Rick and Jencks Global JNDI - Dain and Jencks Some support These features had a few very few 1-2 rankings, but many 3-5 rankings. Additionally, the also had a a few lower half rankings. Additionally, Console usability improvements and More server modularization via plugins are improvements and not features. I do not believe that anyone is working in Console extensibility or OpenEJB 3.0 integration with @Stateless with an eye for inclusion in 1.2 and these features are likely to be quite destabilizing. Therefor, they will not be included in the 1.2 release. Console usability improvements Console extensibility More server modularization via plugins OpenEJB 3.0 integration with @Stateless Little Support -- These features had a small amount of support noted buy a single vote for a top 3 ranking, and normally a supporting vote for a top 5 ranking (except CMP which only had a single #2 vote). Therefor, I think these features are best demonstrated via a plugin or branch to gather more support before they are included in any release. More out of the box samples Geronimo OSGi bundle GShell integration CMP improvements No Support -- These features had no rankings in the top half (1-7). JAF 1.1 Jetspeed integration -dain.
