Re: Separate client/server packages...
On 10/4/06, Komandur [EMAIL PROTECTED] wrote: Is there a way to generate a light weight clientside package (without any broker specifics) when a version is released ? You could try patching the maven build to make a new smaller client jar if you like? -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (AMQ-954) Compilation error when building activemq-web with test enabled.
[ https://issues.apache.org/activemq/browse/AMQ-954?page=all ] Fritz Oconer resolved AMQ-954. -- Resolution: Fixed Done, the updated the activemq-core-test.jar with the correct content. Compilation error when building activemq-web with test enabled. --- Key: AMQ-954 URL: https://issues.apache.org/activemq/browse/AMQ-954 Project: ActiveMQ Issue Type: Bug Reporter: Fritz Oconer Assigned To: Fritz Oconer Fix For: 4.1 Exception below is thrown when building activemq-web with test enabled. Compiling 1 source file to /home/continuum/repository/activemq4/trunk/activemq-web/target/test-classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/continuum/repository/activemq4/trunk/activemq-web/src/test/java/org/apache/activemq/web/JettyServer.java:[22,32] package org.apache.activemq.demo does not exist /home/continuum/repository/activemq4/trunk/activemq-web/src/test/java/org/apache/activemq/web/JettyServer.java:[54,8] cannot find symbol symbol : variable DefaultQueueSender location: class org.apache.activemq.web.JettyServer -- 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: (AMQ-956) Build Issue on snapshot timestamp when downloading transitive dependencies.
Build Issue on snapshot timestamp when downloading transitive dependencies. --- Key: AMQ-956 URL: https://issues.apache.org/activemq/browse/AMQ-956 Project: ActiveMQ Issue Type: Improvement Reporter: Fritz Oconer Assigned To: Fritz Oconer Fix For: 4.1 There are instances when build is unable to download an activemq transitive dependencies due to difference in the snapshot timestamp. -- 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] Resolved: (AMQ-956) Build Issue on snapshot timestamp when downloading transitive dependencies.
[ https://issues.apache.org/activemq/browse/AMQ-956?page=all ]
Fritz Oconer resolved AMQ-956.
--
Resolution: Fixed
Done, created an activemq-version property that will be used instead of using
${pom.version}.
Build Issue on snapshot timestamp when downloading transitive dependencies.
---
Key: AMQ-956
URL: https://issues.apache.org/activemq/browse/AMQ-956
Project: ActiveMQ
Issue Type: Improvement
Reporter: Fritz Oconer
Assigned To: Fritz Oconer
Fix For: 4.1
There are instances when build is unable to download an activemq transitive
dependencies due to difference in the snapshot timestamp.
--
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-956) Build Issue on snapshot timestamp when downloading transitive dependencies.
[ https://issues.apache.org/activemq/browse/AMQ-956?page=comments#action_37105 ] Fritz Oconer commented on AMQ-956: -- revision: 453166 Build Issue on snapshot timestamp when downloading transitive dependencies. --- Key: AMQ-956 URL: https://issues.apache.org/activemq/browse/AMQ-956 Project: ActiveMQ Issue Type: Improvement Reporter: Fritz Oconer Assigned To: Fritz Oconer Fix For: 4.1 There are instances when build is unable to download an activemq transitive dependencies due to difference in the snapshot timestamp. -- 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-876) Kaha DB cannot locate queue data files
[ https://issues.apache.org/activemq/browse/AMQ-876?page=comments#action_37106 ] Rob Davies commented on AMQ-876: Hi Vadim, would you mind trying the latest code ? I've done some bug fixes in the kaha area today - unfortunately one of the bug fixes means it's no longer backwards compatible cheers, Rob Kaha DB cannot locate queue data files -- Key: AMQ-876 URL: https://issues.apache.org/activemq/browse/AMQ-876 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1 Environment: WinXP Reporter: Vadim Pesochinskiy Assigned To: Rob Davies Fix For: 4.1 Attachments: test.zip Keep getting exception below. Note that you are looking for queue-data-1, but actual file name is data-queue-data-1 $ pwd /cygdrive/d/amq/activemq-kaha/kaha.db $ ls data-kaha-1 data-queue-data-1 index-kaha index-queue-data index-transactions javax.jms.JMSException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:46) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1154) at org.apache.activemq.TransactionContext.commit(TransactionContext.java:260) at org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:464) at com.barra.cp.common.io.MultiQueueReceiver.onMessage(MultiQueueReceiver.java:163) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.runMultiQueue(SingleMessageMultiQueueReceiver.java:176) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.doRun(SingleMessageMultiQueueReceiver.java:143) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.run(SingleMessageMultiQueueReceiver.java:124) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.activemq.kaha.RuntimeStoreException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:340) at org.apache.activemq.kaha.impl.MapContainerImpl.remove(MapContainerImpl.java:265) at org.apache.activemq.store.kahadaptor.KahaMessageStore.removeMessage(KahaMessageStore.java:68) at org.apache.activemq.store.kahadaptor.KahaTransaction.commit(KahaTransaction.java:92) at org.apache.activemq.store.kahadaptor.KahaTransactionStore.commit(KahaTransactionStore.java:95) at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:68) at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:154) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:102) at org.apache.activemq.broker.AbstractConnection.processCommitTransactionOnePhase(AbstractConnection.java:330) at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:99) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:228) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:63) 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.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:123) 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:127) ... 1 more Caused by: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.DataManager.getDataFile(DataManager.java:117) at org.apache.activemq.kaha.impl.StoreDataReader.readItem(StoreDataReader.java:62) at org.apache.activemq.kaha.impl.DataManager.readItem(DataManager.java:121) at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:337) ... 20 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
Re: [activemq-cpp] It now compiles under cygwin
Yep! You still need to generate the ./configure file in the base directory using ./autogen.sh but then do a: mkdr out cd out ../configure make On 10/5/06, Bish, Tim [EMAIL PROTECTED] wrote: Is there anyway that this build system can be modified to put the object files and other build artifacts into someplace other than the root dir of the code being built? This really clutter ups the workspace. Previoulsy we had everything going into the out dir under the root activemq folder. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, October 03, 2006 4:08 PM To: activemq-dev@geronimo.apache.org Subject: Re: [activemq-cpp] It now compiles under cygwin Ah.. I just did a source build of cppunit and I see what's happening. The default prefix for cppunit is /usr/local, so it m4 file got installed to /usr/local/share/aclocal which is not picked up automatically. If we configure cppunit with ./configure --prefix=/usr Then everything should work better out of the box. Including when we configure activemq-cpp as now I have to use: ./configure --with-cppunit-prefix=/usr/local To let it know where cppunit is at (that's if I want to run the unit tests). On 10/3/06, Bish, Tim [EMAIL PROTECTED] wrote: AC_DEFUN is line 17 dnl AM_PATH_LIBMCRYPT([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libmcrypt, and define LIBMCRYPT_CFLAGS and LIBMCRYPT_LIBS dnl AC_DEFUN(AM_PATH_LIBMCRYPT, Change this line to: AC_DEFUN([AM_PATH_LIBMCRYPT], K, that got rid of that warning. doh.. I may need to look into this some more. Basically what you want to do is installed the cppunit.m4 file to either the activemq-cpp/m4 directory or the /usr/share/aclocal Once it's there it should get picked up and be good to go. But I would have thought that if you built cppunit from source it would have installed the m4 file to the right place. We should look into seeing if that .m4 file can be redistributed so that we can just check it into our m4 directory. I've got a feeling that it can be redistributed since it just gets sourced into the configure script when you run autogen.sh I put cppunit.m4 in my activemq-cpp m4 folder and its building now. I may just move that over the /usr/shar/alcohol as it should be there anyway. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
RE: [activemq-cpp] It now compiles under cygwin
What happens when I add new classes, do I have to rerun ./configure everytime I and files to the Makefile.am? I know nothing about automake. I've noticed that the builds seem to take about twice as long as they used to. Yep! You still need to generate the ./configure file in the base directory using ./autogen.sh but then do a: mkdr out cd out ../configure make On 10/5/06, Bish, Tim [EMAIL PROTECTED] wrote: Is there anyway that this build system can be modified to put the object files and other build artifacts into someplace other than the root dir of the code being built? This really clutter ups the workspace. Previoulsy we had everything going into the out dir under the root activemq folder. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, October 03, 2006 4:08 PM To: activemq-dev@geronimo.apache.org Subject: Re: [activemq-cpp] It now compiles under cygwin Ah.. I just did a source build of cppunit and I see what's happening. The default prefix for cppunit is /usr/local, so it m4 file got installed to /usr/local/share/aclocal which is not picked up automatically. If we configure cppunit with ./configure --prefix=/usr Then everything should work better out of the box. Including when we configure activemq-cpp as now I have to use: ./configure --with-cppunit-prefix=/usr/local To let it know where cppunit is at (that's if I want to run the unit tests). On 10/3/06, Bish, Tim [EMAIL PROTECTED] wrote: AC_DEFUN is line 17 dnl AM_PATH_LIBMCRYPT([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libmcrypt, and define LIBMCRYPT_CFLAGS and LIBMCRYPT_LIBS dnl AC_DEFUN(AM_PATH_LIBMCRYPT, Change this line to: AC_DEFUN([AM_PATH_LIBMCRYPT], K, that got rid of that warning. doh.. I may need to look into this some more. Basically what you want to do is installed the cppunit.m4 file to either the activemq-cpp/m4 directory or the /usr/share/aclocal Once it's there it should get picked up and be good to go. But I would have thought that if you built cppunit from source it would have installed the m4 file to the right place. We should look into seeing if that .m4 file can be redistributed so that we can just check it into our m4 directory. I've got a feeling that it can be redistributed since it just gets sourced into the configure script when you run autogen.sh I put cppunit.m4 in my activemq-cpp m4 folder and its building now. I may just move that over the /usr/shar/alcohol as it should be there anyway. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (AMQ-813) can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module
[ https://issues.apache.org/activemq/browse/AMQ-813?page=comments#action_37110 ] Gray Watson commented on AMQ-813: - This seems to generate another fault. With 4.1.0.0-fuse, I'm get a whole ton of the following, possibly in an infinite loop: 2006-10-05 16:07:52,178 [DefaultMessageListenerContainer-45] ERROR org.springframework.jms.listener.DefaultMessageListenerContainer - Setup of JMS message listener invoker failed - trying to recover javax.jms.JMSException: Peer disconnected. at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57) at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1119) at org.apache.activemq.ActiveMQSession.init(ActiveMQSession.java:225) at org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:278) at org.apache.activemq.pool.SessionPool.createSession(SessionPool.java:112) at org.apache.activemq.pool.SessionPool.makeObject(SessionPool.java:80) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:840) at org.apache.activemq.pool.SessionPool.borrowSession(SessionPool.java:55) at org.apache.activemq.pool.ConnectionPool.createSession(ConnectionPool.java:70) at org.apache.activemq.pool.PooledConnection.createSession(PooledConnection.java:129) at org.springframework.jms.listener.AbstractMessageListenerContainer.createSession(AbstractMessageListenerContainer.java:1000) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.initResourcesIfNecessary(DefaultMessageListenerContainer.java:882) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:870) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:824) at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsyncTaskExecutor.java:203) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.IOException: Peer disconnected. at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:81) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44) at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:58) at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1117) ... 14 more can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module --- Key: AMQ-813 URL: https://issues.apache.org/activemq/browse/AMQ-813 Project: ActiveMQ Issue Type: Bug Reporter: james strachan Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 See attached thread dump. I think we just need to use a timeout on the close operations (such as to close consumers, sessions, producers) Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing): Shutdown prio=1 tid=0x08385960 nid=0x5e99 in Object.wait() [0xaed7d000..0xaed7e130] at java.lang.Object.wait(Native Method) - waiting on 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75) - locked 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318) at org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:41) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:72) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1660) at org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516) at org.apache.activemq.web.WebClient.closeConsumers(WebClient.java:135) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.close(WebClient.java:145) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.valueUnbound(WebClient.java:318) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:899) at
Re: [activemq-cpp] It now compiles under cygwin
On 10/5/06, Bish, Tim [EMAIL PROTECTED] wrote: What happens when I add new classes, do I have to rerun ./configure everytime I and files to the Makefile.am? I know nothing about when you modify the Makefile.am files, re-run ./autogen.sh and then ./configure automake. I've noticed that the builds seem to take about twice as long as they used to. Not sure! Yep! You still need to generate the ./configure file in the base directory using ./autogen.sh but then do a: mkdr out cd out ../configure make On 10/5/06, Bish, Tim [EMAIL PROTECTED] wrote: Is there anyway that this build system can be modified to put the object files and other build artifacts into someplace other than the root dir of the code being built? This really clutter ups the workspace. Previoulsy we had everything going into the out dir under the root activemq folder. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, October 03, 2006 4:08 PM To: activemq-dev@geronimo.apache.org Subject: Re: [activemq-cpp] It now compiles under cygwin Ah.. I just did a source build of cppunit and I see what's happening. The default prefix for cppunit is /usr/local, so it m4 file got installed to /usr/local/share/aclocal which is not picked up automatically. If we configure cppunit with ./configure --prefix=/usr Then everything should work better out of the box. Including when we configure activemq-cpp as now I have to use: ./configure --with-cppunit-prefix=/usr/local To let it know where cppunit is at (that's if I want to run the unit tests). On 10/3/06, Bish, Tim [EMAIL PROTECTED] wrote: AC_DEFUN is line 17 dnl AM_PATH_LIBMCRYPT([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libmcrypt, and define LIBMCRYPT_CFLAGS and LIBMCRYPT_LIBS dnl AC_DEFUN(AM_PATH_LIBMCRYPT, Change this line to: AC_DEFUN([AM_PATH_LIBMCRYPT], K, that got rid of that warning. doh.. I may need to look into this some more. Basically what you want to do is installed the cppunit.m4 file to either the activemq-cpp/m4 directory or the /usr/share/aclocal Once it's there it should get picked up and be good to go. But I would have thought that if you built cppunit from source it would have installed the m4 file to the right place. We should look into seeing if that .m4 file can be redistributed so that we can just check it into our m4 directory. I've got a feeling that it can be redistributed since it just gets sourced into the configure script when you run autogen.sh I put cppunit.m4 in my activemq-cpp m4 folder and its building now. I may just move that over the /usr/shar/alcohol as it should be there anyway. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (SM-676) In the instance2 of the ws-notification example, the org.apache.servicemix.tck.ReceiverComponent should be removed
In the instance2 of the ws-notification example, the org.apache.servicemix.tck.ReceiverComponent should be removed -- Key: SM-676 URL: https://issues.apache.org/activemq/browse/SM-676 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.0 Reporter: Guillaume Nodet Priority: Trivial Fix For: 3.0.1, 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-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
[ https://issues.apache.org/activemq/browse/SM-582?page=comments#action_37102 ] Grant McDonald commented on SM-582: --- Committed changes. Adding servicemix-components\src\main\java\org\apache\servicemix\components\validation\CountingErrorHandlerFactory.java Sending servicemix-components\src\main\java\org\apache\servicemix\components\validation\MessageAggregatingErrorHandler.java Adding servicemix-components\src\main\java\org\apache\servicemix\components\validation\MessageAggregatingErrorHandlerFactory.java Adding servicemix-components\src\main\java\org\apache\servicemix\components\validation\MessageAwareErrorHandlerFactory.java Sending servicemix-components\src\main\java\org\apache\servicemix\components\validation\ValidateComponent.java Sending servicemix-components\src\test\resources\org\apache\servicemix\components\validation\example.xml Transmitting file data .. Committed revision 453155. Current ErrorHandler implementation used by ValidateComponent is not thread safe Key: SM-582 URL: https://issues.apache.org/activemq/browse/SM-582 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: incubation Environment: Ubuntu Linux 6.06 LTS, WinXP SP2 Reporter: Grant McDonald Assigned To: Grant McDonald Attachments: SM-582.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Due to the error handler being dependency injected it is a singleton which unfortunately stores state across invocations. The solution is to use the factory pattern, whereby an ErrorHandlerFactory implementation is created as the singleton which has properties containing the arguments to pass to the ErrorHandler when it is instantiated. -- 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: (SM-678) Jsr181Component not using SU classloader to load service interface
Jsr181Component not using SU classloader to load service interface -- Key: SM-678 URL: https://issues.apache.org/activemq/browse/SM-678 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0 Reporter: Ken Berthelot When deploying a jsr181endpoint using the serviceInterface attribute, a ClassNotFoundException is generated for the java interface class specified for the attribute. -- 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
Declarative Exception Handling in ServiceMix
Ralf Wunsch wrote: We are starting a new EAI project. At this time ServiceMix is our choice for the implementation plattform. We have strong requirements for monitoring and control issues. At this one aspect is the handling of unexpected errors. For this reason i have implemented the following error handler solution. The error handling solution delegates errors or faults detected in analysis of the MessageExchange objects to an ErrorHandler implemented as XBean. This bean is used by an ErrorHandlerComponent (a JBI component embedded in the flow) or by the JBIContainer (the centralized way) or both. http://www.nabble.com/file/290/error-handler-embedding.png The ErrorHandler can cancel transactions and stop the container or the source component (all cofigurable). Furthermore it's possible to route the error or fault messages and the actuating message to a configurable target. In this case ist possible to embed one or more ErrorHandlerComponents into the flow. http://www.nabble.com/file/291/error-handler-flow.png Such an ambedded ErrorHandlerComponent borrowed by the EIP WireTap ensures that the rerouted message from the source will be in a well know format (the centralised approach can't accomplish this). The embedded and the centralized approach can be used in combination. For synchronization the ErrorHandlerComponent sets a Property on the outgoing MessageExchange and the ErrorEventListener does nothing as long as this property can be found in the MessageEchange which signals a fault or an error. A sample configuration... lt;bean id=errorHandler class=de.eval.eai.error.DefaultErrorHandlergt; lt;/beangt; ... lt;bean id=errorHandlerConfig class=de.eval.eai.error.ErrorHandlerConfiggt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/beangt; ... lt;test:container id=jbi useMBeanServer=true createMBeanServer=false dumpStats=true statsInterval=10 errorHandler=#errorHandler errorHandlerConfig=#errorHandlerConfiggt; ... lt;sm:activationSpecsgt; ... lt;sm:activationSpec componentName=errorHandlergt; lt;sm:componentgt; lt;eai:componentgt; lt;eai:endpointsgt; lt;eai:errorHandler service=errorHandler endpoint=endpointgt; lt;eai:targetgt; lt;eai:exchange-target service=transformer /gt; lt;/eai:targetgt; lt;eai:disqualifyTargetgt; lt;eai:exchange-target service=failedQueue /gt; lt;/eai:disqualifyTargetgt; lt;eai:errorTargetgt; lt;eai:exchange-target service=errorQueue /gt; lt;/eai:errorTargetgt; lt;eai:faultTargetgt; lt;eai:exchange-target service=faultQueue /gt; lt;/eai:faultTargetgt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/eai:errorHandlergt; lt;/eai:endpointsgt; lt;/eai:componentgt; lt;/sm:componentgt; lt;/sm:activationSpecgt; ... Two questions: Ist this a accurate ServieMix way (in accordance with the ideas of ServiceMix)? Is it on behalf of the project or the communitiy to reuse this solution? Thanks, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6658179 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Problem with servicemix-lwcontainer-3.0
We have recently been updating form servicemix-3.0-M2 to servciemix-3.0. I encountered a problem with the lwcontainer with one of my components. This component has several service units that comprise the service assembly. Two of these service units requrie jars at runtime, which I included in their servicemix.xml to add them to the classpath. Once I run my test I get NoClassDefFound errors. I got around this by adding those jars to my lib/optional directory. The odd thing is we have developed several other components that require jars at runtime and none of those other components had problems. One of the other developers here tried deploying the component with the servicemix-lwcontainer-3.0-M2 version and everything worked fine. Any thoughts on why a service assembly with multiple service units would have problems adding jars to the classpathe with the servicemix-lwcontainer-3.0 component. Thanks -- View this message in context: http://www.nabble.com/Problem-with-servicemix-lwcontainer-3.0-tf2388377.html#a6658350 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
Sounds good. Nice work ! A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? If you want to donate this code, feel free to raise a JIRA issue and attach the code. I think it would be a nice addition. On 10/5/06, Ralf Wunsch [EMAIL PROTECTED] wrote: Ralf Wunsch wrote: We are starting a new EAI project. At this time ServiceMix is our choice for the implementation plattform. We have strong requirements for monitoring and control issues. At this one aspect is the handling of unexpected errors. For this reason i have implemented the following error handler solution. The error handling solution delegates errors or faults detected in analysis of the MessageExchange objects to an ErrorHandler implemented as XBean. This bean is used by an ErrorHandlerComponent (a JBI component embedded in the flow) or by the JBIContainer (the centralized way) or both. http://www.nabble.com/file/290/error-handler-embedding.png The ErrorHandler can cancel transactions and stop the container or the source component (all cofigurable). Furthermore it's possible to route the error or fault messages and the actuating message to a configurable target. In this case ist possible to embed one or more ErrorHandlerComponents into the flow. http://www.nabble.com/file/291/error-handler-flow.png Such an ambedded ErrorHandlerComponent borrowed by the EIP WireTap ensures that the rerouted message from the source will be in a well know format (the centralised approach can't accomplish this). The embedded and the centralized approach can be used in combination. For synchronization the ErrorHandlerComponent sets a Property on the outgoing MessageExchange and the ErrorEventListener does nothing as long as this property can be found in the MessageEchange which signals a fault or an error. A sample configuration... lt;bean id=errorHandler class=de.eval.eai.error.DefaultErrorHandlergt; lt;/beangt; ... lt;bean id=errorHandlerConfig class=de.eval.eai.error.ErrorHandlerConfiggt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/beangt; ... lt;test:container id=jbi useMBeanServer=true createMBeanServer=false dumpStats=true statsInterval=10 errorHandler=#errorHandler errorHandlerConfig=#errorHandlerConfiggt; ... lt;sm:activationSpecsgt; ... lt;sm:activationSpec componentName=errorHandlergt; lt;sm:componentgt; lt;eai:componentgt; lt;eai:endpointsgt; lt;eai:errorHandler service=errorHandler endpoint=endpointgt; lt;eai:targetgt; lt;eai:exchange-target service=transformer /gt; lt;/eai:targetgt; lt;eai:disqualifyTargetgt; lt;eai:exchange-target service=failedQueue /gt; lt;/eai:disqualifyTargetgt; lt;eai:errorTargetgt; lt;eai:exchange-target service=errorQueue /gt; lt;/eai:errorTargetgt; lt;eai:faultTargetgt; lt;eai:exchange-target service=faultQueue /gt; lt;/eai:faultTargetgt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/eai:errorHandlergt; lt;/eai:endpointsgt; lt;/eai:componentgt; lt;/sm:componentgt; lt;/sm:activationSpecgt; ... Two questions: Ist this a accurate ServieMix way (in accordance with the ideas of ServiceMix)? Is it on behalf of the project or the communitiy to reuse this solution? Thanks, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6658179 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
out-of-the-box experience very limited
Hej! I just discovered that installing the binary distribution like described in the http://goopen.org/confluence/display/SM30UG/3.+Installation#3.Installation-WindowsBinaryInstallation User's Guide / installation presents errors even for the simplest configurations (at least with the default machine settings in our depatment = maybe something additional (classpath,...) has to be set up?). It's just missing packages, so nothing really bad, but not a nice out-of-the-box-experience -- first having to search for information (that was't available till some minutes ago) and to try around. Two files to demonstrate what I mean: http://www.nabble.com/file/292/Timer2Screen.xml Timer2Screen.xml is generated by CIMERO and connects a timer with a screen output. Does not run, a user has to install servicemix-components-3.0-incubating.jar and quartz-1.5.2.jar manually. http://www.nabble.com/file/293/Timer2WireTap2File_and_Screen.xml Timer2WireTap2File_and_Screen.xml adds a wire tap a file writer to the above config. Requires to install servicemix-eip-3.0-incubating.jar manually. Though quartz is not any more in the examples, it is for sure piece of a lot of try out configs, and EIP is certainly very common to use and it's use encouraged by us. Is there any way to include at least ServiceMix' sub-projects into the libs-dir / classpath, so it at least our own components simply work out of the box? Georg -- View this message in context: http://www.nabble.com/out-of-the-box-experience-very-limited-tf2389329.html#a6661175 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
On 10/5/06, Ralf Wunsch [EMAIL PROTECTED] wrote: gnodet wrote: A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? * If i have more than one ErrorHandlerComponent in the flow it should be possible to use one ErrorHandler with different configurations for each ErrorHandlerComponent (e.g. to specify different targets for different types of failed messages). To provide this the configuration for the ErrorHandler has been extracted and assembled in the ErrorHandlerConfig XBean. * In my opinion the error handler hook and the handlers strategy should be separated. I am involved in a migration project (from a commercial EAI solution to open source). In the current EAI system an error handler is always implemented. We want to migrate this solution that is based on a set of database stored rules. I think there can be a lot of error handler strategy implementations. One default handler can be an implementation as discussed before. * At this time i am using my own extension of the JBIContainer. This extension registeres an ErrorEventListener as EventListener by default. I have not found a way to configure event listeners in the deployment descriptor. The ErrorHandler is a attribute of the extended container (the getter/setter methods are using the ErrorEventListerners 'errorHandler' attribute). Have you tried something like: sm:container id=jbi embedded=true sm:listeners bean class= / /sm:listeners It works. Best regards, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6661952 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Looking for servicemix samples using a specific component ?
Try http://google.com/codesearch?hl=enlr=q=file%3A.xml+TraceComponent+package%3A%22http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fincubator%2Fservicemix%2Ftrunk%22btnG=Search It's a lot faster than looking on your hard drive (at least for me). -- Cheers, Guillaume Nodet
[jira] Created: (GERONIMO-2467) Reference name errors in configs client-corba-sun, client-corba-yoko, j2ee-corba-sun, j2ee-corba-yoko
Reference name errors in configs client-corba-sun, client-corba-yoko, j2ee-corba-sun, j2ee-corba-yoko - Key: GERONIMO-2467 URL: http://issues.apache.org/jira/browse/GERONIMO-2467 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Vamsavardhana Reddy Fix For: 1.2 plan files use configAdapter instead of ConfigAdapter and nameService instead of NameService. -- 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-2467) Reference name errors in configs client-corba-sun, client-corba-yoko, j2ee-corba-sun, j2ee-corba-yoko
[ http://issues.apache.org/jira/browse/GERONIMO-2467?page=all ] Vamsavardhana Reddy updated GERONIMO-2467: -- Attachment: GERONIMO-2467.patch Reference name errors in configs client-corba-sun, client-corba-yoko, j2ee-corba-sun, j2ee-corba-yoko - Key: GERONIMO-2467 URL: http://issues.apache.org/jira/browse/GERONIMO-2467 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: GERONIMO-2467.patch plan files use configAdapter instead of ConfigAdapter and nameService instead of NameService. -- 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: Geronimo jee5 webservices integration
Hi David, Count me in. I am willing to help in this. Will start reading the specs as my knowlege in this is limited. This page cleared some of my questions on why axis/celtix is required. Probably it will be useful for others who are new and interested http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html Thanks Manu On 9/30/06, David Jencks [EMAIL PROTECTED] wrote: On Sep 29, 2006, at 9:33 PM, [EMAIL PROTECTED] wrote: Hi David, Can you please explain what is the meaning of jee5 web services? Any introduction link would be great. I'm just starting to read the specs: the ones I have found so far are jax-ws, jaxb, and jsr109 rev 1.2 (enterprise web services). So far it looks like things may be a little simpler than for j2ee 1.4 web services since we don't have to deal with the jaxrpc-mapping file, apparently jaxb mapping specifications deal with these issues in a better way. Hope this helps, david jencks Thanks, Lasantha Ranaweera I'm starting to look into jee5 webservices integration in geronimo. So far I've got as far as locating some of the specs and starting to read them :-). If anyone wants to help or take over aspects of this that would be great! Unfortunately I haven't been able to keep up with the dev lists for either axis or cxf so I'm not sure whether anyone has thought about this before nor how much of the appropriate specs are implemented already by either project. I have been pointed to a cxf geronimo builder, but haven't determined how out of date it is, as there have been quite a few builder changes in geronimo since the builder was written. Thanks! david jencks
Re: Another Geronimo Sample Is Ready
Paul McMahan wrote: On 10/4/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote: I can add this functionality to the console and provide it as a patch. What do u think? I think that sounds great! Seems like this would fit nicely as an additional item in the Actions column in the initial table that shows up in the database pools portlet, beside the current edit and usage actions. Or you might have something else in mind. Let me know if I can help. Best wishes, Paul Yes we go like that. Do you think is it ok to display list of schema's tables in a deployed pool in the Geronimo console? Also can I assign that task for me in JIRA? I have a user account in JIRA. Thanks, Lasantha Ranaweera
Re: ERROR: Building Geronimo Configs :: Corba J2EE Client
Sorry about that, I made the references follow the naming convention
of being capitalized and forgot to update the plans. It should be
fixed now, rev 453117
Thanks for pointing this out!
david jencks
On Oct 4, 2006, at 10:53 PM, Vamsavardhana Reddy wrote:
Anything that needs a refresh in the repos?
--vamsi
--
[INFO]
--
---
---
[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO]task-segment: [install]
[INFO]
--
---
---
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: G:\configs\client-corba-yoko\target\plan\plan.xml
[WARNING] POM for 'activecluster:activecluster:pom:1.1-
SNAPSHOT:provided' is inv
alid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided'
is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:provided' is
invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql-connector-derby-embed-xa:pom:
1.1:provided' is i
nvalid. It will be ignored for artifact resolution. Reason: Failed
to validate P
OM
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:provided' is
invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:provided' is
invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is
invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1-
SNAPSHOT:compile' is inva
lid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is
invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is
invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is
invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1-
SNAPSHOT:compile' is inva
lid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is
invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is
invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[INFO] snapshot org.apache.geronimo.modules:geronimo-security-
builder:1.2-SNAPSH
OT: checking for updates from local-m1
[INFO] snapshot org.apache.geronimo.modules:geronimo-naming-builder:
1.2-SNAPSHOT
: checking for updates from local-m1
[INFO] [car:package]
[INFO] Packaging module configuration: G:\configs\client-corba-yoko
\target\plan\
plan.xml
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] No reference named configAdapter in gbean
org.apache.geronimo.configs/cli
ent-corba-yoko/1.2-SNAPSHOT/car?
ServiceModule=org.apache.geronimo.configs/client
-corba-yoko/1.2-SNAPSHOT/
car,j2eeType=CORBANameService,name=NameServerRef
[INFO]
--
--
[INFO] For more information, run Maven with the -e switch
[INFO]
--
--
[INFO] Total time: 5 minutes 51 seconds
[INFO] Finished at: Thu Oct 05 11:20:45 IST 2006
[INFO] Final Memory: 59M/138M
[INFO]
--
--
Re: Geronimo jee5 webservices integration
hi David, I would also be glad to make some contributions. I am new to this so would need some pointers as to what to focus on. I would start by reading the specs and also getting familiar with Axis 2. Regards Krishnakumar On 10/5/06, Manu George [EMAIL PROTECTED] wrote: Hi David, Count me in. I am willing to help in this. Will start reading the specs as my knowlege in this is limited. This page cleared some of my questions on why axis/celtix is required. Probably it will be useful for others who are new and interested http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html Thanks Manu On 9/30/06, David Jencks [EMAIL PROTECTED] wrote: On Sep 29, 2006, at 9:33 PM, [EMAIL PROTECTED] wrote: Hi David, Can you please explain what is the meaning of jee5 web services? Any introduction link would be great. I'm just starting to read the specs: the ones I have found so far are jax-ws, jaxb, and jsr109 rev 1.2 (enterprise web services). So far it looks like things may be a little simpler than for j2ee 1.4 web services since we don't have to deal with the jaxrpc-mapping file, apparently jaxb mapping specifications deal with these issues in a better way. Hope this helps, david jencks Thanks, Lasantha Ranaweera I'm starting to look into jee5 webservices integration in geronimo. So far I've got as far as locating some of the specs and starting to read them :-). If anyone wants to help or take over aspects of this that would be great! Unfortunately I haven't been able to keep up with the dev lists for either axis or cxf so I'm not sure whether anyone has thought about this before nor how much of the appropriate specs are implemented already by either project. I have been pointed to a cxf geronimo builder, but haven't determined how out of date it is, as there have been quite a few builder changes in geronimo since the builder was written. Thanks! david jencks
Re: [jira] Created: (AMQ-943) Pluggable Stomp Message Mapping
Did anyone check this patch. I would like to continue to work on this and just want to be sure that I'm heading in the right direction. Also, there are two open questions: - should I add JSON mapper in the AMQ distribution or not? - should we be compatible with current handling of byte messages (content-length header). Regards, Dejan On 9/27/06, Dejan Bosanac (JIRA) [EMAIL PROTECTED] wrote: Pluggable Stomp Message Mapping --- Key: AMQ-943 URL: https://issues.apache.org/activemq/browse/AMQ-943 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 4.1 Reporter: Dejan Bosanac Fix For: 4.1 Attachments: protocol-mapping.patch I have finally found time to finish this. Here's the draft version of the Pluggable Stomp Message Mapping implementation. Few notes: - New interface has been defined: ProtocolMapping (I wanted to use the same name as the message header that we check) - There are two implementations of this interface: DefaultProtocolMapping and ByteProtocolMapping - I used FactoryFinder to create appropriate mapper. The finder use the following path to find keys: META-INF/services/org/apache/activemq/transport/mapping/ (we can change this if you want) - The appropriate mapper is used according to the protocol-mapping header in the CONNECT message. For example protocol-mapping:byte for ByteProtocolMapping handler. - Currently I have implemented only the mapper for BytesMessage since I wasn't sure whether you want to integrate JSON mapper for MapMessages or distribute it in a separate library. - I have changed the test case that tests subscription for byte messages - This solution is not compatible with current mapping for byte messages. If you want backward compatibility, I can hard-code it in a ProtocolConverter class (as it was) since it could not be implemented through this mechanism. TODO: - test it more (create more unit test cases and test it more in a real environment) - create a proper documentation so others can create their handlers. - create a proper JavaDoc documentation for key interfaces and classes - create JSON mapper (integrated or external) - fix STOMP client(s) Give it a try and let me know your impressions Dejan Bosanac -- 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
Build error
hi, I get this error during build [INFO] Packaging module configuration: C:\Apache\geronimo-1.2\configs\client-cor ba-yoko\target\plan\plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] No reference named configAdapter in gbean org.apache.geronimo.configs/cli ent-corba-yoko/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client -corba-yoko/1.2-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServerRef [INFO] [INFO] For more information, run Maven with the -e switch I ran bootstrap clean specs modules openejb2 assemble with SUN JDK 1.4.2 I followed the steps listed in cWiki ( http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html) Any help in fixing this... Regards Krishnakumar
Re: Build error
The problem has been fixed few hours ago. Refresh trunk. --vamsiOn 10/5/06, Krishnakumar B [EMAIL PROTECTED] wrote: hi,I get this error during build[INFO] Packaging module configuration: C:\Apache\geronimo-1.2\configs\client-corba-yoko\target\plan\plan.xml[INFO] [ERROR] BUILD ERROR[INFO] [INFO] No reference named configAdapter in gbean org.apache.geronimo.configs/client-corba-yoko/1.2-SNAPSHOT/car?ServiceModule= org.apache.geronimo.configs/client-corba-yoko/1.2-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServerRef[INFO] [INFO] For more information, run Maven with the -e switch I ran bootstrap clean specs modules openejb2 assemblewith SUN JDK 1.4.2I followed the steps listed in cWiki (http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html )Any help in fixing this...RegardsKrishnakumar
Re: Build error
Krishnakumar B wrote: hi, I get this error during build [INFO] Packaging module configuration: C:\Apache\geronimo-1.2\configs\client-cor ba-yoko\target\plan\plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] No reference named configAdapter in gbean org.apache.geronimo.configs/cli ent-corba-yoko/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client -corba-yoko/1.2-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServerRef [INFO] [INFO] For more information, run Maven with the -e switch I ran bootstrap clean specs modules openejb2 assemble with SUN JDK 1.4.2 I followed the steps listed in cWiki ( http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html) Any help in fixing this... I think you may be missing some updates to your geronimo code. David Jencks cleaned up some things in openejb2 tree, but missed a couple of updates to the geronimo plans. Try doing an svn update and rebuilding. Rick Regards Krishnakumar
RE: [activemq-cpp] It now compiles under cygwin
Is there anyway that this build system can be modified to put the object files and other build artifacts into someplace other than the root dir of the code being built? This really clutter ups the workspace. Previoulsy we had everything going into the out dir under the root activemq folder. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, October 03, 2006 4:08 PM To: activemq-dev@geronimo.apache.org Subject: Re: [activemq-cpp] It now compiles under cygwin Ah.. I just did a source build of cppunit and I see what's happening. The default prefix for cppunit is /usr/local, so it m4 file got installed to /usr/local/share/aclocal which is not picked up automatically. If we configure cppunit with ./configure --prefix=/usr Then everything should work better out of the box. Including when we configure activemq-cpp as now I have to use: ./configure --with-cppunit-prefix=/usr/local To let it know where cppunit is at (that's if I want to run the unit tests). On 10/3/06, Bish, Tim [EMAIL PROTECTED] wrote: AC_DEFUN is line 17 dnl AM_PATH_LIBMCRYPT([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libmcrypt, and define LIBMCRYPT_CFLAGS and LIBMCRYPT_LIBS dnl AC_DEFUN(AM_PATH_LIBMCRYPT, Change this line to: AC_DEFUN([AM_PATH_LIBMCRYPT], K, that got rid of that warning. doh.. I may need to look into this some more. Basically what you want to do is installed the cppunit.m4 file to either the activemq-cpp/m4 directory or the /usr/share/aclocal Once it's there it should get picked up and be good to go. But I would have thought that if you built cppunit from source it would have installed the m4 file to the right place. We should look into seeing if that .m4 file can be redistributed so that we can just check it into our m4 directory. I've got a feeling that it can be redistributed since it just gets sourced into the configure script when you run autogen.sh I put cppunit.m4 in my activemq-cpp m4 folder and its building now. I may just move that over the /usr/shar/alcohol as it should be there anyway. -- Regards, Hiram Blog: http://hiramchirino.com
XBean annotation for ActiveMQConnectionFactory
What about adding an xbean annotation on the ActiveMQConnectionFactory ? This is a commonly used object and it would benefit from an xbean based syntax imho. -- Cheers, Guillaume Nodet
Re: Conditionally loading modules based on expression (and environment)
The plugins should use this, since they have similar restrictions at
install time but not at runtime. It would be nice to carry that over
so any installed Java 1.5-only plugins just wouldn't start if you
started Geronimo under Java 1.4.
Still, if you try to start a module manually (with the deploy tool or
console), it won't go through the same logic, right? It would just
let you load it I think. We should hook the module load process into
that same conditional logic, which I think argues that we may want it
to be a separate GBean rather than part of the persistent
configuration list. (The load logic is in ConfigurationManager I
think.)
Thanks,
Aaron
On 10/2/06, Jason Dillon [EMAIL PROTECTED] wrote:
Hi all... I was chatting with David Jencks in IRC today about GShell
and when server/trunk might be built with Java 1.5 and then it
occurred to me that if config.xml could include some extra
configuration to specify what version of Java a module required, that
we could ship an assembly with GShell but only enable it on JDK 1.5
since it requires 1.5 to run.
And then it occurred to me that we could use this same mechanism to
load a Yoko ORB module or a Sun ORB based on one config and one
assembly... and then I thought that if we had a configuration for
GShell built against 1.5, and then another that was retrostranslated,
then we could define a module that would enable on 1.4 and another on
1.5 and have both supported under one configuration. Now I am not
suggesting that we actually do that, but if we had a flexible way to
define a condition for a module to load, then we certainly could if
we wanted to.
So I took a stab at a quick example of how this might work. I added
a new attribute to local-attributes.xsd to the moduleType/
configurationType called condition which is a plain string. Then
in ConfigurationOverride I added a field of the same name that gets
initialized to the value, and then changed isLoad to:
public boolean isLoad() {
return load parseCondition();
}
And added parseCondition(), which at the moment just uses a simple
JexlExpression to evaluate the text to a boolean. To give the
expression access to some system bits I bound a SystemUtils instance
(from commons-lang) and then ran some simple tests like:
module name=org.apache.geronimo.configs/remote-deploy-jetty/$
{pom.version}/car
condition=!SystemUtils.IS_JAVA_1_5/
module name=org.apache.geronimo.configs/hot-deployer/$
{pom.version}/car
condition=SystemUtils.IS_JAVA_1_5 and
SystemUtils.JAVA_VENDOR == 'sun'/
In these examples, remote-deploy-jetty will only be loaded if the JVM
is not 1.5 and hot-deployer will only be loaded if the JVM is 1.5 and
the vendor is 'sun'.
It appears to work well and I believe this adds some extra ability to
our configuration which can help to provide better JDK version
compatibility or vendor compatibility without needing to create new
assemblies.
I believe that only a small number of modules would need to use the
condition and modules which do not provide a condition will
automatically evaluate to true (so they will load with no changes).
So, adding this feature will not break any existing configurations,
it only adds some new functionality.
We could roll our own parser, though I think that Jexl is fairly
robust and flexible enough and not too big at ~130k. Probably want
to define some helper objects to provide the functionality that gets
picked up from commons-lang as most of that stuff does not need to be
there... or we could simply extract a few classes out of the jar to
include in the boot classpath.
Right now I only added this to module configurations, but it should
also be easy enough to expose this to gbean's too... so a module
could define a set of gbeans that would conditional load based on
configuration. Basically add the same bits to GBeanOverrides adding
the condition attribute to be processed on isLoad(), blah, blah, blah.
* * *
Any comments?
--jason
Re: XBean annotation for ActiveMQConnectionFactory
On 10/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: What about adding an xbean annotation on the ActiveMQConnectionFactory ? This is a commonly used object and it would benefit from an xbean based syntax imho. Good idea - though I'd added them to the connection factory implementations in the spring package - which adds some spring-aware helpers (like using the bean name in the generated JMS clientID - so if you use different IDs in your spring files, you'll get more helpful clientIDs when debugging). I was working with a customer a little while back who had lots of spring configuration files and they found it helpful to name the JMS clients so they could easily see what app was connecting etc. -- James --- http://radio.weblogs.com/0112098/
Re: XBean annotation for ActiveMQConnectionFactory
Cool :) I missed them, I was looking at the 4.0.2 tag .. On 10/5/06, James Strachan [EMAIL PROTECTED] wrote: On 10/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: What about adding an xbean annotation on the ActiveMQConnectionFactory ? This is a commonly used object and it would benefit from an xbean based syntax imho. Good idea - though I'd added them to the connection factory implementations in the spring package - which adds some spring-aware helpers (like using the bean name in the generated JMS clientID - so if you use different IDs in your spring files, you'll get more helpful clientIDs when debugging). I was working with a customer a little while back who had lots of spring configuration files and they found it helpful to name the JMS clients so they could easily see what app was connecting etc. -- James --- http://radio.weblogs.com/0112098/ -- Cheers, Guillaume Nodet
[jira] Resolved: (SM-676) In the instance2 of the ws-notification example, the org.apache.servicemix.tck.ReceiverComponent should be removed
[ https://issues.apache.org/activemq/browse/SM-676?page=all ] Guillaume Nodet resolved SM-676. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Thu Oct 5 05:04:06 2006 New Revision: 453195 URL: http://svn.apache.org/viewvc?view=revrev=453195 Log: SM-676: also clean up a bit the samples and provide both spring / xbean configuration Modified: incubator/servicemix/branches/servicemix-3.0/apache-servicemix/src/main/release/examples/ws-notification/instance1/servicemix1.xml incubator/servicemix/branches/servicemix-3.0/apache-servicemix/src/main/release/examples/ws-notification/instance2/servicemix2.xml incubator/servicemix/branches/servicemix-3.0/apache-servicemix/src/main/release/examples/ws-notification/instance3/servicemix3.xml Author: gnodet Date: Thu Oct 5 05:05:20 2006 New Revision: 453197 URL: http://svn.apache.org/viewvc?view=revrev=453197 Log: SM-676: also clean up a bit the samples and provide both spring / xbean configuration Modified: incubator/servicemix/trunk/apache-servicemix/src/main/release/examples/ws-notification/instance1/servicemix1.xml incubator/servicemix/trunk/apache-servicemix/src/main/release/examples/ws-notification/instance2/servicemix2.xml incubator/servicemix/trunk/apache-servicemix/src/main/release/examples/ws-notification/instance3/servicemix3.xml In the instance2 of the ws-notification example, the org.apache.servicemix.tck.ReceiverComponent should be removed -- Key: SM-676 URL: https://issues.apache.org/activemq/browse/SM-676 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.0 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Trivial Fix For: 3.0.1, 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
Re: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
What is your JAVA_HOME set to ?ThanksAnita- Original Message From: Vamsavardhana Reddy (JIRA) dev@geronimo.apache.orgTo: dev@geronimo.apache.orgSent: Thursday, October 5, 2006 1:09:20 AMSubject: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath[ http://issues.apache.org/jira/browse/GERONIMO-2393?page=comments#action_12440030 ] Vamsavardhana Reddy commented on GERONIMO-2393:---URGH...I will have to withdraw my previous comment that Sun JDK v1.4.2_12 solved it.The problem has not gone away.I did a fresh checkout and bootstrap on a machine that had Sun JDK 1.4.2_09 and noticed that the classpath entries are fine.Afterward that I installed Sun JDK1.4.2_12 on my machine and ran mvn eclipse:eclipse under a specific directory (modules\geronimo-tomcat) and noticed that the classpath entries are alright (this was before a reboot once JDK1.4.2_12 is installed.I do not know if the reboot has any effect on the current issue).I thought the problem is solved.After a later run of mvn eclipse:eclipse, I am still left with incorrect classpath entries. HELP Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: buildsystemAffects Versions: 1.2 Environment: WinXP, G TRUNKReporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: .classpath, .classpath I have run mvn eclipse:eclipse.Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing.Here is an example of some classpath entries in .classpath file. classpathentry kind="var" path="M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar"/ classpathentry kind="var" path="M2_REPO/tax/stax-api/1.0/stax-api-1.0.jar"/ classpathentry kind="var" path="M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar"/ classpathentry kind="var" path="M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar"/-- 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: XBean annotation for ActiveMQConnectionFactory
On 10/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Cool :) I missed them, I was looking at the 4.0.2 tag .. Ah yeah, I was using trunk. We should add them for 4.0.x I guess - though hopefully we can release 4.1 soon -- James --- http://radio.weblogs.com/0112098/
Re: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
I have Sun JDK v1.4.2_12 installed in C:\SUNJDK142. JAVA_HOME is set to the same dir. --vamsiOn 10/5/06, anita kulshreshtha [EMAIL PROTECTED] wrote: What is your JAVA_HOME set to ?Thanks Anita- Original Message From: Vamsavardhana Reddy (JIRA) dev@geronimo.apache.orgTo: dev@geronimo.apache.org Sent: Thursday, October 5, 2006 1:09:20 AMSubject: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath[ http://issues.apache.org/jira/browse/GERONIMO-2393?page=comments#action_12440030 ] Vamsavardhana Reddy commented on GERONIMO-2393:---URGH...I will have to withdraw my previous comment that Sun JDK v1.4.2_12 solved it.The problem has not gone away.I did a fresh checkout and bootstrap on a machine that had Sun JDK 1.4.2_09 and noticed that the classpath entries are fine.Afterward that I installed Sun JDK1.4.2_12 on my machine and ran mvn eclipse:eclipse under a specific directory (modules\geronimo-tomcat) and noticed that the classpath entries are alright (this was before a reboot once JDK1.4.2_12 is installed.I do not know if the reboot has any effect on the current issue).I thought the problem is solved.After a later run of mvn eclipse:eclipse, I am still left with incorrect classpath entries. HELP Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: WinXP, G TRUNKReporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: .classpath, .classpath I have run mvn eclipse:eclipse.Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing.Here is an example of some classpath entries in .classpath file. classpathentry kind=var path=M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar/ classpathentry kind=var path=M2_REPO/tax/stax-api/1.0/stax- api-1.0.jar/ classpathentry kind=var path=M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar/ classpathentry kind=var path=M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar/-- 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-2468) Tribes as the default group communication implementation for WADI
Tribes as the default group communication implementation for WADI - Key: GERONIMO-2468 URL: http://issues.apache.org/jira/browse/GERONIMO-2468 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Gianny Damour The current default group communication implementation is ActiveCluster over AMQ. It seems that the way WADI is leveraging the ActiveCluster API is wrong somewhere as WADI randomly fails when a node is joining the cluster. So far, it seems that the WADI implementation over Tribes is reliable; hence, this move. -- 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-2469) Allow sharing of a single WADI group communication instance between multiple Web-app
Allow sharing of a single WADI group communication instance between multiple Web-app Key: GERONIMO-2469 URL: http://issues.apache.org/jira/browse/GERONIMO-2469 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Gianny Damour In its current state, it is not possible to share a WADI group communication instance between multiple web-applications. A simple migration to the recently added WADI ServiceSpace does allow that. Also, this fixes a bug when a clustered Web-app is restarted. -- 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] Resolved: (GERONIMO-1551) Jetty and Tomcat WADI integrations do not work against current WADI distro
[ http://issues.apache.org/jira/browse/GERONIMO-1551?page=all ] Gianny Damour resolved GERONIMO-1551. - Fix Version/s: 1.2 Resolution: Invalid This is no more required: Tomcat integration code has been removed and Jetty integration code has been re-implemented. Jetty and Tomcat WADI integrations do not work against current WADI distro -- Key: GERONIMO-1551 URL: http://issues.apache.org/jira/browse/GERONIMO-1551 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.0, 1.1 Environment: any Reporter: Jules Gosnell Fix For: 1.2 We either: 1) leave it broken 2) remove the integration alltogether 3) apply a minimal fix (I did this but it was backed out) 4) go the whole hog - currently under discussion on dev list (4) is not going to happen for 1.0.1 I've discussed this with David Jencks - we decided to go for (4) in 1.1 - but no solution, as yet, has been decided for 1.0.1 Jules -- 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: Another Geronimo Sample Is Ready
On 10/5/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Yes we go like that. Do you think is it ok to display list of schema's tables in a deployed pool in the Geronimo console? If I take your meaning correctly then the way a connection would be tested would be to list the schema's tables. That sounds great. Also can I assign that task for me in JIRA? I have a user account in JIRA. If you want to assign the JIRA then you may need to send a note with your JIRA id to the dev list to get the necessary karma in JIRA. If you assign it to yourself then you can unassign it when you attach the patch as a signal that its ready for review. Thanks again for volunteering to work on this. Best wishes, Paul
[jira] Updated: (GERONIMO-2468) Tribes as the default group communication implementation for WADI
[ http://issues.apache.org/jira/browse/GERONIMO-2468?page=all ] Gianny Damour updated GERONIMO-2468: Component/s: Clustering Should have been created as a Clustering component improvement. Tribes as the default group communication implementation for WADI - Key: GERONIMO-2468 URL: http://issues.apache.org/jira/browse/GERONIMO-2468 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Gianny Damour The current default group communication implementation is ActiveCluster over AMQ. It seems that the way WADI is leveraging the ActiveCluster API is wrong somewhere as WADI randomly fails when a node is joining the cluster. So far, it seems that the WADI implementation over Tribes is reliable; hence, this move. -- 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] Closed: (GERONIMO-2468) Tribes as the default group communication implementation for WADI
[ http://issues.apache.org/jira/browse/GERONIMO-2468?page=all ] Gianny Damour closed GERONIMO-2468. --- Fix Version/s: 1.2 Resolution: Fixed This is now done. Tribes as the default group communication implementation for WADI - Key: GERONIMO-2468 URL: http://issues.apache.org/jira/browse/GERONIMO-2468 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Gianny Damour Fix For: 1.2 The current default group communication implementation is ActiveCluster over AMQ. It seems that the way WADI is leveraging the ActiveCluster API is wrong somewhere as WADI randomly fails when a node is joining the cluster. So far, it seems that the WADI implementation over Tribes is reliable; hence, this move. -- 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] Closed: (GERONIMO-2469) Allow sharing of a single WADI group communication instance between multiple Web-app
[ http://issues.apache.org/jira/browse/GERONIMO-2469?page=all ] Gianny Damour closed GERONIMO-2469. --- Fix Version/s: 1.2 Resolution: Fixed This is now done. Allow sharing of a single WADI group communication instance between multiple Web-app Key: GERONIMO-2469 URL: http://issues.apache.org/jira/browse/GERONIMO-2469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Gianny Damour Fix For: 1.2 In its current state, it is not possible to share a WADI group communication instance between multiple web-applications. A simple migration to the recently added WADI ServiceSpace does allow that. Also, this fixes a bug when a clustered Web-app is restarted. -- 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-2470) Add support for Session Replication
Add support for Session Replication --- Key: GERONIMO-2470 URL: http://issues.apache.org/jira/browse/GERONIMO-2470 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Gianny Damour Currently, the WADI clustering code only addresses load-balancing. WADI can also provides sync or async session replication. -- 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: (GERONIMO-2320) New DB pool didn't show up until restarted
[ http://issues.apache.org/jira/browse/GERONIMO-2320?page=comments#action_12440162 ] Aaron Mulder commented on GERONIMO-2320: Just had it happen on the Jetty build with a PostgreSQL pool (likewise when I just downloaded the driver, though I haven't tried it with a pre-existing driver). New DB pool didn't show up until restarted -- Key: GERONIMO-2320 URL: http://issues.apache.org/jira/browse/GERONIMO-2320 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases, deployment Affects Versions: 1.1 Environment: Geronimo 1.1 Tomcat Reporter: Aaron Mulder Fix For: 1.1.2 Deployed a new MySQL database pool using the console wizard in the Geronimo 1.1 Tomcat J2EE distribution (including downloading a driver for it). When it finished, the stdout said Deployment completed successfully! but the new pool did not show up in the list in the Database Pools portlet. I stopped and started the module using the J2EE Connectors screen and then it showed up in the Database Pools list. Haven't seen this in the Jetty build. Need to try to reproduce on a totally clean 1.1 and 1.1.1 Tomcat/J2EE build. -- 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
dojo in Geronimo
Hello all, I finally managed to get my project development/testing server up and working on 1.2-snapshot (Thanks again djencks!). And I finally got to see the JMX console that was added - Which is very cool. But, I think that it brings to light a performance issue. Because we are using dojo widgets that are not 'bundled' into the dojo.js library, we end up pulling down -many- individual files to support the widgets. I think we should consider building our own dojo bundle (I'm going to start looking into exactly how to do this) and deploying it to something like /geronimo-dojo and using that for console apps. Pulling the one (slightly larger) library -should- increase response time since we won't need all of the extra file requests/responses going over the wire. I do like having dojo deployed to /dojo built into the server though and would like to keep the base library there (so far I have just been using the AJAX portion of dojo in my own apps - so I haven't needed any widgets). Does anyone have any thoughts about this? Jay
Re: [jira] Commented: (GERONIMO-2320) New DB pool didn't show up until restarted
I do not see this problem on the trunk. This morning I also deployed a MYSQL DBPool on tomcat-j2ee using Download Driver -- Skip Test and Show Plan -- Deploy Pool and it worked fine. The pool was listed in 'Database Pools'.ThanksAnita- Original Message From: Aaron Mulder (JIRA) dev@geronimo.apache.orgTo: dev@geronimo.apache.orgSent: Thursday, October 5, 2006 11:23:20 AMSubject: [jira] Commented: (GERONIMO-2320) New DB pool didn't show up until restarted[ http://issues.apache.org/jira/browse/GERONIMO-2320?page=comments#action_12440162 ] Aaron Mulder commented on GERONIMO-2320:Just had it happen on the Jetty build with a PostgreSQL pool (likewise when I just downloaded the driver, though I haven't tried it with a pre-existing driver). New DB pool didn't show up until restarted -- Key: GERONIMO-2320 URL: http://issues.apache.org/jira/browse/GERONIMO-2320 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: console, databases, deploymentAffects Versions: 1.1 Environment: Geronimo 1.1 TomcatReporter: Aaron Mulder Fix For: 1.1.2 Deployed a new MySQL database pool using the console wizard in the Geronimo 1.1 Tomcat J2EE distribution (including downloading a driver for it).When it finished, the stdout said "Deployment completed successfully!" but the new pool did not show up in the list in the Database Pools portlet.I stopped and started the module using the J2EE Connectors screen and then it showed up in the Database Pools list.Haven't seen this in the Jetty build.Need to try to reproduce on a totally clean 1.1 and 1.1.1 Tomcat/J2EE build.-- 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: [jira] Commented: (GERONIMO-2320) New DB pool didn't show up until restarted
On 10/5/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I do not see this problem on the trunk. That's good, but I'd still like to see the issue fixed in the 1.1 line... Thanks, Aaron - Original Message From: Aaron Mulder (JIRA) dev@geronimo.apache.org To: dev@geronimo.apache.org Sent: Thursday, October 5, 2006 11:23:20 AM Subject: [jira] Commented: (GERONIMO-2320) New DB pool didn't show up until restarted [ http://issues.apache.org/jira/browse/GERONIMO-2320?page=comments#action_12440162 ] Aaron Mulder commented on GERONIMO-2320: Just had it happen on the Jetty build with a PostgreSQL pool (likewise when I just downloaded the driver, though I haven't tried it with a pre-existing driver). New DB pool didn't show up until restarted -- Key: GERONIMO-2320 URL: http://issues.apache.org/jira/browse/GERONIMO-2320 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases, deployment Affects Versions: 1.1 Environment: Geronimo 1.1 Tomcat Reporter: Aaron Mulder Fix For: 1.1.2 Deployed a new MySQL database pool using the console wizard in the Geronimo 1.1 Tomcat J2EE distribution (including downloading a driver for it). When it finished, the stdout said Deployment completed successfully! but the new pool did not show up in the list in the Database Pools portlet. I stopped and started the module using the J2EE Connectors screen and then it showed up in the Database Pools list. Haven't seen this in the Jetty build. Need to try to reproduce on a totally clean 1.1 and 1.1.1 Tomcat/J2EE build. -- 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: Conditionally loading modules based on expression (and environment)
The idea was to get something working now... and then refactor later.
--jason
On Oct 5, 2006, at 4:33 AM, Aaron Mulder wrote:
The plugins should use this, since they have similar restrictions at
install time but not at runtime. It would be nice to carry that over
so any installed Java 1.5-only plugins just wouldn't start if you
started Geronimo under Java 1.4.
Still, if you try to start a module manually (with the deploy tool or
console), it won't go through the same logic, right? It would just
let you load it I think. We should hook the module load process into
that same conditional logic, which I think argues that we may want it
to be a separate GBean rather than part of the persistent
configuration list. (The load logic is in ConfigurationManager I
think.)
Thanks,
Aaron
On 10/2/06, Jason Dillon [EMAIL PROTECTED] wrote:
Hi all... I was chatting with David Jencks in IRC today about GShell
and when server/trunk might be built with Java 1.5 and then it
occurred to me that if config.xml could include some extra
configuration to specify what version of Java a module required, that
we could ship an assembly with GShell but only enable it on JDK 1.5
since it requires 1.5 to run.
And then it occurred to me that we could use this same mechanism to
load a Yoko ORB module or a Sun ORB based on one config and one
assembly... and then I thought that if we had a configuration for
GShell built against 1.5, and then another that was retrostranslated,
then we could define a module that would enable on 1.4 and another on
1.5 and have both supported under one configuration. Now I am not
suggesting that we actually do that, but if we had a flexible way to
define a condition for a module to load, then we certainly could if
we wanted to.
So I took a stab at a quick example of how this might work. I added
a new attribute to local-attributes.xsd to the moduleType/
configurationType called condition which is a plain string. Then
in ConfigurationOverride I added a field of the same name that gets
initialized to the value, and then changed isLoad to:
public boolean isLoad() {
return load parseCondition();
}
And added parseCondition(), which at the moment just uses a simple
JexlExpression to evaluate the text to a boolean. To give the
expression access to some system bits I bound a SystemUtils instance
(from commons-lang) and then ran some simple tests like:
module name=org.apache.geronimo.configs/remote-deploy-jetty/$
{pom.version}/car
condition=!SystemUtils.IS_JAVA_1_5/
module name=org.apache.geronimo.configs/hot-deployer/$
{pom.version}/car
condition=SystemUtils.IS_JAVA_1_5 and
SystemUtils.JAVA_VENDOR == 'sun'/
In these examples, remote-deploy-jetty will only be loaded if the JVM
is not 1.5 and hot-deployer will only be loaded if the JVM is 1.5 and
the vendor is 'sun'.
It appears to work well and I believe this adds some extra ability to
our configuration which can help to provide better JDK version
compatibility or vendor compatibility without needing to create new
assemblies.
I believe that only a small number of modules would need to use the
condition and modules which do not provide a condition will
automatically evaluate to true (so they will load with no changes).
So, adding this feature will not break any existing configurations,
it only adds some new functionality.
We could roll our own parser, though I think that Jexl is fairly
robust and flexible enough and not too big at ~130k. Probably want
to define some helper objects to provide the functionality that gets
picked up from commons-lang as most of that stuff does not need to be
there... or we could simply extract a few classes out of the jar to
include in the boot classpath.
Right now I only added this to module configurations, but it should
also be easy enough to expose this to gbean's too... so a module
could define a set of gbeans that would conditional load based on
configuration. Basically add the same bits to GBeanOverrides adding
the condition attribute to be processed on isLoad(), blah, blah,
blah.
* * *
Any comments?
--jason
Re: Conditionally loading modules based on expression (and environment)
On 10/5/06, Jason Dillon [EMAIL PROTECTED] wrote:
The idea was to get something working now... and then refactor later.
No problem -- once you check it in let's put in a Jira to link it up
for runtime start operations too.
Thanks,
Aaron
On Oct 5, 2006, at 4:33 AM, Aaron Mulder wrote:
The plugins should use this, since they have similar restrictions at
install time but not at runtime. It would be nice to carry that over
so any installed Java 1.5-only plugins just wouldn't start if you
started Geronimo under Java 1.4.
Still, if you try to start a module manually (with the deploy tool or
console), it won't go through the same logic, right? It would just
let you load it I think. We should hook the module load process into
that same conditional logic, which I think argues that we may want it
to be a separate GBean rather than part of the persistent
configuration list. (The load logic is in ConfigurationManager I
think.)
Thanks,
Aaron
On 10/2/06, Jason Dillon [EMAIL PROTECTED] wrote:
Hi all... I was chatting with David Jencks in IRC today about GShell
and when server/trunk might be built with Java 1.5 and then it
occurred to me that if config.xml could include some extra
configuration to specify what version of Java a module required, that
we could ship an assembly with GShell but only enable it on JDK 1.5
since it requires 1.5 to run.
And then it occurred to me that we could use this same mechanism to
load a Yoko ORB module or a Sun ORB based on one config and one
assembly... and then I thought that if we had a configuration for
GShell built against 1.5, and then another that was retrostranslated,
then we could define a module that would enable on 1.4 and another on
1.5 and have both supported under one configuration. Now I am not
suggesting that we actually do that, but if we had a flexible way to
define a condition for a module to load, then we certainly could if
we wanted to.
So I took a stab at a quick example of how this might work. I added
a new attribute to local-attributes.xsd to the moduleType/
configurationType called condition which is a plain string. Then
in ConfigurationOverride I added a field of the same name that gets
initialized to the value, and then changed isLoad to:
public boolean isLoad() {
return load parseCondition();
}
And added parseCondition(), which at the moment just uses a simple
JexlExpression to evaluate the text to a boolean. To give the
expression access to some system bits I bound a SystemUtils instance
(from commons-lang) and then ran some simple tests like:
module name=org.apache.geronimo.configs/remote-deploy-jetty/$
{pom.version}/car
condition=!SystemUtils.IS_JAVA_1_5/
module name=org.apache.geronimo.configs/hot-deployer/$
{pom.version}/car
condition=SystemUtils.IS_JAVA_1_5 and
SystemUtils.JAVA_VENDOR == 'sun'/
In these examples, remote-deploy-jetty will only be loaded if the JVM
is not 1.5 and hot-deployer will only be loaded if the JVM is 1.5 and
the vendor is 'sun'.
It appears to work well and I believe this adds some extra ability to
our configuration which can help to provide better JDK version
compatibility or vendor compatibility without needing to create new
assemblies.
I believe that only a small number of modules would need to use the
condition and modules which do not provide a condition will
automatically evaluate to true (so they will load with no changes).
So, adding this feature will not break any existing configurations,
it only adds some new functionality.
We could roll our own parser, though I think that Jexl is fairly
robust and flexible enough and not too big at ~130k. Probably want
to define some helper objects to provide the functionality that gets
picked up from commons-lang as most of that stuff does not need to be
there... or we could simply extract a few classes out of the jar to
include in the boot classpath.
Right now I only added this to module configurations, but it should
also be easy enough to expose this to gbean's too... so a module
could define a set of gbeans that would conditional load based on
configuration. Basically add the same bits to GBeanOverrides adding
the condition attribute to be processed on isLoad(), blah, blah,
blah.
* * *
Any comments?
--jason
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm inclined to use jexl for now based on its size and relative simplicity. --jason On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote: btw.. ongl might also be a good canidate to use as an expression language. On 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: I cleaned up my quick POC into a patch suitable to be applied to trunk: https://issues.apache.org/jira/browse/GERONIMO-2463 Please review. If there are no objections I will apply this over the weekend. Thanks, --jason -- Regards, Hiram Blog: http://hiramchirino.com
Re: Geronimo Release Roadmap
As I mentioned earlier, I agree your page is quite useful and we should keep it around. However, Dain and I will stick with our own, more detailed, page for our release management efforts. Regards, Alan On Oct 5, 2006, at 8:26 AM, Hernan Cunico wrote: Hi Alan, I wouldn't say that I have a general roadmap feature set page, I would rather say we do ;-) We have had that page for quite some time now (since v1.0 maybe!?) and people have been posting features and assigning their names there for quite some time too. The Roadmap page ( http://cwiki.apache.org/GMOxPMGT/geronimo- release-roadmap.html ) is available under the project management space. In an effort to continue the same format we used for v1.1 release for consolidating user requirements I tried to create a new similar page for the v1.2 release based on some user feedback already available from the mailing lists. My mistake was to place these pages in the development space instead of the project management one. ( see http://cwiki.apache.org/GMOxDEV/geronimo-v11- user-requirements.html and http://cwiki.apache.org/GMOxDEV/geronimo- v12-user-requirements.html ). The idea was to brainstorm there and then move what we voted for to the actual roadmap page. The page you and Dain are working on came out kind of just now. It is fine with me to use the new Priorities 1.2 page but I think we keep reinventing the wheel over and over again instead of leveraging what we already have working. The wiki is huge, there are over 500 up-to-date pages now and this number keeps going up at a fast pace. I understand it might be hard to keep up with the current content so I would suggest we all discuss our ideas and plans for administering, organizing and maintaining the wiki before taking any big action. It would save us all a lot of time and will help us to maintain a clear and consistent message of what and how we display the info. ( again, just my suggestion ). With that said, what should we do with the pages we already have? Cheers! Hernan Alan D. Cabrera wrote: Hernan, Dain and I are working off of http://cwiki.apache.org/GMOxDEV/ priorities-12.html. I prefer that there be a single source for this kind of information and since Dain and I are working with the pointy end of the stick, let's use our page. The general roadmap feature set that you have is useful. I'd like to keep the resource commitments on the above page. Regards, Alan On Sep 28, 2006, at 11:14 AM, Hernan Cunico wrote: Yeah, tricky column. Should we have a separate release roadmap page for each release? With some exceptions the Target Release column just shows 1.2. I added 1.1.1 because most of the doc is completed after the software is released. I am currently working on v1.1 and v1.1.1 doc and hope to have as a minimum those features also covered in the upcoming release. I see several folks updating the Person working on the function column already. ;-) BTW, adding some comments during the page update may help a lot ( thanks Jacek ;-) ) Probably Dain and/or Alan ( being the release managers ) would have some thoughts as of how to have this list better organized. Cheers! Hernan Paul McMahan wrote: Thanks Hernan. I put my name next to some items. I wasn't sure how to determine the target release, though. I'm assuming that column will undergo some refinement. Best wishes, Paul On 9/26/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I just updated the release roadmap with some doc stuff and put my name on it. http://cwiki.apache.org/GMOxPMGT/geronimo-release-roadmap.html Pls chime in and put your name too. Cheers! Hernan
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
For the simple expressions we are using I don't think it matters... and the jexl bits are already coded... once this is committed, if you guys still want ognl we can look at replacing it. But right now I don't care enough to change it. --jason On Oct 5, 2006, at 11:07 AM, Dain Sundstrom wrote: 40k is nothing so I don't think that should be the deciding factor. I personally think we should go with ognl on rep alone. I hear nothing but bad things about jexl and only praise for ognl. -dain On Oct 5, 2006, at 10:57 AM, Jason Dillon wrote: ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm inclined to use jexl for now based on its size and relative simplicity. --jason On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote: btw.. ongl might also be a good canidate to use as an expression language. On 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: I cleaned up my quick POC into a patch suitable to be applied to trunk: https://issues.apache.org/jira/browse/GERONIMO-2463 Please review. If there are no objections I will apply this over the weekend. Thanks, --jason -- Regards, Hiram Blog: http://hiramchirino.com
Re: dojo in Geronimo
Hello Jay, I agree with your idea to improve Dojo’s performance in G. I suggest you create a JIRA for this so we can keep track of it. You might want to checkout the Dojo builder (uses ant) which packages js and related files into a single compressed js file. I think somebody from the devlist already suggested this. Best wishes, chris Jay D. McHugh wrote: Hello all, I finally managed to get my project development/testing server up and working on 1.2-snapshot (Thanks again djencks!). And I finally got to see the JMX console that was added - Which is very cool. But, I think that it brings to light a performance issue. Because we are using dojo widgets that are not 'bundled' into the dojo.js library, we end up pulling down -many- individual files to support the widgets. I think we should consider building our own dojo bundle (I'm going to start looking into exactly how to do this) and deploying it to something like /geronimo-dojo and using that for console apps. Pulling the one (slightly larger) library -should- increase response time since we won't need all of the extra file requests/responses going over the wire. I do like having dojo deployed to /dojo built into the server though and would like to keep the base library there (so far I have just been using the AJAX portion of dojo in my own apps - so I haven't needed any widgets). Does anyone have any thoughts about this? Jay
[jira] Commented: (GERONIMO-2463) Add support to conditionally load modules based on environment + simple expression
[
http://issues.apache.org/jira/browse/GERONIMO-2463?page=comments#action_12440214
]
Jason Dillon commented on GERONIMO-2463:
TODO: Add support for version ranges like {{1.4+}} or {{1.5*}}
Add support to conditionally load modules based on environment + simple
expression
--
Key: GERONIMO-2463
URL: http://issues.apache.org/jira/browse/GERONIMO-2463
Project: Geronimo
Issue Type: New Feature
Security Level: public(Regular issues)
Components: core
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Attachments: GERONIMO-2463.diff
Add support to conditionally load modules (defined in {{config.xml}}) based
on environment + simple expression.
--
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: dojo in Geronimo
You raise a good point and it sounds like the idea would work, but I'm concerned it could lead to a proliferation of dojo webapp components, one for each custom configuration. I wonder if it might be possible to instead create a servlet in the current dojo app that could build and cache custom configurations on the fly. That way we could keep the current standard library in place for unoptimized dojo apps but still serve up customized configurations from this same location for optimized dojo apps. Off the top of my head, invoking the servlet could look something like: /dojo/dojo?widget1=treewidget2=table... This approach also keeps us in line with some of the other motivations for making dojo a native component in the server -- easy to upgrade, easy to reference from deployment plans, keeps the server footprint to a minimum, etc. Best wishes, Paul On 10/5/06, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, I finally managed to get my project development/testing server up and working on 1.2-snapshot (Thanks again djencks!). And I finally got to see the JMX console that was added - Which is very cool. But, I think that it brings to light a performance issue. Because we are using dojo widgets that are not 'bundled' into the dojo.js library, we end up pulling down -many- individual files to support the widgets. I think we should consider building our own dojo bundle (I'm going to start looking into exactly how to do this) and deploying it to something like /geronimo-dojo and using that for console apps. Pulling the one (slightly larger) library -should- increase response time since we won't need all of the extra file requests/responses going over the wire. I do like having dojo deployed to /dojo built into the server though and would like to keep the base library there (so far I have just been using the AJAX portion of dojo in my own apps - so I haven't needed any widgets). Does anyone have any thoughts about this? Jay
Re: [REVIEW] Conditionally loading modules based on expression (and environment)
Okay, I implemented a ognl condition parser... it appears that the similar syntax can be used... so !java.is1_5 appears to work in both. Not sure which is better though, both provide some sort of syntax errors... neither complains about invalid variable references. I will update the patch with both impls and a few tests... and then we can pick one. --jason On Oct 5, 2006, at 11:07 AM, Dain Sundstrom wrote: 40k is nothing so I don't think that should be the deciding factor. I personally think we should go with ognl on rep alone. I hear nothing but bad things about jexl and only praise for ognl. -dain On Oct 5, 2006, at 10:57 AM, Jason Dillon wrote: ognl-2.6.9.jar is 164k compared to 129k for commons-jexl... so I'm inclined to use jexl for now based on its size and relative simplicity. --jason On Oct 4, 2006, at 8:45 PM, Hiram Chirino wrote: btw.. ongl might also be a good canidate to use as an expression language. On 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: I cleaned up my quick POC into a patch suitable to be applied to trunk: https://issues.apache.org/jira/browse/GERONIMO-2463 Please review. If there are no objections I will apply this over the weekend. Thanks, --jason -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (AMQ-958) Supprot a create=false option on the vm://localhost transport so that the connect fails if the broker is not allready running
Supprot a create=false option on the vm://localhost transport so that the connect fails if the broker is not allready running - Key: AMQ-958 URL: https://issues.apache.org/activemq/browse/AMQ-958 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assigned To: 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] Resolved: (AMQ-958) Supprot a create=false option on the vm://localhost transport so that the connect fails if the broker is not allready running
[ https://issues.apache.org/activemq/browse/AMQ-958?page=all ] Hiram Chirino resolved AMQ-958. --- Resolution: Fixed Committed in trunk revision: 453380 Supprot a create=false option on the vm://localhost transport so that the connect fails if the broker is not allready running - Key: AMQ-958 URL: https://issues.apache.org/activemq/browse/AMQ-958 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assigned To: 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
Re: dojo in Geronimo
Paul McMahan wrote: You raise a good point and it sounds like the idea would work, but I'm concerned it could lead to a proliferation of dojo webapp components, one for each custom configuration. I wonder if it might be possible to instead create a servlet in the current dojo app that could build and cache custom configurations on the fly. That way we could keep the current standard library in place for unoptimized dojo apps but still serve up customized configurations from this same location for optimized dojo apps. Off the top of my head, invoking the servlet could look something like: /dojo/dojo?widget1=treewidget2=table... This approach also keeps us in line with some of the other motivations for making dojo a native component in the server -- easy to upgrade, easy to reference from deployment plans, keeps the server footprint to a minimum, etc. Best wishes, Paul On 10/5/06, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, I finally managed to get my project development/testing server up and working on 1.2-snapshot (Thanks again djencks!). And I finally got to see the JMX console that was added - Which is very cool. But, I think that it brings to light a performance issue. Because we are using dojo widgets that are not 'bundled' into the dojo.js library, we end up pulling down -many- individual files to support the widgets. I think we should consider building our own dojo bundle (I'm going to start looking into exactly how to do this) and deploying it to something like /geronimo-dojo and using that for console apps. Pulling the one (slightly larger) library -should- increase response time since we won't need all of the extra file requests/responses going over the wire. I do like having dojo deployed to /dojo built into the server though and would like to keep the base library there (so far I have just been using the AJAX portion of dojo in my own apps - so I haven't needed any widgets). Does anyone have any thoughts about this? Jay Hey Paul, That sounds like it would be a very cool servlet. Right now, trying to figure out the logistics of making it work are tying my brain into knots. I will see if I can figure out a way to do it though. (suggestions welcome though). I'll let you all know if I come up with something. Jay
Re: dojo in Geronimo (long)
Paul McMahan wrote: You raise a good point and it sounds like the idea would work, but I'm concerned it could lead to a proliferation of dojo webapp components, one for each custom configuration. I wonder if it might be possible to instead create a servlet in the current dojo app that could build and cache custom configurations on the fly. That way we could keep the current standard library in place for unoptimized dojo apps but still serve up customized configurations from this same location for optimized dojo apps. Off the top of my head, invoking the servlet could look something like: /dojo/dojo?widget1=treewidget2=table... This approach also keeps us in line with some of the other motivations for making dojo a native component in the server -- easy to upgrade, easy to reference from deployment plans, keeps the server footprint to a minimum, etc. Best wishes, Paul On 10/5/06, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, I finally managed to get my project development/testing server up and working on 1.2-snapshot (Thanks again djencks!). And I finally got to see the JMX console that was added - Which is very cool. But, I think that it brings to light a performance issue. Because we are using dojo widgets that are not 'bundled' into the dojo.js library, we end up pulling down -many- individual files to support the widgets. I think we should consider building our own dojo bundle (I'm going to start looking into exactly how to do this) and deploying it to something like /geronimo-dojo and using that for console apps. Pulling the one (slightly larger) library -should- increase response time since we won't need all of the extra file requests/responses going over the wire. I do like having dojo deployed to /dojo built into the server though and would like to keep the base library there (so far I have just been using the AJAX portion of dojo in my own apps - so I haven't needed any widgets). Does anyone have any thoughts about this? Jay Hello all, Thought I would throw out the basic frame of what I -think- we would need to do in order to make a dynamic 'dojo.js builder' servlet. First, we would need to spin through all of the dojo source code and assemble the dependencies of everything. I would suggest that this would be stored in a database (probably derby since it's handy). As a second step (or as part of the first) we would need to capture all of the dojo source code in a database as well so that when the servlet receives a request it has the code available to assemble. I originally thought that we might want to make a method in the servlet for each javascript function or library - but I think that would make the assembly of the code more complicated. Lastly (and the easiest step) we would need to write the servlet to receive one or more requirements that would be used to specify how much would need to be pulled in. I think requirements might be a better parameter to specify than widgets and it follows along with how dojo is organized - providers and require-ers. -OR- A simpler version would be to have our base dojo.js be the 'kitchen-sink' distribution (that is really what it is called by the way) and only specify widgets. Each widget and its dependencies would be stored in a method of the servlet and be included along with the base 'dojo.js' that is sent down from the server. Between these, I think the first one is really the better of the two because it could actually send down only what is needed - cutting down the bandwith used (the real purpose of the whole exercise). The second has a strong likelihood of introducing a lot of redundancy in the code that is sent. And that would probably make the library end up either inconsistent or plain old broken (if there are two dojo.doSomething functions, which gets run?). Also, I think we have a better chance of developing an automated process to parse the dojo source all the way down to its smallest pieces. The second choice (that I thought of anyway - there may be more options so if you have one, speak up) would probably just be an ugly manual process that would have to be done each time a new version of dojo comes out. Thoughts? Jay
[jira] Commented: (AMQ-813) can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module
[ https://issues.apache.org/activemq/browse/AMQ-813?page=comments#action_37112 ] Hiram Chirino commented on AMQ-813: --- Hi Gary, Please open a new issue since ti seems like a different problem. Also, a small web app test case would help us be able to reproduce the issue. can get a shutdown hang when using embedded broker with VM transport along with the activemq-web module --- Key: AMQ-813 URL: https://issues.apache.org/activemq/browse/AMQ-813 Project: ActiveMQ Issue Type: Bug Reporter: james strachan Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 See attached thread dump. I think we just need to use a timeout on the close operations (such as to close consumers, sessions, producers) Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing): Shutdown prio=1 tid=0x08385960 nid=0x5e99 in Object.wait() [0xaed7d000..0xaed7e130] at java.lang.Object.wait(Native Method) - waiting on 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75) - locked 0x88af01c8 (a edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) at edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318) at org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:41) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:72) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1660) at org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516) at org.apache.activemq.web.WebClient.closeConsumers(WebClient.java:135) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.close(WebClient.java:145) - locked 0x893e6558 (a org.apache.activemq.web.WebClient) at org.apache.activemq.web.WebClient.valueUnbound(WebClient.java:318) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.unbindValue(AbstractSessionManager.java:899) at org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:755) - locked 0x893caa88 (a org.mortbay.jetty.servlet.HashSessionManager$Session) at org.mortbay.jetty.servlet.AbstractSessionManager.doStop(AbstractSessionManager.java:551) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:124) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:467) at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:477) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerCollection.doStop(HandlerCollection.java:173) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131) at org.mortbay.jetty.Server.doStop(Server.java:242) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:63) at org.mortbay.jetty.Server$ShutdownHookThread.run(Server.java:450) -- 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: micro-G modules(configs)
I marked the ones to remove IMO with an X I seem to have a more extreme view of micro than you :-) I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? X connector-deployer geronimo-gbean-deployer X hot-deployer X j2ee-deployer X j2ee-security X j2ee-server j2ee-system X online-deployer rmi-naming X sharedlib shutdown X transaction X unavailable-client-deployer X unavailable-ejb-deployer X unavailable-webservices-deployer I'd like to be able to remove the unavailable* deployers but at the moment I think they are pretty tightly tied to the j2ee-deployer which IIUC we need to keep since it is really not just for j2ee deployments. IIRC I attempted to remove j2ee-deployer earlier and discovered that I needed this to be able to deploy plugins into micro-G. I think the other j2ee* modules are likewise required for more than just j2ee content. Is this true? I think we might be able to remove hot-deployer ... any thoughts? My only concern is that if we get too fine grained then it gets difficult to build up the image to be equivalent for little-G or higher. Right now to get from micro-G to little-G you need to deploy both the tomcat or jetty plugin and the corresponding deployer. Removing hot-deployer will add another item to the list. Thoughts? Joe
Re: micro-G modules(configs)
I think we need to keep enough in there that the command-line deploy tool still works. It looks like online-deployer is empty (or else I would have said to keep that), but I think j2ee-security is required for the JMX remoting used by the deploy tool. Without this, I think you'll have to mangle the repository contents and config.xml by hand in order to ever have more than Micro G (ick). Anyway, I would also be in favor of separating the specs from RMI naming. Thanks, Aaron P.S. Maybe we should whack the online-deployer module and rename j2ee-security to just security or something. On 10/5/06, David Jencks [EMAIL PROTECTED] wrote: I marked the ones to remove IMO with an X I seem to have a more extreme view of micro than you :-) I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? X connector-deployer geronimo-gbean-deployer X hot-deployer X j2ee-deployer X j2ee-security X j2ee-server j2ee-system X online-deployer rmi-naming X sharedlib shutdown X transaction X unavailable-client-deployer X unavailable-ejb-deployer X unavailable-webservices-deployer I'd like to be able to remove the unavailable* deployers but at the moment I think they are pretty tightly tied to the j2ee-deployer which IIUC we need to keep since it is really not just for j2ee deployments. IIRC I attempted to remove j2ee-deployer earlier and discovered that I needed this to be able to deploy plugins into micro-G. I think the other j2ee* modules are likewise required for more than just j2ee content. Is this true? I think we might be able to remove hot-deployer ... any thoughts? My only concern is that if we get too fine grained then it gets difficult to build up the image to be equivalent for little-G or higher. Right now to get from micro-G to little-G you need to deploy both the tomcat or jetty plugin and the corresponding deployer. Removing hot-deployer will add another item to the list. Thoughts? Joe
[jira] Reopened: (AMQ-805) Restart network bridges if they ever get stopped
[ https://issues.apache.org/activemq/browse/AMQ-805?page=all ] Tom Kaitchuck reopened AMQ-805: --- This issue seems to have never been fixed. Restart network bridges if they ever get stopped Key: AMQ-805 URL: https://issues.apache.org/activemq/browse/AMQ-805 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Right now it seems like we only trap remote exceptions and then restart the bridge. I think we should restart the network bridge if the bridge fails for any reason. -- 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-805) Restart network bridges if they ever get stopped
[ https://issues.apache.org/activemq/browse/AMQ-805?page=comments#action_37114 ] Hiram Chirino commented on AMQ-805: --- Hi Tom, do you have a test case? Restart network bridges if they ever get stopped Key: AMQ-805 URL: https://issues.apache.org/activemq/browse/AMQ-805 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Right now it seems like we only trap remote exceptions and then restart the bridge. I think we should restart the network bridge if the bridge fails for any reason. -- 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-805) Restart network bridges if they ever get stopped
[ https://issues.apache.org/activemq/browse/AMQ-805?page=all ] Tom Kaitchuck updated AMQ-805: -- Attachment: test_patch.diff Does this make sense as a way to deal with the problem? Obviously before committing this we should make the interval configurable, and probably make it exponential. I am also still concerned about thread safety, but that is a separate issue. Restart network bridges if they ever get stopped Key: AMQ-805 URL: https://issues.apache.org/activemq/browse/AMQ-805 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Attachments: test_patch.diff Right now it seems like we only trap remote exceptions and then restart the bridge. I think we should restart the network bridge if the bridge fails for any reason. -- 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: micro-G modules(configs)
On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote: I think we need to keep enough in there that the command-line deploy tool still works. It looks like online-deployer is empty (or else I would have said to keep that), but I think j2ee-security is required for the JMX remoting used by the deploy tool. Without this, I think you'll have to mangle the repository contents and config.xml by hand in order to ever have more than Micro G (ick). Anyway, I would also be in favor of separating the specs from RMI naming. Thanks, Aaron P.S. Maybe we should whack the online-deployer module and rename j2ee-security to just security or something. 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? thanks david jencks On 10/5/06, David Jencks [EMAIL PROTECTED] wrote: I marked the ones to remove IMO with an X I seem to have a more extreme view of micro than you :-) I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? X connector-deployer geronimo-gbean-deployer X hot-deployer X j2ee-deployer X j2ee-security X j2ee-server j2ee-system X online-deployer rmi-naming X sharedlib shutdown X transaction X unavailable-client-deployer X unavailable-ejb-deployer X unavailable-webservices-deployer I'd like to be able to remove the unavailable* deployers but at the moment I think they are pretty tightly tied to the j2ee-deployer which IIUC we need to keep since it is really not just for j2ee deployments. IIRC I attempted to remove j2ee-deployer earlier and discovered that I needed this to be able to deploy plugins into micro-G. I think the other j2ee* modules are likewise required for more than just j2ee content. Is this true? I think we might be able to remove hot-deployer ... any thoughts? My only concern is that if we get too fine grained then it gets difficult to build up the image to be equivalent for little-G or higher. Right now to get from micro-G to little-G you need to deploy both the tomcat or jetty plugin and the corresponding deployer. Removing hot-deployer will add another item to the list. Thoughts? Joe
Re: out-of-the-box experience very limited
[EMAIL PROTECTED] wrote: Please don't get me wrong: I'm not aiming at critisizing the example or the great work done so far. I'm just and only trying to show where newbies lack information. As the user feedback request showed, for most users quality of information is an issue -- and mainly the why and where to get that info?. Just as an example what I mean by where to get that info?: I stumbled in http://goopen.org/confluence/display/SM/Quartz quartz over A number of properties can be configured on the component: marshaler:... Briefly, we tell a newbie hey, there's a property called marshaler you can set but we do not provide him with the slightest hint on how to set it correctly. Well, from that description I guess marshaler will be on the same level as triggers (thus inside bean class=org.apache.servicemix.components.quartz.QuartzComponent ) and -- as only one single parameter is needed -- the statement has to be just like it is for property name=repeatCount value=20/ thus I add property name=marshaler value=org.apache.servicemix.components.quartz.DefaultQuartzMarshaler / which brings the following error (truncated) Loading Apache ServiceMix from file: Timer2WireTap2File_and_Screen.xml INFO - ConnectorServerFactoryBean - JMX connector available at: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi Caught: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.servicemix.jbi.container.ActivationSpec' defined in file [C:\SM_binary30b\bin\Timer2WireTap2File_and_Screen.xml]: Cannot create inner bean 'org.apache.servicemix.components. quartz.QuartzComponent' while setting constructor argument with index 0; ... ... Caused by: java.lang.IllegalArgumentException: No matching editors or conversion strategy found at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:212) at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:127) ... ... This message is not really leading towards the correct way. And IMHO it's not THAT proximate/obvious to do this http://google.com/codesearch?q=marshaler+file%3A.xml+package%3Ahttp%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fincubator%2Fservicemix%2FtrunkbtnG=Searchhl=enlr= google search in order to find how other marshalers are configured and to try out property name=marshaler bean class=org.apache.servicemix.components.quartz.DefaultQuartzMarshaler / /property what finally works. IMHO, a guide on _how to figure out the correct way_ to configure SM and it's components is required, as a) docu will never cover own components etc. (=user HAS TO find out himself) and b) will also never cover 100% for current code, e.g. http://goopen.org/confluence/display/SM30UG/6.+Configuring+ServiceMix configuration does not mention the meaning of several attributes (eg. persistent, notifyStatistics). It teaches newbies some practices (redurcing frustration) and helps us more experienced ones to find more efficient ways for our issue fixing. I myself tried to include some of the methods learned into the wiki pages, but it's a) distributed and b) only the tip of the iceberg. Consequently, one brainstorming wiki page is my suggestion. Items may usually consist of 1) error message highlighting relevant pieces of information, 2) conclusions from those pieces, 3) successful way(s) of info retrieval, 4) (maybe) why/when using this way?, see http://goopen.org/confluence/display/SM30UG/3.+Installation#3.Installation-Troubleshooting troubleshooting for a clue. Any thoughts? Any volunteers? I really hope a well helping docu will be installed :-) but I'm quite surprised how difficult it is to do for a software with such a complex infrastructure :-/ Georg -- View this message in context: http://www.nabble.com/out-of-the-box-experience-very-limited-tf2389329.html#a6670310 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-1823) Add Embedded LDAP Server Viewer Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1823?page=all ] Christopher M. Cardona updated GERONIMO-1823: - Attachment: GERONIMO-1823-trunk2.patch ldapviewer-jetty-1.2-SNAPSHOT.car ldapviewer-tomcat-1.2-SNAPSHOT.car The ff. files are attached: 1. GERONIMO-1823-trunk2.patch - an updated patch with the ff. changes: - Added a way to connect to other LDAP servers and not just the embedded Apache DS. By default it connects to the embedded Apache DS but if it fails to connect the user will have the option to connect to other directory servers. - Left navigation portlet link was modified from 'Embedded LDAP' to 'LDAP Viewer' to make it more generic and appropriate. 2. ldapviewer-portlet-1.2-SNAPSHOT.jpg - sample connecting to Apache DS Note: Because it is now possible to connect to other LDAP servers it would be nice for this portlet to be included in the Console as an additional easily accessible tool like the JMX viewer. This will allow the user to test and navigate any directory server being used when creating an LDAP realm or just to test any directory server being used by any application. This patch was included as one of the options to integrate this work to Geronimo. The other option as suggested by Aaron is to create a standalone webapp version of this portlet so I created the ff. plugins: 1. ldapviewer-jetty-1.2-SNAPSHOT.car - LDAP viewer webapp for G/Jetty 1.2-SNAPSHOT build 2. ldapviewer-tomcat-1.2-SNAPSHOT.car - LDAP viewer webapp for G/Tomcat 1.2-SNAPSHOT build 3. ldapviewer-webapp-1.2-SNAPSHOT.jpg - sample connecting to OpenLDAP As always comments and suggestions are welcome. Thanks. Add Embedded LDAP Server Viewer Portlet --- Key: GERONIMO-1823 URL: http://issues.apache.org/jira/browse/GERONIMO-1823 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, GERONIMO-1823-trunk2.patch, ldapMgrPortlet-B1.1.1.jpg, ldapMgrPortlet-B1.1.1.patch, ldapMgrPortlet-Snapshot.zip, ldapMgrPortlet.patch, ldapviewer-jetty-1.2-SNAPSHOT.car, ldapviewer-tomcat-1.2-SNAPSHOT.car, sample.ldif Add a new portlet for viewing the contents of the embedded directory server (Apache DS). This portlet will be under 'Misc' portlets. -- 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-1823) Add Embedded LDAP Server Viewer Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1823?page=all ] Christopher M. Cardona updated GERONIMO-1823: - Attachment: ldapviewer-portlet-1.2-SNAPSHOT.jpg ldapviewer-webapp-1.2-SNAPSHOT.jpg Add Embedded LDAP Server Viewer Portlet --- Key: GERONIMO-1823 URL: http://issues.apache.org/jira/browse/GERONIMO-1823 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, GERONIMO-1823-trunk2.patch, ldapMgrPortlet-B1.1.1.jpg, ldapMgrPortlet-B1.1.1.patch, ldapMgrPortlet-Snapshot.zip, ldapMgrPortlet.patch, ldapviewer-jetty-1.2-SNAPSHOT.car, ldapviewer-portlet-1.2-SNAPSHOT.jpg, ldapviewer-tomcat-1.2-SNAPSHOT.car, ldapviewer-webapp-1.2-SNAPSHOT.jpg, sample.ldif Add a new portlet for viewing the contents of the embedded directory server (Apache DS). This portlet will be under 'Misc' portlets. -- 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-680) org.apache.servicemix.soap.handlers.security.WSSecurityHandlerTest
org.apache.servicemix.soap.handlers.security.WSSecurityHandlerTest -- Key: SM-680 URL: https://issues.apache.org/activemq/browse/SM-680 Project: ServiceMix Issue Type: Sub-task Components: servicemix-soap Affects Versions: incubation Reporter: Fritz Oconer -- 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
Info needed: migrating openejb-itests to testsuite framework
I am looking at migrating the openejb-itests to the new testsuite framework. I already have the plan migrated to the 1.1 format. However I have some questions regarding the way the classes for the ejb jars are set up and the classes for tests. Can someone please shed some light on it and help me understand the present structure ? The way I see it, the openejb-itests project creates 8 ejb archives by jar'ing a set or subset of classes and combining it with different plans and DDs. The archives are : scenario1 scenario2 scenario3 cmp2-prefetch cmp2-petstore cmp2-storage cmp2-cmrmapping openejb-itests The classes come from the java source files in src/java. The correct m2 way of building these many artifacts would be to create their own projects. Question 1 Now, are these java files disjoint enough that they can be split apart into as many projects as the ejb archives we need ? Don't think we can build all the classes in one core m2 project and use the classes in another project which has just the plan DD. Can we ? Question 2. Is the openejb-itests archive really needed ? It is the one big archive for the whole project that encompasses everything. It has it's own plan and DD and is also distributed into the server. But it also contains the other archives. This is kinda confusing. I believe the test java files are in src/itest directory. However, they have a dependency on the java files in src/java. Like I said, the only a subset of files in src/java are used to create archives. The rest are either included in that big openejb-itests archive or simply needed to support the junit tests in src/itests. Now why is it structured this way ? Why weren't they moved to the src/itests dir where they are needed ? Thanx in advance Cheers Prasad
Re: micro-G modules(configs)
Yes, we need to keep enough to be able to run the command line deployer. When I pulled j2ee-deployer I was unable to run the command line deploy. more comments/questions below David Jencks wrote: On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote: I think we need to keep enough in there that the command-line deploy tool still works. It looks like online-deployer is empty (or else I would have said to keep that), but I think j2ee-security is required for the JMX remoting used by the deploy tool. Without this, I think you'll have to mangle the repository contents and config.xml by hand in order to ever have more than Micro G (ick). Anyway, I would also be in favor of separating the specs from RMI naming. So let me see if I understand the idea here. I can pull the spec dependencies from RMI naming and create a new config with just those dependencies. I suspect that I will need to make rmi-naming dependent on the new spec config but then I think that limits the ability to easily switch between 1.4 and 1.5 specs. Are the specs not really required for rmi-naming and currently included just as a way to get the specs in the image? Thanks, Aaron P.S. Maybe we should whack the online-deployer module and rename j2ee-security to just security or something. 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 was under the impression that this was required for the command line deploy as well but I'll pull it and see what happens. 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? thanks david jencks On 10/5/06, David Jencks [EMAIL PROTECTED] wrote: I marked the ones to remove IMO with an X I seem to have a more extreme view of micro than you :-) I'm all for getting micro-G as small as possible so long as we can grow it easily. I guess if the dependencies are all correct (which is not the case right now) then installing the higher level plugins should pull everything else along for the ride. I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? X connector-deployer OK, I'll attempt to pull this one. geronimo-gbean-deployer X hot-deployer I'll pull this one too. X j2ee-deployer So I assume that we really need to keep this for plugin deployment unless we rework that code some more. X j2ee-security If this isn't really j2ee specific then I can rename it but based upon Aaron's comments it looks like this is still required in micro-G. X j2ee-server Is it true j2ee-server can be removed? I was under the impress that this was necessary for some of the management capabilities. j2ee-system X online-deployer Is this not necessary for command-line deployement as well? rmi-naming X sharedlib Isn't sharelib of value even without the web containers? I didn't think there was a lot of value in removing this but it's an easy one to pull. shutdown X transaction I can look at removing this as well but I was under the impression that the transaction capability was general purpose and not tied directly to j2ee. X unavailable-client-deployer X unavailable-ejb-deployer X unavailable-webservices-deployer I think these three unavailable* configs are necessary so long as we keep the j2ee-deployer. I'd like to be able to remove the unavailable* deployers but at the moment I think they are pretty tightly tied to the j2ee-deployer which IIUC we need to keep since it is really not just for j2ee deployments. IIRC I attempted to remove j2ee-deployer earlier and discovered that I needed this to be able to deploy plugins into micro-G. I think the other j2ee* modules are likewise required for more than just j2ee content. Is this true? I think we might be able to remove hot-deployer ... any thoughts? My only concern is that if we get too fine grained then it gets difficult to build up the image to be equivalent for little-G or higher. Right now to get from micro-G to little-G you need to deploy both the tomcat or jetty plugin and the corresponding deployer. Removing hot-deployer will add another item to the list. Thoughts? Joe
[jira] Created: (SM-681) org.apache.servicemix.jsr181.Jsr181SpringTest
org.apache.servicemix.jsr181.Jsr181SpringTest - Key: SM-681 URL: https://issues.apache.org/activemq/browse/SM-681 Project: ServiceMix Issue Type: Sub-task Components: servicemix-jsr181 Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-682) org.apache.servicemix.jsr181.Jsr181SpringProxyTest
org.apache.servicemix.jsr181.Jsr181SpringProxyTest -- Key: SM-682 URL: https://issues.apache.org/activemq/browse/SM-682 Project: ServiceMix Issue Type: Sub-task Components: servicemix-jsr181 Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-683) org.apache.servicemix.jsr181.Jsr181ProxySUTest
org.apache.servicemix.jsr181.Jsr181ProxySUTest -- Key: SM-683 URL: https://issues.apache.org/activemq/browse/SM-683 Project: ServiceMix Issue Type: Sub-task Components: servicemix-jsr181 Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-684) (servicemix-itests) org.apache.servicemix.itests.deadlock.DeadlockTest
[ https://issues.apache.org/activemq/browse/SM-684?page=all ] Fritz Oconer updated SM-684: Summary: (servicemix-itests) org.apache.servicemix.itests.deadlock.DeadlockTest (was: org.apache.servicemix.itests.deadlock.DeadlockTest) Component/s: (was: servicemix-jsr181) (servicemix-itests) org.apache.servicemix.itests.deadlock.DeadlockTest -- Key: SM-684 URL: https://issues.apache.org/activemq/browse/SM-684 Project: ServiceMix Issue Type: Sub-task Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-684) org.apache.servicemix.itests.deadlock.DeadlockTest
org.apache.servicemix.itests.deadlock.DeadlockTest -- Key: SM-684 URL: https://issues.apache.org/activemq/browse/SM-684 Project: ServiceMix Issue Type: Sub-task Components: servicemix-jsr181 Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-685) (servicemix-itests) org.apache.servicemix.itests.WSNComponentTest
(servicemix-itests) org.apache.servicemix.itests.WSNComponentTest - Key: SM-685 URL: https://issues.apache.org/activemq/browse/SM-685 Project: ServiceMix Issue Type: Sub-task Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-686) (servicemix-itests) org.apache.servicemix.itests.Jsr181HttpTest
(servicemix-itests) org.apache.servicemix.itests.Jsr181HttpTest --- Key: SM-686 URL: https://issues.apache.org/activemq/browse/SM-686 Project: ServiceMix Issue Type: Sub-task Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-687) (servicemix-itests) org.apache.servicemix.itests.HttpJmsRoundtripTest
(servicemix-itests) org.apache.servicemix.itests.HttpJmsRoundtripTest - Key: SM-687 URL: https://issues.apache.org/activemq/browse/SM-687 Project: ServiceMix Issue Type: Sub-task Affects Versions: incubation Reporter: Fritz Oconer -- 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: (SM-688) (servicemix-itests) org.apache.servicemix.itests.EIPAndXsltTest
(servicemix-itests) org.apache.servicemix.itests.EIPAndXsltTest --- Key: SM-688 URL: https://issues.apache.org/activemq/browse/SM-688 Project: ServiceMix Issue Type: Sub-task Affects Versions: incubation Reporter: Fritz Oconer -- 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] Resolved: (GERONIMO-2465) Relocate plugin repository list to a source controlled location
[ http://issues.apache.org/jira/browse/GERONIMO-2465?page=all ] Paul McMahan resolved GERONIMO-2465. Fix Version/s: 1.2 Resolution: Fixed Created a repository list at http://geronimo.apache.org/plugins/plugin-repository-list-1.2.txt and adjusted the config.xml files in assemblies to point at it. Relocate plugin repository list to a source controlled location --- Key: GERONIMO-2465 URL: http://issues.apache.org/jira/browse/GERONIMO-2465 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1, 1.1.1 Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2 The default list of plugin repositories that gets loaded into the admin console currently comes from a user directory at people.apache.org. The list should be relocated to SVN so that it can be version controlled and updated by project committers. See discussion at: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200609.mbox/[EMAIL PROTECTED] -- 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
Pluggable Stomp/AMQ translation
Just checked in a first take on pluggable stomp to amq translation. Right now there is one interface defined for doing both message conversions and destination name conversions. The behavior for the legacy conversion scheme is identical, I just moved the code around so that those four functions could be varied. Right now it takes the FrameTranslator instance off the transport factory. This probably isn't ideal, but I wanted to talk about the best way to do it here before trying to muck around with xbean. -Brian ps: Speaking of xbean, has anyone considered making a less sysadmin- hostile configuration scheme than java class names mapped not-quite- obviously into XML?
[jira] Commented: (GERONIMO-2413) Add a Certification Authority (CA) portlet to Geronimo console
[ http://issues.apache.org/jira/browse/GERONIMO-2413?page=comments#action_12440341 ] Vamsavardhana Reddy commented on GERONIMO-2413: --- Excerpt from my first comment: Certification Authority portlet with the following functions: 1. 2. 3. another 3. 4 ... I seem to have counting problems :o(. But, you can definitely count on me :o) Add a Certification Authority (CA) portlet to Geronimo console -- Key: GERONIMO-2413 URL: http://issues.apache.org/jira/browse/GERONIMO-2413 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console, security Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.x Attachments: 02.ca-initialization-enter-details.JPG, 07.issue-certificate-show-csr-details.JPG, 09.issue-certificate-successful.JPG, GERONIMO-2413-revised.patch, GERONIMO-2413.patch, GeronimoCA.zip A Certification Authority portlet will be very useful. A full fledged CA may be a long way to go. But what ever minimum function is required to process CSR's etc. is not hard and the users can issue their own digital certificates instead of getting trial certificates from some CA. -- 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
