how many connections?
we're experiencing an OOM with heavy CPU usage at startup on an activemq 4.0final release broker. we're connecting with activemq 4.0 final release client. We're using jencks message driven pojo's and jencks outbound message pooling. Our config looks like this: [...] bean id=jmsBootstrapContext class= org.jencks.factory.BootstrapContextFactoryBean property name=threadPoolSize value=10 / /bean [] bean id=jmsPoolingSupport class=org.jencks.factory.SinglePoolFactoryBean property name=maxSize value30/value /property property name=minSize value5/value /property property name=blockingTimeoutMilliseconds value500/value /property [...] We were seeing this OOM consistently this morning after the broker started failing for unknown reasons and we restarted it. We're not sending very many messages (6/second/process), but we're connecting to the broker with a lot of processes. We have 22 processes connecting, all running the configuration above. That's potentially 880 simultaneous connections to the broker, but more realistically maybe 330. Is this likely to be a problem? Do other people typically connect this many clients to a broker? I ran kill -3 while the broker was OOM and consuming the CPU. there are lots of threads that look like this: ActiveMQ Transport: tcp:///10.144.71.38:53513 daemon prio=1 tid=0x5e017188 nid =0x2a2b waiting for monitor entry [0x52788000..0x52788780] at edu.emory.mathcs.backport.java.util.concurrent.CopyOnWriteArrayList.r emove(CopyOnWriteArrayList.java:165) - waiting to lock 0x6335cdd0 (a edu.emory.mathcs.backport.java.util.co ncurrent.CopyOnWriteArrayList) at org.apache.activemq.broker.TransportConnector.onStopped (TransportConn ector.java:290) at org.apache.activemq.broker.TransportConnection.stop(TransportConnecti on.java:82) at org.apache.activemq.util.ServiceSupport.dispose( ServiceSupport.java:3 9) at org.apache.activemq.broker.AbstractConnection.serviceTransportExcepti on(AbstractConnection.java :172) at org.apache.activemq.broker.TransportConnection$1.onException (Transpor tConnection.java:68) at org.apache.activemq.transport.TransportFilter.onException (TransportFi lter.java:94) at org.apache.activemq.transport.ResponseCorrelator.onException (Response Correlator.java:120) at org.apache.activemq.transport.TransportFilter.onException (TransportFi lter.java:94) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:94) I also ran jmap. Here's the top of the histogram: Object Histogram: SizeCount Class description --- 923908224 14096 org.apache.activemq.command.DataStructure[] 180613424 68212 byte[] 8106048 253314 edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap $Segment 6926992 80479 char[] 4461856 58151 java.util.HashMap$Entry [] 4063768 253312 edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap $HashEntry[] 4053168 253323 edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLo ck$NonfairSync 3981208 36371 * ConstMethodKlass 3012240 125510 java.util.HashMap$Entry 2622552 36371 * MethodKlass 2325400 58135 java.util.HashMap 2119864 36717 java.lang.Object[] 2076464 48139 * SymbolKlass 1680408 70017 java.lang.String 1596296 2893* ConstantPoolKlass 1266560 15832 edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap $Segment[] 1195160 2893* InstanceKlassKlass 1045808 2581* ConstantPoolCacheKlass 934208 29194 org.apache.activemq.filter.DestinationMapNode 902224 56389 edu.emory.mathcs.backport.java.util.concurrent.atomic.AtomicBool Any ideas? This is becoming a very critical issue for us and while we're going to continue using activemq 4.0 for our release next week, we may get paged a whole lot and have to wake up in the middle of the night to restart if this issue continues to occur. Thanks for any help.
[jira] Commented: (AMQ-758) Message Groups disables server side JMS session pooling
[ https://issues.apache.org/activemq/browse/AMQ-758?page=comments#action_36423 ] james strachan commented on AMQ-758: I don't really understand the problem. Message Groups are designed so that a single thread processes all messages of the same group. If you don't want that, don't use message groups. If you want to allow concurrent processing (multiple threads processing the same message group) then you need to use something else. A fix for your problem would be to just use a separate background thread to do the long operation so that the caller can cancel the operation. e.g. foo.startLongOperation(); // the above returns without blocking foo.cancelLongOperation(); That way you can use message groups Message Groups disables server side JMS session pooling --- Key: AMQ-758 URL: https://issues.apache.org/activemq/browse/AMQ-758 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0 Reporter: Sanjiv Jivan Attachments: lingocluster.zip Specifying Message Groups on the client causes serialized/ single threaded processing of messages on the server side even when server side session pooling is configured. Please find attached sample code along with a JUnit test MessageGroupTests that demonstrates the issue. My sample is based on Lingo. The client calls an async method solve(scenarioName) and receives progress callbacks. When the cleint calls cancel(scenarioName) during a solve, the cancel method on the server side should be received and stop the running solve. Since a single JMS session evexcutes message listeners serially, I've configured a JMS server session pool of size 20 using Spring's DefaultMessageListenerContainer class. I've configured use of a message group via a Lingo marshaller class org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the JMS header JMSXGroupID to the scenarioName in question so that when a cluster of servers are running, the cancel(scenarioName) call is directed to the server that had solve(scenarioName) called for a given scenarioName. The issue is that when the message groups are enabled using the MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for the async solve(scenarioName) method to complete on the server (which is not the right behaviour). Disabling message groups by commenting out the client side MessageGroupMarshaller marshaller in org/sanjiv/lingo/test/messageGroupContext.xml results in the call being excuted correctly. I see that the docs for message groups say that message order is preserved, however that should not require that the second message blocks till the first message completes. Only the order in which the listeners are executes should be guaranteed to be the order of message receipt. Let me know if you have any questions. -- 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-758) Message Groups disables server side JMS session pooling
[ https://issues.apache.org/activemq/browse/AMQ-758?page=all ] james strachan resolved AMQ-758: Resolution: Won't Fix Closed for now as this bug is an effect of the design of Message Groups - they are meant to implement single-threaded processing of a single message group. Message Groups disables server side JMS session pooling --- Key: AMQ-758 URL: https://issues.apache.org/activemq/browse/AMQ-758 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0 Reporter: Sanjiv Jivan Attachments: lingocluster.zip Specifying Message Groups on the client causes serialized/ single threaded processing of messages on the server side even when server side session pooling is configured. Please find attached sample code along with a JUnit test MessageGroupTests that demonstrates the issue. My sample is based on Lingo. The client calls an async method solve(scenarioName) and receives progress callbacks. When the cleint calls cancel(scenarioName) during a solve, the cancel method on the server side should be received and stop the running solve. Since a single JMS session evexcutes message listeners serially, I've configured a JMS server session pool of size 20 using Spring's DefaultMessageListenerContainer class. I've configured use of a message group via a Lingo marshaller class org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the JMS header JMSXGroupID to the scenarioName in question so that when a cluster of servers are running, the cancel(scenarioName) call is directed to the server that had solve(scenarioName) called for a given scenarioName. The issue is that when the message groups are enabled using the MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for the async solve(scenarioName) method to complete on the server (which is not the right behaviour). Disabling message groups by commenting out the client side MessageGroupMarshaller marshaller in org/sanjiv/lingo/test/messageGroupContext.xml results in the call being excuted correctly. I see that the docs for message groups say that message order is preserved, however that should not require that the second message blocks till the first message completes. Only the order in which the listeners are executes should be guaranteed to be the order of message receipt. Let me know if you have any questions. -- 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] Assigned: (AMQ-757) MapMessage to support nested Map objects to create a typesafe hierarchial message such as used on RV etc
[ https://issues.apache.org/activemq/browse/AMQ-757?page=all ] james strachan reassigned AMQ-757: -- Assign To: james strachan MapMessage to support nested Map objects to create a typesafe hierarchial message such as used on RV etc Key: AMQ-757 URL: https://issues.apache.org/activemq/browse/AMQ-757 Project: ActiveMQ Type: Improvement Versions: 4.0 Reporter: james strachan Assignee: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-719) OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client
[ https://issues.apache.org/activemq/browse/AMQ-719?page=comments#action_36432 ] James Stanton commented on AMQ-719: --- This can be fixed by changing ActiveMQTextMessage Text getter/setter to look like this: (tested with Java 1.4.2) public string Text { get { if (text == null) { // now lets read the content byte[] data = this.Content; if (data != null) { // TODO assume that the text is ASCII char[] chars = new char[data.Length - sizeof(int)]; for (int i = 0; i chars.Length; i++) { chars[i] = (char)data[i + sizeof(int)]; } text = new String(chars); } } return text; } set { this.text = value; byte[] data = null; if (text != null) { // TODO assume that the text is ASCII byte[] intData = System.BitConverter.GetBytes(text.Length); data = new byte[text.Length + intData.Length]; //int at the front of it char[] chars = text.ToCharArray(); for (int j = 0; j intData.Length; j++) { data[j] = intData[intData.Length - j - 1]; //reverse byte order, I'm not certain why this is necessary, but it is -Jamie } for (int i = 0; i chars.Length; i++) { data[i + intData.Length] = (byte)chars[i]; } } this.Content = data; } } Hope this helps. Jamie OpenWire ActiveMQTextMessage not sharable between JMS client and dotNet client -- Key: AMQ-719 URL: https://issues.apache.org/activemq/browse/AMQ-719 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: ActiveMQ incubator 4.0 release - windows xp pro - jdk1.5 - dotNet2003 - openwire dotnet client from svn head Reporter: James Bradt Fix For: 4.1, 4.0.2 The payload content for a JMS message contains initial bytes for the length of the text string. The payload content for an dotNet openwire content does not contain this information. This mismatch in payload results in invalid payloads when passing jms messages between technologies. -- 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: build failure with latest source: maven-jetty6-plugin
This plugin is available on public repos, so you may try again to run maven until is successfully download all the needed dependencies. See http://repo.mergere.com/maven2/org/mortbay/jetty/maven-jetty6-plugin/6.0.0beta17/ Cheers, Guillaume Nodet On 6/16/06, David Black [EMAIL PROTECTED] wrote: Hi, With the latest src from here: http://svn.apache.org/repos/asf/incubator/servicemix/trunk/ and with maven 2.0.4 doing a mvn eclipse:eclipse in the root folder, I am having a build problem so: [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.mortbay.jetty:maven-jetty6-plugin' does not exist or no valid version could be found I've grabbed maven-jetty6-plugin-6.0.0beta9.jar manually, and placed it with that name and also as maven-jetty6-plugin.jar into my m2 repository at this location: .m2\repository\org\mortbay\jetty\maven-jetty6-plugin The build failure persists. Anyone else having / had this problem? I'm not so familiar with maven2 so maybe I'm confused ... but I assume the code should build from subversion, and I'm following the instructions from here: http://www.servicemix.org/site/building.html Any help much appreciated thanks David Black http://radio.weblogs.com/0146416/
Re: src for BPEL-Example
Thanks! I've checked that. -- View this message in context: http://www.nabble.com/src-for-BPEL-Example-t1791958.html#a4934663 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Updated 1.1 Release Binaries
On 6/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote: No other changes were made to the 1.1.0 branch. I have rebuilt the server and provided updated links to them below. *DayTrader Application* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final2.ear I'm working on a website and documentation to help folks out but the deliverable is the ear above. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final2.zip Just to warn others before they rise it up - the urls above are invalid as they don't contain final-2 in their names (note the hyphen between final and 2). At what point is the vote called and the distribution allowed? I think it should have started with your announcement the latest builds were available. I'd change the title of the message to begin with [VOTE] and resent. Since the above urls are broken it would make others' lifes easier, too ;-) Matt Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (GERONIMO-2136) Remove/Update licenses displayed in about page of console
Remove/Update licenses displayed in about page of console - Key: GERONIMO-2136 URL: http://issues.apache.org/jira/browse/GERONIMO-2136 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.1.1 The licenses displayed in the console in the about page ( http://localhost:8080/console/about.jsp ) are a subset of those in Geronimo's LICENSE.txt file. Either this licenses on this page should be removed or they should be updated to match the LICENSE.txt file. See mail thread. http://www.mail-archive.com/dev%40geronimo.apache.org/msg24852.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-747) Redelivery backoff should add random delay for collision avoidance
[ https://issues.apache.org/activemq/browse/AMQ-747?page=all ] james strachan resolved AMQ-747: Resolution: Fixed Patch applied - many thanks! (we just missed 4.0.1 but will try release 4.1 real soon). Redelivery backoff should add random delay for collision avoidance -- Key: AMQ-747 URL: https://issues.apache.org/activemq/browse/AMQ-747 Project: ActiveMQ Type: Improvement Components: Connector Versions: 4.0 Reporter: Christopher G. Stach II Fix For: 4.1 Attachments: AMQ-747.patch If a rollback on two messages happens between three transactional deliveries, and the two messages are redelivered with the same redelivery backoff settings, there is a likelihood that both messages will cause another rollback to happen. If maximumRedeliveries is set too low, or there are a maximumRedeliveries + 1 messages coming in simultaneously, messages may never get delivered. Can we get another option for the clients that adds a random backoff delay adjustment in addition to the constant backoff delay factor? This would end up working like most other collision avoidance algorithms. -- 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: Wiki based FAQ
+1 On Jun 16, 2006, at 6:19 PM, Dain Sundstrom wrote: I put together a FAQ in the sandbox on the cwiki. I seeded it with content from the main wiki on the Geronimo website and with some content from a resent email I sent about accessing an MBean server from a GBean. This is just an idea, and I will have no hard feelings if we decide to delete it (it only took 20 minutes to get going). http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ What do you think? -dain -sachin
[jira] Resolved: (AMQ-753) exposing the client IP Address
[ https://issues.apache.org/activemq/browse/AMQ-753?page=all ] james strachan resolved AMQ-753: Fix Version: 4.1 Resolution: Fixed Patch applied - many thanks! exposing the client IP Address -- Key: AMQ-753 URL: https://issues.apache.org/activemq/browse/AMQ-753 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 Environment: all os. Reporter: Ramesh Bobba Fix For: 4.1 Attachments: AMQ-753.patch We have a requirement to validate a client's host when a subscription request is performed. Is there a way to do this? If not, can we add this? -- 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-758) Message Groups disables server side JMS session pooling
[ https://issues.apache.org/activemq/browse/AMQ-758?page=comments#action_36428 ] Sanjiv Jivan commented on AMQ-758: -- Makes sense. I'll use the pooled executor from the concurrent library. Message Groups disables server side JMS session pooling --- Key: AMQ-758 URL: https://issues.apache.org/activemq/browse/AMQ-758 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: XP, ActiveMQ 4.0 release, Lingo 1.1, Spring 2.0 Reporter: Sanjiv Jivan Attachments: lingocluster.zip Specifying Message Groups on the client causes serialized/ single threaded processing of messages on the server side even when server side session pooling is configured. Please find attached sample code along with a JUnit test MessageGroupTests that demonstrates the issue. My sample is based on Lingo. The client calls an async method solve(scenarioName) and receives progress callbacks. When the cleint calls cancel(scenarioName) during a solve, the cancel method on the server side should be received and stop the running solve. Since a single JMS session evexcutes message listeners serially, I've configured a JMS server session pool of size 20 using Spring's DefaultMessageListenerContainer class. I've configured use of a message group via a Lingo marshaller class org.sanjiv.lingo.client.MessageGroupMarshaller. This class basically sets the JMS header JMSXGroupID to the scenarioName in question so that when a cluster of servers are running, the cancel(scenarioName) call is directed to the server that had solve(scenarioName) called for a given scenarioName. The issue is that when the message groups are enabled using the MessageGroupMarshaller, the cancel(scenarioName) call blocks and waits for the async solve(scenarioName) method to complete on the server (which is not the right behaviour). Disabling message groups by commenting out the client side MessageGroupMarshaller marshaller in org/sanjiv/lingo/test/messageGroupContext.xml results in the call being excuted correctly. I see that the docs for message groups say that message order is preserved, however that should not require that the second message blocks till the first message completes. Only the order in which the listeners are executes should be guaranteed to be the order of message receipt. Let me know if you have any questions. -- 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: Licenses displayed in console
I think the best bet is to point the user to the LICENSE.txt file as well as the NOTICES.txt file. Or alternately, we can read these files and display them. Since we have the correct license files in the build I'd prefer to defer a solution to this until 1.1.1. Aaron Mulder wrote: I'm not sure we really need a license screen in the console -- it seems unlikely to always be up to date. But if we do want it, we should probably update it with everything in LICENSE.txt. Thanks, Aaron On 6/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm not sure of the correct answer to that. The console cannot always display the licenses about third party software that has been installed. I would think that it should display the licenses that shipped with Geronimo. Others thoughts? John Sisson wrote: Are the licenses displayed in the console in the about page ( http://localhost:8080/console/about.jsp ) meant to represent the whole of Geronimo, or just the console? Currently the licenses displayed there are a subset of those in Geronimo's LICENSE.txt file. John
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: m2-plugins.patch configs.patch configs.log These patches modify geronimo packaging plugin to add geronimo-plugin.xml to the generated car and handle multiple artifacts genearated by the daytrader configuration. The configs.patch adds daytrader configuration for jetty and tomcat. 1. m2-plugins.patch 2. configs.patch 3. configs.log - results for rev. 414318 4. etc.patch - attached earlier A brief description of the changes to the plugin - Plugin takes a parameter 'geronimoPlugin' (true), and by default uses src/conf/geronimo-plugin.xml. This file is filtered and packaged in the car. The daytrader configuration generates multiple artifacts. Plugin takes multipleArtifacts (true) as a parameter to generate attached artifacts. For configurations that generate multiple artifacts, the target/repository/${groupId}/ directory is scanned for the artifacts generated by the deployer. All the artifacts are zipped to target directory and installed using attached artifacts. Maven restricts the name of the artifacts to be - ${artifactId}-${version}-classifier.car I prefer ${artifactId}-classifier-${version}.car. I have filed an issue - http://jira.codehaus.org/browse/MNG-2395 Also filed issues to exclude pom.xml and pom.properties for war and rar files generated by maven http://jira.codehaus.org/browse/MPWAR-59 http://jira.codehaus.org/browse/MRAR-10 Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 1.2 Attachments: configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, etc.patch, m2-plugins.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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
M2 : Build Instruction
Hi All, I was looking for a suitable place to add the build instrucitons for M2. I could not find any section dealing with the trunk at http://cwiki.apache.org/geronimo/ Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (GERONIMO-2135) Improve the ActiveMQ GBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2135?page=all ] Hiram Chirino updated GERONIMO-2135: Attachment: GERONIMO-2135.patch Fixes most of the items in this issue. Improve the ActiveMQ GBeans --- Key: GERONIMO-2135 URL: http://issues.apache.org/jira/browse/GERONIMO-2135 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2135.patch Suggestions by David Jencks: I think that this gbean adaptation code should be in geronimo rather than amq. I'm OK with applying it as is but would prefer some issues to be addressed first or, even better, immediately after the transfer (assuming it is done with svn mv). 1. DataSourceReference should be replaced by the geronimo class that does the same thing, ConnectionFactorySource. 2. I think it would be preferable to get the module/configuration classloader in the constructor as a magic attribute and use it in BrokerServiceGBeanImpl.doStart rather than the classloader of BrokerServiceGBeanImpl. 3. Same for TransportConnectorGBeanImpl. 4. This is a question, not really an issue, about this code: +protected TransportConnector createBrokerConnector(String url) throws Exception { +return brokerService.getBrokerContainer().addConnector(url); +} To me it seems like this code is combining the functions of factory object and container. Is this necessary and appropriate? I'd be more comfortable with Connector connector = ConnectorFactory.createConnector(url); brokerService.getBrokerContainer().addConnector(connector); I find that the combination style typically creates problems whenever trying to extend stuff, say by wrapping the connector. What do you think? 5. hardcoding the protocols in ActiveMQManagerGBean seems like a temporary expedient at best. 6. javadoc on public JMSConnector addConnector( ... in the manager gbean seems wrong... does not appear to return an object name. 7. Typo and innaccuracies in the first package.html... this stuff is only going to work in geronimo, jsr77/88 is not enough. 8. I'm not sure exactly what our official policy is but I prefer to remove public from methods in interfaces since it is the only choice and implied. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RTC] http://issues.apache.org/jira/browse/GERONIMO-2135
Hi folks, Looking for 3 +1s for the patch attached to http://issues.apache.org/jira/browse/GERONIMO-2135. This patch addresses previous concerns raised by David Jencks. Items not addressed by the patch are: #4: yes. I agree, but since these GBeans are just meant to be a simple integration between Geronimo and ActiveMQ, we are taking some short cuts. In general ActiveMQ allows you to configure many more options than what the current GBeans allows you to do. #5, I also agree, but I don't have a programmatic way of listing all protocols since they are loaded by searching the classpath for META-INF resources. -- Regards, Hiram Blog: http://hiramchirino.com
Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)
There's an interesting plugin site for eclipse at eclipseplugincentral.com that implements some of the ideas we have discussed. It provides a directory of plugins but not the actual files themselves, pointing elsewhere for the purchase/download. It also provides a rating system, news page, and discussion forums. IMHO the geronimo project should strive to provide this type of site for building a healthy commercial and open source community around geronimo plugins. The domain names geronimoplugincentral.com and geronimoplugincentral.org were available and match the form used by eclipseplugincentral.com so I purchased them and would like to donate them to the ASF. How can I do that? Just send a note to [EMAIL PROTECTED] Best wishes, Paul On 6/14/06, David Blevins [EMAIL PROTECTED] wrote: Everyone, please read and ACK. On Jun 14, 2006, at 4:31 PM, John Sisson wrote: Hiram, I care if a private or commercial entity has control over the default option. I think Hiram does too, he just a read a little too fast. His thoughts are clear though. On Jun 14, 2006, at 3:55 PM, Hiram Chirino wrote: All I'm saying is I don't care if IBM puts up http://www.ibm.com/wasce/plugins, I also don't care if you put up a http://virtuas.com/geronimo/plugins site. Now the default link issue is something else. Can we point it by default at some Apache machines by default? I'm sure Aaron would not mind, would you? That pretty much sums it up for me. Aaron seems to agree. In fact, is there anyone out there who doesn't agree? -David
[jira] Created: (GERONIMO-2137) Empty datasource tracefile causes fatal error attempting to run web app
Empty datasource tracefile causes fatal error attempting to run web app --- Key: GERONIMO-2137 URL: http://issues.apache.org/jira/browse/GERONIMO-2137 Project: Geronimo Type: Bug Security: public (Regular issues) Components: databases Versions: 1.0 Environment: Issue was found on Windows, but unsure if it is limited to Windows server 2003. Reporter: Tim Pickett If you deploy a web applicaiton with a datasource(db2 in this instance) and do not specify a tracefile, the application will run fine. Once you use the admin console to change an attribute in the datasource, the application server will add an empty tracefile attribute to the config.xml, and you will no longer be able to run the web application if it attempt so access the database. (Issue was found in CE) WORKAROUND: remove the 2 attributes from the config.xml and it will work fine, no attempt to trace occurs. The attributes added are: attribute name=TraceFile/attribute attribute name=TraceFileAppendfalse/attribute The entire section of the config.xml file for the datasource is as follows: configuration name=Trade gbean name=geronimo.server:J2EEApplication=Trade,J2EEServer=geronimo,JCAResource=TradeDataSource,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource attribute name=DatabaseNametradev/attribute attribute name=Usertrade/attribute attribute name=DriverType4/attribute attribute name=Password{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwECL7hrKO7YATsIUlVrzQ9VxwdAADQUVT/attribute attribute name=PortNumber5/attribute attribute name=ServerNameviper22/attribute attribute name=TraceFile/attribute attribute name=TraceFileAppendfalse/attribute /gbean gbean name=geronimo.server:J2EEApplication=Trade,J2EEServer=geronimo,JCAResource=TradeDataSource,j2eeType=JCAConnectionManager,name=jdbc/TradeDataSource attribute name=partitionMinSize0/attribute attribute name=partitionMaxSize40/attribute attribute name=blockingTimeoutMilliseconds5000/attribute attribute name=idleTimeoutMinutes30/attribute /gbean /configuration Stack trace follows: {\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}} {\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\f0\fs20 com.ibm.db2.jcc.a.SqlException: Unable to open file\par at com.ibm.db2.jcc.a.xd.a(xd.java:93)\par at com.ibm.db2.jcc.DB2BaseDataSource.computePrintWriter(DB2BaseDataSourc\par e.java:1955)\par at com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriter(DB2BaseDataSour\par ce.java:1848)\par at com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriterForNewConnection\par (DB2BaseDataSource.java:1808)\par at com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriterForNewConnection\par (DB2BaseDataSource.java:1768)\par at com.ibm.db2.jcc.DB2XADataSource.getXAConnection(DB2XADataSource.java:\par 62)\par at org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnecti\par on(AbstractXADataSourceMCF.java:74)\par at org.tranql.connector.db2.XAMCF.createManagedConnection(XAMCF.java:57)\par \par at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo\par nnection(MCFConnectionInterceptor.java:41)\par at org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor\par .getConnection(XAResourceInsertionInterceptor.java:41)\par at org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto\par r.internalGetConnection(SinglePoolConnectionInterceptor.java:63)\par at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn\par terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:73)\par at org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto\par r.getConnection(TransactionEnlistingInterceptor.java:47)\par at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.\par getConnection(TransactionCachingInterceptor.java:86)\par at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge\par tConnection(ConnectionHandleInterceptor.java:43)\par at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(\par TCCLInterceptor.java:39)\par at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.\par getConnection(ConnectionTrackingInterceptor.java:66)\par at org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo\par cateConnection(AbstractConnectionManager.java:57)\par at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56\par )\par at
[jira] Created: (XBEAN-21) org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work
org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work --- Key: XBEAN-21 URL: http://issues.apache.org/jira/browse/XBEAN-21 Project: XBean Type: Bug Components: spring Versions: 2.4 Reporter: Guillaume Nodet Assigned to: Guillaume Nodet Fix For: 2.5 -- 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: Do we need a Plugin Repo at the ASF ?
Aaron, I'd also like to help maintain the geronimoplugins website and work on providing patches to enable building all of the samples and configurations needed to upgrade a minimal-server to a full J2EE server. -Donald Matt Hogstrom wrote: Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: If others feel that it needs to be at Apache *AND* are willing to set it up then this is the time to speak up. If 'it' is singular, then having 'it' hosted at Apache means only Apache-licensed plugins can go into it. No GPL or LGPL or others.. Based on that I think sticking with 'it' being geronimoplugins.com (although .org might be/have been better) makes sense. When the Geronimo project has a significant number -- like, say, a dozen or so -- then having an ASF repo for them might be worth revisiting. I'm of the same mind that we don't have enough content to warrant the churn to create the resources at Apache now. I think there are lots of good ideas but Aaron did create the code and make it work so I'll give him credit for that effort. The point of this thread is to identify people that want to work on the plugin repo at Apache and I don't think we've found them yet :) For now let's stick with geronimoplugins.com -- but make sure the code can handle a *list* of repositories. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRJKE0ZrNPMCpn3XdAQJnzwP/SaS+1r994T8VJ6VvGD+deCod/GCZs8b5 +6MfKXvjgPqg6dRPKfvrGn8UblnhT0WL+/0kZH1+230/fWmM5ngMLCIS3c/cxvmP 8M53v2UD6JPtLfyos6wgOc9bLe5JKGSbqRJms8TAIXBiX+csjC1huHqfitRyvgp/ DdtgCZFEIzw= =01nm -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)
+1 great idea Paul. Paul McMahan wrote: There's an interesting plugin site for eclipse at eclipseplugincentral.com that implements some of the ideas we have discussed. It provides a directory of plugins but not the actual files themselves, pointing elsewhere for the purchase/download. It also provides a rating system, news page, and discussion forums. IMHO the geronimo project should strive to provide this type of site for building a healthy commercial and open source community around geronimo plugins. The domain names geronimoplugincentral.com and geronimoplugincentral.org were available and match the form used by eclipseplugincentral.com so I purchased them and would like to donate them to the ASF. How can I do that? Just send a note to [EMAIL PROTECTED] Best wishes, Paul On 6/14/06, David Blevins [EMAIL PROTECTED] wrote: Everyone, please read and ACK. On Jun 14, 2006, at 4:31 PM, John Sisson wrote: Hiram, I care if a private or commercial entity has control over the default option. I think Hiram does too, he just a read a little too fast. His thoughts are clear though. On Jun 14, 2006, at 3:55 PM, Hiram Chirino wrote: All I'm saying is I don't care if IBM puts up http://www.ibm.com/wasce/plugins, I also don't care if you put up a http://virtuas.com/geronimo/plugins site. Now the default link issue is something else. Can we point it by default at some Apache machines by default? I'm sure Aaron would not mind, would you? That pretty much sums it up for me. Aaron seems to agree. In fact, is there anyone out there who doesn't agree? -David
Re: [VOTE] 1.1 Release
John Sisson wrote: Some notes in relation to documentation: * Clicking on the the Geronimo Documentation link on http://myhost:8080/ takes me to http://geronimo.apache.org/documentation.html which doesn't currently have any 1.1 documentation. What are the plans for the 1.1 documentation? I'm planning to update the web site today so it will point to the new cwiki with the 1.0 and 1.1 (inprogress) documentation * Clicking on the Additional Documentation link on http://myhost:8080/ takes me to http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Home which contains a warning that the documentation has moved to http://cwiki.apache.org/geronimo . Are we planning on changing this to take users directly to http://cwiki.apache.org/geronimo ? Additional Documentation is using a redirect (http://geronimo.apache.org/redirects/additionalDocumentation.html) to point to the Atlassian confluence. Fixing this redirect is part of the web site update. I just froze (for edit) the confluence installation at Atlassian so we will not have more adds there (wanted or unwanted). I've been adding labels to some pages on that installation to point to the new cwiki.apache.org/geronimo. As far as I know, we can not add an automatic redirect directly from a confluence page. Cheers! Hernan Other comments in-line below.. I'm still kicking the tires.. John Matt Hogstrom wrote: All, I have created what I hope is the final release of Geronimo 1.1. There has been a lot of work that has gone into this release (please review the RELEASE-NOTES). Here are the final release candidates for your review. *DayTrader Application* http://people.apache.org/~hogstrom/1.1-final/daytrader-ear-1.1.ear I'm working on a website and documentation to help folks out but the deliverable is the ear above. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.zip *Geronimo 1.1 Source Code* FYI (in case you re-use this mail) the line above should read *Geronimo 1.1 Specs* http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.tar.gz http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.zip Is there are reason why the specs distributions don't have a version in their file name? Shouldn't it be 1.0.1? Please remember that only PMC votes are binding but they will ultimately make their decision based on your feedback. Thanks to everyone who has spent long hours working on this. A special thanks to Jencks, Sisson and Miller who spent long days working on getting the final release right with License issues, last minute release note changes, etc. I look forward to a positive outcome and a unanimous vote by Sunday. Assuming all goes well by Sunday night I will propogate the jars to the mirrors on Sunday and declare the release official on Tuesday. Cross your fingers, grab your beverage of choice and let's close this release out. Matt
RE: [jira] Commented: (GERONIMO-1046) ORA-00920 SQL Exception thrown when testing day trader with Oracle
Matt, What do you mean by plans you corrected? And by select for update we need to be able to specify? Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 5:48 AM To: dev@geronimo.apache.org Subject: Re: [jira] Commented: (GERONIMO-1046) ORA-00920 SQL Exception thrown when testing day trader with Oracle Thanks Vasily, I have corrected the plans. How are the plans going for Oracle? I think that we need to be able to specify select for update to achieve the right consistency level for SPECj2004. Curious what your feedback is. Vasily Zakharov (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1046?page=comments#action_ 12416551 ] Vasily Zakharov commented on GERONIMO-1046: --- There's a typo in this bug's resolution - the package name for ejb-ql-compiler-factory is org.tranql.ejbQLcompiler. So the right line would be: ejb-ql-compiler-factoryorg.tranql.ejbqlcompiler.OracleEJBQLCompilerFac tory/ejb-ql-compiler-factory ORA-00920 SQL Exception thrown when testing day trader with Oracle -- Key: GERONIMO-1046 URL: http://issues.apache.org/jira/browse/GERONIMO-1046 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.0 Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0 The following exception occurs when running day trader with Oracle: 15:54:36,575 WARN [/trade] /trade/app: java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.ja va(Compiled Code)) at org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$c46b8cb8.login(gen erated) at org.apache.geronimo.samples.daytrader.TradeAction.login(TradeAction.java :421) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(Tra deServletAction.java:341) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(Tr adeAppServlet.java:124) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAp pServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.j ava:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:830) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(Ord ersAlertFilter.java:84) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:821) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: javax.transaction.SystemException: Unable to commit container transac tion at org.apache.geronimo.transaction.context.InheritableTransactionContext .rollbackAndThrow(InheritableTransactionContext.java:327) at org.apache.geronimo.transaction.context.InheritableTransactionContext .complete(InheritableTransactionContext.java(Compiled Code)) at org.apache.geronimo.transaction.context.InheritableTransactionContext .commit(InheritableTransactionContext.java(Compiled Code)) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPo licy.java(Compiled Code)) at org.openejb.transaction.TransactionContextInterceptor.invoke(Transact ionContextInterceptor.java(Compiled Code)) at
Re: Do we need a Plugin Repo at the ASF ?
On 6/19/06, Donald Woods [EMAIL PROTECTED] wrote: Aaron, I'd also like to help maintain the geronimoplugins website and work on providing patches to enable building all of the samples and configurations needed to upgrade a minimal-server to a full J2EE server. OK. I've actually got a tool now to generate the web site from the set of available plugins, so the web site maintenance is less onerous. So in the short term, it would be great to work on getting the upgrade plugin together. Basically, you need to: - create a geronimo-plugin.xml with a name and description and stuff but no module ID (you can refer to the plugins-1.1.xsd schema) - add all the needed CARs (the ones in the J2EE server but not the minimal server) as dependencies - list the unavailable module builders as obsoletes To try this out, the easiest way will be to put it in an otherwise empty JAR at META-INF/geronimo-plugin.xml and then try installing that JAR using the command-line deploy tool (deployer install-plugin yourfile.jar). Let me know how you make out. Once this is working, we should create plugin metadata files for many of the CARs on the list, which will let us install the appropriate settings into config.xml (ports and so on), as well as copying any needed files into var/* or whatever. I don't think this is super-critical (many of the important files and settings will be there already), but it will be nice to have. We should also probably create JMS+Derby and EJB+Derby upgrade packages in case people don't want to do the full Minimal-J2EE upgrade. Thanks, Aaron Matt Hogstrom wrote: Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: If others feel that it needs to be at Apache *AND* are willing to set it up then this is the time to speak up. If 'it' is singular, then having 'it' hosted at Apache means only Apache-licensed plugins can go into it. No GPL or LGPL or others.. Based on that I think sticking with 'it' being geronimoplugins.com (although .org might be/have been better) makes sense. When the Geronimo project has a significant number -- like, say, a dozen or so -- then having an ASF repo for them might be worth revisiting. I'm of the same mind that we don't have enough content to warrant the churn to create the resources at Apache now. I think there are lots of good ideas but Aaron did create the code and make it work so I'll give him credit for that effort. The point of this thread is to identify people that want to work on the plugin repo at Apache and I don't think we've found them yet :) For now let's stick with geronimoplugins.com -- but make sure the code can handle a *list* of repositories. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRJKE0ZrNPMCpn3XdAQJnzwP/SaS+1r994T8VJ6VvGD+deCod/GCZs8b5 +6MfKXvjgPqg6dRPKfvrGn8UblnhT0WL+/0kZH1+230/fWmM5ngMLCIS3c/cxvmP 8M53v2UD6JPtLfyos6wgOc9bLe5JKGSbqRJms8TAIXBiX+csjC1huHqfitRyvgp/ DdtgCZFEIzw= =01nm -END PGP SIGNATURE-
Re: Request change to RTC Process
On 6/17/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't consider this valid, either. If you have the time to be a committer, you have the time to be part of the community and collaborate with your peers on the project. One thing about RTC is that it tends to promote interaction, since people are dependent on each other and the occasional quid pro quo -- unlike the everyone haring off in his own direction with no-one else watching that can occur (and has occurred) under CTR. No-one says you have to test *anyone* else's patches. Unless, of course, you hope they'll test *yours*, which is where the collaboration-for-the-project aspect comes in. So if you don't find time to test someone else's code, regardless of for whom he may work, don't expect him to spend a lot of time testing *yours*. True. But this quid pro quo holds good only for code submitted by committers. Consider the case of active contributors who are non-committers. If they choose to work on JIRAs in the wish list, it will be quite a herculean task for them to get a sign-off from 3 committers. The you scratch my back, I'll scratch yours convenience is not available for non-committers. Going by this thread, if the committers of the project are apprehensive about the RTC model and are requesting changes, then contributors have an even tougher task cut out for them. I hope that doesn't sent a message to the community that only patches from committers have any chance of getting in. I hope that doesn't de-moralize the non-committers and turn them away from the project. The RTC is not entirely bad either. It is a good thing to happen to the project but not in it's present form. What would be good for Geronimo would be take the best of RTC and CTR. Here's something to think about - 1) Bug fixes (esp. blockers) shouldn't need a review. 2) Improvements need atleast ONE +1 vote by a commiter. RTC turns into CTR after 15 days. A reminder message to be sent 3 days before the model changes to CTR. 3) Features need THREE +1 votes by other committers. RTC turns into CTR after 30 days. A reminder message to be sent 7 days before the model changes to CTR Just a suggestion. Cheers Prasad. - -- #kenP-|} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao 38KzZSDD1WM= =M+w0 -END PGP SIGNATURE-
[jira] Reopened: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ] Hiram Chirino reopened AMQ-732: --- ah.. just noticed that 4.0.1 did not build a new activeio and ship with the new version. I guess this will make it into 4.0.2 then. Infinite recovery loop. --- Key: AMQ-732 URL: https://issues.apache.org/activemq/browse/AMQ-732 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: Linux RHEL 3 Reporter: Maxim Fateev Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz The simplest way to reproduce the problem: 1. Remove storage directory. 2. Start broker using the following code: public static void main(String[] args) throws Exception { BrokerService broker = new BrokerService(); broker.setPersistent(true); DefaultPersistenceAdapterFactory pFactory = new DefaultPersistenceAdapterFactory(); pFactory.setJournalLogFiles(1); pFactory.setJournalLogFileSize(2048); broker.setPersistenceFactory(pFactory); broker.setUseJmx(false); broker.addConnector(tcp://localhost:61616); broker.start(); Thread.sleep(1l); } 3. Shutdown the broker. 4. Start broker. It enters infinite loop [ main] BrokerService INFO ActiveMQ null JMS Message Broker (localhost) is starting [ main] BrokerService INFO For help or more information please see: http://incubator.apache.org/activemq/ [ main] JDBCPersistenceAdapter INFO Database driver recognized: [apache_derby_embedded_jdbc_driver] [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) [ main] DefaultJDBCAdapter DEBUG Could not create JDBC tables; The message table already existed. Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 2 [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS (MSGID_PROD,MSGID_SEQ) [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER) [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION) [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) [ main] DefaultJDBCAdapter DEBUG Could not create JDBC tables; The message table already existed. Failure was: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 2 [ main] JDBCPersistenceAdapter DEBUG Cleaning up old messages. [ main] DefaultJDBCAdapter DEBUG Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER) [ main] DefaultJDBCAdapter DEBUG Deleted 0 old message(s). [ main] JDBCPersistenceAdapter DEBUG Cleanup done. [ main] JournalPersistenceAdapter INFO Journal Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at: /workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal [ main] JournalPersistenceAdapter DEBUG TRACE Entry: RECOVERED [Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=53 [Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=97 [Journal Writer] LogFileManager DEBUG
[jira] Updated: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ] Hiram Chirino updated AMQ-732: -- Fix Version: 4.0.2 (was: 4.0.1) Infinite recovery loop. --- Key: AMQ-732 URL: https://issues.apache.org/activemq/browse/AMQ-732 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Environment: Linux RHEL 3 Reporter: Maxim Fateev Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz The simplest way to reproduce the problem: 1. Remove storage directory. 2. Start broker using the following code: public static void main(String[] args) throws Exception { BrokerService broker = new BrokerService(); broker.setPersistent(true); DefaultPersistenceAdapterFactory pFactory = new DefaultPersistenceAdapterFactory(); pFactory.setJournalLogFiles(1); pFactory.setJournalLogFileSize(2048); broker.setPersistenceFactory(pFactory); broker.setUseJmx(false); broker.addConnector(tcp://localhost:61616); broker.start(); Thread.sleep(1l); } 3. Shutdown the broker. 4. Start broker. It enters infinite loop [ main] BrokerService INFO ActiveMQ null JMS Message Broker (localhost) is starting [ main] BrokerService INFO For help or more information please see: http://incubator.apache.org/activemq/ [ main] JDBCPersistenceAdapter INFO Database driver recognized: [apache_derby_embedded_jdbc_driver] [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) [ main] DefaultJDBCAdapter DEBUG Could not create JDBC tables; The message table already existed. Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 2 [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS (MSGID_PROD,MSGID_SEQ) [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER) [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION) [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) [ main] DefaultJDBCAdapter DEBUG Could not create JDBC tables; The message table already existed. Failure was: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 2 [ main] JDBCPersistenceAdapter DEBUG Cleaning up old messages. [ main] DefaultJDBCAdapter DEBUG Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER) [ main] DefaultJDBCAdapter DEBUG Deleted 0 old message(s). [ main] JDBCPersistenceAdapter DEBUG Cleanup done. [ main] JournalPersistenceAdapter INFO Journal Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at: /workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal [ main] JournalPersistenceAdapter DEBUG TRACE Entry: RECOVERED [Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=53 [Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=97 [Journal Writer] LogFileManager DEBUG getNextDataRecordLocation overflowing into next logFile=0 [
Fwd: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)
Forwarding request to infra@ list. -- Forwarded message -- From: Paul McMahan [EMAIL PROTECTED] Date: Jun 19, 2006 8:51 AM Subject: Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager) To: dev@geronimo.apache.org There's an interesting plugin site for eclipse at eclipseplugincentral.com that implements some of the ideas we have discussed. It provides a directory of plugins but not the actual files themselves, pointing elsewhere for the purchase/download. It also provides a rating system, news page, and discussion forums. IMHO the geronimo project should strive to provide this type of site for building a healthy commercial and open source community around geronimo plugins. The domain names geronimoplugincentral.com and geronimoplugincentral.org were available and match the form used by eclipseplugincentral.com so I purchased them and would like to donate them to the ASF. How can I do that? Just send a note to [EMAIL PROTECTED] -- 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/
[Fwd: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote]
I originally sent this note about 3 hours ago. Not sure where the bottleneck is so I'm trying again. Apologies if there are duplicates. Original Message Subject: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote Date: Mon, 19 Jun 2006 11:33:31 -0400 From: Matt Hogstrom [EMAIL PROTECTED] To: dev@geronimo.apache.org, [EMAIL PROTECTED], user@geronimo.apache.org Here are the latest binaries built from http://svn.apache.org/repos/asf/geronimo/branches/1.1.0, http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0. I believe this will start a new vote for this binary. All issues that I'm aware of have been addressed that needed to be for this release. RELEASE-NOTES-1.1.txt were updated with issues that will be addressed in 1.1.1. *Previous Votes are invalidated...please re-vote* The console has been updated to reflect issues related to bad links. Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE and NOTICES files are included in the builds. DayTrader sources are included with updated README to instruct the user how to build and install DayTrader on Geronimo. Please cast your votes and remember that only PMC member votes are binding. However, I am confident that commiter votes will help to inform the PMC of the quality of this release candidate. Thanks to all that have been checking this out. John Sisson especially has been burning the midnight oil and finding the remaining issues that have helped to improve the quality of this release. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear Note: to build Geronimo the above ear needs to be placed into your repo as $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Hi, On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote: Working copies of versions in branches would be branches/n.n. This would be the effective trunk for any version work. Does this mean that someone will be re-creating a branches/1.1 branch? There used to be one, and it looks as if there isn't one now. Otherwise I can do a new checkout of the 1.1.1 branch but if there's going to be a 1.1 branch I think I'd rather track it than a specific release branch. Thanks, Toby
Web site update
Hi All, I'm a bit lost with the two branches we have now to manage the web site. I have the .../site/branches/may2006 branch updated and ready to go live, it already includes that last two changes (updated events and added book to documentation). What would be the next step? replacing the content of .../site/trunk and then commit to the live site from the updated trunk? how do I replace it the content in .../site/trunk with the may2006 branch? Thanks Cheers! Hernan
[jira] Created: (GERONIMO-2138) Configuration jsp-examples-tomcat includes Jetty dependencies
Configuration jsp-examples-tomcat includes Jetty dependencies - Key: GERONIMO-2138 URL: http://issues.apache.org/jira/browse/GERONIMO-2138 Project: Geronimo Type: Bug Security: public (Regular issues) Components: sample apps Versions: 1.1 Environment: Geronimo 1.1.0 RC2 Reporter: Donald Woods Assigned to: Donald Woods Priority: Trivial Fix For: 1.1.1 Will attach a patch to remove the following build dependencies - jetty-deployer-1.1.car geronimo-jetty-1.1.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 : Build Instruction
On 6/19/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I was looking for a suitable place to add the build instrucitons for M2. I could not find any section dealing with the trunk at http://cwiki.apache.org/geronimo/ Pick your favorite name and propose it. Send a note to dev and await comments. Upon having received some, go and create it. What about 'Apache Geronimo Build using Apache Maven 2' ? Anita Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Wiki based FAQ
On 6/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I put together a FAQ in the sandbox on the cwiki. I seeded it with content from the main wiki on the Geronimo website and with some content from a resent email I sent about accessing an MBean server from a GBean. This is just an idea, and I will have no hard feelings if we decide to delete it (it only took 20 minutes to get going). http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ What do you think? The more places one can contribute the better. Documentation is always a big PITA for open source projects so I don't worry about its existence. It will survive, esp. now when editing is so easy to do. I wonder why the name is so...well...different? How was it chosen? +1 -dain Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (AMQ-761) ActiveMQConnectionFactory.setBrokerURL does not set all connection properties corrrectly
ActiveMQConnectionFactory.setBrokerURL does not set all connection properties corrrectly Key: AMQ-761 URL: https://issues.apache.org/activemq/browse/AMQ-761 Project: ActiveMQ Type: Bug Components: JMS client Versions: 3.2.2 Environment: Windows XP, Java 1.4.1 Reporter: Jim Beattie Attachments: UrlSetterTest.java If I set the brokerUrl of ActiveMQConnectionFactory using setBrokerURL(), the connection factory does not reparse all of the properties from the URL. As a result, when a new connection is created, some of the properties from the URL specified during the construction of the connection factory (typically the defaults) are used instead. Attached is a unit test to demonstrate the problem. As a minimum, the following block of code is required in setBrokerURL(). But this doesn't really fix it because properties settings from the URL used by the constructor may not be reset by this code. A structural change may be in order (e.g. just-in-time parsing of the properties). if( brokerURL.indexOf(?)= 0 ) { String options = brokerURL.substring(brokerURL.indexOf(?)+1); Map properties = URIHelper.parseQuery(options); if (!properties.isEmpty()) { BeanUtils.populate(this, properties); } -- 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: [Fwd: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote]
+1 from me. Thanks, dims PS: Please don't cc a closed list. On 6/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I originally sent this note about 3 hours ago. Not sure where the bottleneck is so I'm trying again. Apologies if there are duplicates. Original Message Subject: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote Date: Mon, 19 Jun 2006 11:33:31 -0400 From: Matt Hogstrom [EMAIL PROTECTED] To: dev@geronimo.apache.org, [EMAIL PROTECTED], user@geronimo.apache.org Here are the latest binaries built from http://svn.apache.org/repos/asf/geronimo/branches/1.1.0, http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0. I believe this will start a new vote for this binary. All issues that I'm aware of have been addressed that needed to be for this release. RELEASE-NOTES-1.1.txt were updated with issues that will be addressed in 1.1.1. *Previous Votes are invalidated...please re-vote* The console has been updated to reflect issues related to bad links. Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE and NOTICES files are included in the builds. DayTrader sources are included with updated README to instruct the user how to build and install DayTrader on Geronimo. Please cast your votes and remember that only PMC member votes are binding. However, I am confident that commiter votes will help to inform the PMC of the quality of this release candidate. Thanks to all that have been checking this out. John Sisson especially has been burning the midnight oil and finding the remaining issues that have helped to improve the quality of this release. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear Note: to build Geronimo the above ear needs to be placed into your repo as $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Commented: (AMQ-721) Openwire client hangs after receiving 999 messages
[ https://issues.apache.org/activemq/browse/AMQ-721?page=comments#action_36430 ] James Stanton commented on AMQ-721: --- I also had the same problem, but I was able to put together a hack that gets around this problem. I don't recommend this as the solution going forward, but it appears to work on my test cases (which failed before I implemented it). First we need to change the dotNet dll client classes. in class IMessageConsumer, add a new function: IMessage AutoAcknowledge(IMessage message); in class MessageConsumer, make AutoAcknowledge public rather then protected. Then, create your dll. Now, in your test app do the following: Let's assume you've created a consumer called consumer and have defined the following: consumer.Listener += new MessageListener(onMessage); set up the listener function as follows: public void onMessage(IMessage message) { If (consumer != null) //just a good idea to check consumer.AutoAcknowledge(message); // whatever you want to do with your message goes here... I've just put a Console.WriteLine here, but do whatever you want here Console.WriteLine(got Message: + ((ActiveMQTextMessage)message).Text); } This isn't an ideal solution, because it requires the MessageListener to call AutoAcknowledge, but it seems to work. I hope this helps folks who are trying to do this! Jamie Openwire client hangs after receiving 999 messages -- Key: AMQ-721 URL: https://issues.apache.org/activemq/browse/AMQ-721 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: .NET 2.0 ,C# + trunk Reporter: vincent boilay Priority: Blocker Openwire client hangs after receiving 999 messages changing Session.Prefetch postpone the problem... Current code is : public class Session : ISession { : : private int prefetchSize = 1000; this block at message #999 changing private int prefetchSize = 2000 == blocks at message #1999 -- 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-721) Openwire client hangs after receiving 999 messages
[ https://issues.apache.org/activemq/browse/AMQ-721?page=comments#action_36431 ] James Stanton commented on AMQ-721: --- Oh, sorry, one more thing. Make sure you're connecting with tcp://localhost:61616?jms.optimizeAcknowledge=false (the jms.optimizeAcknowledge=false being the important part of that, at least until 4.0.1 is out which defaults to this) Openwire client hangs after receiving 999 messages -- Key: AMQ-721 URL: https://issues.apache.org/activemq/browse/AMQ-721 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: .NET 2.0 ,C# + trunk Reporter: vincent boilay Priority: Blocker Openwire client hangs after receiving 999 messages changing Session.Prefetch postpone the problem... Current code is : public class Session : ISession { : : private int prefetchSize = 1000; this block at message #999 changing private int prefetchSize = 2000 == blocks at message #1999 -- 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: Wiki based FAQ
Jacek Laskowski wrote: On 6/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I put together a FAQ in the sandbox on the cwiki. I seeded it with content from the main wiki on the Geronimo website and with some content from a resent email I sent about accessing an MBean server from a GBean. This is just an idea, and I will have no hard feelings if we decide to delete it (it only took 20 minutes to get going). http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ What do you think? The more places one can contribute the better. Documentation is always a big PITA for open source projects so I don't worry about its existence. It will survive, esp. now when editing is so easy to do. I wonder why the name is so...well...different? How was it chosen? cwiki.apache.org was decided with the infraestructure folks. Dain included the direct link to confluence but we now have an customized HTML version that gets updated automatically everytime a page is edited. So, to access the wiki you should just typen cwiki.apache.org/geronimo Does that answer your question about the name? Cheers! Hernan +1 -dain Jacek
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Done. On Jun 19, 2006, at 11:36 AM, toby cabot wrote: Hi, On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote: Working copies of versions in branches would be branches/n.n. This would be the effective trunk for any version work. Does this mean that someone will be re-creating a branches/1.1 branch? There used to be one, and it looks as if there isn't one now. Otherwise I can do a new checkout of the 1.1.1 branch but if there's going to be a 1.1 branch I think I'd rather track it than a specific release branch. Thanks, Toby
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Hi David, Done. Thanks! Toby
Re: Wiki based FAQ
On Jun 19, 2006, at 2:27 PM, Hernan Cunico wrote: Jacek Laskowski wrote: On 6/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I put together a FAQ in the sandbox on the cwiki. I seeded it with content from the main wiki on the Geronimo website and with some content from a resent email I sent about accessing an MBean server from a GBean. This is just an idea, and I will have no hard feelings if we decide to delete it (it only took 20 minutes to get going). http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ What do you think? The more places one can contribute the better. Documentation is always a big PITA for open source projects so I don't worry about its existence. It will survive, esp. now when editing is so easy to do. I wonder why the name is so...well...different? How was it chosen? cwiki.apache.org was decided with the infraestructure folks. Dain included the direct link to confluence but we now have an customized HTML version that gets updated automatically everytime a page is edited. So, to access the wiki you should just typen cwiki.apache.org/geronimo Duh :) I forgot about the exporting. You can find the page directly here: http://cwiki.apache.org/GMOxSBOX/faq.html -dain
Ported gbuild space to cwiki
Hey all, I ported the GBuild space over to cwiki and updated it slightly. http://cwiki.apache.org/gbuild/ Next, I'd like to get a Subprojects box in addition to our tab that lists GBuild and links directly to the site above. Love that Geronimo template in cwiki! -David
Re: Web site update
On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote: Hi All, I'm a bit lost with the two branches we have now to manage the web site. I have the .../site/branches/may2006 branch updated and ready to go live, it already includes that last two changes (updated events and added book to documentation). What would be the next step? replacing the content of .../site/ trunk and then commit to the live site from the updated trunk? how do I replace it the content in .../site/trunk with the may2006 branch? Typically, you'd merge over your changes. Could use the 'svn merge' command. Or you could create a patch file and apply it to trunk. I like to use the graphical diff tool in Visual SlickEdit, but that's not free. -David
Re: Request change to RTC Process
I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side benefit. My understanding was that RTC was enforce to improve community collaboration and communication. Clearly its not working very well based on the comments in this thread. Seems to be going the opposite way. Clearly the opinion of some on the thread is they trust each other and communication has already been fine so this is just slowing them down? Is that the summary? I'd have to disagree that things have been fine although I'll concede that perhaps some changes to RTC may be warranted. I'm sitting in an airport right now so I don't have time to do this but it might be nice if someone can compile some statistics on what has actually transpired and then we can discuss why this isn't working and then make some recommendations as to how to move forward rather than the current dialogue which doesn't seem to be improving collaboration and communication but is actually driving polarization (which I think we're trying to avoid). Hiram Chirino wrote: On 6/17/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: RTC means tested quality, not assumed quality. If you can't find people to test the quality of something, it doesn't go in because the quality isn't assured. I'm not sure where 'quality' requirement is coming from. I don't think it's ever been discussed on the list. For example, I don't remember a discussion of should we focus on stabilizing and in effect slowing down the development of Geronimo. Or should it focus on implementing the J2EE features that it's missing as quickly as possible? I can see how IBM would prefer the 1st option since it would allow it's chimerical offerings to stay differentiated from Geronimo. But I don't think the rest of this community would agree. I'm having trouble understanding the above paragraph and Dain's comments in another e-mail. I proposed that we take 1.1.1 to stabilize it because there are a number of quality issues in Geronimo that make it undesireable in a production enviroment. NPEs abound and we have usability problems. Personally I think these need to be addressed to improve the adoption rate of Geronimo. I'm not aware of a lot of developers or administrators that accept a server that is 90% reliable (my made up number). If you disagree that fixing these are a waste of time then please speak up. I have other things to do then. I'm also having difficulty understanding the chimerical comment. I can only assume that you mean that WAS CE is some mythical and unachievable goal? Here is where I'm drawing my inference from: http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html Here is a quote from the above: 1. Merely imaginary; produced by or as if by a wildly fanciful imagination; fantastic; improbable or unrealistic. If WAS CE is mythical then I'm not sure what hope there is for Geronimo because it is the basis for WAS CE. If CE can't succeed then I'd say Geronimo poisoned the apple. Can you please clarify your comments Hiram because they aren't making sense to me. I'm sure you don't mean the above. - Eliminates trust. I know say, David J has a lot of experience with say, connectors, and if he puts a patch in that area, I think I can read his summary and trust that he's implemented it sensibly. But now that doesn't count, I have to review it line by line? I think it should be up to me which patches I trust and which patches want to review in detail. Considering the problems concerning trust that are already extant, I think the first sentence as a conclusion is bogus. And once again you want to *assume* quality rather than *assure* it. That's how CTR works. RTC works to *assure* it. I trust a bunch of the folks that work here and while I could review patches, unless you are working with that code ALL the time, there could be unexpected side-effects that only folks working on it all the time could catch. So I would rather than assume I know what I'm doing, I'd delegate to folks who specialize in that area of Geronimo. By way of example, if its connector or Tx code I'd trust Jencks. Perhaps the problem is that Geronimo has not attracted enough people to have more than one person interested in a specific area. I would say this is unfortunate but I agree with your trust comment in light of individual components. - Favors full-time open source developers over free-time contributors. I don't have enough time to work on the work *I* want to do in my spare time, much less get a clean tree to apply, test, and review everyone else's patches I don't consider this valid, either. If you have the time to be a committer, you have the time to be part of the community and collaborate with your peers on the project. One thing about RTC is that it tends to promote interaction, since people are dependent on each other and the occasional quid pro quo -- unlike the everyone
Re: Request change to RTC Process
On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote: I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side benefit. My understanding was that RTC was enforce to improve community collaboration and communication. Clearly its not working very well based on the comments in this thread. Seems to be going the opposite way. I'd agree with your first two statements, but I think you went a little off track in your generalization that it's not working very well and seems to be going the opposite way. I certainly don't agree. I'm very happy to see so many people say they like RTC -- I like it too -- and am encouraged to see people actually think about RTC in general and how it can benefit Geronimo best. In the eye of this beholder, these are good omens. -David
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Oh, I see. There is already a 1.1.1 branch. My bad. Sorry, going to delete the branches/1.1 and call for a vote. -David On Jun 19, 2006, at 2:54 PM, toby cabot wrote: Hi David, Done. Thanks! Toby
Re: Request change to RTC Process
On 6/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side benefit. My understanding was that RTC was enforce to improve community collaboration and communication. Clearly its not working very well based on the comments in this thread. Seems to be going the opposite way. Clearly the opinion of some on the thread is they trust each other and communication has already been fine so this is just slowing them down? Is that the summary? I'd have to disagree that things have been fine although I'll concede that perhaps some changes to RTC may be warranted. I'm sitting in an airport right now so I don't have time to do this but it might be nice if someone can compile some statistics on what has actually transpired and then we can discuss why this isn't working and then make some recommendations as to how to move forward rather than the current dialogue which doesn't seem to be improving collaboration and communication but is actually driving polarization (which I think we're trying to avoid). Hiram Chirino wrote: On 6/17/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: RTC means tested quality, not assumed quality. If you can't find people to test the quality of something, it doesn't go in because the quality isn't assured. I'm not sure where 'quality' requirement is coming from. I don't think it's ever been discussed on the list. For example, I don't remember a discussion of should we focus on stabilizing and in effect slowing down the development of Geronimo. Or should it focus on implementing the J2EE features that it's missing as quickly as possible? I can see how IBM would prefer the 1st option since it would allow it's chimerical offerings to stay differentiated from Geronimo. But I don't think the rest of this community would agree. I'm having trouble understanding the above paragraph and Dain's comments in another e-mail. I proposed that we take 1.1.1 to stabilize it because there are a number of quality issues in Geronimo that make it undesireable in a production enviroment. NPEs abound and we have usability problems. Personally I think these need to be addressed to improve the adoption rate of Geronimo. I'm not aware of a lot of developers or administrators that accept a server that is 90% reliable (my made up number). If you disagree that fixing these are a waste of time then please speak up. I have other things to do then. I think that's great! and I hope a 1.1.2 rolls out soon too and that the 1.1 branch keeps stabilizing at a good pace. I'm also having difficulty understanding the chimerical comment. I can only assume that you mean that WAS CE is some mythical and unachievable goal? Here is where I'm drawing my inference from: http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html Here is a quote from the above: 1. Merely imaginary; produced by or as if by a wildly fanciful imagination; fantastic; improbable or unrealistic. If WAS CE is mythical then I'm not sure what hope there is for Geronimo because it is the basis for WAS CE. If CE can't succeed then I'd say Geronimo poisoned the apple. Can you please clarify your comments Hiram because they aren't making sense to me. I'm sure you don't mean the above. lol.. that's why you can't trust spell checkers! replace chimerical with commercial! I was more referring to WAS compared to WASCE and it staying highly differentiated because RTC could stifle geronimo's innovation. - Eliminates trust. I know say, David J has a lot of experience with say, connectors, and if he puts a patch in that area, I think I can read his summary and trust that he's implemented it sensibly. But now that doesn't count, I have to review it line by line? I think it should be up to me which patches I trust and which patches want to review in detail. Considering the problems concerning trust that are already extant, I think the first sentence as a conclusion is bogus. And once again you want to *assume* quality rather than *assure* it. That's how CTR works. RTC works to *assure* it. I trust a bunch of the folks that work here and while I could review patches, unless you are working with that code ALL the time, there could be unexpected side-effects that only folks working on it all the time could catch. So I would rather than assume I know what I'm doing, I'd delegate to folks who specialize in that area of Geronimo. By way of example, if its connector or Tx code I'd trust Jencks. Perhaps the problem is that Geronimo has not attracted enough people to have more than one person interested in a specific area. I would say this is unfortunate but I agree with your trust comment in light of individual components. - Favors full-time open source developers over free-time contributors. I don't have enough time to work on the work *I* want to do in my spare time,
Re: Request change to RTC Process
On 6/19/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote: Clearly the opinion of some on the thread is they trust each other and communication has already been fine so this is just slowing them down? Is that the summary? I'd have to disagree that things have been fine although I'll concede that perhaps some changes to RTC may be warranted. I think that the model of reviewing is working and I like it. What I don't like is the requirement to physically apply every patch and run a full build. I feel that a careful read of the patch is good enough for trunk and tends to spur collaboration and communication that was the original intent of switching to RTC. +1 For micro releases, I taking a more conservative approach may be warranted, but I honestly don't see how applying a patch and building it is going to find more error. For example, the NPEs you pointed out are likely to only be found by testing user applications, and when we do find one a test case should be added to prevent regressions. -dain -- Regards, Hiram Blog: http://hiramchirino.com
[VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
Here are the latest binaries built from http://svn.apache.org/repos/asf/geronimo/branches/1.1.0, http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0. I believe this will start a new vote for this binary. All issues that I'm aware of have been addressed that needed to be for this release. RELEASE-NOTES-1.1.txt were updated with issues that will be addressed in 1.1.1. *Previous Votes are invalidated...please re-vote* The console has been updated to reflect issues related to bad links. Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE and NOTICES files are included in the builds. DayTrader sources are included with updated README to instruct the user how to build and install DayTrader on Geronimo. Please cast your votes and remember that only PMC member votes are binding. However, I am confident that commiter votes will help to inform the PMC of the quality of this release candidate. Thanks to all that have been checking this out. John Sisson especially has been burning the midnight oil and finding the remaining issues that have helped to improve the quality of this release. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear Note: to build Geronimo the above ear needs to be placed into your repo as $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear
Re: Wiki based FAQ
+1 I think that this is a good idea. I setup a wiki-based Knowledge Base at my previous company in Confluence and it really helped to collect and spread knowledge. For this to work in Confluence it should have its own space, like GMOxKB. It also works really well when using the {excerpt} macro to give the TOC more context, and the {scrollbar} macro to make it easier to navigate through pages in the KB. --jason On Jun 16, 2006, at 3:19 PM, Dain Sundstrom wrote: I put together a FAQ in the sandbox on the cwiki. I seeded it with content from the main wiki on the Geronimo website and with some content from a resent email I sent about accessing an MBean server from a GBean. This is just an idea, and I will have no hard feelings if we decide to delete it (it only took 20 minutes to get going). http://cwiki.apache.org/confluence/display/GMOxSBOX/FAQ What do you think? -dain
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 On Jun 19, 2006, at 8:33 AM, Matt Hogstrom wrote: Here are the latest binaries built from http://svn.apache.org/repos/asf/geronimo/branches/1.1.0, http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0. I believe this will start a new vote for this binary. All issues that I'm aware of have been addressed that needed to be for this release. RELEASE-NOTES-1.1.txt were updated with issues that will be addressed in 1.1.1. *Previous Votes are invalidated...please re-vote* The console has been updated to reflect issues related to bad links. Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE and NOTICES files are included in the builds. DayTrader sources are included with updated README to instruct the user how to build and install DayTrader on Geronimo. Please cast your votes and remember that only PMC member votes are binding. However, I am confident that commiter votes will help to inform the PMC of the quality of this release candidate. Thanks to all that have been checking this out. John Sisson especially has been burning the midnight oil and finding the remaining issues that have helped to improve the quality of this release. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1- final-2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1- final-2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs-1.1-final-2.zip *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/ daytrader_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/ daytrader_src-1.1-final-2.zip *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader- ear-1.1-final-2.ear Note: to build Geronimo the above ear needs to be placed into your repo as $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 Regards, Alan Matt Hogstrom wrote: Here are the latest binaries built from http://svn.apache.org/repos/asf/geronimo/branches/1.1.0, http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0. I believe this will start a new vote for this binary. All issues that I'm aware of have been addressed that needed to be for this release. RELEASE-NOTES-1.1.txt were updated with issues that will be addressed in 1.1.1. *Previous Votes are invalidated...please re-vote* The console has been updated to reflect issues related to bad links. Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE and NOTICES files are included in the builds. DayTrader sources are included with updated README to instruct the user how to build and install DayTrader on Geronimo. Please cast your votes and remember that only PMC member votes are binding. However, I am confident that commiter votes will help to inform the PMC of the quality of this release candidate. Thanks to all that have been checking this out. John Sisson especially has been burning the midnight oil and finding the remaining issues that have helped to improve the quality of this release. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear Note: to build Geronimo the above ear needs to be placed into your repo as $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear
[jira] Created: (GERONIMODEVTOOLS-85) Plugin does not recognize started Geronimo 1.1 Final-2
Plugin does not recognize started Geronimo 1.1 Final-2 -- Key: GERONIMODEVTOOLS-85 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-85 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Windows, Callisto RC4a. Reporter: Neal Sanche Priority: Critical I downloaded the Geronimo 1.1 final release which has the final directory structure layout, the 1.1-SNAPSHOT is now simply 1.1 everywhere in the geronimo-1.1/repository directory. I defined a new 'Server' using the wizard, and pointed it at my newly unzipped geronimo-1.1 tree. When I try to 'start' the server using the right-click menu, the plugin begins the start of the server as usual, this seems to work. Problem is that the plugin does not recognize that the server is actually started. I suspect that it may be using 1.1-SNAPSHOT somewhere to recognize when the server has started, or something similar, but that is only a hunch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-85) Plugin does not recognize started Geronimo 1.1 Final-2
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-85?page=comments#action_12416849 ] Neal Sanche commented on GERONIMODEVTOOLS-85: - To clarify a little, the plugin thinks the server has started and displays this fact about 15 seconds before the server finishes loading and displays the 'Geronimo server started' message in the console. But as soon as that happens, the plugin displays the 'Stopped' message instead of started. Plugin does not recognize started Geronimo 1.1 Final-2 -- Key: GERONIMODEVTOOLS-85 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-85 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Windows, Callisto RC4a. Reporter: Neal Sanche Priority: Critical I downloaded the Geronimo 1.1 final release which has the final directory structure layout, the 1.1-SNAPSHOT is now simply 1.1 everywhere in the geronimo-1.1/repository directory. I defined a new 'Server' using the wizard, and pointed it at my newly unzipped geronimo-1.1 tree. When I try to 'start' the server using the right-click menu, the plugin begins the start of the server as usual, this seems to work. Problem is that the plugin does not recognize that the server is actually started. I suspect that it may be using 1.1-SNAPSHOT somewhere to recognize when the server has started, or something similar, but that is only a hunch. -- 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