[jira] Resolved: (AMQ-531) XBean has a runtime issue with Spring 2.0M2
[ https://issues.apache.org/activemq/browse/AMQ-531?page=all ] james strachan resolved AMQ-531: Resolution: Fixed This is now fixed in SVN HEAD - we are using 2.0-m5 of Spring which works with 2.4 or later of xbean-spring XBean has a runtime issue with Spring 2.0M2 --- Key: AMQ-531 URL: https://issues.apache.org/activemq/browse/AMQ-531 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 M4 Environment: Spring 2.0M2 Reporter: Ben Hale Assignee: james strachan Fix For: 4.1 Apparently there is an issue with XBean now that Spring 2.0 (starting with M2) is compiled against a Java 5 compiler (http://jira.codehaus.org/browse/XB-7). It's probably worth investigating how long before XBean releases a fix and postponing the 4.0 release until they do. If not, at least documenting in a known issues list that ActiveMQ 4.0 can't working with 2.0M2 and later until a later release where they do fix it. -- 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-25) allow messages for a particular clientID to be visible on a single Queue for administrators
[ https://issues.apache.org/activemq/browse/AMQ-25?page=all ] james strachan resolved AMQ-25: --- Resolution: Duplicate allow messages for a particular clientID to be visible on a single Queue for administrators --- Key: AMQ-25 URL: https://issues.apache.org/activemq/browse/AMQ-25 Project: ActiveMQ Type: New Feature Reporter: james strachan Priority: Minor Fix For: 4.1 For a topic consumer with a client ID, we could make all the messsages oustanding for the client appear as a logical Queue so that administrators could browser the outstanding messages and if need be delete/modify them. e.g. for a topic consumer with client ID of X we could create a virtual queue... ACTIVEMQ.CLIENT.TOPIC.X which could be used via some queue browser tool (like Hermes) to view all messages outstanding for a particular client. -- 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-430) create a Java Service Wrapper for ActiveMQ
[ https://issues.apache.org/activemq/browse/AMQ-430?page=all ] james strachan resolved AMQ-430: Fix Version: (was: 4.1) Resolution: Duplicate create a Java Service Wrapper for ActiveMQ -- Key: AMQ-430 URL: https://issues.apache.org/activemq/browse/AMQ-430 Project: ActiveMQ Type: New Feature Reporter: james strachan Assignee: Jonas Lim http://wrapper.tanukisoftware.org/doc/english/introduction.html so it can be easily monitored and restarted etc -- 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-360) total ordering of topics across networks (store and forward brokers)
[ https://issues.apache.org/activemq/browse/AMQ-360?page=all ] james strachan updated AMQ-360: --- Fix Version: 4.2 (was: 4.1) total ordering of topics across networks (store and forward brokers) Key: AMQ-360 URL: https://issues.apache.org/activemq/browse/AMQ-360 Project: ActiveMQ Type: New Feature Reporter: james strachan Fix For: 4.2 all messages sent to a topic are ordered across all producers on any broker in the network -- 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-468) Queue load balancing - optionally give highest priority to the local connection, then local broker then networks
[ https://issues.apache.org/activemq/browse/AMQ-468?page=all ] james strachan updated AMQ-468: --- Summary: Queue load balancing - optionally give highest priority to the local connection, then local broker then networks (was: Queue load balancing - optionally give highest priority to the local connection) Description: For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc was:For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Queue load balancing - optionally give highest priority to the local connection, then local broker then networks Key: AMQ-468 URL: https://issues.apache.org/activemq/browse/AMQ-468 Project: ActiveMQ Type: Improvement Reporter: Rob Davies Fix For: 4.1 For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc -- 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-340) allow topics in particular but also queues to have a 'namespace URI' like WS-Notification
[ https://issues.apache.org/activemq/browse/AMQ-340?page=comments#action_36503 ] james strachan commented on AMQ-340: Its been a while - I've kinda forgotten :) I think the idea was to allow different 'roots'. By default in JMS there is one global topic namespace where will receive every message. In WS-Notification you can have many 'root's. e.g. its a bit like having a topic which is owned by a particular broker. So I guess its more about having optional 'owners' of the topic namespace - so it could be a global foo.bar or could be foo.bar within the 'cheese' domain which might be owned by a particular broker allow topics in particular but also queues to have a 'namespace URI' like WS-Notification - Key: AMQ-340 URL: https://issues.apache.org/activemq/browse/AMQ-340 Project: ActiveMQ Type: New Feature Reporter: james strachan Fix For: 4.1 This would allow a real clean mapping from WS-N topics and ActiveMQ at the protocol level. We could use the namespace as a level of indirection to map to a broker, a cluster of brokers or even a particular area of a network etc. The namespace could be a broker's name too. -- 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-468) Queue load balancing - optionally give highest priority to the local connection, then local broker then networks
[ https://issues.apache.org/activemq/browse/AMQ-468?page=comments#action_36504 ] james strachan commented on AMQ-468: We mght want to weight consumers via * the session (so replies tend to go to the session which sent a message) * the connection that sent the message * VM connections (which are generally cheaper to use) I guess we might want this to be configurable. Queue load balancing - optionally give highest priority to the local connection, then local broker then networks Key: AMQ-468 URL: https://issues.apache.org/activemq/browse/AMQ-468 Project: ActiveMQ Type: Improvement Reporter: Rob Davies Fix For: 4.1 For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc -- 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-517) Create a C++ client for ActiveMQ that can work with STOMP and OpenWire
[ https://issues.apache.org/activemq/browse/AMQ-517?page=comments#action_36505 ] Nathan Mittler commented on AMQ-517: We're getting there - I've submitted the activemq-cpp to trunk. Currently it still only supports stomp, so it is a complete replacement for CMS. But, it's architecture is very close to the .NET openwire client and supports pluggable connectors in preparation for merging the openwire-cpp code in. This will be our next major task. Create a C++ client for ActiveMQ that can work with STOMP and OpenWire -- Key: AMQ-517 URL: https://issues.apache.org/activemq/browse/AMQ-517 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: Nathan Mittler Assignee: Nathan Mittler Priority: Minor Attachments: cms.tar.gz, cms_v2.tar.gz, cms_v3.tar.gz I've created this issue to post my code. Attached is my first cut at CMS (C++ Message Service) with a Stomp client. The idea is that CMS is the API (like JMS) and any messaging protocol can be used behind it (Stomp, OpenWire, etc). The docs folder contains the doxygen html for the source as well as a pdf document that gives a high-level overview. -- 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
New c++ client for stomp
I have just submitted a new C++ stomp client to the activemq SVN at https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ This serves as a full blown replacement for CMS, which didn't fully implementation of the protocol. Some of the features this includes are: 1) stomp protocol (requies AMQ 4.0.1 or later for the added request/response ids) 2) JMS 1.1-like API - consumers, producers, etc. - closely follows what was done in the .NET client. 3) support for topics and queues (so far as they are supported by stomp). 4) A pluggable architecture - facilitates having swappable protocols (can use openwire or stomp without changing code) 5) meta-url syntax similar to the other libraries to support passing in options on the url string. 6) complete suite of cpp-unit tests 7) integration-level tests (requires a broker) 8) Maven 2 build (uses Mojo native plugin) 9) Support for selectors 10) Support for durable subscriptions 11) Support for transactions *BUILDING** So far, we've only built on linux and windows - so feedback would be much appreciated from you Mac and Solaris users :) We have a couple ways of building: Maven 2 and makefiles. See the readme.txt at the root for details. The Maven build uses the Mojo Native Plugin, which has some limitations that we'll eventually need to get past. For one, there seems to be linking issues on Solaris, because it's passing in a -o option to AR, which causes heartburn. Other than that, we've had Maven sucessfully building on linux/gcc and windows/msvc-2005. *EXAMPLES* The usage is pretty similar to CMS. Check out the integration tests (essentially unit tests that require an activemq broker running) at https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/s rc/test-integration/ for examples of how to get up and running with activemq-cpp. TODO* 1) Merge in the openwire-cpp client as a connector in activemq-cpp. User's will be able to choose which connector they use in the URI syntax (similar to the way transports are configured in ActiveMQ). 2) Eliminate the makefiles and have everything building through Maven 3) Complete the Logging API 4) Add how to docs on the wiki 5) investigate the 999 (1000) messages bug with transactions - seems to be at the broker (not sure) 6) investigate why durable subscriptions aren't working 7) test with Hiram's latest stomp transport changes. KNOWN ISSUES* 1) Durable subscriptions don't seem to be working. The documentation reads that they are on by default, but reconnecting a client with the same client id doesn't seem to do the trick. 2) After committing a transaction, the consumer seems to stop getting messages after around 999/1000 messages. We think this is a bug at the broker, but more investigation is needed. 3) The Maven build doesn't work on Solaris - a -o is being passed into the archiver, which is unsupported. For all the tasks that CMS did, activemq-cpp should do just as well and is much better tested, so I would encourage those using CMS to make the switch. The next big step is to merge in the openwire-cpp code so that activemq-cpp is a one-stop-shop for all ActiveMQ protocols from C++. BTW - many thanks to Tim Bish for cranking out a lot of the code! Regards, Nate
RE: [activemq-user] Queue and Persistence for CMS
Arashad, Looking at the code, it appears that Tim Bish has implemented persistence in the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ ). This is a full-on replacement for CMS, but you'll need v4.0.1 (or later) of the broker. Unfortunately, I'm not sure that we have a use case that verifies whether or not persistence works, but you may want to give it a try. Let me know how it goes. Regards, Nate -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 2:04 AM To: [EMAIL PROTECTED]; activemq-dev@geronimo.apache.org Subject: Re: [activemq-user] Queue and Persistence for CMS Hi James.Strachan, I am working cms(ActiveMQ-4.0) code on SuSe(Linux machine- i686-suse-linux, version 2.6.13-15.8-default) You refer me to use Queue to mentain the persistence in the cms code, but this is Outstanding Item http://svn.apache.org/repos/asf/incubator/activemq/trunk/cms/d ocs/cms_overvi ew.pdf)according to the documentation. If it is under developing by the ActiveMQ team, then my I ask you when it will develope because my work is delaying. If you have any other option to maintain the persistence Please refere me so that I can start my work. Thanks in advance Regards Arashad Ahamad
[jira] Created: (AMQ-790) support for non-XBean based XML configuration files does not seem to work
support for non-XBean based XML configuration files does not seem to work - Key: AMQ-790 URL: https://issues.apache.org/activemq/browse/AMQ-790 Project: ActiveMQ Type: Bug Versions: 4.0.1 Reporter: james strachan Assigned to: james strachan Fix For: 4.1 It seems we don't currently support regular Spring XML configuration files when using the 'activemq' command. Steps to reproduce: [EMAIL PROTECTED] jms]$ unzip incubator-activemq-4.0.1.zip Archive: incubator-activemq-4.0.1.zip creating: incubator-activemq-4.0.1/ creating: incubator-activemq-4.0.1/bin/ creating: incubator-activemq-4.0.1/conf/ creating: incubator-activemq-4.0.1/docs/ creating: incubator-activemq-4.0.1/example/ creating: incubator-activemq-4.0.1/example/activemq-web-console/ ... inflating: incubator-activemq-4.0.1/userGuide.html inflating: incubator-activemq-4.0.1/var/activemq.log [EMAIL PROTECTED] jms]$ echo '?xml version=1.0 encoding=UTF-8? !DOCTYPE beans PUBLIC -//SPRING//DTD BEAN//EN http://www.springframework.org/dtd/spring-beans.dtd; beans bean id=broker class=org.apache.activemq.broker.BrokerService init-method=start property name=transportConnectorURIs list valuetcp://localhost:61234/value /list /property /bean /beans ' incubator-activemq-4.0.1/conf/activemq.xml [EMAIL PROTECTED] jms]$ cd incubator-activemq-4.0.1/bin [EMAIL PROTECTED] bin]$ sh activemq ACTIVEMQ_HOME: /home/john/devel/java/jms/incubator-activemq-4.0.1 Loading message broker from: xbean:activemq.xml INFO BrokerService - ActiveMQ 4.0.1 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 2 x 20.0 Megs at: /home/john/devel/java/jms/incubator-activemq-4.0.1/bin/activemq-data/localhost/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://prokopiev.stc.donpac.ru:61234 INFO TransportConnector - Connector tcp://prokopiev.stc.donpac.ru:61234 Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:prokopiev.stc.donpac.ru-41458-1151926448246-1:0) started ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: java.lang.ClassCastException: org.apache.activemq.broker.BrokerService ERROR: java.lang.Exception: java.lang.ClassCastException: org.apache.activemq.broker.BrokerService INFO BrokerService - ActiveMQ Message Broker (localhost, ID:prokopiev.stc.donpac.ru-41458-1151926448246-1:0) is shutting down INFO TransportConnector - Connector tcp://prokopiev.stc.donpac.ru:61234 Stopped INFO VMTransportFactory - Shutting down VM connectors for broker: localhost INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:prokopiev.stc.donpac.ru-41458-1151926448246-1:0) stopped -- 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-790) support for non-XBean based XML configuration files does not seem to work
[ https://issues.apache.org/activemq/browse/AMQ-790?page=all ] james strachan resolved AMQ-790: Resolution: Fixed as a workaround just use a regular XML configuration file like the one that ships with ActiveMQ... http://incubator.apache.org/activemq/xml-configuration.html support for non-XBean based XML configuration files does not seem to work - Key: AMQ-790 URL: https://issues.apache.org/activemq/browse/AMQ-790 Project: ActiveMQ Type: Bug Versions: 4.0.1 Reporter: james strachan Assignee: james strachan Fix For: 4.1 It seems we don't currently support regular Spring XML configuration files when using the 'activemq' command. Steps to reproduce: [EMAIL PROTECTED] jms]$ unzip incubator-activemq-4.0.1.zip Archive: incubator-activemq-4.0.1.zip creating: incubator-activemq-4.0.1/ creating: incubator-activemq-4.0.1/bin/ creating: incubator-activemq-4.0.1/conf/ creating: incubator-activemq-4.0.1/docs/ creating: incubator-activemq-4.0.1/example/ creating: incubator-activemq-4.0.1/example/activemq-web-console/ ... inflating: incubator-activemq-4.0.1/userGuide.html inflating: incubator-activemq-4.0.1/var/activemq.log [EMAIL PROTECTED] jms]$ echo '?xml version=1.0 encoding=UTF-8? !DOCTYPE beans PUBLIC -//SPRING//DTD BEAN//EN http://www.springframework.org/dtd/spring-beans.dtd; beans bean id=broker class=org.apache.activemq.broker.BrokerService init-method=start property name=transportConnectorURIs list valuetcp://localhost:61234/value /list /property /bean /beans ' incubator-activemq-4.0.1/conf/activemq.xml [EMAIL PROTECTED] jms]$ cd incubator-activemq-4.0.1/bin [EMAIL PROTECTED] bin]$ sh activemq ACTIVEMQ_HOME: /home/john/devel/java/jms/incubator-activemq-4.0.1 Loading message broker from: xbean:activemq.xml INFO BrokerService - ActiveMQ 4.0.1 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 2 x 20.0 Megs at: /home/john/devel/java/jms/incubator-activemq-4.0.1/bin/activemq-data/localhost/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://prokopiev.stc.donpac.ru:61234 INFO TransportConnector - Connector tcp://prokopiev.stc.donpac.ru:61234 Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:prokopiev.stc.donpac.ru-41458-1151926448246-1:0) started ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: java.lang.ClassCastException: org.apache.activemq.broker.BrokerService ERROR: java.lang.Exception: java.lang.ClassCastException: org.apache.activemq.broker.BrokerService INFO BrokerService - ActiveMQ Message Broker (localhost, ID:prokopiev.stc.donpac.ru-41458-1151926448246-1:0) is shutting down INFO TransportConnector - Connector tcp://prokopiev.stc.donpac.ru:61234 Stopped INFO VMTransportFactory - Shutting down VM connectors for broker: localhost INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:prokopiev.stc.donpac.ru-41458-1151926448246-1:0) stopped -- 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: fix for m2 builds when making wars...
On 6/28/06, James Strachan [EMAIL PROTECTED] wrote: I just experienced a temporary glitch in the m2 build when making activemq-web-demo. If this has failed for you today you might wanna try the following which fixed it for me... rm -rf ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/ James, I've removed the maven-asssembly-plugin and I'm still getting the following failure: [INFO] [INFO] Building ActiveMQ :: Web Demo [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /Users/bsnyder/src/activemq/trunk/activemq-web-demo/target [INFO] Deleting directory /Users/bsnyder/src/activemq/trunk/activemq-web-demo/target/classes [INFO] Deleting directory /Users/bsnyder/src/activemq/trunk/activemq-web-demo/target/test-classes [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from mortbay-repo [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from apache-snapshots Downloading: http://people.apache.org/maven-snapshot-repository//org/apache/maven/plugins/maven-war-plugin/2.0.1/maven-war-plugin-2.0.1.pom [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Not compiling test sources [INFO] [surefire:test] [INFO] Tests are skipped. - this realm = app0.child-container[org.apache.maven.plugins:maven-war-plugin] urls[0] = file:/Users/bsnyder/.m2/repository/org/apache/maven/plugins/maven-war-plugin/2.0.1/maven-war-plugin-2.0.1.jar Number of imports: 0 this realm = plexus.core.maven urls[0] = file:/Users/bsnyder/m2/lib/commons-cli-1.0.jar urls[1] = file:/Users/bsnyder/m2/lib/doxia-sink-api-1.0-alpha-7.jar urls[2] = file:/Users/bsnyder/m2/lib/jsch-0.1.24.jar urls[3] = file:/Users/bsnyder/m2/lib/maven-artifact-2.0.4.jar urls[4] = file:/Users/bsnyder/m2/lib/maven-artifact-manager-2.0.4.jar urls[5] = file:/Users/bsnyder/m2/lib/maven-core-2.0.4.jar urls[6] = file:/Users/bsnyder/m2/lib/maven-error-diagnostics-2.0.4.jar urls[7] = file:/Users/bsnyder/m2/lib/maven-model-2.0.4.jar urls[8] = file:/Users/bsnyder/m2/lib/maven-monitor-2.0.4.jar urls[9] = file:/Users/bsnyder/m2/lib/maven-plugin-api-2.0.4.jar urls[10] = file:/Users/bsnyder/m2/lib/maven-plugin-descriptor-2.0.4.jar urls[11] = file:/Users/bsnyder/m2/lib/maven-plugin-parameter-documenter-2.0.4.jar urls[12] = file:/Users/bsnyder/m2/lib/maven-plugin-registry-2.0.4.jar urls[13] = file:/Users/bsnyder/m2/lib/maven-profile-2.0.4.jar urls[14] = file:/Users/bsnyder/m2/lib/maven-project-2.0.4.jar urls[15] = file:/Users/bsnyder/m2/lib/maven-reporting-api-2.0.4.jar urls[16] = file:/Users/bsnyder/m2/lib/maven-repository-metadata-2.0.4.jar urls[17] = file:/Users/bsnyder/m2/lib/maven-settings-2.0.4.jar urls[18] = file:/Users/bsnyder/m2/lib/plexus-interactivity-api-1.0-alpha-4.jar urls[19] = file:/Users/bsnyder/m2/lib/wagon-file-1.0-alpha-7.jar urls[20] = file:/Users/bsnyder/m2/lib/wagon-http-lightweight-1.0-alpha-6.jar urls[21] = file:/Users/bsnyder/m2/lib/wagon-provider-api-1.0-alpha-6.jar urls[22] = file:/Users/bsnyder/m2/lib/wagon-ssh-1.0-alpha-7.jar urls[23] = file:/Users/bsnyder/m2/lib/wagon-ssh-external-1.0-alpha-6.jar Number of imports: 0 this realm = plexus.core urls[0] = file:/Users/bsnyder/m2/core/plexus-container-default-1.0-alpha-9.jar urls[1] = file:/Users/bsnyder/m2/core/plexus-utils-1.1.jar Number of imports: 0 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' org/codehaus/plexus/archiver/ArchiverException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538) at
Re: fix for m2 builds when making wars...
Did you try a 'mvn -U install' to see if that fixed it? On 7/3/06, Bruce Snyder [EMAIL PROTECTED] wrote: On 6/28/06, James Strachan [EMAIL PROTECTED] wrote: I just experienced a temporary glitch in the m2 build when making activemq-web-demo. If this has failed for you today you might wanna try the following which fixed it for me... rm -rf ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/ James, I've removed the maven-asssembly-plugin and I'm still getting the following failure: [INFO] [INFO] Building ActiveMQ :: Web Demo [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /Users/bsnyder/src/activemq/trunk/activemq-web-demo/target [INFO] Deleting directory /Users/bsnyder/src/activemq/trunk/activemq-web-demo/target/classes [INFO] Deleting directory /Users/bsnyder/src/activemq/trunk/activemq-web-demo/target/test-classes [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from mortbay-repo [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from apache-snapshots Downloading: http://people.apache.org/maven-snapshot-repository//org/apache/maven/plugins/maven-war-plugin/2.0.1/maven-war-plugin-2.0.1.pom [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Not compiling test sources [INFO] [surefire:test] [INFO] Tests are skipped. - this realm = app0.child-container[org.apache.maven.plugins:maven-war-plugin] urls[0] = file:/Users/bsnyder/.m2/repository/org/apache/maven/plugins/maven-war-plugin/2.0.1/maven-war-plugin-2.0.1.jar Number of imports: 0 this realm = plexus.core.maven urls[0] = file:/Users/bsnyder/m2/lib/commons-cli-1.0.jar urls[1] = file:/Users/bsnyder/m2/lib/doxia-sink-api-1.0-alpha-7.jar urls[2] = file:/Users/bsnyder/m2/lib/jsch-0.1.24.jar urls[3] = file:/Users/bsnyder/m2/lib/maven-artifact-2.0.4.jar urls[4] = file:/Users/bsnyder/m2/lib/maven-artifact-manager-2.0.4.jar urls[5] = file:/Users/bsnyder/m2/lib/maven-core-2.0.4.jar urls[6] = file:/Users/bsnyder/m2/lib/maven-error-diagnostics-2.0.4.jar urls[7] = file:/Users/bsnyder/m2/lib/maven-model-2.0.4.jar urls[8] = file:/Users/bsnyder/m2/lib/maven-monitor-2.0.4.jar urls[9] = file:/Users/bsnyder/m2/lib/maven-plugin-api-2.0.4.jar urls[10] = file:/Users/bsnyder/m2/lib/maven-plugin-descriptor-2.0.4.jar urls[11] = file:/Users/bsnyder/m2/lib/maven-plugin-parameter-documenter-2.0.4.jar urls[12] = file:/Users/bsnyder/m2/lib/maven-plugin-registry-2.0.4.jar urls[13] = file:/Users/bsnyder/m2/lib/maven-profile-2.0.4.jar urls[14] = file:/Users/bsnyder/m2/lib/maven-project-2.0.4.jar urls[15] = file:/Users/bsnyder/m2/lib/maven-reporting-api-2.0.4.jar urls[16] = file:/Users/bsnyder/m2/lib/maven-repository-metadata-2.0.4.jar urls[17] = file:/Users/bsnyder/m2/lib/maven-settings-2.0.4.jar urls[18] = file:/Users/bsnyder/m2/lib/plexus-interactivity-api-1.0-alpha-4.jar urls[19] = file:/Users/bsnyder/m2/lib/wagon-file-1.0-alpha-7.jar urls[20] = file:/Users/bsnyder/m2/lib/wagon-http-lightweight-1.0-alpha-6.jar urls[21] = file:/Users/bsnyder/m2/lib/wagon-provider-api-1.0-alpha-6.jar urls[22] = file:/Users/bsnyder/m2/lib/wagon-ssh-1.0-alpha-7.jar urls[23] = file:/Users/bsnyder/m2/lib/wagon-ssh-external-1.0-alpha-6.jar Number of imports: 0 this realm = plexus.core urls[0] = file:/Users/bsnyder/m2/core/plexus-container-default-1.0-alpha-9.jar urls[1] = file:/Users/bsnyder/m2/core/plexus-utils-1.1.jar Number of imports: 0 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' org/codehaus/plexus/archiver/ArchiverException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 'org.apache.maven.plugins:maven-war-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538)
Re:
Hi Nathan, I'm not so sure about that. I think that AMQ should support receiving a STOMP frame terminated by \0 without a subsequent \n. The STOMP spec does say that white space before a frame should be ignored. Anyways, if anybody can confirm that this is not the case, then it's a bug with how we implemented STOMP in AMQ. On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (AMQ-688) Avoid blocking producers
[ https://issues.apache.org/activemq/browse/AMQ-688?page=comments#action_36508 ] Hiram Chirino commented on AMQ-688: --- I think that the changes required to fix this are both in the research stange and substancial enought that we should create a new activemq branch where we explore solutions for this. How about we create a temporary development branch under /branches/tmp/AMQ-688 ??? Avoid blocking producers Key: AMQ-688 URL: https://issues.apache.org/activemq/browse/AMQ-688 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 RC2 Reporter: Christopher A. Larrieu Assignee: Christopher A. Larrieu Fix For: 4.1 Original Estimate: 8 weeks Remaining: 8 weeks Our main goal is to avoid stalled producers by addressing the main culprit: too many undispatched messages in the broker's memory. Our motivation is to handle significant --though temporary-- imbalances between production and consumption rates. Reaching this goal entails specific broker modifications: 1. When memory gets tight, start dropping undispatched non-persistent messages. This is the first-cut attempt to maintain throughput of persistent messages. Unlike the approach documented at http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling, the message dropping will only occur after the UsageManager reaches capacity. Non-persistent messages in dispatch lists will be dropped according to per-destination policy. Subscriptions can purge their own messages triggered via callback from the UsageManager. 2. Evict messages if memory remains tight, to be fetched from backing store prior to dispatch. ActiveMQ already supports this for persistent messages on Topics with durable subscriptions. If a consumer's prefetch buffer is full, the splash-over messages remain as IndirectMessageReference objects in the dispatch list, with the actual message body loaded from store on demand. I believe we can extend this approach for Queues as well. 3. Improve the efficiency with which evicted messages are loaded back into memory. Currently, they are loaded one at a time as needed. It would make sense to batch-load message sets periodically. This will require a significant shift in responsibilities between objects, since an IndirectMessageReference doesn't know about other instances that can be loaded in mass. The goal will be to keep each subscription dispatch list stocked with a decent number of messages in-memory to reasonably trade-off between it's consumer's performance and resource usage in the broker. As with everything else, we can implement this as a strategy class with the first cut implementing a simple resource allocation strategy: divvy up available memory amongst all subscriptions and keep that memory filled with messages for dispatch. I envision a worker task assuming responsibility for keeping these lists filled. 4. Even with the above modifications, we still can't entirely avoid blocked producers, so we'd like to add client-configurable time-outs to provide a bound for the time a producer can remain stalled. Maybe this should be a new attribute of ActiveMQConnection: maxProducerFlowControlWait. Calls to UsageManager.waitForSpace can take this quantity as an argument. Failure to reach sufficient space for the new message will throw an exception back up the stack and across the wire, letting the producer know that the message was not delivered. 5. Finally, we need to extend disk support for Topics that have only non-durable subscribers, otherwise their dispatch lists can fill up with persistent messages. In order to maintain compliance with JMS, it would be nice to provide some alternative to dropping persistent messages. One possible first cut is to layer this on top of a DurableTopicSubscription by creating an anonymous subscriber for every Topic that has only non-durable subscriptions. When all such subscriptions terminate, the broker can remove the anonymous subscriber. -- 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-688) Avoid blocking producers
[ https://issues.apache.org/activemq/browse/AMQ-688?page=comments#action_36516 ] james strachan commented on AMQ-688: A few comments on this issue... #1 we already support the dropping of messages for non-durable topic subscribers... http://incubator.apache.org/activemq/slow-consumer-handling.html so that parts done right? #2 we support eviction and reloading of messages for durable topic subscribers/durable messages and for durable queues #3 the prefetch buffer act as the buffer of in RAM messages; we back fill these one at a time. We could have some pluggable strategy to provide more optimised back-filling - though its a tricky algorithm as thanks to selectors and different subscription rates - its hard to know what messages are required to be fetched. #4 currently for performance, we tend to dispatch to non-durable topic subscriptions in a single thread to many producers to minimise context switching when using blocking IO. If we used a thread pool for this (async sending) or AIO or NIO then it would be easier to avoid the thread blocking on the send - right now blocking on the send there's no real way we can interupt it. So its clearly a performance hit tradeoff; fast versus fair. #5 basically means to use spooling to disk right? Avoid blocking producers Key: AMQ-688 URL: https://issues.apache.org/activemq/browse/AMQ-688 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 RC2 Reporter: Christopher A. Larrieu Assignee: Christopher A. Larrieu Fix For: 4.1 Original Estimate: 8 weeks Remaining: 8 weeks Our main goal is to avoid stalled producers by addressing the main culprit: too many undispatched messages in the broker's memory. Our motivation is to handle significant --though temporary-- imbalances between production and consumption rates. Reaching this goal entails specific broker modifications: 1. When memory gets tight, start dropping undispatched non-persistent messages. This is the first-cut attempt to maintain throughput of persistent messages. Unlike the approach documented at http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling, the message dropping will only occur after the UsageManager reaches capacity. Non-persistent messages in dispatch lists will be dropped according to per-destination policy. Subscriptions can purge their own messages triggered via callback from the UsageManager. 2. Evict messages if memory remains tight, to be fetched from backing store prior to dispatch. ActiveMQ already supports this for persistent messages on Topics with durable subscriptions. If a consumer's prefetch buffer is full, the splash-over messages remain as IndirectMessageReference objects in the dispatch list, with the actual message body loaded from store on demand. I believe we can extend this approach for Queues as well. 3. Improve the efficiency with which evicted messages are loaded back into memory. Currently, they are loaded one at a time as needed. It would make sense to batch-load message sets periodically. This will require a significant shift in responsibilities between objects, since an IndirectMessageReference doesn't know about other instances that can be loaded in mass. The goal will be to keep each subscription dispatch list stocked with a decent number of messages in-memory to reasonably trade-off between it's consumer's performance and resource usage in the broker. As with everything else, we can implement this as a strategy class with the first cut implementing a simple resource allocation strategy: divvy up available memory amongst all subscriptions and keep that memory filled with messages for dispatch. I envision a worker task assuming responsibility for keeping these lists filled. 4. Even with the above modifications, we still can't entirely avoid blocked producers, so we'd like to add client-configurable time-outs to provide a bound for the time a producer can remain stalled. Maybe this should be a new attribute of ActiveMQConnection: maxProducerFlowControlWait. Calls to UsageManager.waitForSpace can take this quantity as an argument. Failure to reach sufficient space for the new message will throw an exception back up the stack and across the wire, letting the producer know that the message was not delivered. 5. Finally, we need to extend disk support for Topics that have only non-durable subscribers, otherwise their dispatch lists can fill up with persistent messages. In order to maintain compliance with JMS, it would be nice to provide some alternative to dropping persistent messages. One possible first cut is to layer this on top of a DurableTopicSubscription by creating an anonymous subscriber for every Topic that has only non-durable subscriptions. When all such
Re: handling slow consumers on non-persistent topics and AMQ-688
I think that fixing these issues are going to require substancial work on internals of the broker. I want to try to take a stab fixing this stuff but since it's going to take a few iterations to get right, how about we branch trunk and work there to avoid breaking everbody else? Any sugestions for the branch name? Regards, Hiram On 7/3/06, James Strachan [EMAIL PROTECTED] wrote: While perusing JIRA I spotted this issue again... http://issues.apache.org/activemq/browse/AMQ-688 I know its an issue close to folks at Amazon's hearts. Dealing with slow consumers is a fascinating problem for a messaging system; its quite a tricky problem :). Here's some background on the issue... http://incubator.apache.org/activemq/slow-consumers.html together with the currently supported features - to allow messages to be discarded on slow consumers using a pluggable algorithm... http://incubator.apache.org/activemq/slow-consumer-handling.html Now for all consumers we fill up prefetch buffers as quickly as possible... http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html so there's always a buffer of messages per consumer. For non-durable topics once these messages are written to a socket they are evicted from RAM; so we already have some support for slow consumers. I wanted to start a discussion on both AMQ-688 and to see if folks had other requirements for handling slow consumers to try decide what features stragegies we should add next in this area. One of the first requirements folks ask for is that rather than blocking permanently the non-persistent topic engine until RAM is cleared, that at a certain threshhold we start spooling to disk. I've raised a separate JIRA issue for this specific feature request... http://issues.apache.org/activemq/browse/AMQ-791 Another issue some folks have hit in the past is that for high performance and to minimise context switches in the broker, we tend to use the current thread in the broker to dispatch to all the non-durable topic consumers so a slow/blocked consumer can appear to 'block' the producer. I've raised this issue to track that feature http://issues.apache.org/activemq/browse/AMQ-792 I just wondered if folks had any other issues or requirements with the whole slow consumers and non-durable topics they'd like to discuss? Is there any requirements we won't have covered if the above two JIRAs are fixed -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Assigned: (AMQ-340) allow topics in particular but also queues to have a 'namespace URI' like WS-Notification
[ https://issues.apache.org/activemq/browse/AMQ-340?page=all ] Hiram Chirino reassigned AMQ-340: - Assign To: james strachan This sounds like WSN root then maps to a broker instance. Since a JVM can run more than 1 broker, the WSN layer just needs to route requests to different brokers based on the root. What do you think? allow topics in particular but also queues to have a 'namespace URI' like WS-Notification - Key: AMQ-340 URL: https://issues.apache.org/activemq/browse/AMQ-340 Project: ActiveMQ Type: New Feature Reporter: james strachan Assignee: james strachan Fix For: 4.1 This would allow a real clean mapping from WS-N topics and ActiveMQ at the protocol level. We could use the namespace as a level of indirection to map to a broker, a cluster of brokers or even a particular area of a network etc. The namespace could be a broker's name too. -- 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:
Hi Nathan,
Please review the following patch. It allows the stomp client to accept a
variable amount of while space between frames. I ran the integration tests
a slightly modified amq broker where it used 3 \n between frames and also
one where no \n were used between frames. Everything seemed to work, but
since c++ is not my forte, I'm looking for a +1 from a before I commit the
change.
Index: src/main/activemq/connector/stomp/StompCommandReader.cpp
===
--- src/main/activemq/connector/stomp/StompCommandReader.cpp(revision
418889)
+++ src/main/activemq/connector/stomp/StompCommandReader.cpp(working
copy)
@@ -70,20 +70,46 @@
void StompCommandReader::readStompCommand( StompFrame frame )
throw ( StompConnectorException )
{
-// Read the command;
-int numChars = readStompHeaderLine();
+ while( true )
+ {
+ // Clean up the mess.
+ buffer.clear();
-if( numChars = 0 )
-{
-throw StompConnectorException(
-__FILE__, __LINE__,
-StompCommandReader::readStompCommand:
-Error on Read of Command Header );
-}
+ // Read the command;
+ readStompHeaderLine();
-// Set the command in the frame - copy the memory.
-frame.setCommand( reinterpret_castchar*(buffer[0]) );
-
+// Ignore all white space before the command.
+int offset=-1;
+for( size_t ix = 0; ix buffer.size()-1; ++ix )
+{
+ // Find the first non space character
+ char b = buffer[ix];
+switch ( b )
+{
+ case '\n':
+ case '\t':
+ case '\r':
+ break;
+
+ default:
+ offset = ix;
+ break;
+}
+
+ if( offset != -1 )
+ {
+ break;
+ }
+}
+
+ if( offset = 0 )
+ {
+ // Set the command in the frame - copy the memory.
+ frame.setCommand(
reinterpret_castchar*(buffer[offset]) );
+ break;
+ }
+
+ }
// Clean up the mess.
buffer.clear();
}
@@ -224,8 +250,7 @@
read( buffer[0], content_length );
// Content Length read, now pop the end terminator off (\0\n).
-if(inputStream-read() != '\0' ||
- inputStream-read() != '\n')
+if(inputStream-read() != '\0' )
{
throw StompConnectorException(
__FILE__, __LINE__,
@@ -251,16 +276,6 @@
continue;
}
-// We read up to the first NULL, now lets pop off the required
-// newline to complete the packet.
-if(inputStream-read() != '\n')
-{
-throw StompConnectorException(
-__FILE__, __LINE__,
-StompCommandReader::readStompBody:
-Read Body, and no trailing newline);
-}
-
break; // Read null and newline we are done.
}
}
On 7/3/06, Nathan Mittler [EMAIL PROTECTED] wrote:
No problem - sorry for the confusion :)
On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Oh. That makes sense! Sorry for the noise!
On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:
Hey Hiram,
I was actually thinking of the messages coming from the broker to the
client - the newer version of the broker always sends a \0\n to denote
the end of the frame. I'm not sure if the CMS client is sly enough to
handle both cases - I think it's expecting one or the other (either \0
or \0\n). I was just throwing that out there as a possible reason
that
the client may freeze on a read - waiting for the trailing \n that
never
comes.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Hiram Chirino
Sent: Monday, July 03, 2006 12:58 PM
To: activemq-dev@geronimo.apache.org
Subject: Re:
Hi Nathan,
I'm not so sure about that. I think that AMQ should support
receiving a STOMP frame terminated by \0 without a subsequent
\n. The STOMP spec does say that white space before a frame
should be ignored. Anyways, if anybody can confirm that this
is not the case, then it's a bug with how we implemented STOMP in
AMQ.
On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote:
Hi Naveen,
There are a couple of things that might be causing this.
1) The stomp frame ending characters have changed in recent
versions
of AMQ. AMQ now enforces that stomp frames end with \0\n
for all commands.
If you have an older version of CMS, and a fairly new
version of AMQ
(e.g. 4.0), they may not play nice together.
2) I have seen some deadlocking occur on compilers that
don't support
the
RE: Interested in becoming a contributor
Hi James, Thanks for those Grant! No problem: everybody benefits when people get involved. There's some documentation about it here... http://incubator.apache.org/servicemix/becoming-a-committer.html basically keep doing what you're doing and the committers will take a vote to grant you full commit karma. I take it you are interested in becoming a committer? :) I read the doco at the earlier and I am definitely interested in becoming a committer, so I'll keep submitting patches. Btw, do you mind if new contributors like myself take a look at unassigned issues and attach patches? That's probably the quickest way to get some work done that everybody can use. Regards, Grant
[jira] Created: (SM-481) servicemix-http provider truncates a large xml response
servicemix-http provider truncates a large xml response --- Key: SM-481 URL: https://issues.apache.org/activemq/browse/SM-481 Project: ServiceMix Type: Bug Components: servicemix-http Environment: windows xp professional. Java 1.5 Reporter: Pete Priority: Critical Fix For: incubation Attachments: soap_response.txt When using servicemix-http as a provider, our provider web service returns a very large xml response, this gets truncated somewhere in servicemix (I did notice when debugging it went down the stax xml route) We had the same problem when using SaajBinding, we fixed this locally by extending the SaajBinding and overridng the onMessageExchange in particular just after the call() we added response.saveChanges(); e.g. SOAPMessage response = connection.call(inMessage, soapEndpoint); response.saveChanges(); This I believe was a known issue using this particular SAAJ implementation, which is why saveChanges() was added to the api. see http://www.nabble.com/servicemix-http-provider-truncates-a-large-xml-response-tf1857975.html for forum post Our response xml is 673148 bytes. I have attached an example of the failing soap response. Note: you'll need to remove header stuff and save as xml. The response has a single xml element, where embedded (as a string) is another xml document - nasty I know. XML Config is !-- Http based client recieve/send html request/response passes message to a router component-- sm:activationSpec componentName=httpReceiver service=my:httpBinding endpoint=httpReceiver destinationService=my:router sm:component bean xmlns=http://xbean.org/schemas/spring/1.0; class=org.apache.servicemix.components.http.HttpConnector property name=host value=localhost / property name=port value=8912 / property name=marshaler bean class=org.apache.servicemix.components.http.HttpMarshaler / /property /bean /sm:component /sm:activationSpec Then there is an eip router that routes to sm:component http:component http:endpoints http:endpoint service=my:search endpoint=search role=provider soap=true soapAction=http://www.blah.com/blah; locationURI=http://www.blah.com:80/blah.asmx/ /http:endpoints /http:component /sm:component -- 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: (SM-480) Transitive dependencies of dependent projects not included in installer lib directory
[ https://issues.apache.org/activemq/browse/SM-480?page=all ] Philip Dodds resolved SM-480: - Fix Version: incubation Resolution: Fixed The problem was the different in versions between the dependency management and the transitive dependency - have added a warning and will use the version from the transitive dependency for packaging. Transitive dependencies of dependent projects not included in installer lib directory - Key: SM-480 URL: https://issues.apache.org/activemq/browse/SM-480 Project: ServiceMix Type: Bug Components: tooling Versions: incubation Environment: Ubuntu Linux 5.10, Windows XP SP2 Reporter: Grant McDonald Fix For: incubation Original Estimate: 2 days Remaining: 2 days Whilst using servicemix I got a NoClassDefFound error from the servicemix-http service engine. It appears that the code in question was throwing a DecoderException which is defined in commons-codec which is a transitive dependency of commons-httpclient. This dependency was not included in the installer lib directory and is obviously quite critical to the running of httpclient. -- 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
ServiceMix Geronimo Plugin
So Guillaume and I talked at ApacheCon EU, and we came up with the following thoughts about ServiceMix integration into Geronimo. Use Cases * Deploy combined JBI/J2EE applications. In the short term there may not be one bundle such as a ZIP or EAR containing both types of components, but they should be able to work well together. * A J2EE web application should be able to send messages to the JBI bus * A JBI service should be able to dispatch messages to a J2EE endpoint (other than just an MDB via JMS, etc.). Typically this would be a stateless session bean. * Should be able to deploy both JBI and J2EE components using the same deploy tool(s) * Eventually, should be able to deploy a combined package containing both types of components, supporting bidirectional dependencies (J2EE components send messages to JBI components in the same app and vice versa) * Manage Geronimo and ServiceMix together, via a combined admin console, combined JMX space, etc. * Share resources between Geronimo and ServiceMix * Same security realm for authentication and same Subject for authorization * Same transaction manager * Same HTTP server * Single source of SSL settings (keystores, passwords, etc.) SSL factories As I understand it, as of today: * There are GBeans to start ServiceMix in Geronimo * There is a builder to deploy JBI service assemblies to ServiceMix using the Geronimo deploy tools (I'm not clear whether this can also deploy JBI components, which actually seem more like containers) * Some work has been done to leverage the Geronimo transaction manager * The JCA flow in ServiceMix may use the Geronimo transaction manager * There is a ServiceMix admin console using the same technology as the Geronimo admin console So out of these, we have the following to-dos to create a ServiceMix plugin for Geronimo 1.1: * Try out the current ServiceMix Geronimo GBeans * Confirm whether the JCA flow uses the Geronimo transasction manager correctly * Update the GBeans to expose EJBs as endpoints for ServiceMix (perhaps leveraging JSR-181 code for mapping normalized messages to EJB invocations?) * Provide a GBean that is a client factory -- so you can map this factory into JNDI for a J2EE component, and it can look that up and use it to generate a ServiceMixClient instance * Provide factories that support both client authentication (caller specifies user/password if any) and container authentication (e.g. Subject from web app login is passed to ServiceMix as is) * Add a security provider to ServiceMix that uses Geronimo security realms to authenticate and populate a Subject * Update ServiceMix so it can use the Geronimo HTTP container for HTTP/HTTPS binding components (allowing only configuring of the part after http://host:port/context/ in the URL) * Add the glue code to deploy the ServiceMix admin screens to the Geronimo admin console when the ServiceMix features are added * Create and document sample apps to call JBI-J2EE and vice versa And the following that will require Geronimo code changes (in other words, targeting G 1.2+): * Provide a deployment unit that contains both J2EE and JBI components (either an EAR with extra content or a ZIP containing both a JBI service assembly and an EAR, etc.) * Let ServiceMix initiate HTTP bindings on new ports, wtih fully arbitrary URLs, etc. * Update Geronimo keystore provider to offer the new functions that ServiceMix needs We thought it would be best for any work done on this in the short term to happen in the ServiceMix SVN head (for GBeans and Geronimo configus) using the ServiceMix 3.0-M2-incubating ServiceMix release for the ServiceMix features, and the Geronimo 1.1 release for the Geronimo features. Anyone else have any thoughts about this? Thanks, Aaron
Re: Transitive dependency problem with jbi maven plugin
Yeah the warning is in place to just show the problem has occurred though you are right that probably managing situations like this in either changes to the dependencyManagement or the pom Cheers P On 7/3/06, Grant McDonald [EMAIL PROTECTED] wrote: I tried something similar by switching off the lines I mentioned in the issue report. This had the effect of including commons-codec-1.2 instead of 1.3 which actually caused servicemix to completely crash since the versions had different encoding/decoding formats (this was using the trunk as of 2006-06-28 with a few custom patches). When I explicitly added commons-codec-1.3 as a dependency in servicemix-http this problem went away. So it may be that fine tuning is needed in some cases with regards to transitive dependencies (either that or just use the override from the parent pom. -Original Message- From: Philip Dodds [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 July 2006 12:27 AM To: servicemix-dev@geronimo.apache.org Subject: Re: Transitive dependency problem with jbi maven plugin The problem was that the version found through the transitive dependency was not the same as the version from the top level pom's dependency management - I have switched it so that in this case a warning it thrown but the version from the transitive dependency it packaged into the installer. P On 7/2/06, Grant McDonald [EMAIL PROTECTED] wrote: This appears to be due to line 181 in GenerateComponentMojo.java in the jbi-maven-plugin project. At this point the includes are refiltered based on the JbiResolutionListener created for the project. This seems to eject some dependencies of subprojects needs more investigation. -- View this message in context: http://www.nabble.com/Transitive-dependency-problem-with-jbi-maven-plugin-tf 1879526.html#a5139375 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418906
]
John Sisson commented on GERONIMO-2161:
---
+1 : applied patch and tested build. Due to xmlbeans issue (which is a
separate problem not caused by this patch) It took a number of build attempts
using Jason's script he shared with me on IRC:
{noformat}
#!/bin/sh
# Drop all existing repo state
rm -rf ~/.m2/repository
# Clean, since mvn clean won't work everytime because of chicken-egg plugins
find . -name target -type d -exec rm -rf \{\} \;
# Build the G modules - 13 times to get around xmlbeans crap
for x in 1 2 3 4 5 6 7 8 9 10 11 12 13; do
mvn -Dstage=bootstrap -Dmaven.test.skip=true
done
# Build OpenEJB - 3 times to get around xmlbeans crap
( cd openejb2/modules; mvn clean; mvn install; mvn install; mvn install )
# Build G apps, config and assembly
mvn -Dstage=assemble -Dmaven.test.skip=true
{noformat}
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
Re: How do we build the Eclipse Plugin assembly?
Hi Sachin,I too am facing the same problem as Donald during the assembly of Eclipse Plugin. I am building Revision 418691 of the trunk, using Sun JDK 1.4.2_08 Maven 2.0.4 on a WinXP sp2 machine. By the way, I am interested in contributing to Geronimo Eclipse Plugin. Last year I have done some work on Eclipse Plugin Development and I am comfortable with SWT, JFace and Plugin Development. Also, some of the work I did in Eclipse Drag and Drop got published here: http://www-128.ibm.com/developerworks/library/os-ecl-dragdrop/index.htmlLast one week I have been browsing through the Geronimo Dev Mailing Lists, as well as JIRA, to figure out how I can contribute to the Eclipse plugin development. If you can point me to a few to-do items of immediate interest, I would be more than happy to pick them up and start working on them right away. Thanks,Shiva Kumar On 7/1/06, Sachin Patel [EMAIL PROTECTED] wrote: You have to invoke it manually as you've done.I haven't figured outhow to invoke a build+assembly in one step.As far as the file sizeskevan saw the same problem, and we couldn't figure out why.On Jun 30, 2006, at 5:15 PM, Donald Woods wrote: I just checked out Rev418113 of the Eclipse plugin trunk, started with a clean m2 repo and successfully got a mvn install to complete after several attempts. But, when I look in the assembly/ directory, no target/ directory was created.Is this expected? When I ran mvn from the assembly directory, it created a target directory, but the following zipfiles were only 22 bytes each -g-eclipse-plugin-1.1-deployable.zip g-eclipse-plugin-1.1-updatesite.zip I'm building on WinXP with Maven 2.0.4 and Sun Java 1.4.2_12-b03. -Donald-sachin
Re: Re: [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Alan, can I get you to add your vote/comments to the JIRA please? http://issues.apache.org/jira/browse/GERONIMO-2161 Thanks, --jason On 7/1/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Jason Dillon wrote: Please read the JIRA for details: http://issues.apache.org/jira/browse/GERONIMO-2161 --jason It seems reasonable to me. IIRC, this was originally set up by Mr. MavenHead himself. Might want to run this by him to see what he was originally thinking. +1 - pending a quick check w/ Mr. van Zyl. Regards. Alan
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418909
]
John Sisson commented on GERONIMO-2161:
---
My +1 above is for the GERONIMO-2161-v2.patch.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
[jira] Commented: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2132?page=comments#action_12418911 ] John Sisson commented on GERONIMO-2132: --- What is the status of this JIRA, as there has been an svn commit for it http://svn.apache.org/viewvc?rev=415034view=rev ? Are you planning on doing more work on this issue? Trying to piece togther the status of this issue and GERONIMO-2135. Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Fix For: 1.2 Attachments: amq4.patch -- 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: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Alan D. Cabrera wrote: John Sisson wrote: Alan D. Cabrera wrote: John Sisson wrote: Alan D. Cabrera wrote: John Sisson wrote: Alan D. Cabrera wrote: John Sisson wrote: snip Lots of process... /snip * If a PMC member is the person who completes the vote ( three binding +1s and no vetos) for the latest version of the patch then they should change the status to review-complete. Just need to move it on to the regular Open status, no? Thought it may be clearer to have a different status showing the review is complete and have the JIRA workflow match the true workflow. For example if we were to move to open status after the review is complete, then the user would be given the opportunity to go back to review-required status, which isn't really a valid state transition, but maybe we should keep it simple and rely upon common sense? Any JIRA experts out there who can comment on the benefits/disadvantages of having an additional review-complete status? mmm, ok. I'm sold. I'm a Jira admin so I have dug up the work flow that we're currently using. Here's what I think we're proposing. Thanks for creating the diagrams Alan. Currently one can create Open a JIRA issue and start working on it, optionally marking it as In Progress as you showed below in your first diagram. In your second diagram this won't be possible. The JIRA should be able to be worked on prior to RTC (and hopefully will be discussed on the dev list with the developer community before it gets to the RTC phase). Ok, so the In Progress state will go off of Open state. I guess that the idea of the reviewed state for the actual patch application. Please note that I have removed the Reopened state. It seemed superfluous. A JIRA issue may also be created for a bug and bug fixes do not need to go through the RTC process. Yeah, we can use the current process for that. I assume we would always allow the user to move to the Review state (no matter what their issue type is) rather than trying to restrict it programatically. I had intended to restrict it. Do you think that it would be useful to always be able to move back to a RTC voting stage? When would we need to do that after approval? How did you intend to restrict it? By just simply limiting the transitions. Anything else would require us dropping a plugin into the Jira server. There is a possibility that that the developer of the patch or another developer could discover an issue with the patch after it has been approved but before it was committed and wants to revise the patch and go through the review again. Should we allow transitions from the review and reviewed states to the Open state to cater for this type of situation (it may take the developer a couple of weeks to rework the patch before they Ok, so every state should have a transition to go back to Open? I think that would allow the most flexibility. Thanks, John Regards, Alan
Interested in becoming a contributor
Hi, I have recently had the need to submit several patches and have been quickly becoming familar with the servicemix code base. As such I was wondering what was necessary to become a contributor? Regards, Grant McDonald
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418915
]
David Jencks commented on GERONIMO-2161:
The v2 patch does not apply cleanly to my clean tree. Will try to investigate
further tomorrow. All problems are in the packaging plugin.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee-builder/artifactId
[no subject]
Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat
Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Odd... I generated the patch in the same way I did for v1. I just tried: svn co https://svn.apache.org/repos/asf/geronimo/trunk cd trunk patch -p0 ~/Downloads/GERONIMO-2161-v2.patch.txt Below is the output of patch... and I'm a touch concerned since I don't get why it would fail to apply this patch. I generated the file with: svn diff GERONIMO-2161-v2.patch.txt Is that not the correct method to generate the patch file? Or is svn diff + patch not reliable? I don't get it. --jason snip patching file pom.xml Hunk #1 succeeded at 17 with fuzz 2. Hunk #2 FAILED at 33. 1 out of 2 hunks FAILED -- saving rejects to file pom.xml.rej patching file pom.xml Reversed (or previously applied) patch detected! Assume -R? [n] ^C Bliss:~/ws/apache/geronimo/tmp/trunk jason$ patch -p0 ~/Downloads/ GERONIMO-2161-v2.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/online-deployer/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml patching file configs/client-corba/pom.xml patching file configs/axis/pom.xml patching file configs/j2ee-system/pom.xml patching file configs/servlets-examples-tomcat/pom.xml patching file configs/j2ee-corba/pom.xml patching file configs/ldap-realm/pom.xml patching file configs/client/pom.xml patching file pom.xml Hunk #1 FAILED at 17. Hunk #2 succeeded at 49 (offset 4 lines). Hunk #3 succeeded at 537 (offset 4 lines). Hunk #4 succeeded at 551 (offset 4 lines). Hunk #5 succeeded at 576 (offset 4 lines). Hunk #6 succeeded at 596 (offset 4 lines). Hunk #7 succeeded at 689 (offset 4 lines). Hunk #8 succeeded at 874 (offset 4 lines). 1 out of 8 hunks FAILED -- saving rejects to file pom.xml.rej patching file m2-plugins/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file m2-plugins/geronimo-packaging-plugin/src/java/org/
Re: Interested in becoming a contributor
On 7/3/06, Grant McDonald [EMAIL PROTECTED] wrote: Hi, I have recently had the need to submit several patches Thanks for those Grant! and have been quickly becoming familar with the servicemix code base. As such I was wondering what was necessary to become a contributor? There's some documentation about it here... http://incubator.apache.org/servicemix/becoming-a-committer.html basically keep doing what you're doing and the committers will take a vote to grant you full commit karma. I take it you are interested in becoming a committer? :) -- James --- http://radio.weblogs.com/0112098/
Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Hrm... so I tried something else... I just svn up'd to get my working copy to revision 418706. Then svn status to make sure there are no conflicts... I've only got M and A indicators. Then `svn diff test.patch` from trunk, and then in a clean checkout `patch -p0 --dry-run ../../trunk/test.patch`. Below is the output... notice that it fails on packaging bits too. Why on earth would this happen? Either... I have made/applied the patches incorrectly, or svn diff is busted, or patch is busted, or somehow my workspace is now corrupt... how?!?! I hope it is not the latter else I just wasted several days worth of work to get this patch put together. WTF is going on?! I checked some of the rejects and most are harmless... but regardless of that I am really concerned about the reliability of patches. :-( snip patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/online-deployer/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml patching file configs/client-corba/pom.xml patching file configs/axis/pom.xml patching file configs/j2ee-system/pom.xml patching file configs/servlets-examples-tomcat/pom.xml patching file configs/j2ee-corba/pom.xml patching file configs/ldap-realm/pom.xml patching file configs/client/pom.xml patching file pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file m2-plugins/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file m2-plugins/geronimo-packaging-plugin/src/java/org/ apache/geronimo/plugin/packaging/PackageBuilderShellMojo.java Hunk #1 FAILED at 14. 1 out of 1 hunk FAILED -- saving rejects to file m2-plugins/geronimo- packaging-plugin/src/java/org/apache/geronimo/plugin/packaging/ PackageBuilderShellMojo.java.rej patching file m2-plugins/geronimo-packaging-plugin/src/java/org/ apache/geronimo/plugin/packaging/PlanProcessorMojo.java
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418922
]
Jason Dillon commented on GERONIMO-2161:
*NOTE:* The changes to the packaging plugin are mostly formatting related
(cleaned up tabs) etc. I did change some of the output to using logging too
instead of System.out.
I'm still really concerned than svn diff + patch is not working. I tried
several times and also tried a simple check to see if my workspace was corrupt
by checking out the packaging dir again and then copying over the changed
files. Still patch shows failures.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
[jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v3.patch
GERONIMO-2161-v3.patch is the same as v2 minus the changes to the packaging
plugin. This applied cleanly (spat out nothing with the -s flag) on a fresh
checkout of trunk with:
{noformat}
patch -p0 -s GERONIMO-2161-v3.patch
{noformat}
The packaging changes are not directly related to the changes that this issue
is tracking, its additional clean up work... as well as build debugging bits to
add better logging.
I believe that the icky script foo above should produce the same results (sans
the logging output) as the v2 patch.
*NOTE:* I do not believe that it is needed to reapply v3 if you already believe
that v2 is acceptable.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
Re: Interested in becoming a contributor
On 7/3/06, Grant McDonald [EMAIL PROTECTED] wrote: Do you have any particular areas that you're targetting for the next milestone release? The roadmap is generally defined in JIRA... http://issues.apache.org/activemq/browse/SM?report=com.atlassian.jira.plugin.system.project:roadmap-panel Things can move around in the roadmap before a release gets cut so by all means dive in and tackle whatever you see as particularly important/useful to your use cases. Incidentally I meant to say - with JIRA we generally need to grant JIRA karma for folks to be able to assign issues to themselves. So normally if you don't have karma just fire a quick mail to the dev list with your email address that you registered with JIRA and we can grant you karma. Though I've just gone ahead and granted you JIRA karma so you should now be able to assign any outstanding issues to yourself. Good luck fixing stuff - please fire mail to the dev list if you need any help figuring stuff out. -- James --- http://radio.weblogs.com/0112098/
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with
caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm
not exactly sure how that affects the current votes... or does adding
a new version of the patch negate anything else voted upon.
All for work that took about an hour. I've spent much more time
trying to get folks to look at it and then hack up scripts to make
the build work most of the time. I don't know how much time other
folks have put in... but I'm guessing that collectively we have
*wasted* many hours on this one single minor change RTC.
Folks, development like this will not scale... it does not scale!
I'm trying to play along... but really if it is going to take this
much effort for relatively minor changes that are aimed at helping to
fix issues we have and move forward with projects that have been
lagging for months (the m2 migration in this case) then I'm not sure
how we will ever get anything done.
I don't think we will attract many new committers into this type of
environment. Its already resulted in several folks who had been
active before switching focus to other tasks/projects. I hope they
come back at some point, but I can see why they might want to apply
their time in more rewarding ways.
--jason
On Jul 3, 2006, at 2:01 AM, Jason Dillon (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v3.patch
GERONIMO-2161-v3.patch is the same as v2 minus the changes to the
packaging plugin. This applied cleanly (spat out nothing with the -
s flag) on a fresh checkout of trunk with:
{noformat}
patch -p0 -s GERONIMO-2161-v3.patch
{noformat}
The packaging changes are not directly related to the changes that
this issue is tracking, its additional clean up work... as well as
build debugging bits to add better logging.
I believe that the icky script foo above should produce the same
results (sans the logging output) as the v2 patch.
*NOTE:* I do not believe that it is needed to reapply v3 if you
already believe that v2 is acceptable.
[RTC] Remove Geronimo modules from dependencyManagement in root
pom.xml
-
--
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-
v1.patch, GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch
As I have mentioned before, I believe we should remove the
Geronimo modules that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's
adjusted to include version${pom.version}/version and
typecar/type for the configs. But in many places version
already exists with the ${geronimoVersion} property... which kinda
negates the purpose of the dependencyManagement section anyways.
I believe that it is more work to keep track of every module in
the root pom than it is to specify the additonal elements (mostly
just version${pom.version}/version) in child poms. There is
no additional maintenance, as the new elements never need to be
changed.
Net effect if this change is less configuration to maintain and
thus a less brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
Re: [HeadsUp] changes to the ServiceMixClient API to support simpler access via URIs
On 6/30/06, Hossam Karim [EMAIL PROTECTED] wrote: Excellent, Thanks Guillaume and James. I have two comments: - James, does the client API intentionally allow invoking a service without specifying an operation? So the URI could include the operation name via 'operation:... http://incubator.apache.org/servicemix/uris.html Or maybe we could append an operation name on any URI as a query argument... service:http://foo.com/bar/whatnot?operation=foo there's also nothing stopping the user of the ServiceMixClient APIs to configure the MessageExchange directly in any way. I personally prefer hiding all those details in the URI so that a Destination is just some endpoint in a JMS-like way hiding all the various details of the routing. - Guillaume, would it be possible to inject a DeliveryChannel instance into the web application context? The ServiceMixClient - if its dependency injected with a JBI container instance - has a delivery channel it uses. So I guess the ServiceMixClient could be dependency injected - say via Spring - or put inside JNDI so that web apps can invoke arbitrary services in JBI without itself being a JBI component. -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (GERONIMODEVTOOLS-87) Distribution of configuration failed
Distribution of configuration failed Key: GERONIMODEVTOOLS-87 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.0.0 Environment: eclipse.buildId=M20060629-1905 java.version=1.4.2_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_BE Command-line arguments: -os win32 -ws win32 -arch x86 WPT 1.5 (Callisto) Geronimo 1.0 Reporter: Jens Nicolay When I do the following... - create Dynamic Web Project, name: TestWeb - create Servlet in TestWeb, name: TestServlet - TestServlet.java - Run on Server - Geronimo ... I get this error: Error Mon Jul 03 11:42:51 CEST 2006 Distribution of configuration failed. See .log for details. java.lang.Exception: Cannot deploy the requested application module (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:226) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Unknown Source) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:86) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubjectInvoker.java:80) at $Proxy0.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:221) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:329) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:260) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:230) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:214) at
Unassigned Patches: week of 07-03-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 6 2006 - GERONIMO-1783 - Welcome application i18n Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started May 3 2006 - GERONIMO-1976 - Change Welcome Application for G1.1 May 10 2006 - GERONIMO-1518 - Installer - only copy jars needed by selected configuration May 12 2006 - GERONIMO-2014 - Geronimo uses outdated version of ApacheDS
Re: [HeadsUp] changes to the ServiceMixClient API to support simpler access via URIs
James Strachan wrote: The ServiceMixClient - if its dependency injected with a JBI container instance - The doco does not explain how to do this: inject the JBI container. Most of the time I want to use the client I am inside a service unit deployed to a component like lwcontainer or http - I do not know how to get the reference to the container in the xbean.xml. I can do something like ((ComponentContextImpl) getContext()).getContainer() but this is ugly and wrong. What's the best way to go about this? - Renaud
Re: support for oneway MEP in servicemix-http ?
ok I've hacked up something, but I can't test it because I can't build trunk. Any idea ? (why is it so friggin' hard to build this thing btw?) Missing: -- 1) org.apache.servicemix.samples.wsdl-first:http-su:jar:3.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.wsdl-first -DartifactId=http-su \ -Dversion=3.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.wsdl-first:sa:jbi-service-assembly:3.0-incubating-SNAPSHOT 2) org.apache.servicemix.samples.wsdl-first:http-su:jar:3.0-incubating-SNAPSHOT 2) org.apache.servicemix.samples.wsdl-first:jsr181-su:jar:3.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.samples.wsdl-first -DartifactId=jsr181-su \ -Dversion=3.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix.samples.wsdl-first:sa:jbi-service-assembly:3.0-incubating-SNAPSHOT 2) org.apache.servicemix.samples.wsdl-first:jsr181-su:jar:3.0-incubating-SNAPSHOT -- 2 required artifacts are missing. for artifact: org.apache.servicemix.samples.wsdl-first:sa:jbi-service-assembly:3.0-incubating-SNAPSHOT from the specified remote repositories: central (http://ibiblio.org/maven2/), servicemix-m2-repo (http://servicemix.org/m2-repo), codehaus (http://repository.codehaus.org), apache.snapshots (http://people.apache.org/maven-snapshot-repository), codehaus.m1 (http://dist.codehaus.org), activemq-tmp-repo (http://people.apache.org/~chirino/incubator-activemq-4.0/maven2) Guillaume Nodet wrote: I do not really know which http code should be returned. I would have thought a 204 (NO_CONTENT) would be fine. Everything is handled in the o.a.s.http.processors.ConsumerProcessor class. I guess that just returning the 202 when there is no out message in the jbi exchange line 210 (either in-only, robust-in-only, or in-optional-out without response). Cheers, Guillaume Nodet On 6/30/06, Renaud Bruyeron [EMAIL PROTECTED] wrote: I could try to fix it, but I am not sure on the best way to do this... I am not even sure on the semantics here: in which case should we return a 202 ? Is it when the MEP is in-only, or when the WSDL says 'oneway', or both? I am willing to look into this, but I am not too sure on the correct fix. If you have any pointers/ideas, let me know. In the mean time, I'll create a jira for this. - Renaud Guillaume Nodet wrote: I think you are right. A 202 code should be returned. Could you raise a JIRA for that please ? If you can provide a patch, that would be cool :) Cheers, Guillaume Nodet On 6/30/06, Renaud Bruyeron [EMAIL PROTECTED] wrote: I am trying to send a oneway message into a http endpoint, but I am having trouble doing this. Here's the endpoint declaration: http:endpoint service=mmx:mms-service endpoint=mms-service role=consumer soap=true locationURI=http://localhost/mm7; defaultMep=http://www.w3.org/2004/08/wsdl/in-only; wsdlResource=classpath:wsdl/gwxms.wsdl/ Notice the MEP is in-only. The proxied endpoint is actually a JMS queue: jms:endpoint service=mmx:mms-service endpoint=mms-service role=provider destinationStyle=queue soap=true jmsProviderDestinationName=queue.mms jndiConnectionFactoryName=java:comp/env/jms/ConnectionFactory/ I am using a Axis 1.4 client to send the message in (I must use Axis because I need proper SAAJ support). Because it is a oneway message, the client expects a HTTP 202 response. However servicemix-http only replies with HTTP 200, which means synchronous in HTTP/SOAP. The exchange is working ok (I see the mime message on the JMS queue), the trouble is with the http endpoint. Am I correct in setting up the MEP as in-only on the http:endpoint? Any idea on what the problem could be? (I suspect that http:endpoint should figure out from the WSDL that the message is oneway and return HTTP 202 accordingly, but I could be wrong). - Renaud
Re: [HeadsUp] changes to the ServiceMixClient API to support simpler access via URIs
On 7/3/06, Renaud Bruyeron [EMAIL PROTECTED] wrote: James Strachan wrote: The ServiceMixClient - if its dependency injected with a JBI container instance - The doco does not explain how to do this: inject the JBI container. Most of the time I want to use the client I am inside a service unit deployed to a component like lwcontainer or http - I do not know how to get the reference to the container in the xbean.xml. I can do something like ((ComponentContextImpl) getContext()).getContainer() but this is ugly and wrong. What's the best way to go about this? If you are a component and have access to a component context then just create a ServiceMixClientFacade which implements the ServiceMixClient API. ServiceMixClient client = new ServiceMixClientFacade(context); I just added this snippet of code to the end of the web page... http://servicemix.org/site/client-api.html -- James --- http://radio.weblogs.com/0112098/
Dublin - Clustering get-together.... - Report
Here is the promised report on the Geronimo Clustering get-together held on thursday (6:00pm-8:00pm) in Dublin: Attendees: In the room : Aaron Mulder Alan Cabrera Filip Hanik Greg Wilkins Jan Bartel Jeremy Boynes Jules Gosnell Mark Brewer Matt Hogstrom Paul Buck Phil Robinson Rainer Jung Winston Damarillo On the phone: Bill Dudney Dain Sundstrom Jeff Genender Rajith Attapattu We started by enumerating the areas that were felt to require some form of clustering support (web, ejb, jndi, jms, deployment, management, monitoring, pojo, db). The idea was to prioritise the outstanding issues and thus scope work to be done. We used the first cut of this document as a basis for this walkthrough : http://cwiki.apache.org/GMOxDOC10/clustering.html I shall be bringing this up to date with the meetings findings as soon as I have arranged write access with the wiki's owners. All of these areas were covered and priorities were assigned thus : 1 - Web 2 - EJB/JNDI 3 - Management/Monitoring/Provisioning 4 - .. remaining issues We then looked at the software components available to us (ActiveMQ, ActiveCluster, ActiveSpace, WADI, Tribes, Kache, Tomcat Clustering) - also listed in the architecture document (to be updated with new software components ASAP). A number of interesting and useful points came up during the discussion : The 'fastest to market' clustering solution is not necessarily the same as the 'optimal' clustering solution. Multiple clustering solutions must be accomodated - APIs help abstract away from implementations - facilitating this Re: Web - although there seem to be two independant routes to a session clustering API (the containers' own native session management API vs a common Geronimo API), both must be made accessible since both native (e.g. Tomcat clustering and WADI) and Geronimo (Kache) solutions must be pluggable. Furthermore, the adaptor from native API to Geronimo API requires the exposure of the native API to be plugged in in the first place. Re: EJB - stateless session beans, whilst stateless, may still be facading more 'stateful' components, such as large trees of Entity beans that may be expensive to throw away/reload - so it may be useful to treat SLSBs as SFSBs as far as the session management API is concerned - also providing some form of session affinity rather than round robin load-balancing in the client stub. Re: EJB - it may not be a requirement to add further clustered support for Entity beans (i.e. clustered caches with distributed invalidations etc). Re: Management/Monitoring - tooling will hook in via standard and possibly extended APIs made available via JMX. GBeans managing e.g. native clustering solutions might adapt and make available equivalent functionality. Re: farmed deployment - It was noted that some form of pull/push support deployment was available. Perhas Aaron's plugin architecture ? Re: JMS - AMQ clustering is not yet integrated with Geronimo - it is awaiting decisions on what the integration should look like. Re: POJO clustering and JCache - whilst interesting, it is probably better if users bring their own clustered caches to Geronimo and plug them in, rather than Geronimo mandating the use of a single solution. Re: Database clustering - This was also marked as probably out of scope - although there was some discussion about the Sequoia project. The support of 3rd party clustered components means that a number of different implementations of a cluster may be in operation within any given node at any given time. These different implementations may each be from the ground up and share no code. Questions around this were e.g. : - can we expose different components' ideas about cluster membership through a common API (i.e. compare which nodes e.g. ProductA thinks are running against e.g. what Geronimo thinks are running) ? - should this preclude the usage of a common clustering layer and therefore API in areas where we are building clustered Geronimo services from the ground up - Sessions, Monitoring/Management, JNDI... The Geronimo Session API came in for particular discussion. This seemed to hinge around the fact that its aim might be to hide clustering issues from client containers (although it actually exposes a session's location and thus clustering issues at this level), but that it would be useful if a lower level clustering API, on which other clustered Geronimo services might be constructed, were also exposed. There were a number of differing and strongly held positions - including the view that trying to define what a cluster actually was, was much too hard a task in the first place ! It was finally agreed that there should be a 2 week period during which modifications and alternate session management apis might be floated on the dev list. The need for a lower-level clustering API and potential candidates for this role might also be debated during this time. Immediately after this period, a vote would decide the way based
Re: M2 Issues and Actions
inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE:
Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat
Re: M2 Issues and Actions
On 7/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Hi Anita, How does it apply to what Jason's working on in GERONIMO-2161? I think Jason has provided us a good solution for the issue - his latest patch http://issues.apache.org/jira/browse/GERONIMO-2161 should do the trick. I couldn't test it out as it blew out with Error assembling WAR: Deployment descriptor: c:\oss\GERONIMO-2082-2161\applications\demo\target\demo-1.2-SNAPSHOT\WEB-INF\web.xml does not exist. which seemed to me was not strictly related to the issue in question. (I've just noticed there's a brand new patch - on to testing it out) Anita Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: magicGball/src and magicGball/*/*
On 7/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where there are duplicate srcs under magicGball? Looks like this is to support m1 and m2 builds. I don't understand what you're asking for. How do you know they exist at all? An answer for the question might help me a bit understand what you're after ;-) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2132) Move activemq gbean integration modules from ActiveMQ to Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2132?page=comments#action_12418966 ] Hiram Chirino commented on GERONIMO-2132: - I just recently found out that we need 3 +1 from PMC memebers for RTC. I think the patch that did this failed to get that support. I think we may need to make sure that we do get the 3 +1's from the PMC before we proceed any further. Move activemq gbean integration modules from ActiveMQ to Geronimo - Key: GERONIMO-2132 URL: http://issues.apache.org/jira/browse/GERONIMO-2132 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Fix For: 1.2 Attachments: amq4.patch -- 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: How do we build the Eclipse Plugin assembly?
On 7/1/06, Sachin Patel [EMAIL PROTECTED] wrote: You have to invoke it manually as you've done. I haven't figured out how to invoke a build+assembly in one step. As far as the file sizes kevan saw the same problem, and we couldn't figure out why. I might misunderstand your question, but it's possible to attach a plugin to a phase so this way you could invoke 'build + assembly' in one step. Btw, what's 'the one step'? Is it 'mvn'? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMODEVTOOLS-87) Distribution of configuration failed
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87?page=comments#action_12418970 ] Jens Nicolay commented on GERONIMODEVTOOLS-87: -- I tested the same scenario with WAS CE 1.0.1.2 and wtp-all-in-one-sdk-R-1.0.1-200602171228-win32.zip and it works. Distribution of configuration failed Key: GERONIMODEVTOOLS-87 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.0.0 Environment: eclipse.buildId=M20060629-1905 java.version=1.4.2_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_BE Command-line arguments: -os win32 -ws win32 -arch x86 WPT 1.5 (Callisto) Geronimo 1.0 Reporter: Jens Nicolay When I do the following... - create Dynamic Web Project, name: TestWeb - create Servlet in TestWeb, name: TestServlet - TestServlet.java - Run on Server - Geronimo ... I get this error: Error Mon Jul 03 11:42:51 CEST 2006 Distribution of configuration failed. See .log for details. java.lang.Exception: Cannot deploy the requested application module (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:226) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Unknown Source) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:86) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubjectInvoker.java:80) at $Proxy0.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:221) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:329) at
Re: [openejb-dev] openejb m2 groupId
David Jencks wrote: The contents of the m1 and m2 build openejb jars are necessarily somewhat different, so it's desirable that they have different names: otherwise the geronimo m2 configs build tends to pick up m1 openejb jars. I think the easiest way to do this is to give the m2 jars m2 style groupIds. To get this started I changed the m2 openejb build to use org.openejb. If this is the wrong groupId let me know what is more correct and I will change it. Makes sense to me. Regards, Alan
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote: So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm not exactly sure how that affects the current votes... or does adding a new version of the patch negate anything else voted upon. You're completely right - it doesn't read good. Do you think doing such experiments on trunk would break it *at least* once? I guess so. Do you think it matters? Yes. I think there's a solution to RTC and having a place for experiments like this where nothing's known ahead - a branch. With a branch you can do whatever you want and no RTC rules apply there. I think it would help us all. Interested? Count me in! ;-) If I knew how to create a branch, I'd go for it. m2build would be the name for it. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: something wrong with the mirrored jars
I had the same problem when you reported it, but didn't have time to chase it up, but it seems fine now. Anyone know what happened? John Sachin Patel wrote: So it looks like something is wrong with the mirrored jars on ibiblio. If you take a look at any of the 1.1 jars Matt published to http://www.apache.org/dist/java-repository/geronimo/jars/ then compare it to the ones on http://www.ibiblio.org/maven/geronimo/jars/, at first glance, the 1.1 jars exist, have matching file sizes, but clicking the link brings up a page with Not found. -sachin
[jira] Resolved: (AMQ-394) for non-durable topics add a configurable Policy to drop messages from slow consumers
[ https://issues.apache.org/activemq/browse/AMQ-394?page=all ] james strachan resolved AMQ-394: Resolution: Fixed For details see http://incubator.apache.org/activemq/slow-consumer-handling.html for non-durable topics add a configurable Policy to drop messages from slow consumers - Key: AMQ-394 URL: https://issues.apache.org/activemq/browse/AMQ-394 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Fix For: 4.1 e.g. for market data pricing we may wish to only allow say 1000 pending messages but discard old messages rather than have things back up. Similarly we may wish to do something like remove old price changes for the same stock and just keep around the latest prices. So some kind of pluggable policy on the non-durable topic subscription would be a good idea, letting users customize this behaviour. Maybe some FlowControlPolicy or something? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12418994
]
Alan Cabrera commented on GERONIMO-2161:
+1 w/ comments
I find it odd that we have to build geronimo 13 times but, this is an artifact
of our circular depdendencies rather than a difficiency of this patch.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
[jira] Reopened: (AMQ-394) for non-durable topics add a configurable Policy to drop messages from slow consumers
[ https://issues.apache.org/activemq/browse/AMQ-394?page=all ] james strachan reopened AMQ-394: changing fix version... for non-durable topics add a configurable Policy to drop messages from slow consumers - Key: AMQ-394 URL: https://issues.apache.org/activemq/browse/AMQ-394 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Fix For: 4.0.1, 4.0 e.g. for market data pricing we may wish to only allow say 1000 pending messages but discard old messages rather than have things back up. Similarly we may wish to do something like remove old price changes for the same stock and just keep around the latest prices. So some kind of pluggable policy on the non-durable topic subscription would be a good idea, letting users customize this behaviour. Maybe some FlowControlPolicy or something? -- 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-394) for non-durable topics add a configurable Policy to drop messages from slow consumers
[ https://issues.apache.org/activemq/browse/AMQ-394?page=all ] james strachan resolved AMQ-394: Fix Version: 4.0.1 4.0 (was: 4.1) Resolution: Fixed for non-durable topics add a configurable Policy to drop messages from slow consumers - Key: AMQ-394 URL: https://issues.apache.org/activemq/browse/AMQ-394 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Fix For: 4.0.1, 4.0 e.g. for market data pricing we may wish to only allow say 1000 pending messages but discard old messages rather than have things back up. Similarly we may wish to do something like remove old price changes for the same stock and just keep around the latest prices. So some kind of pluggable policy on the non-durable topic subscription would be a good idea, letting users customize this behaviour. Maybe some FlowControlPolicy or something? -- 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-391) message consumption is too slow, only 40/s
[ https://issues.apache.org/activemq/browse/AMQ-391?page=all ] james strachan resolved AMQ-391: Fix Version: 4.0.1 Resolution: Fixed This should be fixed in 4.0.1 now. If its not let us know and we can reopen the issue message consumption is too slow, only 40/s -- Key: AMQ-391 URL: https://issues.apache.org/activemq/browse/AMQ-391 Project: ActiveMQ Type: Improvement Versions: 3.1 Environment: java version 1.5.0_05, Windows XP, Pentium IV 2.6 GHz, 1 Gb memory Reporter: Daniel Aioanei Fix For: 4.0.1 For this test I used text messages with two Long properties, two String properties and one text message, all of them with normal sizes. The text message is 80 characters long, while the String properties have 12 characters. I'm using the following activemq configuration: ?xml version=1.0 encoding=UTF-8? !DOCTYPE beans PUBLIC -//ACTIVEMQ//DTD//EN http://activemq.org/dtd/activemq.dtd; beans !-- -- !-- ActiveMQ Broker Configuration -- !-- -- broker connector tcpServerTransport uri=tcp://localhost:61616 backlog=1000 useAsyncSend=false maxOutstandingMessages=50/ /connector persistence cachePersistence journalPersistence directory=../var/journal jdbcPersistence dataSourceRef=derby-ds/ /journalPersistence /cachePersistence /persistence redeliveryPolicy maximumRetryCount=416 backOffMode=true backOffIncreaseRate=1 initialRedeliveryTimeout=1000/ /broker !-- -- !-- JDBC DataSource Configurations -- !-- -- !-- The Derby Datasource that will be used by the Broker -- bean id=derby-ds class=org.apache.commons.dbcp.BasicDataSource destroy-method=close property name=driverClassName valueorg.apache.derby.jdbc.EmbeddedDriver/value /property property name=url !-- Use a URL like 'jdbc:hsqldb:hsql://localhost:9001' if you want to connect to a remote hsqldb -- valuejdbc:derby:derbydb;create=true/value /property property name=username value/value /property property name=password value/value /property property name=poolPreparedStatements valuetrue/value /property /bean /beans where activemq runs in its own jvm. After I produced about 1000 messages with a producer, I shut it down and then start a consumer jvm. Unfortunately it can only consume about 40 msg/second while I'd like to get about 400/s. The consumer is configured like this: ?xml version=1.0 encoding=UTF-8? !-- START SNIPPET: spring -- !DOCTYPE beans PUBLIC -//SPRING//DTD BEAN//EN http://www.springframework.org/dtd/spring-beans.dtd; beans !-- START SNIPPET: jca -- bean id=jencks class=org.jencks.JCAContainer !-- lets use the default configuration of work manager and transaction manager-- property name=bootstrapContext bean class=org.jencks.factory.BootstrapContextFactoryBean property name=threadPoolSize value=25/ /bean /property !-- the JCA Resource Adapter -- property name=resourceAdapter bean id=activeMQResourceAdapter class=org.activemq.ra.ActiveMQResourceAdapter property name=serverUrl value=reliable:tcp://localhost:61616?asyncSend=falseamp;copyMessageOnSend=falseamp;disableTimeStampsByDefault=trueamp;doMessageCompression=falseamp;doMessageFragmentation=falseamp;prepareMessageBodyOnSend=falseamp;cachingEnabled=false/ /bean /property /bean !-- END SNIPPET: jca -- !-- || an inbound message connector using a stateless, thread safe MessageListener -- !-- START SNIPPET: inbound -- bean id=inboundConnectorA class=org.jencks.JCAConnector property name=jcaContainer ref=jencks / !-- subscription details -- property name=activationSpec bean class=org.activemq.ra.ActiveMQActivationSpec property name=destination value=InboundQueue/ property name=destinationType value=javax.jms.Queue/ /bean /property property name=ref value=echoBean/ /bean bean id=echoBean class=com.foo.bar.Mdp singleton=true/ !-- END SNIPPET: inbound -- /beans Mdp only reads the properties and nothing more. I tried varying threadPoolSize from 25 to 250 to no avail. I think 40 msg/second is too slow in this configuration. -- 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:
RE:
Hey Hiram, I was actually thinking of the messages coming from the broker to the client - the newer version of the broker always sends a \0\n to denote the end of the frame. I'm not sure if the CMS client is sly enough to handle both cases - I think it's expecting one or the other (either \0 or \0\n). I was just throwing that out there as a possible reason that the client may freeze on a read - waiting for the trailing \n that never comes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, July 03, 2006 12:58 PM To: activemq-dev@geronimo.apache.org Subject: Re: Hi Nathan, I'm not so sure about that. I think that AMQ should support receiving a STOMP frame terminated by \0 without a subsequent \n. The STOMP spec does say that white space before a frame should be ignored. Anyways, if anybody can confirm that this is not the case, then it's a bug with how we implemented STOMP in AMQ. On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cp p/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat -- Regards, Hiram Blog: http://hiramchirino.com
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Jacek Laskowski wrote: On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote: So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm not exactly sure how that affects the current votes... or does adding a new version of the patch negate anything else voted upon. You're completely right - it doesn't read good. Do you think doing such experiments on trunk would break it *at least* once? I guess so. Do you think it matters? Yes. I think there's a solution to RTC and having a place for experiments like this where nothing's known ahead - a branch. With a branch you can do whatever you want and no RTC rules apply there. I think it would help us all. Interested? Count me in! ;-) If I knew how to create a branch, I'd go for it. m2build would be the name for it. Jacek Jacek, I'm not following your line of thought when you mention experiments. Can you provide more detail? Regards, Alan
[jira] Resolved: (AMQ-361) duplicate delivery, already consumed messages are reconsumed after server restart
[ https://issues.apache.org/activemq/browse/AMQ-361?page=all ] james strachan resolved AMQ-361: Fix Version: 4.0.1 Resolution: Fixed AFAIK this is all working now in 4.0.1 - let us know if you can still reproduce on 4.0.1 and we can reopen duplicate delivery, already consumed messages are reconsumed after server restart - Key: AMQ-361 URL: https://issues.apache.org/activemq/browse/AMQ-361 Project: ActiveMQ Type: Bug Components: Broker, Message Store, JCA Container Versions: 3.1 Environment: windows xp, jdk 1.5, embedded activemq 3.1 broker, jboss 4.02, persistent messages with derby db. Reporter: Gokturk Ozer Fix For: 4.0.1 Attachments: 1.log I am running an embedded activemq broker inside jboss server, I send 1000 messages with ~10K size each to a queue, these messages are consumed by MDBs. After all the messages are consumed, I check the queue via hermes, it also shows no message in the queue. Everything works perfect up to this point. I observe the problem after I stop the jboss server. I connect to derby database via networkserver, I still see some messages in activemq_msgs table. I shutdown derby networkserver and start jboss again, I see from the log that some of the messages which were consumed previously, are being consumed again. If I start the server without deploying the MDB and check the queue via hermes, I see some but not all the messages which were consumed previously still in the queue, before restart hermes was showing no messages. -- 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-275) Could not enqueue message and Too many open files
[ https://issues.apache.org/activemq/browse/AMQ-275?page=all ]
james strachan resolved AMQ-275:
Fix Version: 4.0.1
(was: 3.2.5)
Resolution: Fixed
This issue is fixed now in 4.0.1
Could not enqueue message and Too many open files
-
Key: AMQ-275
URL: https://issues.apache.org/activemq/browse/AMQ-275
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 3.0
Environment: Windows 2000/XP SP2
Reporter: Glen Klyuzner
Fix For: 4.0.1
Attachments: patchfile.txt
Relaited to slow consumer condition.
WARN 2005-06-22 12:55:44,135 - Queue is full, waiting for it to be dequeued.
2005-06-22 11:51:09,678 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2024-1119453996333-6:0 is a slow consumer
2005-06-22 11:51:09,678 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2024-1119453996333-6:0 is a slow consumer
2005-06-22 11:51:09,694 [ocalport=61616]] INFO DataContainer
- making directory for temporary spooled data: ActiveMQTemp
2005-06-22 11:51:11,069 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2005-1119453893347-6:0 is a slow consumer
2005-06-22 11:51:11,069 [ocalport=61616]] WARN BrokerClientImpl
- Connection: ID:ny-cap-33-2005-1119453893347-6:0 is a slow consumer
2005-06-22 11:51:17,288 [ocalport=61616]] DEBUG
ientTopicBoundedMessageManager - Adding consumer: CONSUMER_INFO: id = 336
ConsumerInfo{ browser = false, destination =
ActiveMQ.Advisory.TempDestinations.temp-queue.TemporaryQueue-{TD{ID:ny-cap-33-2150-1119455437835-16:0}TD}ID:ny-cap-33-2150-1119455437835-23:0,
consumerIdentifier = 'ID:ny-cap-33-2024-1119453996333-16:0.27.53' , clientId
= 'ID:ny-cap-33-2024-1119453996333-16:0' , sessionId = '27' , consumerName =
'' , selector = '' , startTime = 1119455477008, started = true, consumerNo =
53, noLocal = false, prefetchNumber = 1000, consumerKey =
'[ID:ny-cap-33-2024-1119453996333-16:0:]' }
2005-06-22 11:51:54,773 [ocalport=61616]] ERROR BrokerClientImpl
- Could not enqueue message ACTIVEMQ_OBJECT_MESSAGE: id = 0 ActiveMQMessage{
, jmsMessageID = ID:ny-cap-33-2005-1119453893347-68:121589, bodyAsBytes =
[EMAIL PROTECTED], readOnlyMessage = false, jmsClientID =
'ID:ny-cap-33-2005-1119453893347-6:0' , jmsCorrelationID = 'null' ,
jmsDestination = Topic.sds.PropertyTemplatePublisher, jmsReplyTo = null,
jmsDeliveryMode = 2, jmsRedelivered = false, jmsType = 'null' , jmsExpiration
= 1119455573508, jmsPriority = 4, jmsTimestamp = 1119455513508, properties =
null, readOnlyProperties = false, entryBrokerName =
'ID:nyotc023-2882-1119382254093-0:0' , entryClusterName = 'default' ,
consumerNos = [EMAIL PROTECTED], transactionId = 'null' , xaTransacted =
false, consumerIdentifer = 'null' , messageConsumed = false,
transientConsumed = false, sequenceNumber = 121589, deliveryCount = 1,
dispatchedFromDLQ = false, messageAcknowledge = null, jmsMessageIdentity =
null, producerKey = ID:ny-cap-33-2005-1119453893347-68: }
ActiveMQObjectMessage{ object = null } to SpooledBoundedQueue for this slow
consumer
javax.jms.JMSException: enqueNoBlock failed: Too many open files
at
org.activemq.io.util.SpooledBoundedActiveMQMessageQueue.enqueueNoBlock(SpooledBoundedActiveMQMessageQueue.java:121)
at
org.activemq.io.util.SpooledBoundedActiveMQMessageQueue.enqueue(SpooledBoundedActiveMQMessageQueue.java:91)
at
org.activemq.broker.impl.BrokerClientImpl.dispatch(BrokerClientImpl.java:198)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageContainer.dispatchToQueue(TransientTopicBoundedMessageContainer.java:223)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageContainer.targetAndDispatch(TransientTopicBoundedMessageContainer.java:155)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageManager.doSendMessage(TransientTopicBoundedMessageManager.java:225)
at
org.activemq.service.boundedvm.TransientTopicBoundedMessageManager.sendMessage(TransientTopicBoundedMessageManager.java:204)
at
org.activemq.broker.impl.DefaultBroker.doMessageSend(DefaultBroker.java:563)
at
org.activemq.broker.impl.DefaultBroker.sendMessage(DefaultBroker.java:305)
at
org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:462)
at
org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:271)
at
org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:706)
at
org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:310)
at
org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
at
[jira] Commented: (AMQ-729) Using a very simple producer and consumer messages are received in wrong order.
[ https://issues.apache.org/activemq/browse/AMQ-729?page=comments#action_36513 ] james strachan commented on AMQ-729: Can you reproduce this on 4.0.1? Using a very simple producer and consumer messages are received in wrong order. --- Key: AMQ-729 URL: https://issues.apache.org/activemq/browse/AMQ-729 Project: ActiveMQ Type: Test Versions: 4.0 RC2 Environment: i386-pc-solaris2.10 Reporter: Dietrich Bollmann Priority: Minor Attachments: test.tar.gz * Summary: Using a very simple producer and consumer (I appended the code to this message) the messages are received in the wrong order. The following setting produced problems in 7 of 10 cases: - One broker - Two producers sending 10 messages each - One consumer - Broker, producers and consumer are all running on the same host. * Test protocol: Preparations: gunzip test.tar.gz tar xvf test.tar cd test ant compile Start the broker: cd $ACTIVEMQ_HOME bin/activemq Start the consumer: ant \ -DconsumerName=consumer \ -Durl=tcp://localhost:61616 \ -DproducerCount=2 \ -DmessageCount=10 \ consumer Start the producers: ant \ -DproducerName=producer1 \ -Durl=tcp://localhost:61616 \ -DproducerCount=2 \ -DmessageCount=10 \ producer ant \ -DproducerName=producer2 \ -Durl=tcp://localhost:61616 \ -DproducerCount=2 \ -DmessageCount=10 \ producer * Results: Running the test 10 times the messages were received 3 times in the right order and 7 times in a mixed up fashion: 1. Succesfully received all messages 2. Wrong message order: Received message 33045 after message 33043 from producer2 3. Wrong message order: Received message 97909 after message 97829 from producer1 4. Wrong message order: Received message 67839 after message 67837 from producer2 5. Wrong message order: Received message 63717 after message 63610 from producer2 6. Succesfully received all messages 7. Wrong message order: Received message 61603 after message 61576 from producer2 8. Wrong message order: Received message 51119 after message 49043 from producer2 9. Succesfully received all messages 10. Wrong message order: Received message 99710 after message 99707 from producer1 -- 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-319) ActiveMQ hangs when initial connection to broker fails using reliable transport
[ https://issues.apache.org/activemq/browse/AMQ-319?page=comments#action_36515 ] james strachan commented on AMQ-319: Eric - in 4.x you can configure the amount of time or number of tempts that the failover: transport will attempt before the connection is considered dead and the operation (such as opening a connection) will consider to be failed. Otherwise to avoid sends blocking you can use async sends... http://incubator.apache.org/activemq/async-sends.html however the only way to allow things like connection, session, producer, consumer to be created without blocking is to use a special transport filter that spoofs return responses for these operations - which effectively breaks JMS complaince (as we can't implement security for example). ActiveMQ hangs when initial connection to broker fails using reliable transport Key: AMQ-319 URL: https://issues.apache.org/activemq/browse/AMQ-319 Project: ActiveMQ Type: Improvement Components: JMS client Versions: 3.0 Reporter: Ramzi Saba Fix For: 3.2.5 Make these changes in the JMS client to avoid blocking on startup in case all brokers are down: 1- Start the reliable tcp channel in its own thread (seems there was an attempt to do so anyway) 2- Synchronous and asynchronous client calls (via session, consumer, etc.) to the reliable tcp channel should simply verify if a reliable channel has been already established, else throw a JMSException, alternatively allow the client to configure a timeout (currently it's hardcoded for synchronous calls only I believe). 3- Other than starting the reliable channel, the client should not be responsible of reestablishing a lost or unavailable channel. I would delegate reliability to the reliable channel itself. 4- Look into adding a listener to allow for a silent client startup and reconnect behind the scene once the broker is up -- 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] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I'm not following your line of thought when you mention experiments. Can you provide more detail? (It turns out that I'm a victim of my own English, and I can't express my mind clearly.) What I meant was to refer to our m2 efforts when it works for one and does not for others and we can't figure out why. As many stated, it's unacceptable to happen in trunk, which would've had if it'd done in a conventional manner - CTR. Call it whatever you like - experiments are what suited best for me, esp. while we're experimenting with m2 build until we get to the point when it's ready to be applied to the trunk. Rather than wasting Jason's time and encouraging him to follow RTC rules, which add nothing but frustration and disgust, we could use a solution that was indeed mentioned many times - a branch. It's like a sandbox where we can do everything - experimenting - until we find the one working solution ready for RTC. (somehow I feel you read it otherwise, but again it might be that my English's not working well) Alan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
m2migration branch - thoughts?
Hi, After having read so many emails with frustration and disgust, I think we could get rid of these shortcomings and do the migration in a branch - m2migration or alike. The idea of the branch would be to loosen up the RTC rules that are bound to the trunk and let people experimenting - do the migration without having to follow RTC, preparing patches that don't work for everyone, but often very temporarily until they're again fixed and improved. Thoughts? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (AMQ-792) allow asynchronous dispatch to consumers in the broker for non-durable topics
[ https://issues.apache.org/activemq/browse/AMQ-792?page=all ] james strachan updated AMQ-792: --- Description: We typically use the current thread in the broker to dispatch to all the available non-durable consumers for performance - as this hugely reduces the context switching and increases performance. However (see AMQ-688) sometimes this can cause one dead consumer to block a producer. Some folks may want to switch this strategy to use slower asynchronous dispatch with a thread pool to reduce the risk of blocking a producer at the expensive of lower performance was: We typically use a single thread in the producer to dispatch to all the available non-durable consumers for performance - as this hugely reduces the context switching and increases performance. However (see AMQ-688) sometimes this can cause one dead consumer to block a producer. Some folks may want to switch this strategy to use slower asynchronous dispatch with a thread pool to reduce the risk of blocking a producer at the expensive of lower performance allow asynchronous dispatch to consumers in the broker for non-durable topics - Key: AMQ-792 URL: https://issues.apache.org/activemq/browse/AMQ-792 Project: ActiveMQ Type: Improvement Components: Broker Reporter: james strachan Fix For: 4.2 We typically use the current thread in the broker to dispatch to all the available non-durable consumers for performance - as this hugely reduces the context switching and increases performance. However (see AMQ-688) sometimes this can cause one dead consumer to block a producer. Some folks may want to switch this strategy to use slower asynchronous dispatch with a thread pool to reduce the risk of blocking a producer at the expensive of lower performance -- 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
handling slow consumers on non-persistent topics and AMQ-688
While perusing JIRA I spotted this issue again... http://issues.apache.org/activemq/browse/AMQ-688 I know its an issue close to folks at Amazon's hearts. Dealing with slow consumers is a fascinating problem for a messaging system; its quite a tricky problem :). Here's some background on the issue... http://incubator.apache.org/activemq/slow-consumers.html together with the currently supported features - to allow messages to be discarded on slow consumers using a pluggable algorithm... http://incubator.apache.org/activemq/slow-consumer-handling.html Now for all consumers we fill up prefetch buffers as quickly as possible... http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html so there's always a buffer of messages per consumer. For non-durable topics once these messages are written to a socket they are evicted from RAM; so we already have some support for slow consumers. I wanted to start a discussion on both AMQ-688 and to see if folks had other requirements for handling slow consumers to try decide what features stragegies we should add next in this area. One of the first requirements folks ask for is that rather than blocking permanently the non-persistent topic engine until RAM is cleared, that at a certain threshhold we start spooling to disk. I've raised a separate JIRA issue for this specific feature request... http://issues.apache.org/activemq/browse/AMQ-791 Another issue some folks have hit in the past is that for high performance and to minimise context switches in the broker, we tend to use the current thread in the broker to dispatch to all the non-durable topic consumers so a slow/blocked consumer can appear to 'block' the producer. I've raised this issue to track that feature http://issues.apache.org/activemq/browse/AMQ-792 I just wondered if folks had any other issues or requirements with the whole slow consumers and non-durable topics they'd like to discuss? Is there any requirements we won't have covered if the above two JIRAs are fixed -- James --- http://radio.weblogs.com/0112098/
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Jacek Laskowski wrote: On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I'm not following your line of thought when you mention experiments. Can you provide more detail? (It turns out that I'm a victim of my own English, and I can't express my mind clearly.) What I meant was to refer to our m2 efforts when it works for one and does not for others and we can't figure out why. As many stated, it's unacceptable to happen in trunk, which would've had if it'd done in a conventional manner - CTR. Call it whatever you like - experiments are what suited best for me, esp. while we're experimenting with m2 build until we get to the point when it's ready to be applied to the trunk. Rather than wasting Jason's time and encouraging him to follow RTC rules, which add nothing but frustration and disgust, we could use a solution that was indeed mentioned many times - a branch. It's like a sandbox where we can do everything - experimenting - until we find the one working solution ready for RTC. (somehow I feel you read it otherwise, but again it might be that my English's not working well) Cool. I'll reply to your new post. Regards, Alan
Re: m2migration branch - thoughts?
Jacek Laskowski wrote: Hi, After having read so many emails with frustration and disgust, I think we could get rid of these shortcomings and do the migration in a branch - m2migration or alike. The idea of the branch would be to loosen up the RTC rules that are bound to the trunk and let people experimenting - do the migration without having to follow RTC, preparing patches that don't work for everyone, but often very temporarily until they're again fixed and improved. Thoughts? Jacek The problem w/ migrating in a branch is that it gets out of date quickly. Since we're not using m2 in trunk anyway, why not just let Jason go crazy in trunk? If there are any changes that are needed in trunk that would affect the current build then for that bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs. Regards, Alan
Re: m2migration branch - thoughts?
On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: The problem w/ migrating in a branch is that it gets out of date quickly. Quickly?! Is my English working badly again? ;-) How could you say 'quickly' while we're almost stopped and everybody's frustrated? That's why I proposed it. Since we're not using m2 in trunk anyway, why not just let Jason go crazy in trunk? If there are any changes that are needed in trunk that would affect the current build then for that bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs. Isn't a branch suitable for such a work? I think Ken wouldn't agree with the above ;-) Alan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
Do you have an simple example project that implements the build and use of the plugin in the same cycle that I can peek at? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: magicGball/src and magicGball/*/*
Just have a peek at: http://svn.apache.org/repos/asf/geronimo/trunk/applications/ magicGball/src/ and then peek at the modules, like: http://svn.apache.org/repos/asf/geronimo/trunk/applications/ magicGball/magicGball-ejb/src/ NOTE: the pom.xml for applications/magicGball is pom packaging, so it does not make sense that the top-level pom for magicGball has a src directory at all. --jason On Jul 3, 2006, at 7:08 AM, Jacek Laskowski wrote: On 7/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where there are duplicate srcs under magicGball? Looks like this is to support m1 and m2 builds. I don't understand what you're asking for. How do you know they exist at all? An answer for the question might help me a bit understand what you're after ;-) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419012
]
Jason Dillon commented on GERONIMO-2161:
13 times is *definitely* not due to this patch or any work I have done. Its is
a ugly hack work-around to a broken xmlbeans plugin. This crappy rebuild muck
will go away soon... but I am weary about making more changes with out first
getting this lot committed.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee/artifactId
version${geronimoVersion}/version
/dependency
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
NOTE... the m2 build in trunk is already broken... this patches help FIX MANY OF THOSE PROBLEMS! Since the official build is still m1 and this will not affect the m1 build, I don't see why your point about breakage is applicable at all. When I first created the m1 build for Geronimo years ago there were certainly a few moments of breakage due to build changes, but since there was no commit by committee junk going on then it was easy to just fix when things happened to get a bit askew. The branch idea was just to make it easier to actually make progress, as I am move on this stuff way way faster than the lot of you can react to emails and JIRAs which often (as this one did) need several sets of emails to clarify. :-( --jason On Jul 3, 2006, at 11:31 AM, Jacek Laskowski wrote: On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I'm not following your line of thought when you mention experiments. Can you provide more detail? (It turns out that I'm a victim of my own English, and I can't express my mind clearly.) What I meant was to refer to our m2 efforts when it works for one and does not for others and we can't figure out why. As many stated, it's unacceptable to happen in trunk, which would've had if it'd done in a conventional manner - CTR. Call it whatever you like - experiments are what suited best for me, esp. while we're experimenting with m2 build until we get to the point when it's ready to be applied to the trunk. Rather than wasting Jason's time and encouraging him to follow RTC rules, which add nothing but frustration and disgust, we could use a solution that was indeed mentioned many times - a branch. It's like a sandbox where we can do everything - experimenting - until we find the one working solution ready for RTC. (somehow I feel you read it otherwise, but again it might be that my English's not working well) Alan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: magicGball/src and magicGball/*/*
That was my guess. Do you know if there is a JIRA to clean that up? --jason On Jul 3, 2006, at 12:39 PM, David Jencks wrote: I think this might be an m1/m2 artifact. I believe the m1 build uses the stuff in magicGball/src whereas the m2 build uses the subdirectories and ignores the stuff used by m1. Yet another reason to ditch m1 as soon as possible. thanks david jencks On Jul 3, 2006, at 12:34 PM, Jason Dillon wrote: Just have a peek at: http://svn.apache.org/repos/asf/geronimo/trunk/applications/ magicGball/src/ and then peek at the modules, like: http://svn.apache.org/repos/asf/geronimo/trunk/applications/ magicGball/magicGball-ejb/src/ NOTE: the pom.xml for applications/magicGball is pom packaging, so it does not make sense that the top-level pom for magicGball has a src directory at all. --jason On Jul 3, 2006, at 7:08 AM, Jacek Laskowski wrote: On 7/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where there are duplicate srcs under magicGball? Looks like this is to support m1 and m2 builds. I don't understand what you're asking for. How do you know they exist at all? An answer for the question might help me a bit understand what you're after ;-) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
The problem w/ migrating in a branch is that it gets out of date quickly. Quickly?! Is my English working badly again? ;-) How could you say 'quickly' while we're almost stopped and everybody's frustrated? That's why I proposed it. Problem is that the branch needs to be kept in sync with other changes to trunk... which is merging overhead, less overhead perhaps than with RTC. Unless we can agree that the m2 changes in trunk are okay to commit w/ o RTC because they only affect the m2 build, then I feel I have not choice but to branch and work out how best to keep the branch sync'd with out causing artificial merge conflicts... or simply stop working on this. IMO, the branch is better than RTC on trunk... but I think that it is still more work than what is really needed... and I don't really like to waste my time (or yours). --jason
[RTC] pluggable jacc
I think my latest patch for pluggable jacc is plausible to commit, see http://issues.apache.org/jira/browse/GERONIMO-1563?page=all and be sure to apply only the v4 patches. I realize this is a significant amount of work, so at this time I'm not actually asking any PMC members to review this, but I would greatly appreciate it if at least 3 could spend a couple minutes estimating how long they think it would take them to evaluate the patch and when they might be able to complete evaluating it, as this will personally affect my plans for the next few weeks. I think all the committers and other contributors might find this information useful in planning their development activities for the next few months. Many thanks, david jencks
Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
I think there's a solution to RTC and having a place for experiments like this where nothing's known ahead - a branch. With a branch you can do whatever you want and no RTC rules apply there. I think it would help us all. Interested? Count me in! ;-) I don't really consider this work experimental... gshell is experimental, but the m2 work that I am doing is just the application of experience with this system and other build systems for the past years (and years). But... lets see what others have to say. I may create an experimental branch to see how well SVN actually handles merges and remerges of an entire (massive) branch. And if that ends up being relatively feasible then I would consider creating a branch for the remaining m2 work. Though... even with a branch, we would have to RTC to merge back to trunk, which may take several weeks... which is not acceptable IMO. --jason
Re: m2migration branch - thoughts?
I'm concerned that after all the work is done, it will be hard to merge the M2 changes from the branch to the trunk. SVN doesn't seem to have particularly good handing for merging changes that involve a lot of subsequent adds, deletes, moves, etc. When this stuff gets complex, more often than not, I've had to just whack the old tree and check out a fresh copy. So we could all shift to working out the kinks in the M2 branch as CTR and then vote to make that branch *into* head under the rules for revolutionaries. But really, I think this just emphasizes the limitations of RTC for the kind of work that's going on for 1.2. Thanks, Aaron On 7/3/06, Jacek Laskowski [EMAIL PROTECTED] wrote: Hi, After having read so many emails with frustration and disgust, I think we could get rid of these shortcomings and do the migration in a branch - m2migration or alike. The idea of the branch would be to loosen up the RTC rules that are bound to the trunk and let people experimenting - do the migration without having to follow RTC, preparing patches that don't work for everyone, but often very temporarily until they're again fixed and improved. Thoughts? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
Did want happens when you `mvn clean` after a clean check out and have an empty repository? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: m2migration branch - thoughts?
Jacek Laskowski wrote: On 7/3/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: The problem w/ migrating in a branch is that it gets out of date quickly. Quickly?! Is my English working badly again? ;-) How could you say 'quickly' while we're almost stopped and everybody's frustrated? That's why I proposed it. Because m2 work is not the only work that's going on. Not all work has stopped. You are only speaking of the m2 conversion work. There are other efforts underway. Since we're not using m2 in trunk anyway, why not just let Jason go crazy in trunk? If there are any changes that are needed in trunk that would affect the current build then for that bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs. Isn't a branch suitable for such a work? I think Ken wouldn't agree with the above ;-) As I mentioned above, the branch could get out of sync w/ trunk pretty quickly. The only reason to make a branch is to isolate the m2 work from the m2 stuff that's being used in trunk. But, the m2 stuff isn't being used in trunk. Working in the branch and working on the trunk is then virtually the same since m2 isn't being used in trunk. When the m2 work is done, we can fire up an RTC vote. This is not to say that there won't be a healthy dose of discussion along the way. It's ultimately up to the PMC and, most likely, Ken if it's following the intent of RTC. Regards, Alan
Re: fix for m2 builds when making wars...
On 7/3/06, James Strachan [EMAIL PROTECTED] wrote: Did you try a 'mvn -U install' to see if that fixed it? Here's what fixed it: mvn -U -cpu -e -Dmaven.test.skip=true clean install Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419022
]
Jason Dillon commented on GERONIMO-2161:
Looks like the latest 2.0.1-SNAPSHOT of the xmlbeans plugin removes the need
for the insaino 13 time build. I'm validating now. There are still issues of
removal of extraneous stax depends in our build, but we have a bunch of
dependency pruning to do and that can wait. Simply using 2.0.1-SNAPSHOT for
the plugin (which is deployed at snapshots.repository.codehaus.org) appears to
work much much better.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
Re:
Oh. That makes sense! Sorry for the noise! On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hey Hiram, I was actually thinking of the messages coming from the broker to the client - the newer version of the broker always sends a \0\n to denote the end of the frame. I'm not sure if the CMS client is sly enough to handle both cases - I think it's expecting one or the other (either \0 or \0\n). I was just throwing that out there as a possible reason that the client may freeze on a read - waiting for the trailing \n that never comes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, July 03, 2006 12:58 PM To: activemq-dev@geronimo.apache.org Subject: Re: Hi Nathan, I'm not so sure about that. I think that AMQ should support receiving a STOMP frame terminated by \0 without a subsequent \n. The STOMP spec does say that white space before a frame should be ignored. Anyways, if anybody can confirm that this is not the case, then it's a bug with how we implemented STOMP in AMQ. On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cp p/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
FW: Apache Geronimo
-Original Message-From: milan [mailto:[EMAIL PROTECTED]Sent: Tuesday, June 27, 2006 0:42To: general@incubator.apache.orgSubject: Apache Geronimo My name is Milan Shrestha .Am am an IT Engineeer . I have about one year experience working in java. I have heard the project proposed by apache named Apache Geronimo . So I would be thankful if I got chance to work and contribute for your project . Regards, Milan Shrestha Kathmandu Nepal
Re: M2 Issues and Actions
I used our project. Here are the steps - 1. add a print statements to say PackageBuilderShellMojo. 2. To make this test go faster comment out modules, applications from the parent pom. 3. use mvn clean install The .m2 Repo already has a packaging plugin with version 1.2.0. So maven happily builds. After the plugin is built, the configs are built. That is when the reloading plugin container message appears. You should see the message you added to the packaging plugin. The message should appear in all the configs except may be gbean-deployer. The gbean-delpoyer config is a special case, you must make sure that the new statement is executed. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: Do you have an simple example project that implements the build and use of the plugin in the same cycle that I can peek at? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Geronimo specs pre-RTC
We had talked about breaking out the Geronimo specs so that they don't share the same root pom. There seemed to be a consensus that this was a good idea. John Sisson mentioned that we might need separate Jiras for each. I think that that might be excessive given how the specs jars are unlikely to change. The nature of this change is that it will not be possible to make a patch to reflect the changes that need to be done. What I can do is to concretely express the changes that need to be made in an RTC. Thoughts? Regards, Alan
Re:
No problem - sorry for the confusion :) On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Oh. That makes sense! Sorry for the noise! On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hey Hiram, I was actually thinking of the messages coming from the broker to the client - the newer version of the broker always sends a \0\n to denote the end of the frame. I'm not sure if the CMS client is sly enough to handle both cases - I think it's expecting one or the other (either \0 or \0\n). I was just throwing that out there as a possible reason that the client may freeze on a read - waiting for the trailing \n that never comes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, July 03, 2006 12:58 PM To: activemq-dev@geronimo.apache.org Subject: Re: Hi Nathan, I'm not so sure about that. I think that AMQ should support receiving a STOMP frame terminated by \0 without a subsequent \n. The STOMP spec does say that white space before a frame should be ignored. Anyways, if anybody can confirm that this is not the case, then it's a bug with how we implemented STOMP in AMQ. On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cp p/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Geronimo specs pre-RTC
I think it is more work than it is worth to try and create patches and have separate issues for this. * * * This will generally move individual modules from http:// svn.apache.org/repos/asf/geronimo/specs/trunk/XXX to http:// svn.apache.org/repos/asf/geronimo/specs/XXX/trunk and then clean up the pom's right? I think it is still a good idea to have them all extend from a parent pom... there is still stuff that would be good to centralize, but the parent and the child do not need to exists within the same tree and do not need to share the same version. I recommend creating a top-level spec-config/trunk/pom.xml that has all of the common pom configuration... then release it a 1.0, and have each of the spec pom's extend from that. Spec config will almost never change (unless we have to change project urls or repos)... but when we do, its easier to manage in a central place. I think we eventually need a general project-config module that we can share with all sub-projects. That module would be part of a build-support project where our independent custom modules and build configuration lives. --jason On Jul 3, 2006, at 3:54 PM, Alan D. Cabrera wrote: We had talked about breaking out the Geronimo specs so that they don't share the same root pom. There seemed to be a consensus that this was a good idea. John Sisson mentioned that we might need separate Jiras for each. I think that that might be excessive given how the specs jars are unlikely to change. The nature of this change is that it will not be possible to make a patch to reflect the changes that need to be done. What I can do is to concretely express the changes that need to be made in an RTC. Thoughts? Regards, Alan
[jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon updated GERONIMO-2161:
---
Attachment: GERONIMO-2161-v4.patch
Adding GERONIMO-2161-v4; This patch supersedes all other patches. Includes
packaging plugin changes which will harmlessly fail on patching because the
universe hates me.
This patch:
* Updates the xmlbeans plugin to 2.0.1-SNAPSHOT which removes the need to
rebuild so many times.
* Consolidates the bulk of xmlbeans config into the root pom's
dependencyManagement. Same goes for JSPC and WAR.
* Using ${pom.groupId} for module dependencies
* Some pom's reordered for consistency
* Adds a few more dependencies to dependencyManagement to free modules from
needing to specify version (still a bunch more work to clean this up)
* Normalized some more pom headers... yada yada
Latest script to make a clean build:
{noformat}
#!/bin/sh
rm -rf ~/.m2/repository
find . -name target -type d -exec rm -rf \{\} \;
mvn -Dstage=bootstrap -Dmaven.test.skip=true
( cd openejb2/modules; mvn clean; mvn -Dmaven.test.skip=true install )
mvn -Dstage=assemble -Dmaven.test.skip=true
{noformat}
This depends on the latest pom's from openejb2 so be sure to update first.
As soon as openejb2's m2 build is published, then the build should function
with just:
{noformat}
./build -Dmaven.test.skip=true
{noformat}
Still a bunch more clean up that needs to be done...
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
Re: Geronimo specs pre-RTC
Jason Dillon wrote: I think it is more work than it is worth to try and create patches and have separate issues for this. Patches don't work for moving dirs, IIUC. * * * This will generally move individual modules from http://svn.apache.org/repos/asf/geronimo/specs/trunk/XXX to http://svn.apache.org/repos/asf/geronimo/specs/XXX/trunk and then clean up the pom's right? Yep. I think it is still a good idea to have them all extend from a parent pom... there is still stuff that would be good to centralize, but the parent and the child do not need to exists within the same tree and do not need to share the same version. I see no reason for there to be a parent POM. What stuff needs to be centralized? Can you explain what the phrase the parent and the child do not need to exists within the same tree and do not need to share the same version means? I recommend creating a top-level spec-config/trunk/pom.xml that has all of the common pom configuration... then release it a 1.0, and have each of the spec pom's extend from that. Spec config will almost never change (unless we have to change project urls or repos)... but when we do, its easier to manage in a central place. The whole point of this change is to get *rid* of the root POM. I think we eventually need a general project-config module that we can share with all sub-projects. That module would be part of a build-support project where our independent custom modules and build configuration lives. Why? Regards, Alan --jason On Jul 3, 2006, at 3:54 PM, Alan D. Cabrera wrote: We had talked about breaking out the Geronimo specs so that they don't share the same root pom. There seemed to be a consensus that this was a good idea. John Sisson mentioned that we might need separate Jiras for each. I think that that might be excessive given how the specs jars are unlikely to change. The nature of this change is that it will not be possible to make a patch to reflect the changes that need to be done. What I can do is to concretely express the changes that need to be made in an RTC. Thoughts? Regards, Alan
[jira] Commented: (GERONIMO-2082) [m2] stax dependencies are all wrong
[ http://issues.apache.org/jira/browse/GERONIMO-2082?page=comments#action_12419032 ] Jason Dillon commented on GERONIMO-2082: GERONIMO-2161 (v4) now addresses part of this problem, which fixes the build, but does not remove dependencies on stax, etc. [m2] stax dependencies are all wrong Key: GERONIMO-2082 URL: http://issues.apache.org/jira/browse/GERONIMO-2082 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.2 Attachments: geronimo-no-stax-v2.diff, geronimo-no-stax.diff, m2-repo.jar, openejb-no-stax-v2.diff, openejb-no-stax.diff, xbean-2.0.0.pom, xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar, xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar The dependencies for xmlbeans and the maven xmlbeans plugins are all wrong. xmlbeans pom needs to depend on stax-api, see http://jira.codehaus.org/browse/MEV-406 xmlbeans plugin needs to have stax-api and stax dependencies removed, see http://jira.codehaus.org/browse/MXMLBEANS-19 At this point we can remove all stax and stax-api dependencies from our (and openejb) poms. I'll attach the modified xmlbeans pom, the modified plugin, and the patches to remove all stax mentions from our poms. I'd appreciate some verification of my results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 Issues and Actions
FYI... issue opened to fix the problem using extensions here: http://jira.codehaus.org/browse/MNG-1911 And you were right... m2 will reload the plugin :-) --jason On Jul 3, 2006, at 3:26 PM, anita kulshreshtha wrote: I used our project. Here are the steps - 1. add a print statements to say PackageBuilderShellMojo. 2. To make this test go faster comment out modules, applications from the parent pom. 3. use mvn clean install The .m2 Repo already has a packaging plugin with version 1.2.0. So maven happily builds. After the plugin is built, the configs are built. That is when the reloading plugin container message appears. You should see the message you added to the packaging plugin. The message should appear in all the configs except may be gbean-deployer. The gbean-delpoyer config is a special case, you must make sure that the new statement is executed. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: Do you have an simple example project that implements the build and use of the plugin in the same cycle that I can peek at? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419034
]
David Jencks commented on GERONIMO-2161:
I've applied the v4 patch and aside from the combination of svn diff and patch
not being compatible the result of applying the patch works and looks good to
me. If I had a vote I'd vote +1
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee/artifactId
version${geronimoVersion}/version
/dependency
dependency
