[jira] Resolved: (AMQ-918) Inactivity Monitor timeout does not on disconnected client does not cause blocked dispatch to client to fail.
[ https://issues.apache.org/activemq/browse/AMQ-918?page=all ] Jonas Lim resolved AMQ-918. --- Fix Version/s: 4.0.1 4.0 Resolution: Fixed fixed applied in 4.x branches and trunk (r443267) Inactivity Monitor timeout does not on disconnected client does not cause blocked dispatch to client to fail. - Key: AMQ-918 URL: https://issues.apache.org/activemq/browse/AMQ-918 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2, 4.0.1, 4.0 The cause is that inactivity timeout cause an async thread to call TransportConnection.stop() but it in turn tries to do a transport.oneway(new ShutdownInfo()); before a transport.stop(); Since another thread is currently stuck in the oneway() call (due to the client having disconnected but the OS has not thrown an IOException up to us yet), our ShutdownInfo message blocks too. So in essence the InactivityMonitor is not currently shutitng down the failed connections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-923) Add the ability to remove network connectors dynamically
Add the ability to remove network connectors dynamically Key: AMQ-923 URL: https://issues.apache.org/activemq/browse/AMQ-923 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-923) Add the ability to remove network connectors dynamically
[ https://issues.apache.org/activemq/browse/AMQ-923?page=all ] Hiram Chirino resolved AMQ-923. --- Resolution: Fixed Done in trunk rev 434068 Add the ability to remove network connectors dynamically Key: AMQ-923 URL: https://issues.apache.org/activemq/browse/AMQ-923 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-922) Add the ability to remove transport connectors dynamically
[ https://issues.apache.org/activemq/browse/AMQ-922?page=all ] Hiram Chirino updated AMQ-922: -- Summary: Add the ability to remove transport connectors dynamically (was: Add a removeConnector() to BrokerServer to remove added transport connectors.) Description: Add a removeConnector() to BrokerServer to remove added transport connectors. Add the ability to remove transport connectors dynamically --- Key: AMQ-922 URL: https://issues.apache.org/activemq/browse/AMQ-922 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 Add a removeConnector() to BrokerServer to remove added transport connectors. -- 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
how to pass a integer value as a message header in STOMP C
Hi, I am wondering how to pass a integer value to a message header property using the STOMP C. I don't find any other information about how to set a message header with a integer value in the apr hash. Thanks! Vik
[VOTE RESULT] Relase 4.1 of the ActiveMQ maven plugins
Hi folks, Thanks for taking the time to check the release. Vote passes with 6 +1's . We just need to get the incubator PMC to now approve the release. +1 Votes: Hiram Chirino Guillaume Nodet Rob Davies James Strachan Alan D. Cabrera Kevan Miller No +/- 0 or -1's -- Regards, Hiram Blog: http://hiramchirino.com
Re: how to pass a integer value as a message header in STOMP C
Hi Vik.. I don't think stomp supports it. On 9/14/06, Dhawan, Vikram (LNG-DAY) [EMAIL PROTECTED] wrote: Hi, I am wondering how to pass a integer value to a message header property using the STOMP C. I don't find any other information about how to set a message header with a integer value in the apr hash. Thanks! Vik -- Regards, Hiram Blog: http://hiramchirino.com
RE: how to pass a integer value as a message header in STOMP C
Hi Hiram, Do you know if CMS client for activemq supports it? Thanks! Vik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, September 14, 2006 12:26 PM To: activemq-dev@geronimo.apache.org Subject: Re: how to pass a integer value as a message header in STOMP C Hi Vik.. I don't think stomp supports it. On 9/14/06, Dhawan, Vikram (LNG-DAY) [EMAIL PROTECTED] wrote: Hi, I am wondering how to pass a integer value to a message header property using the STOMP C. I don't find any other information about how to set a message header with a integer value in the apr hash. Thanks! Vik -- Regards, Hiram Blog: http://hiramchirino.com
RE: how to pass a integer value as a message header in STOMP C
Do you know if CMS client for activemq supports it? We provide a properties object that you can get from a Message object. The Properties Object allows you to set string properties (string key, string value). We also provide classes like Integer that define toString() methods. Or you can just use itoa or sprintf to convert the numeric to a String, Thanks! Vik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, September 14, 2006 12:26 PM To: activemq-dev@geronimo.apache.org Subject: Re: how to pass a integer value as a message header in STOMP C Hi Vik.. I don't think stomp supports it. On 9/14/06, Dhawan, Vikram (LNG-DAY) [EMAIL PROTECTED] wrote: Hi, I am wondering how to pass a integer value to a message header property using the STOMP C. I don't find any other information about how to set a message header with a integer value in the apr hash.
[jira] Commented: (AMQ-915) Failover transport does not replay all the transaction operations on failover.
[ https://issues.apache.org/activemq/browse/AMQ-915?page=comments#action_36952 ] Hiram Chirino commented on AMQ-915: --- Applied patch to to 4.0 branch rev 443423 Failover transport does not replay all the transaction operations on failover. -- Key: AMQ-915 URL: https://issues.apache.org/activemq/browse/AMQ-915 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Adrian Co Fix For: 4.1 If transactions are being used on a connection that is using failover.. these is a small chance that the transaction will fail or the connection will fail due to a partial tx being run when the client reconnects. I will change the failover transport to buffer up all the tx operations that are run against the broker and on failure, replay those operations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [activemq-dev] Support for message priority (AMQ-122)
Is this feature going to be in activeMQ 4.2 version or was this feature existed in any of the previous releases (3.2 or any) of activeMQ ? How about specifying producer priorities and consumer priorities ? Does this exist in 4.0.1 release? From the documentation, my understanding is confused. Could you please clarify ? - Sreenivas Hiram Chirino wrote: Not at the current time. On 9/13/06, samahome [EMAIL PROTECTED] wrote: Does this mean ActiveMQ(Version 4.0.1) does not support Message priorities ? If it does support, could you please point me to some specific documentation ? Regards Sreenivas Sama Ramzi Saba wrote: Per AMQ-122, the existing ActiveMQ implementation does not support message priority. I was able to make straightforward changes to MemoryBoundedQueue to store packets in one of 10 linked lists (DefaultQueueList) based on the packet's priority. Per the JMS spec, I support priorities 0 thru 9. On dequeue, I try to consume packets from the 10 linked lists by priority. I just wanted to run this idea by you guys before I submit to SVN HEAD. Let me know if you have any concerns. Thanks. -ramzi -- View this message in context: http://www.nabble.com/-activemq-dev--Support-for-message-priority-%28AMQ-122%29-tf135416.html#a6297119 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/-activemq-dev--Support-for-message-priority-%28AMQ-122%29-tf135416.html#a6311172 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Created: (AMQ-924) Patch to make activemq-cpp compile under sun studio 11
Patch to make activemq-cpp compile under sun studio 11 -- Key: AMQ-924 URL: https://issues.apache.org/activemq/browse/AMQ-924 Project: ActiveMQ Issue Type: Improvement Components: CMS (C++ client) Environment: Sun Solaris 10 (SunOS chi-dev-chris1 5.10 Generic_118855-15 i86pc i386 i86pc Solaris) Studio 11 (Sun C++ 5.8 Patch 121018-04 2006/08/02) Reporter: Chris Knight Priority: Minor Fix For: 4.x Attachments: PATCH Fixes compilation of activemq-cpp for studio 11 C++ compiler. Mostly additions of #include string.h and added namespace qualifiers std:: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dojo Toolkit inclusion to Geronimo
Hi Jeff, Thanks for the info. Dojo is licensed under Academic Free License and BSD so I think it should be fine. The only decision now is how to include Dojo in Geronimo. A couple of suggestions were given by Gianny and Paul and everybody is definitely welcome for additional input. Best wishes, chris Jeff Genender wrote: Not from the ZPMC... Chris, if its a BSD/ASL license, it's likely fine. Jeff Christopher M. Cardona wrote: I’m sending this email to officially ask the PMC what they think about including Dojo Toolkit in Geronimo. Last month Paul already started a thread on the devlist (http://www.mail-archive.com/dev@geronimo.apache.org/msg29777.html) that discussed this idea. A couple of people replied to this thread supporting the idea but no official decision was made or the PMC wasn’t officially asked. In addition, I submitted 2 patches that utilized some Dojo widgets: 1. Add Embedded LDAP Server Viewer Portlet - http://issues.apache.org/jira/browse/GERONIMO-1823 2. Add JMX Portlet - http://issues.apache.org/jira/browse/GERONIMO-2333 FYI, here’s a summary of some basic info about Dojo: Web site: http://dojotoolkit.org/ Description: Dojo is the Open Source Javascript toolkit that makes professional web development better, easier, and faster. Latest Release: 0.3.1 (http://download.dojotoolkit.org/release-0.3.1/dojo-0.3.1-ajax.zip) License: AFL and BSD Supported Browsers: - Latest Safari (2.0.x today). - Latest Opera (8.5 today, 9.0 soon) - IE 5.5+ - Firefox 1.0+ - Latest Konqueror (3.5 today) Comments, concerns, and suggestions are welcome. Best wishes, chris
[jira] Created: (SM-578) HttpComponent can not be deployed as managed!
HttpComponent can not be deployed as managed! - Key: SM-578 URL: https://issues.apache.org/activemq/browse/SM-578 Project: ServiceMix Issue Type: Improvement Components: servicemix-http Affects Versions: incubation Environment: Windows 2000, JBoss AS 4.0.3 Reporter: Andreas Held At present, HttpComponent does not work in connection with HttpManagedServlet. On the other hand, HttpSpringComponent, which does work with HttpManagedServlet, does not allow for JBI style deployment. HttpComponent should be extended so that it can be configured as managed in an easy way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dojo Toolkit inclusion to Geronimo
Gianny, Thanks again for finding time to look at the patch. Sorry to hear that it didn’t worked out smoothly in Safari. I agree with you that we should find a better way to include/checkin Dojo in G. I decided to include the Dojo source in the patch to make it easier for people like you who want to look at it without doing additional work like downloading some distribution. Your suggestion of expanding the Dojo files upon build is fine but I think checking in Dojo as a separate module (webapp) as suggested by Paul has an advantage of being reused by other webapps deployed in G simply by making the webapp’s parent the Dojo module. Furthermore, I was able to verify that this works. I’m still open for other suggestions but if we are left with these 2 options I’ll give +1 to checking in Dojo as a separate module. Any thoughts? Best wishes, chris Gianny Damour wrote: Hi Chris, The JMX Viewer portlet is finally working for me. Actually, it seems that due to a Dojo known issue, this portlet does not work with Safari :(; having said that, it works really nicely, and I really mean really nicely, with IE. Regarding your patch, I believe that this is a large piece of work; unfortunately, I cannot appreciate it as this is the first time that I am seeing dojo in action. Also, I think that instead of checking in the dojo files directly at the right location, we should check in a tar.ball of these files and expand it upon build of the module. I think that this is better because this way we do know which files are dojo specifics (this is a minor detail). What do you think? It would be cool if other people could have a look to this patch; for sure, it really deserves it! Thanks, Gianny
[jira] Commented: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12434603 ] Chris Cardona commented on GERONIMO-2333: - Gianny, I appreciate all your help on checking out this patch too bad it didn't work out in Safari otherwise it would have been sweet. :-) I would love to know if you guys have additional comments to make the patch better. I'm currently recreating the patch to make it work on trunk and include some changes suggested by Paul. Also, if we made a final decision on how to include Dojo source in G I would change the patch accordingly. Thanks again. Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Chris Cardona Assigned To: Chris Cardona Attachments: dojo-0.3.1-bin.zip, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- 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: gcache imlementation ideas[long]
Why not use ActiveMQ for communication and take advantage of its broker network for failover? --jason On Sep 12, 2006, at 9:19 AM, Jeff Genender wrote: I wanted to go over a high level design on a gcache cache component and get some feedback, input and invite folks who are interested to join in. ..so here it goes... The gcache will be one of several cache/clustering offerings...but starting off with the first one... The first pass I want to go with the master/slave full replication implementation. What this means is a centralized caching server which runs a cache implementation (likely will use ehcache underneath), and this server is known as a master. My interest in ehcache is it provides the ability to persist session state from a configuration if full failure recovery is needed (no need to reinvent the wheel on a great cache). The master will communicate with N number of slave servers, also running a gcache implementation. ++ +-+ +-+ || | | | | | MASTER | | SLAVE 1 | | SLAVE 2 | ... n-slaves || | | | | ++ +-+ +-+ | || | | || | | || | || || We then have client component(s) that plugs in and communicates with the server. The configuration for the client should be very light where it will only really be concerned with the master/slave/slave/nth- slave. In other words, it communicates only with the master. The master is responsible for pushing anything it receives to its slaves and other nodes in the cluster. The slaves basically look like clients to the master. ++ +-+ +-+ || | | | | | MASTER |---| SLAVE 1 | | SLAVE 2 | || | | | | ++ +-+ +-+ | | | | +---+ | ,---. ( CLIENT ) `---' In the event the master goes down, the client notes the timeout and then automatically communicates with slave #1 as the new master. Since slave #1 is also a client of the MASTER, it can determine either by itself, or by the first request that comes in asking for data, that it is the new master. ++ +-+ +-+ | OLD | |NEW MSTER| | | | MASTER | | WAS |--| SLAVE 2 | || | SLAVE 1 | | | ++ +-+ +-+ | _,' X ,' | ,-' ,---.' ( CLIENT ) `---' I think this is a fairly simple implementation, yet fairly robust. Since we are not doing the heart beat and mcast, we cut down on a lot of network traffic. Communication will be done by TCPIP sockets and would probably like to use NIO. I would like to see this component be able to run on its own...i.e. no Geronimo needed. We can build a Geronimo gbean and deployer around it, but I would like to see this component usable in many other areas, including outside of Geronimo. Open source needs more free clustering implementations. I would like this component to be broken down into 2 major categories...server and client. After a successful implementation of master/slave, I would like to make pluggable strategies, so we can provide for more of a distributed cache, partitioning, and other types of joins, such as mcast/heart beat for those who want it. Thoughts and additional ideas? Thanks, Jeff
[jira] Created: (AMQ-921) When recovering messages on startup - execution of Store.getMessage is executed as many times as many subscribers to this destination there are
When recovering messages on startup - execution of Store.getMessage is executed as many times as many subscribers to this destination there are --- Key: AMQ-921 URL: https://issues.apache.org/activemq/browse/AMQ-921 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 4.1 Environment: Any Reporter: Nikolai Penkov Priority: Minor Fix of issue https://issues.apache.org/activemq/browse/AMQ-878 (when recovering gigantic queues) come to a new performance problem. - When recovering messages on startup - execution of Store.getMessage (from IndirectMessageRefference.incrementReferenceCount) is executed as many times as many subscribers to this destination there are. E.g. 1. Start of broker with a queue A with a lot of messages 2. Queue is recovered from database by creation of IndirectMessageRefferences 3. 2 Subscribers connect to recovered queue with two different message selectors. 4. Messages are loaded from database (IndirectMessageRefference.incrementReferenceCount - destinationStore.getMessage) twice - for 2 subscribers... -- 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: gcache imlementation ideas[long]
On 9/14/06, Jason Dillon [EMAIL PROTECTED] wrote: Why not use ActiveMQ for communication and take advantage of its broker network for failover? I'd be better off leaving answering the question to Jeff, but here's my take on Jeff's proposal that may answer your question. AFAIUI, Jeff proposes a solution that doesn't need to be complicated in its first days of living. Since, everybody knows how sockets work the only issue is to combine separated Geronimo instance to a one clustered environment. The real value of the proposal is that it's that simple. A client may eventually use a better communication means like AMQ by pluggable strategies (as Jeff pointed out), but it would require more knowledge for the starters (like me) to understand and help developing it. I like the idea of doing it with the KISS principle in mind (thanks Dain). Once the master-slave and client-master communications are done (a 2/3th-closed triangle) the rest would be left to these magical pluggable solutions. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] 1.1.1-rc4 (built on 1.1.1)
Jeff and Brian did most of the heavy lifting for the Liferay integration. I don't know why the now defunct method was needed. But since the method was intentionally removed as part of a security related JIRA it sounds like we need a new version of the Liferay EAR and not a new rev of the release. So +1 on rc4. thanks, Paul On 9/13/06, David Jencks [EMAIL PROTECTED] wrote: That method got removed in trunk in rev 431706 as part of GERONIMO-2313, work which was also done on the branches. Why do you need it-- it didn't seem that geronimo needed it? thanks david jencks On Sep 13, 2006, at 12:19 PM, Paul McMahan wrote: Matt, I did a pretty thorough test of the console and it looks good. However, when I tried to install and start the Liferay plugin I got the stack trace below. I don't know if this is a real problem or just indicative that the Liferay plugin needs to be updated to synch up with api changes in the JACC spec jar. I strongly suspect the latter but I wanted to get this in front of the right eyeballs before we pull the trigger since its security related. Sorry I was not able to report this problem earlier but when I tried to import the plugin on a previous release candidate the plugin/server compatibility version numbers didn't match up yet. 12:03:29,065 ERROR [ResultsHandler] Unable to start configuration liferay/liferay-portal-tomcat/4.0.0/car org.apache.geronimo.kernel.config.LifecycleException: start of liferay/liferay-portal-tomcat/4.0.0/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf iguration(SimpleConfigurationManager.java:544) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf iguration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$ $FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$ $EnhancerByCGLIB$$cb32bcee.startConfiguration(generated) at org.apache.geronimo.console.car.ResultsHandler.actionAfterView (ResultsHandler.java:76) at org.apache.geronimo.console.MultiPagePortlet.processAction (MultiPagePortlet.java:116) at org.apache.pluto.core.PortletServlet.dispatch (PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet (PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service (PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke (PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action (PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction (PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPo rtletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke (DefaultSubjectValve.java:56) at
Re: gcache implementation ideas[long]
On 9/14/06, Jeff Genender [EMAIL PROTECTED] wrote: David Jencks wrote: ... - the former master comes back up Good question. Do we A) have it return as a master? or B) have it come in as a slave-n? Need some input here. First off, I'm a complete clastering beginner so don't be cruel to a heart that's true ;-) I'd say it depends on a strategy a cluster's configured with. On the other hand, does it really matter who's the master if all are equal? When a tcpip connection is made to a slave-n it would become a master and in case it gets up and running again it could become a slave-n (as the state would change in the meantime when it's been down) and only become a master when other slaves are gone. I think there's no need to promote a just-hung-and-booted server as a master when there's a master and it's doing well. - slave 1 (or any intermediate slave) goes down. - slave 1 (or any intermediate slave) comes back up - slave n (last slave) goes down. All great questions. I would like feedback here. See above. The next slave will act as a master until all are gone and the cluster is deemed to have failed. The way 'the next' is computed depends on the magical strategy that's in use (it could be the next in the sense of a list concept or computed randomly). Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] 1.1.1-rc4 (built on 1.1.1)
On 9/12/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Please vote on this release as it should be our last one. +1. Go babe go! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: gcache implementation ideas[long]
On 14/09/2006, at 10:58 PM, Jacek Laskowski wrote: On 9/14/06, Jeff Genender [EMAIL PROTECTED] wrote: David Jencks wrote: - slave 1 (or any intermediate slave) goes down. - slave 1 (or any intermediate slave) comes back up - slave n (last slave) goes down. All great questions. I would like feedback here. See above. The next slave will act as a master until all are gone and the cluster is deemed to have failed. The way 'the next' is computed depends on the magical strategy that's in use (it could be the next in the sense of a list concept or computed randomly). I agree. I think that the way this could be achieved is by the mean of an ActiveCluster or WADI like API. Basically, each node executes locally an election strategy, when a failure is detected. If the election strategy implementation has a determistic outcome, i.e. each node uses the same list of nodes and each of them elects the same one, then you have your next master. For instance, the WADI implementation is to use the oldest node of the cluster. I think that if each node picks a node at random, then each one will have to broadcast their selection to the other nodes. I believe that if one of them has quorum, then each node does know now which of them is master. Thanks, Gianny Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12434675 ] Greg Wilkins commented on GERONIMO-2163: Jan and I went over the patch today and we are generally pleased with it. I like the architecture of a generic geronimo session, extended to a wadi session and then the jetty session manager just using the generic API. I am a little concerned that the session API is not one of thosed proposed or discussed... but hey... it has a working implementation so that is a huge start. Jules will be happy that it captures the invocation concept as well... so everybody should be happy with the basic approach. Jan also said the refactoring in the builder was very much for the better. WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Priority: Minor Attachments: GERONIMO-2163-v3.patch, GERONIMO-2163-v3b.patch, GERONIMO-2163-v4-old.patch, GERONIMO-2163-v4.patch, GERONIMO-2163-v5-partial.patch, GERONIMO-2163-v5-plus.patch, GERONIMO-2163-v6.patch, GERONIMO-2163-v6b.patch, GERONIMO-2163-v6c.patch, geronimo-wadi-integration-preview.patch, geronimo-wadi-integration-RTC.patch, geronimo.patch, setUpServers.tar.gz, wadi-geronimo-integration-preview.patch, wadi.patch, wadi.zip Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12434678 ] Jan Bartel commented on GERONIMO-2163: -- Finally got a working network connection! I like the refactoring in the builder and the introduction of the geronimo clustering interfaces. My only concern is that there are very few comments in the code and I think for something as important as the introduction of new clustering architecture we should have that pretty well documented. WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Priority: Minor Attachments: GERONIMO-2163-v3.patch, GERONIMO-2163-v3b.patch, GERONIMO-2163-v4-old.patch, GERONIMO-2163-v4.patch, GERONIMO-2163-v5-partial.patch, GERONIMO-2163-v5-plus.patch, GERONIMO-2163-v6.patch, GERONIMO-2163-v6b.patch, GERONIMO-2163-v6c.patch, geronimo-wadi-integration-preview.patch, geronimo-wadi-integration-RTC.patch, geronimo.patch, setUpServers.tar.gz, wadi-geronimo-integration-preview.patch, wadi.patch, wadi.zip Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-915) Failover transport does not replay all the transaction operations on failover.
[ https://issues.apache.org/activemq/browse/AMQ-915?page=comments#action_36948 ] Hiram Chirino commented on AMQ-915: --- Adrian what was the svn revision that the fix was comitted on and on what branch? Failover transport does not replay all the transaction operations on failover. -- Key: AMQ-915 URL: https://issues.apache.org/activemq/browse/AMQ-915 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 If transactions are being used on a connection that is using failover.. these is a small chance that the transaction will fail or the connection will fail due to a partial tx being run when the client reconnects. I will change the failover transport to buffer up all the tx operations that are run against the broker and on failure, replay those operations. -- 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-915) Failover transport does not replay all the transaction operations on failover.
[ https://issues.apache.org/activemq/browse/AMQ-915?page=comments#action_36949 ] Hiram Chirino commented on AMQ-915: --- I'm not even sure that this has made it into trunk either. Failover transport does not replay all the transaction operations on failover. -- Key: AMQ-915 URL: https://issues.apache.org/activemq/browse/AMQ-915 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 If transactions are being used on a connection that is using failover.. these is a small chance that the transaction will fail or the connection will fail due to a partial tx being run when the client reconnects. I will change the failover transport to buffer up all the tx operations that are run against the broker and on failure, replay those operations. -- 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] Reopened: (AMQ-915) Failover transport does not replay all the transaction operations on failover.
[ https://issues.apache.org/activemq/browse/AMQ-915?page=all ] Hiram Chirino reopened AMQ-915: --- Assignee: Adrian Co (was: Hiram Chirino) Failover transport does not replay all the transaction operations on failover. -- Key: AMQ-915 URL: https://issues.apache.org/activemq/browse/AMQ-915 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Adrian Co Fix For: 4.1 If transactions are being used on a connection that is using failover.. these is a small chance that the transaction will fail or the connection will fail due to a partial tx being run when the client reconnects. I will change the failover transport to buffer up all the tx operations that are run against the broker and on failure, replay those operations. -- 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: [VOTE] 1.1.1-rc4 (built on 1.1.1)
The one problem I noticed in rc1 is gone. My +1 (if it counts :o)) VamsiOn 9/13/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I have updated build in the following ways:- Removed the code that left extraneous 0 length DTDs in the build.- Built on 1.1.1.These binaries are the final ones that will beused for distribution. They can be found athttp://people.apache.org/~hogstrom/1.1.1-rc4/Please note that these jars are based on a build with 1.1.1.It*DOES NOT HAVE* and -rcn extensions in the name.Building and testing will generate 1.1.1 artifacts.The -rc4 extension was added only to differentiate it from the otherrcs.Please vote on this release as it should be our last one.I have built the server from the sources (using the provided schema and spec jars).The datasource creation issue has been addressed.This vote will conclude on Friday, 9/15 at 1800 Eastern time.Matt Hogstrom[EMAIL PROTECTED]
Re: [activemq-dev] Support for message priority (AMQ-122)
Not at the current time. On 9/13/06, samahome [EMAIL PROTECTED] wrote: Does this mean ActiveMQ(Version 4.0.1) does not support Message priorities ? If it does support, could you please point me to some specific documentation ? Regards Sreenivas Sama Ramzi Saba wrote: Per AMQ-122, the existing ActiveMQ implementation does not support message priority. I was able to make straightforward changes to MemoryBoundedQueue to store packets in one of 10 linked lists (DefaultQueueList) based on the packet's priority. Per the JMS spec, I support priorities 0 thru 9. On dequeue, I try to consume packets from the 10 linked lists by priority. I just wanted to run this idea by you guys before I submit to SVN HEAD. Let me know if you have any concerns. Thanks. -ramzi -- View this message in context: http://www.nabble.com/-activemq-dev--Support-for-message-priority-%28AMQ-122%29-tf135416.html#a6297119 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ CNFE on CTRL-C
BTW.. you can. The ActiveMQ GB now supports a brokerURI attribute that you can set it to either an external spring or xbean file for the broker configuration. For example: xbean:file:/path/to/activemq.xml or spring:file:/path/to/applicationContext.xml Regards, Hiram On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: I will try adding a new attribute and updating the plan to set it... GBeans are so tedious, I wish I just had a spring XML to configure this bean... :-( --jason On Sep 13, 2006, at 8:32 AM, Aaron Mulder wrote: As I said, for the current version of ActiveMQ, the property can be set directly on the broker, instead of using a system property. I assume we'll be able to ditch the system property GBean and just configure the broker GBean accordingly. Thanks, Aaron On 9/13/06, Kevan Miller [EMAIL PROTECTED] wrote: On Sep 13, 2006, at 7:37 AM, Aaron Mulder wrote: We shouldn't use the ActiveMQ shutdown hook -- we'll shut it down gracefully during the Geronimo kernel shutdown process. In a normal ActiveMQ config file you disable it with something like this: broker useShutdownHook=false ... I haven't looked at our current ActiveMQ integration syntax but I assume we can set that same property on the broker object/GBean. Right. The real issue is why the ActiveMQ shutdown hook is running. I think the CNFE is occurring because the module has been stopped and MultiParentClassLoader.destroy() has been called (thus no more classes will be loaded...). For G 1.0 and 1.1 we disabled the ActiveMQ shutdown hook with the following in configs/activemq-broker/src/plan/plan.xml gbean name=SystemProperties class=org.apache.geronimo.system.properties.SystemProperties attribute name=systemProperties activemq.broker.disable-clean-shutdown=true /attribute /gbean I see we're still setting the system property in the active mq plan. So, either ActiveMQ 4 uses a different system property or there's a different problem. On the different problem track: a while back, we had a dependency issue which allowed ActiveMQ to start before the SystemProperties GBean had been started -- so, ActiveMQ wasn't seeing the above system property. See http://issues.apache.org/jira/browse/GERONIMO-1818 --kevan Thanks, Aaron On 9/12/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm not sure if this was the same error that was reported before... but I am seeing a CNFE when shutting down jetty j2ee (`java - jar bin/ sever.jar --long`) with CTRL-C: snip java.lang.NoClassDefFoundError: org/apache/activemq/broker/ BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop (BrokerService.java:1137) at org.apache.activemq.util.ServiceStopper.stop (ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop (BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run (BrokerService.java:1288) /snip This does not show up when using the shutdown command, or at least I can't see it on the console when I use shutdown.sh, but it does show up w/CTRL-C. Is the shutdown hook, not using the right classloader or something? --jason -- Regards, Hiram Blog: http://hiramchirino.com
Re: [RTC] Split connector + transaction manager out of j2ee-server, and related stuff
+1 it's good direction to drive towards! On 9/13/06, David Jencks [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/GERONIMO-2398 Thinking about how we might support plugging in a jta11 transaction manager I remembered that one part of the little-g work we never did was to split the connector and transaction stuff out from the core j2ee stuff.I made this work in the patches to the above issue. Basically this involves a major cleanup of dependencies between cars and geronimo jars, fixing a big bug in the AppClientModuleBuilder where it was using the wrong classloader to deploy client side rars, and a small amount of actually moving gbeans into new configurations. Here's a summary: j2ee-server: all the tm GBeans and ConnectionTrackingCoordinatorGBean are moved to the new transaction module (configuration) client: similar beans in the client are moved to client-transaction module j2ee-builder: connector-builder, resource-ref and resource-env-ref builder gbeans are moved to the new connector-deployer module. This includes the newly introduced 2nd connector-builder gbean for the app client. There are also a bunch of default environment changes so apps get the correct parents at runtime. About 95% of the changes are bug fixes. I still think I need at least support for the idea of this split with some pmc votes. Many thanks! david jencks -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines On 9/10/06, Kevan Miller [EMAIL PROTECTED] wrote: This is a vote to determine the development process the Geronimo community wishes to use for trunk development. If any modifications are needed for a branch development process, then a separate vote will be held. All votes are important. This is a community-wide issue. Please let your voice be heard... Choose the development process which you think will best serve the Geronimo community. I'd like to limit voting to a single process, rather than using a poll/ranking system (i.e. 1,2,3). If a clear consensus does not emerge, then we'll need to refine and hold another vote. [ ] +1 Relaxed RTC [ ] +1 RTC with Lazy Consensus [ ] +1 CTR with documentation guidelines These development processes are summarized below: 1. Relaxed RTC Geronimo follows a Review-Then-Commit (RTC) model. Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. In order for a patch to be accepted it requires the following: * Needs to be reviewed by committers on the project. Others may comment but their comments are not binding. The review may, but does not have to, include application and testing. The goal of the review is to understand the technical attributes of the change as well as the assess other impacts to the project as a whole. * 3 +1 votes from committers on the project with no outstanding -1 votes. * Any -1 votes need to be accompanied by a reason (the parties should then attempt to reach a mutually agreed upon solution to the issue raised). * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. * Issues are generally of a technical nature. However, issues may include other items like usability, project cohesiveness or other issues that impact the project as a whole. The goal of these guidelines is to facilitate timely communication as well as the fostering of ideas and collaboration as well as innovation. 2. RTC with Lazy Consensus Geronimo follows a Review-Then-Commit model with Lazy consensus. Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. A patch is accepted if: * 3 +1 votes from committers on the project with no outstanding -1 votes and no significant, ongoing discussion * 72 hours pass with no outstanding -1 votes and no significant, ongoing discussion. A 24 hour warning should be sent to the dev list. 3. CTR with documentation guidelines Geronimo follows a Commit-Then-Review model. There should be an emphasis of community communication. Community-based policing and persuasion will be used to remedy any problem areas. Guidelines are not strict dogma -- common sense should prevail. Community communication is the key, not a process. General guidelines are: * Non-trivial changes (and certainly potentially controversial changes) should be announced on the dev list. This announcement should be well in advance of the change being committed. The community should be given the opportunity to understand and discuss the proposal. * Concurrent with the commit of a significant change, the committer should document the change on the dev list. You should describe what you are doing, describe why you are doing it, and provide an overview of how you implemented it. --kevan -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] 1.1.1-rc4 (built on 1.1.1)
On 9/14/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: My +1 (if it counts :o)) Always! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (AMQ-920) Two TCP connection requirement for bidirectional message flow ...
[ https://issues.apache.org/activemq/browse/AMQ-920?page=comments#action_36950 ] Sridhar Komandur commented on AMQ-920: -- Jon brought up another important use case related to brokers outside the Firewall (perhaps in the DMZ) ... -- Forwarded message -- From: Jon [EMAIL PROTECTED] Date: Sep 14, 2006 6:34 AM Subject: Re: Firewall To: activemq-users@geronimo.apache.org Hi, I gave it a vote. This problem should be a quite common problem i would guess. Accessing a broker behind firewall would simply not be done without reusing the connection from the broker behind firewall. So if a broker outside a firewall detects brokers inside the firewall (by the inside connecting to the outside), it should make the broker inside the firewall available to all other brokers on the outside-network. So if it was possible to build a network of brokers and address them by an unique name, and let all brokers know of everybody - i quess the problem was solved. Since my network topology often is a mix of firewalls i have no control over and them i have control over, i really need something like this. Anyone who knows of a JMS project supporting this? -Jon Two TCP connection requirement for bidirectional message flow ... - Key: AMQ-920 URL: https://issues.apache.org/activemq/browse/AMQ-920 Project: ActiveMQ Issue Type: Improvement Components: Connector Reporter: Sridhar Komandur We noticed the following during our testing When a broker A establishes connection to broker B, the message flow is unidirectional from A to B. This is a an issue for us: For example, consider brokers associated with business critical services X and Y. There are many secondary services that either monitor/feed off of the messages coming from them. A FOO service would like to process messages going from X to Y. So in FOO's broker configuration we add X's name. However, messages are not going to flow from X to FOO, till X initiates a connection to FOO. It may not be desirable/possible to change business critical brokers' configuration for usage scenarios like this. TCP is bidirectional and asymmetry at connection establishment should not be translated to the higher level network connector. Is there a fundamental need/justification for this design that I may not be aware of ? Otherwise I would like to explore other design options. Thanks Regards - Sridhar Komandur -- 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: [VOTE] 1.1.1-rc4 (built on 1.1.1)
+1 Thanks for your hard work Matt! Gianny On 13/09/2006, at 7:51 AM, Matt Hogstrom wrote: I have updated build in the following ways: - Removed the code that left extraneous 0 length DTDs in the build. - Built on 1.1.1. These binaries are the final ones that will be used for distribution. They can be found at http://people.apache.org/~hogstrom/1.1.1-rc4/ Please note that these jars are based on a build with 1.1.1. It *DOES NOT HAVE* and -rcn extensions in the name. Building and testing will generate 1.1.1 artifacts. The -rc4 extension was added only to differentiate it from the other rcs. Please vote on this release as it should be our last one. I have built the server from the sources (using the provided schema and spec jars). The datasource creation issue has been addressed. This vote will conclude on Friday, 9/15 at 1800 Eastern time. Matt Hogstrom [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-2375) console has invalid XHTML in the db bool
[ http://issues.apache.org/jira/browse/GERONIMO-2375?page=all ] Bill Dudney updated GERONIMO-2375: -- Attachment: GERONIMO-2375-bdudney-v2.patch GERONIMO-2375-bdudney-v2.patch use this patch instead of the previous on - still not 100% but getting closer... console has invalid XHTML in the db bool Key: GERONIMO-2375 URL: http://issues.apache.org/jira/browse/GERONIMO-2375 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Attachments: GERONIMO-2375-bdudney-v2.patch, GERONIMO-2375.bdudney.patch the invalid XHTML prevevents automated tests from deploying a db pool -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2385) server does not update any state when persistent configuration is loaded and ready to serve applications
[ http://issues.apache.org/jira/browse/GERONIMO-2385?page=all ] Bill Dudney reassigned GERONIMO-2385: - Assignee: Bill Dudney server does not update any state when persistent configuration is loaded and ready to serve applications Key: GERONIMO-2385 URL: http://issues.apache.org/jira/browse/GERONIMO-2385 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2385.bdudney.patch see this thread http://www.nabble.com/When-has-the-server-started--tf2205476.html for reference -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2344) Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs
[ http://issues.apache.org/jira/browse/GERONIMO-2344?page=all ] Bill Dudney reassigned GERONIMO-2344: - Assignee: Bill Dudney Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs -- Key: GERONIMO-2344 URL: http://issues.apache.org/jira/browse/GERONIMO-2344 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2344.bdudney-2.patch, GERONIMO-2344.bdudney.patch Console classpath problems prevent the class from being found. Here are the error messages; 10:12:39,240 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager 10:12:39,298 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 10:12:39,305 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer The patch simply removes the scopeprovided/scope from the tomcat-deployer dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2375) console has invalid XHTML in the db bool
[ http://issues.apache.org/jira/browse/GERONIMO-2375?page=all ] Bill Dudney reassigned GERONIMO-2375: - Assignee: Bill Dudney console has invalid XHTML in the db bool Key: GERONIMO-2375 URL: http://issues.apache.org/jira/browse/GERONIMO-2375 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Bill Dudney Attachments: GERONIMO-2375-bdudney-v2.patch, GERONIMO-2375.bdudney.patch the invalid XHTML prevevents automated tests from deploying a db pool -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2180) Add Yoko ORB support to openejb/Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2180?page=all ] Rick McGuire updated GERONIMO-2180: --- Attachment: yoko.zip A snapshot of the Yoko ORB code to be added to the .m2 repository (unzip under org/apache directory). Add Yoko ORB support to openejb/Geronimo Key: GERONIMO-2180 URL: http://issues.apache.org/jira/browse/GERONIMO-2180 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.x Attachments: yoko.zip One key to obtaining JVM independence is to replace the exiting openejb Sun ORB usage with the open source Yoko ORB. The first step is to enable Yoko as an option. -- 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: [VOTE] ServiceMix-3.0-M2-incubating (second try)
I'm closing this vote now with 7 +1. I will ask the incubator PMC to validate this release. On 9/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I've fixed the missing headers files that Hiram pointed out, so I'm starting a new vote. I have uploaded the 3.0-incubating release at http://people.apache.org/repo/m2-incubating-repository Distributions are available at http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.0-incubating/apache-servicemix-3.0-incubating.tar.gz http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.0-incubating/apache-servicemix-3.0-incubating.zip Please, take some time to download and review ... and vote :) -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Updated: (GERONIMO-2180) Add Yoko ORB support to openejb/Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2180?page=all ] Rick McGuire updated GERONIMO-2180: --- Attachment: GERONIMO-2180-v1-openejb2.patch GERONIMO-2180-v1-geronimo.patch Patches to openejb2 and geronimo to enable Yoko ORB support. These are dependent upon the yoko ORB being in the me repository. Add Yoko ORB support to openejb/Geronimo Key: GERONIMO-2180 URL: http://issues.apache.org/jira/browse/GERONIMO-2180 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.x Attachments: GERONIMO-2180-v1-geronimo.patch, GERONIMO-2180-v1-openejb2.patch, yoko.zip One key to obtaining JVM independence is to replace the exiting openejb Sun ORB usage with the open source Yoko ORB. The first step is to enable Yoko as an option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2180) Add Yoko ORB support to openejb/Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2180?page=comments#action_12434698 ] Balaji Ravi commented on GERONIMO-2180: --- Why can't the yoko maven artifacts be pulled from the snapshot repository? I assume geronimo is using maven as its build system, so it would be easier to do this instead of using the yoko releases... Add Yoko ORB support to openejb/Geronimo Key: GERONIMO-2180 URL: http://issues.apache.org/jira/browse/GERONIMO-2180 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.x Attachments: GERONIMO-2180-v1-geronimo.patch, GERONIMO-2180-v1-openejb2.patch, yoko.zip One key to obtaining JVM independence is to replace the exiting openejb Sun ORB usage with the open source Yoko ORB. The first step is to enable Yoko as an option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2180) Add Yoko ORB support to openejb/Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2180?page=comments#action_12434695 ] Rick McGuire commented on GERONIMO-2180: I've added some patches to to enable this support. There are serveral issues I need community input to resolve, which will be handled on the discussion list. There are 3 parts to this patch. To apply: 1) unzip the archive yoko.zip to the .m2/repositoryorg/apache directory. This is a development snapshot of the yoko M1 release candidate code. 2) checkout a fresh copy of openejb2 and apply the openejb patch. Build openejb2. 3) apply the geronimo patch and build it. This is a little bit of a pain, as building openejb2 with these changes in place cause conflicts with other versions of the Geronimo trunk code you might be using. The openejb2 jars that get published to the repository in step 2) will cause compile errors to source trees without patch 3) applied. Add Yoko ORB support to openejb/Geronimo Key: GERONIMO-2180 URL: http://issues.apache.org/jira/browse/GERONIMO-2180 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.x Attachments: GERONIMO-2180-v1-geronimo.patch, GERONIMO-2180-v1-openejb2.patch, yoko.zip One key to obtaining JVM independence is to replace the exiting openejb Sun ORB usage with the open source Yoko ORB. The first step is to enable Yoko as an option. -- 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: gcache imlementation ideas[long]
Jacek Laskowski wrote: On 9/14/06, Jason Dillon [EMAIL PROTECTED] wrote: Why not use ActiveMQ for communication and take advantage of its broker network for failover? I'd be better off leaving answering the question to Jeff, but here's my take on Jeff's proposal that may answer your question. AFAIUI, Jeff proposes a solution that doesn't need to be complicated in its first days of living. Since, everybody knows how sockets work the only issue is to combine separated Geronimo instance to a one clustered environment. The real value of the proposal is that it's that simple. A client may eventually use a better communication means like AMQ by pluggable strategies (as Jeff pointed out), but it would require more knowledge for the starters (like me) to understand and help developing it. I like the idea of doing it with the KISS principle in mind (thanks Dain). Once the master-slave and client-master communications are done (a 2/3th-closed triangle) the rest would be left to these magical pluggable solutions. Perfectly said...you said it better than me ;-) Jacek
Re: gcache imlementation ideas[long]
Jason Dillon wrote: Why not use ActiveMQ for communication and take advantage of its broker network for failover? The JMS provider would be a pluggable comm strategy. For performance reasons, I want to start with TCP communication. I definitely want to have a JMS strategy...maybe next. But initially I don't want any dependencies on other servers or brokers. With that said, after looking at openwire, the comm marshaller for ActiveMQ, there is a lot to leverage there and will prevent a rewrite of the comm layer. So, there will be some use of that code base initially. Jeff --jason On Sep 12, 2006, at 9:19 AM, Jeff Genender wrote: I wanted to go over a high level design on a gcache cache component and get some feedback, input and invite folks who are interested to join in. ..so here it goes... The gcache will be one of several cache/clustering offerings...but starting off with the first one... The first pass I want to go with the master/slave full replication implementation. What this means is a centralized caching server which runs a cache implementation (likely will use ehcache underneath), and this server is known as a master. My interest in ehcache is it provides the ability to persist session state from a configuration if full failure recovery is needed (no need to reinvent the wheel on a great cache). The master will communicate with N number of slave servers, also running a gcache implementation. ++ +-+ +-+ || | | | | | MASTER | | SLAVE 1 | | SLAVE 2 | ... n-slaves || | | | | ++ +-+ +-+ | || | | || | | || | || || We then have client component(s) that plugs in and communicates with the server. The configuration for the client should be very light where it will only really be concerned with the master/slave/slave/nth-slave. In other words, it communicates only with the master. The master is responsible for pushing anything it receives to its slaves and other nodes in the cluster. The slaves basically look like clients to the master. ++ +-+ +-+ || | | | | | MASTER |---| SLAVE 1 | | SLAVE 2 | || | | | | ++ +-+ +-+ | | | | +---+ | ,---. ( CLIENT ) `---' In the event the master goes down, the client notes the timeout and then automatically communicates with slave #1 as the new master. Since slave #1 is also a client of the MASTER, it can determine either by itself, or by the first request that comes in asking for data, that it is the new master. ++ +-+ +-+ | OLD | |NEW MSTER| | | | MASTER | | WAS |--| SLAVE 2 | || | SLAVE 1 | | | ++ +-+ +-+ | _,' X ,' | ,-' ,---.' ( CLIENT ) `---' I think this is a fairly simple implementation, yet fairly robust. Since we are not doing the heart beat and mcast, we cut down on a lot of network traffic. Communication will be done by TCPIP sockets and would probably like to use NIO. I would like to see this component be able to run on its own...i.e. no Geronimo needed. We can build a Geronimo gbean and deployer around it, but I would like to see this component usable in many other areas, including outside of Geronimo. Open source needs more free clustering implementations. I would like this component to be broken down into 2 major categories...server and client. After a successful implementation of master/slave, I would like to make pluggable strategies, so we can provide for more of a distributed cache, partitioning, and other types of joins, such as mcast/heart beat for those who want it. Thoughts and additional ideas? Thanks, Jeff
Re: gcache implementation ideas[long]
Hi Gianny, Thanks for the comments. I am not so sure I want to inject election or quorum into the mix as I want the first pass to be as simple as possible. For the sake of simplicity, already knowing the order will help. As I thought about this more, if a slave comes back, it can notify the other slaves that its alive and then it's back in its proper order. Keep in mind, an intermediate slave only really needs to notify the master and other slaves that it's back. Jeff Gianny Damour wrote: On 14/09/2006, at 10:58 PM, Jacek Laskowski wrote: On 9/14/06, Jeff Genender [EMAIL PROTECTED] wrote: David Jencks wrote: - slave 1 (or any intermediate slave) goes down. - slave 1 (or any intermediate slave) comes back up - slave n (last slave) goes down. All great questions. I would like feedback here. See above. The next slave will act as a master until all are gone and the cluster is deemed to have failed. The way 'the next' is computed depends on the magical strategy that's in use (it could be the next in the sense of a list concept or computed randomly). I agree. I think that the way this could be achieved is by the mean of an ActiveCluster or WADI like API. Basically, each node executes locally an election strategy, when a failure is detected. If the election strategy implementation has a determistic outcome, i.e. each node uses the same list of nodes and each of them elects the same one, then you have your next master. For instance, the WADI implementation is to use the oldest node of the cluster. I think that if each node picks a node at random, then each one will have to broadcast their selection to the other nodes. I believe that if one of them has quorum, then each node does know now which of them is master. Thanks, Gianny Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: gcache imlementation ideas[long]
Jacek Laskowski wrote: On 9/13/06, Jeff Genender [EMAIL PROTECTED] wrote: The code lives in sandbox/gcache. Its in it's early stages. Could you describe what's already there? A wiki page would be of help, too. Do you plan to convert these fancy ascii arts into UML diagrams? I think a jira issue would bring some attention, too. Need help? ;-) Yes!!! All help is welcome and encouraged. Roll up your sleeves Jacek! Thanks! Jacek
Re: [VOTE] 1.1.1-rc4 (built on 1.1.1)
Based on this report, I'm going to mark the current Liferay plugin as only works for Geronimo 1.1. As soon as a new compatible release is available, we'll mark it for 1.1.1 and 1.1.2-SNAPSHOT. (It would be great to have one that worked in the Geronimo/Jetty distribution too!) Thanks, Aaron On 9/13/06, Paul McMahan [EMAIL PROTECTED] wrote: Matt, I did a pretty thorough test of the console and it looks good. However, when I tried to install and start the Liferay plugin I got the stack trace below. I don't know if this is a real problem or just indicative that the Liferay plugin needs to be updated to synch up with api changes in the JACC spec jar. I strongly suspect the latter but I wanted to get this in front of the right eyeballs before we pull the trigger since its security related. Sorry I was not able to report this problem earlier but when I tried to import the plugin on a previous release candidate the plugin/server compatibility version numbers didn't match up yet. 12:03:29,065 ERROR [ResultsHandler] Unable to start configuration liferay/liferay-portal-tomcat/4.0.0/car org.apache.geronimo.kernel.config.LifecycleException: start of liferay/liferay-portal-tomcat/4.0.0/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:544) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$cb32bcee.startConfiguration(generated) at org.apache.geronimo.console.car.ResultsHandler.actionAfterView(ResultsHandler.java:76) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:116) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at
[jira] Commented: (GERONIMO-2180) Add Yoko ORB support to openejb/Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-2180?page=comments#action_12434707 ] Balaji Ravi commented on GERONIMO-2180: --- Yes... It is in the apache snapshot repository... http://people.apache.org/maven-snapshot-repository/org/apache/yoko/ Add Yoko ORB support to openejb/Geronimo Key: GERONIMO-2180 URL: http://issues.apache.org/jira/browse/GERONIMO-2180 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.x Attachments: GERONIMO-2180-v1-geronimo.patch, GERONIMO-2180-v1-openejb2.patch, yoko.zip One key to obtaining JVM independence is to replace the exiting openejb Sun ORB usage with the open source Yoko ORB. The first step is to enable Yoko as an option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RTC] Split connector + transaction manager out of j2ee-server, and related stuff
I like the direction but I haven't tried the patches. Thanks, Aaron On 9/13/06, David Jencks [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/GERONIMO-2398 Thinking about how we might support plugging in a jta11 transaction manager I remembered that one part of the little-g work we never did was to split the connector and transaction stuff out from the core j2ee stuff.I made this work in the patches to the above issue. Basically this involves a major cleanup of dependencies between cars and geronimo jars, fixing a big bug in the AppClientModuleBuilder where it was using the wrong classloader to deploy client side rars, and a small amount of actually moving gbeans into new configurations. Here's a summary: j2ee-server: all the tm GBeans and ConnectionTrackingCoordinatorGBean are moved to the new transaction module (configuration) client: similar beans in the client are moved to client-transaction module j2ee-builder: connector-builder, resource-ref and resource-env-ref builder gbeans are moved to the new connector-deployer module. This includes the newly introduced 2nd connector-builder gbean for the app client. There are also a bunch of default environment changes so apps get the correct parents at runtime. About 95% of the changes are bug fixes. I still think I need at least support for the idea of this split with some pmc votes. Many thanks! david jencks
Re: How to get predictable moduleId when using DeploymentManager.distribute()
On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Can I use the artifactId with javax.enterprise.deploy.spi.DeploymentManager and friends? I'll have to look -- I'm not sure whether the decode artifact to full module ID code is in the deployment tool or the deployment manager. But if it's not in the deployment manager today, we could certainly move it there. Can you try and if it doesn't work create a Jira? Thanks, Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote: First, if you specify a module ID in your plan, that will be used (or as much as you provide with defaults for the rest). And you can pack the plan in the module if you don't want to track it separately. Second, you can undeploy using only the artifact ID (so in your example, you could undeploy test-ear-j2ee_1.4-1.2-SNAPSHOT) so long as there aren't conflicts. The default artifact ID is the JAR name minus the extension. Thanks, Aaron On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know how to get predictable moduleIds when using DeploymentManager.distribute()? I'd like to figure out how to get the moduleIds to be the same as the artifactId for the archive that is deployed, so that we can undeploy it after tests have been run. How can I do this? Do I need to specify a plan for the archive to tie it to a specific moduleId? I have been playing with test-ear-j2ee_1.4.ear, and it keeps generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ 1158129807807/car' which is kinda hard to undeploy after that state has been lost. If I do need to specify a plan, can I tuck that into the .ear so that Maven does not need to worry about 2 artifacts for one deployment? --jason
Re: How to get predictable moduleId when using DeploymentManager.distribute()
I think what you may be looking for is ConfigIDExtractor.identifyTargetModuleIDs perhaps?On Sep 14, 2006, at 10:48 AM, Aaron Mulder wrote:On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Can I use the artifactId withjavax.enterprise.deploy.spi.DeploymentManager and friends? I'll have to look -- I'm not sure whether the "decode artifact to fullmodule ID" code is in the deployment tool or the deployment manager.But if it's not in the deployment manager today, we could certainlymove it there. Can you try and if it doesn't work create a Jira?Thanks, Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote: First, if you specify a module ID in your plan, that will be used (or as much as you provide with defaults for the rest). And you can pack the plan in the module if you don't want to track it separately. Second, you can undeploy using only the artifact ID (so in your example, you could "undeploy test-ear-j2ee_1.4-1.2-SNAPSHOT") so long as there aren't conflicts. The default artifact ID is the JAR name minus the extension. Thanks, Aaron On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know how to get predictable moduleIds when using DeploymentManager.distribute()? I'd like to figure out how to get the moduleIds to be the same as the artifactId for the archive that is deployed, so that we can undeploy it after tests have been run. How can I do this? Do I need to specify a plan for the archive to tie it to a specific moduleId? I have been playing with test-ear-j2ee_1.4.ear, and it keeps generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ 1158129807807/car' which is kinda hard to undeploy after that state has been lost. If I do need to specify a plan, can I tuck that into the .ear so that Maven does not need to worry about 2 artifacts for one deployment? --jason -sachin
[jira] Commented: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12434713 ] Paul McMahan commented on GERONIMO-2333: Like Gianny I had problems using Safari 2.0.4. I also had problems with Konqueror 3.5.2, it displayed the message: FATAL: symbol 'dojo.widget' is not defined after loading __package__.js These two browsers are based on the same rendering engine so that's not surprising. Creating a sophisticated web UI that works in all browsers is extremely difficult. Since the UI works in firefox which is available in most environments IMHO its OK to keep moving forward and work with the dojo project to get a fix for those problems later. Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Chris Cardona Assigned To: Chris Cardona Attachments: dojo-0.3.1-bin.zip, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RTC Yoo-Hoo Wake Up Please and Review the Wadi Integration Patch
Hi Gianny, I applied the patch and got a few simple to fix hunks failing. Got them fixed and it built until the failure to find the wadi-group artifact. Any chance that could get uploaded so I can be lazy and not build it myself? If I understand things correctly geronimo-clustering is an alternative to the geronimo-session module we had/have in the 1.2- dead branch. Am I correct? Just trying to make sure I understand things correctly. And one last thing, I to would like to see some more docs at least in the geronimo-clustering module. Thanks! -bd- On Sep 13, 2006, at 9:34 AM, Gianny Damour wrote: Many thanks David for this wake-up call :) I do agree: the NamespaceDrivenBuilder change is a great improvement. If I am entitled to vote for this patch, even if I am one of the reporters, then we now have 3 +1. Having said that, I would appreciate if Greg could have a quick scan prior to commit. Thanks, Gianny On 13/09/2006, at 1:59 AM, David Jencks wrote: I'd like to thank the PMC members who promptly reviewed my jta 1.1 and jndi refactoring patches and point them to an at least equally deserving patch that has been quietly mouldering for lack of attention http://issues.apache.org/jira/browse/GERONIMO-2163 Aside from - Integrating WADI in an architecturally appropriate way (finally!) - Providing a clustering api as a basis for discussion and further development this also now includes a big improvement to the NamespaceDrivenBuilder interface that lets these builders add stuff to the environment. We should be able to leverage this to e.g. only include axis when you are actually using a web service and/or switch webservices implementations. thanks david jencks
java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode
I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java:1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown(BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java:1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: How to get predictable moduleId when using DeploymentManager.distribute()
I tried your suggestion about using just the artifactId in a mojo execution. That wouldn't work. However, it works as you said from the CLI. Cheers Prasad On 9/14/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Can I use the artifactId with javax.enterprise.deploy.spi.DeploymentManager and friends? I'll have to look -- I'm not sure whether the decode artifact to full module ID code is in the deployment tool or the deployment manager. But if it's not in the deployment manager today, we could certainly move it there. Can you try and if it doesn't work create a Jira? Thanks, Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote: First, if you specify a module ID in your plan, that will be used (or as much as you provide with defaults for the rest). And you can pack the plan in the module if you don't want to track it separately. Second, you can undeploy using only the artifact ID (so in your example, you could undeploy test-ear-j2ee_1.4-1.2-SNAPSHOT) so long as there aren't conflicts. The default artifact ID is the JAR name minus the extension. Thanks, Aaron On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know how to get predictable moduleIds when using DeploymentManager.distribute()? I'd like to figure out how to get the moduleIds to be the same as the artifactId for the archive that is deployed, so that we can undeploy it after tests have been run. How can I do this? Do I need to specify a plan for the archive to tie it to a specific moduleId? I have been playing with test-ear-j2ee_1.4.ear, and it keeps generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ 1158129807807/car' which is kinda hard to undeploy after that state has been lost. If I do need to specify a plan, can I tuck that into the .ear so that Maven does not need to worry about 2 artifacts for one deployment? --jason
Re: java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode
Hi Anita, This is almost certianly from not cleaning everything out before doing a build. You have to nuke all the m2 repo bits related to geronimo and openejb 2 to get rid of all the old code that was using the EDU.oswego classes as well as mvn clean everything (i.e. a bootstrap :-) HTH, -bd- On Sep 14, 2006, at 10:06 AM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
I've just attached patches for issue http://issues.apache.org/jira/browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non-Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee-corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would take this NameService instance, and configure the ORB to use the NameService.getURI() result for it's initial NameService reference. Well, when trying to get Geronimo to build, I got a failure on one of the client plans because there was a CORBABean coded, but no NameService. The CORBABean had use the now obsolete arguments attribute to configure the ORB to use a remote NameService. I thought on this a little, and decided to just add a local attribute to the NameService GBean. If local is false, then the bean does not launch a local server instance and the getURI() returns the remote location of the NameService as specified by the host/port combination. This worked very well, but it somehow feels like a convenience hack to me. Does this sound ok, or should I take some other approach with this? For GERONIMO-2002, I create a new SSLConfig GBean. This class has a reference to a KeystoreManager GBean, plus various attributes that are required to generate SSLSocketFactory and SSLServerSocketFactory instances for creating the SSL sockets. The CORBABean and CSSBean objects can be configured with an SSLConfig reference, which is then used whenever an SSL connection is required. This is separate from the TSSConfig/CSSConfig specifications. TSSConfig/CSSConfig help determine WHEN an SSL connection is required. The SSLConfig determines HOW the connection gets created when it is required. ISSUE #2: This works fairly well for the j2ee-corba plan, which imports the j2ee-security plan. The j2ee-security plan defines the default KeystoreManager instances, so things get resolved properly. On the
Re: How to get predictable moduleId when using DeploymentManager.distribute()
OK. I guess the issue is that by default, the DeploymentManager expects a TargetModuleID which is assumed to be complete. We have to decide in this case whether we should just allow TargetModuleIDs that essentially have wildcards, or whether we should add some methods to our DeploymentManager subinterface that take arguments more like we want for this case. Do you guys asking for this care whether you're using the strict JSR-88 DeploymentManager interface or e.g. a GeronimoDeploymentManager interface? Thanks, Aaron On 9/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: I tried your suggestion about using just the artifactId in a mojo execution. That wouldn't work. However, it works as you said from the CLI. Cheers Prasad On 9/14/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Can I use the artifactId with javax.enterprise.deploy.spi.DeploymentManager and friends? I'll have to look -- I'm not sure whether the decode artifact to full module ID code is in the deployment tool or the deployment manager. But if it's not in the deployment manager today, we could certainly move it there. Can you try and if it doesn't work create a Jira? Thanks, Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote: First, if you specify a module ID in your plan, that will be used (or as much as you provide with defaults for the rest). And you can pack the plan in the module if you don't want to track it separately. Second, you can undeploy using only the artifact ID (so in your example, you could undeploy test-ear-j2ee_1.4-1.2-SNAPSHOT) so long as there aren't conflicts. The default artifact ID is the JAR name minus the extension. Thanks, Aaron On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know how to get predictable moduleIds when using DeploymentManager.distribute()? I'd like to figure out how to get the moduleIds to be the same as the artifactId for the archive that is deployed, so that we can undeploy it after tests have been run. How can I do this? Do I need to specify a plan for the archive to tie it to a specific moduleId? I have been playing with test-ear-j2ee_1.4.ear, and it keeps generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ 1158129807807/car' which is kinda hard to undeploy after that state has been lost. If I do need to specify a plan, can I tuck that into the .ear so that Maven does not need to worry about 2 artifacts for one deployment? --jason
Make bootstrap less aggressive?
Would it hurt to adjust bootstrap to whack only the Geronimo-related content from the M2 repo? Or perhaps only the SNAPSHOT artifacts? I resist using it only because I have a lot of non-Geronimo content in my local repo that I hate to lose every time. I used to be happy to do the m:cleanrepo target that only killed the pertinent stuff, though. Thanks, Aaron On 9/14/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Anita, This is almost certianly from not cleaning everything out before doing a build. You have to nuke all the m2 repo bits related to geronimo and openejb 2 to get rid of all the old code that was using the EDU.oswego classes as well as mvn clean everything (i.e. a bootstrap :-) HTH, -bd- On Sep 14, 2006, at 10:06 AM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode
Hi Anita, This problem should be fixed with RC 443131. Suggest you give it a try... --kevan On Sep 14, 2006, at 12:06 PM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Make bootstrap less aggressive?
Hi Aaron, Try bootstrap -Dclean-minimal=true for only nuking the pertinent stuff. HTH, -bd- On Sep 14, 2006, at 10:21 AM, Aaron Mulder wrote: Would it hurt to adjust bootstrap to whack only the Geronimo-related content from the M2 repo? Or perhaps only the SNAPSHOT artifacts? I resist using it only because I have a lot of non-Geronimo content in my local repo that I hate to lose every time. I used to be happy to do the m:cleanrepo target that only killed the pertinent stuff, though. Thanks, Aaron On 9/14/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Anita, This is almost certianly from not cleaning everything out before doing a build. You have to nuke all the m2 repo bits related to geronimo and openejb 2 to get rid of all the old code that was using the EDU.oswego classes as well as mvn clean everything (i.e. a bootstrap :-) HTH, -bd- On Sep 14, 2006, at 10:06 AM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp:// 0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp:// 0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java: 42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java: 442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Make bootstrap less aggressive?
OK, cool! Thanks, Aaron On 9/14/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Aaron, Try bootstrap -Dclean-minimal=true for only nuking the pertinent stuff. HTH, -bd- On Sep 14, 2006, at 10:21 AM, Aaron Mulder wrote: Would it hurt to adjust bootstrap to whack only the Geronimo-related content from the M2 repo? Or perhaps only the SNAPSHOT artifacts? I resist using it only because I have a lot of non-Geronimo content in my local repo that I hate to lose every time. I used to be happy to do the m:cleanrepo target that only killed the pertinent stuff, though. Thanks, Aaron On 9/14/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Anita, This is almost certianly from not cleaning everything out before doing a build. You have to nuke all the m2 repo bits related to geronimo and openejb 2 to get rid of all the old code that was using the EDU.oswego classes as well as mvn clean everything (i.e. a bootstrap :-) HTH, -bd- On Sep 14, 2006, at 10:06 AM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp:// 0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp:// 0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java: 42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java: 442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (SM-579) Setters on JaxenXPathExpression have no effect on the underlying DOMXPath object
Setters on JaxenXPathExpression have no effect on the underlying DOMXPath object Key: SM-579 URL: https://issues.apache.org/activemq/browse/SM-579 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.0-M2 Environment: Not relevant Reporter: Horst Studer The setter methods of JaxenXPathExpression (for fields other than the xpathObject) only set the private field of the JaxenXPathExpression. The new values are not propagated to the xpathObject and therefore have no effect. The method afterPropertiesSet() probably was initially designed for this purpose, but it is only called in the constructor. Besides that, this method would have no effect if called in the setter methods, because it does nothing if the xpathObject is not null (i.e. after the first call). The bug was found in the following use case: Namespace prefixes in an XPath expression within a jbi:condition element in a drools rule are not recognized when the expression is evaluated. This should work, since the JaxenConditionFactory correctly sets the namespace context in the JaxenXPathExpression object. But because of the bug, the namespace context in the DOMXPath object is not set. -- 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: How to get predictable moduleId when using DeploymentManager.distribute()
JSR-88 interfaceOn Sep 14, 2006, at 12:18 PM, Aaron Mulder wrote:OK. I guess the issue is that by default, the DeploymentManagerexpects a TargetModuleID which is assumed to be complete. We have todecide in this case whether we should just allow TargetModuleIDs thatessentially have wildcards, or whether we should add some methods toour DeploymentManager subinterface that take arguments more like wewant for this case.Do you guys asking for this care whether you're using the strictJSR-88 DeploymentManager interface or e.g. a GeronimoDeploymentManagerinterface?Thanks, AaronOn 9/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: I tried your suggestion about using just the artifactId in a mojoexecution. That wouldn't work. However, it works as you said from theCLI.CheersPrasadOn 9/14/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Can I use the artifactId with javax.enterprise.deploy.spi.DeploymentManager and friends? I'll have to look -- I'm not sure whether the "decode artifact to full module ID" code is in the deployment tool or the deployment manager. But if it's not in the deployment manager today, we could certainly move it there. Can you try and if it doesn't work create a Jira? Thanks, Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote:First, if you specify a module ID in your plan, that will be used (or as much as you provide with defaults for the rest). And you can pack the plan in the module if you don't want to track it separately. Second, you can undeploy using only the artifact ID (so in your example, you could "undeploy test-ear-j2ee_1.4-1.2-SNAPSHOT") so long as there aren't conflicts. The default artifact ID is the JAR name minus the extension. Thanks, Aaron On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know how to get predictable moduleIds when using DeploymentManager.distribute()? I'd like to figure out how to get the moduleIds to be the same as the artifactId for the archive that is deployed, so that we can undeploy it after tests have been run. How can I do this? Do I need to specify a plan for the archive to tie it to a specific moduleId? I have been playing with test-ear-j2ee_1.4.ear, and it keeps generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ 1158129807807/car' which is kinda hard to undeploy after that state has been lost. If I do need to specify a plan, can I tuck that into the .ear so that Maven does not need to worry about 2 artifacts for one deployment? --jason -sachin
j2se 5 - build successful
Hi All, After running into the jdk 1.5 building problem a couple of days ago and posting about it ; http://www.nabble.com/fail-bootstrap-early-with-wrong-jdk-tf2265472.html I decided to dig into how far away we are from being able to build with J2SE 5. So I set out to give it a shot. And to my amazement everything just worked :-). Of course 'everthing' does not include the bits that rely on the Sun ORB but the server fired up and I was able to poke around in the console. Anyway here is what I did to get everything building with JDK 1.5; 1) checkout a fresh copy of a) https://svn.apache.org/repos/asf/geronimo/server/trunk b) https://svn.apache.org/repos/asf/geronimo/genesis/trunk c) https://svn.apache.org/repos/asf/geronimo/specs/trunk 2) delete all the geronimo stuff from my local m2 repo (rm -rf ~/.m2/ repository/org/apache/geronimo) 3) set my jdk to 1.5 4) build a) genesis b) specs c) remove the check for jdk 1.4 (patch attached) build geronimo 5) start the server under 1.5 6) poke around - of course anything requiring the ORB will not work but the other stuff I tried worked, I poked around a bit with jconsole and the stuff running all looked 'normal' to me. Thoughts? TTFN, -bd- no-1.4check.patch Description: Binary data
Re: [jira] Commented: (SM-573) LoanBroker example occasionnally hangs
I tried it in the 3.0 release and when I run the client a second time it hangs. JIRA [EMAIL PROTECTED] wrote: [ https://issues.apache.org/activemq/browse/SM-573?page=comments#action_36933 ] Guillaume Nodet commented on SM-573: This has been fixed quite recently. Could you try with the 3.0 release being currently voted (unofficial release) ? Also the No Source available is due to the fact that this example does not make use of the xml payload, only properties which is a bit in contradiction with the JBI spec, though supported somehow by Servicemix. LoanBroker example occasionnally hangs -- Key: SM-573 URL: https://issues.apache.org/activemq/browse/SM-573 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0-M2 Environment: Linux Reporter: Alain Knaff Often, the loan-broker example hangs. When that happens, the client (launched with ant) hangs for a while at [java] Sending request and eventually gets a javax.jms.JMSException: EDU.oswego.cs.dl.util.concurrent.TimeoutException When that happens, nothing at all is logged on the server (launched with servicemix.xml). Once in that state, it stays like that (until restarted). If the server is good at first, it often gets into that state at the second request. Occasionnally, 1 request in 2 succeed (i.e. first succeeds, second hangs, third succeeds, fourth hangs...) -- 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 -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28SM-573%29-LoanBroker-example-occasionnally-hangs-tf2253032.html#a6310806 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: [VOTE] 1.1.1-rc4 (built on 1.1.1)
+1 -dain On Sep 12, 2006, at 2:51 PM, Matt Hogstrom wrote: I have updated build in the following ways: - Removed the code that left extraneous 0 length DTDs in the build. - Built on 1.1.1. These binaries are the final ones that will be used for distribution. They can be found at http://people.apache.org/~hogstrom/1.1.1-rc4/ Please note that these jars are based on a build with 1.1.1. It *DOES NOT HAVE* and -rcn extensions in the name. Building and testing will generate 1.1.1 artifacts. The -rc4 extension was added only to differentiate it from the other rcs. Please vote on this release as it should be our last one. I have built the server from the sources (using the provided schema and spec jars). The datasource creation issue has been addressed. This vote will conclude on Friday, 9/15 at 1800 Eastern time. Matt Hogstrom [EMAIL PROTECTED]
[jira] Closed: (SM-487) network clogging when service mix runs
[ https://issues.apache.org/activemq/browse/SM-487?page=all ] Guillaume Nodet closed SM-487. -- Resolution: Won't Fix Assignee: Guillaume Nodet Changing / removing the discovery mechanism will have no effect if you don't use clustering. If you need clustering, you could use a different discovery mechanism but this has no impact on servicemix itself. network clogging when service mix runs -- Key: SM-487 URL: https://issues.apache.org/activemq/browse/SM-487 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0-M1, 3.0-M2, 3.0.1 Environment: Linux 2.6.x (Suse 10 and Gentoo), Java 1.5.0_0x Reporter: Anand K Kalyanasundaram Assigned To: Guillaume Nodet Priority: Critical Running servicemix 3.0 overloads the network on a linux machine. This does not happen with service mix 2.0.2. This happens with service mix 3.0-M1, 3.0-M2 and 3.0-SNAPSHOT and all of them consistently caused a server configured linux machine to become unresponsive on the network. On a linux desktop, the machine was responsive, but all outgoing and incomming connections to the machine where incurring huge latencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12434757 ] David Jencks commented on GERONIMO-2333: This is very nice. +1 from me, wherever the dojo files end up. I think a separate plugin would be better. Do they need to be unpacked or can we just include them in a packed jar in the classpath? What would people think of a top-bottom split rather than the side to side split? On my 17 mac I cant see that much of either the names in the tree or the stuff in the tables on the right. I'm not sure this is enough of a bug-fix to apply to the 1.1.x branch but I certainly want it in trunk ASAP. I'll attach a patch with the paths modified to trunk, and including the dojo stuff unpacked according to Chris' instructions Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=all ] David Jencks updated GERONIMO-2333: --- Attachment: GERONIMO-2333-trunk.patch I moved the files to their locations in trunk and included all the dojo files in the patch. Also the jsp compiler include comment in web.xml seems to have changed: what's there now works for me in trunk. Other than that no code changes from chris' work. I don't know if this patch will actually apply :-) so feel free to ask me to commit it when we get another vote. Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- 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: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/ browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non- Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee- corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. This sounds great! Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would take this NameService instance, and configure the ORB to use the NameService.getURI() result for it's initial NameService reference. Well, when trying to get Geronimo to build, I got a failure on one of the client plans because there was a CORBABean coded, but no NameService. The CORBABean had use the now obsolete arguments attribute to configure the ORB to use a remote NameService. I thought on this a little, and decided to just add a local attribute to the NameService GBean. If local is false, then the bean does not launch a local server instance and the getURI() returns the remote location of the NameService as specified by the host/port combination. This worked very well, but it somehow feels like a convenience hack to me. Does this sound ok, or should I take some other approach with this? This seems reasonable to me. There might be an even better way to deal with this, but we definitely need to support both a name server in the same vm (in which case with luck we can communicate with it in- vm without tcp) or a remote name server. We were starting a name server in vm mostly because it's simpler to administer. Theoretically we could start an app client where all it did was run the name server :-). For GERONIMO-2002, I create a new SSLConfig GBean. This class has a reference to a KeystoreManager GBean, plus various attributes that are required to generate SSLSocketFactory and SSLServerSocketFactory instances for creating the SSL sockets. The
Re: j2se 5 - build successful
Cool ! Unknowingly I had been building on JDK 1.5 for a while now. The java installation on my windows decided to upgrade itself. The builds had passed successfully but I hadn't tested the server runtime. Recently, I downgraded my jdk back to 1.4.2 after I encountered some build problems. The build problems turned out to be non-jdk related anyways. Cheers Prasad On 9/14/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi All, After running into the jdk 1.5 building problem a couple of days ago and posting about it ; http://www.nabble.com/fail-bootstrap-early-with-wrong-jdk-tf2265472.html I decided to dig into how far away we are from being able to build with J2SE 5. So I set out to give it a shot. And to my amazement everything just worked :-). Of course 'everthing' does not include the bits that rely on the Sun ORB but the server fired up and I was able to poke around in the console. Anyway here is what I did to get everything building with JDK 1.5; 1) checkout a fresh copy of a) https://svn.apache.org/repos/asf/geronimo/server/trunk b) https://svn.apache.org/repos/asf/geronimo/genesis/trunk c) https://svn.apache.org/repos/asf/geronimo/specs/trunk 2) delete all the geronimo stuff from my local m2 repo (rm -rf ~/.m2/ repository/org/apache/geronimo) 3) set my jdk to 1.5 4) build a) genesis b) specs c) remove the check for jdk 1.4 (patch attached) build geronimo 5) start the server under 1.5 6) poke around - of course anything requiring the ORB will not work but the other stuff I tried worked, I poked around a bit with jconsole and the stuff running all looked 'normal' to me. Thoughts? TTFN, -bd-
Re: java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode
The activemq problem was fixed... but I am unaware that the shutdown EDU/oswego/cs/dl/util/concurrent/LinkedNode is fixed. There is an open bug assigned to david blevins to fix that. --jason On Sep 14, 2006, at 9:21 AM, Kevan Miller wrote: Hi Anita, This problem should be fixed with RC 443131. Suggest you give it a try... --kevan On Sep 14, 2006, at 12:06 PM, anita kulshreshtha wrote: I am seeing this error on trunk (rev 443034) during shutdown: 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector vm://localhost Stopped 11:42:10,359 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService$2$1 at org.apache.activemq.broker.BrokerService$2.stop(BrokerService.java: 1137) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:442) at org.apache.activemq.broker.BrokerService.containerShutdown (BrokerService.java:1311) at org.apache.activemq.broker.BrokerService$3.run(BrokerService.java: 1288) java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) Server shutdown completed Thnaks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
We might need aliased modules/configurations/artifactIds
I started working on a version of geronimo that uses the jta11 transaction manager in the sandbox. So, I wrote a new transaction configuration using the new gbean and started trying to assemble a server. My new config has gbeans with exactly the same names (except for artifactId) as the old jta 1.0.1B configuration (present in GERONIMO-2398, please vote). Now it turns out that in order to swap these configs I am going to need to change almost all the other configs so they depend on my new one instead of the old one. This highlights a need for more functional-based dependencies. Conceptually we kind of want to say, this module depends on a module supplying services A, B, C One idea I had that might be pretty easy to implement would be to expand the explicit-versions resolving code a bit so that you can supply a properties file that says replace requests for artifactId X with artifactId Y and plug it in the the artifact resolver, configuration, and kernel so that when you ask for a gbean with artifactId X you get one with the same name map and interfaces but with artifactId Y. I think of this as aliasing X as Y (or maybe its vice-versa). I'm starting to try to implement this since I'm kind of blocked without something like this... but this might not be the best possible solution or even the easiest. Anyone want to comment or suggest better ideas? thanks david jencks
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
This is great news! Feels like we are getting very close to being able to move to J2SE 5 and Java EE 5! 1) Leave the Sun ORB code in the tree, make the yoko package a separate module that with a dependency on the openejb2 code. The existing build works ok, and the tests can be built for the Sun ORB. The build of the yoko package could then have its own versions of the tests, which would work find. 2) Replace the Sun ORB code with the yoko code and kick the Sun code into a separate module. Same things apply with the test. 3) Place both ORB adapters in outside modules, each with their own builds and tests. I prefer option 3 if I understand you correctly with this we can have an assembly that is intended to run on Sun JDK and one intended to run on Sun or anywhere else. On Issue #3 is it just a build problem? From the sound of it the code won't run if the Sun ORB code is in the bootstrap class path (as it would be on the Sun 1.4 JDK). If we go with option #3 above and completely remove our dependence on the Sun ORB then we could run just fine on the 1.4 JDK correct? If that is the case then I think dropping the Sun ORB ASAP (getting past the TCK etc.) is the way to go. I was also just looking at 2180 and noticed that the yoko dependencies are in maven, is it safe to pull them from there instead of using the attached zip file? I'm applying the patch now to play around with this, thanks again! TTFN, -bd- On Sep 14, 2006, at 12:56 PM, David Jencks wrote: Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/ browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non- Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee- corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. This sounds great! Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would
Re: We might need aliased modules/configurations/artifactIds
I sure wouldn't mind if a module could say I provide javax.foo.Bar and a separate module could say I require a parent that provides javax.foo.Bar... As in, interface dependencies instead of name-based dependencies. Thanks, Aaron On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I started working on a version of geronimo that uses the jta11 transaction manager in the sandbox. So, I wrote a new transaction configuration using the new gbean and started trying to assemble a server. My new config has gbeans with exactly the same names (except for artifactId) as the old jta 1.0.1B configuration (present in GERONIMO-2398, please vote). Now it turns out that in order to swap these configs I am going to need to change almost all the other configs so they depend on my new one instead of the old one. This highlights a need for more functional-based dependencies. Conceptually we kind of want to say, this module depends on a module supplying services A, B, C One idea I had that might be pretty easy to implement would be to expand the explicit-versions resolving code a bit so that you can supply a properties file that says replace requests for artifactId X with artifactId Y and plug it in the the artifact resolver, configuration, and kernel so that when you ask for a gbean with artifactId X you get one with the same name map and interfaces but with artifactId Y. I think of this as aliasing X as Y (or maybe its vice-versa). I'm starting to try to implement this since I'm kind of blocked without something like this... but this might not be the best possible solution or even the easiest. Anyone want to comment or suggest better ideas? thanks david jencks
[jira] Created: (SM-580) Support for standard POST request from the provider.
Support for standard POST request from the provider. - Key: SM-580 URL: https://issues.apache.org/activemq/browse/SM-580 Project: ServiceMix Issue Type: New Feature Components: servicemix-http Reporter: Jimmy Kongoli Priority: Minor Fix For: 3.1 Attachments: diff.txt We may run in situations where we need to POST the xml message to the provider in a post standard form named=value. Proposed solution: Add an optional parameter postParamName at http:endpoint. If the parameter is defined and http:endpoint soap parameter is false than - modify the http Contet-Type header to support Post method. - create the http post body postParamName=xml (message). I have attached a potential solution as a .diff file. -- 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: We might need aliased modules/configurations/artifactIds
This sounds a lot like OSGi. Felix might be a bit young but it seems like a big part of this functionality is covered there. Thoughts? -bd- On Sep 14, 2006, at 1:32 PM, Aaron Mulder wrote: I sure wouldn't mind if a module could say I provide javax.foo.Bar and a separate module could say I require a parent that provides javax.foo.Bar... As in, interface dependencies instead of name-based dependencies. Thanks, Aaron On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I started working on a version of geronimo that uses the jta11 transaction manager in the sandbox. So, I wrote a new transaction configuration using the new gbean and started trying to assemble a server. My new config has gbeans with exactly the same names (except for artifactId) as the old jta 1.0.1B configuration (present in GERONIMO-2398, please vote). Now it turns out that in order to swap these configs I am going to need to change almost all the other configs so they depend on my new one instead of the old one. This highlights a need for more functional-based dependencies. Conceptually we kind of want to say, this module depends on a module supplying services A, B, C One idea I had that might be pretty easy to implement would be to expand the explicit-versions resolving code a bit so that you can supply a properties file that says replace requests for artifactId X with artifactId Y and plug it in the the artifact resolver, configuration, and kernel so that when you ask for a gbean with artifactId X you get one with the same name map and interfaces but with artifactId Y. I think of this as aliasing X as Y (or maybe its vice-versa). I'm starting to try to implement this since I'm kind of blocked without something like this... but this might not be the best possible solution or even the easiest. Anyone want to comment or suggest better ideas? thanks david jencks
[jira] Created: (GERONIMO-2406) Provide Dojo AJAX library as a native webapp
Provide Dojo AJAX library as a native webapp Key: GERONIMO-2406 URL: http://issues.apache.org/jira/browse/GERONIMO-2406 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.2 Reporter: Paul McMahan Assigned To: Paul McMahan Providing the dojo library as a native webapp in Geronimo has the following benefits: - allows applications to use the native library instead of making a copy in each webapp - makes browser caching better when multiple applications in the same server use Dojo - allows the Dojo library to be upgraded and managed separately from the webapps that depend on it The proposal discussed on the dev list was to host the Dojo kitchen sink build at the /dojo context. See: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200608.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12434786 ] Paul McMahan commented on GERONIMO-2333: David, the trunk version of the patch didn't work for me. I may not have applied it correctly. I can see where the new portlet is registered in the console but when I try to start it I get a javascript error: Error: dojo.require is not a function Source File: http://localhost:8080/console/portal/JMXViewer Line: 22 followed by some more errors. BTW, I just created GERONIMO-2406 for separating the Dojo library into a separate webapp. If the JMX portlet goes in first then I can work with Chris to retrofit when GERONIMO-2406 is ready, or he may want to wait on it. Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- 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
Possible workspace for jetty 6 work and other jee5 stuff
I'm trying to get a jpa-aware server constructed so I can see if my code actually works so I've been setting up sandbox/jee5-jta so we can have jee5 modules, configs, and assemblies. I think this might be an ok place to work on other jee5 stuff like the jetty6 integration without duplicating the entire server and dealing with the associated update headaches. thoughts? thanks david jencks
Re: How to get predictable moduleId when using DeploymentManager.distribute()
Trying to avoid pulling in too much of the server for the plugin, so the plugin has a better hope of working with different versions of G. --jason On Sep 14, 2006, at 9:18 AM, Aaron Mulder wrote: OK. I guess the issue is that by default, the DeploymentManager expects a TargetModuleID which is assumed to be complete. We have to decide in this case whether we should just allow TargetModuleIDs that essentially have wildcards, or whether we should add some methods to our DeploymentManager subinterface that take arguments more like we want for this case. Do you guys asking for this care whether you're using the strict JSR-88 DeploymentManager interface or e.g. a GeronimoDeploymentManager interface? Thanks, Aaron On 9/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: I tried your suggestion about using just the artifactId in a mojo execution. That wouldn't work. However, it works as you said from the CLI. Cheers Prasad On 9/14/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Can I use the artifactId with javax.enterprise.deploy.spi.DeploymentManager and friends? I'll have to look -- I'm not sure whether the decode artifact to full module ID code is in the deployment tool or the deployment manager. But if it's not in the deployment manager today, we could certainly move it there. Can you try and if it doesn't work create a Jira? Thanks, Aaron On Sep 13, 2006, at 4:30 AM, Aaron Mulder wrote: First, if you specify a module ID in your plan, that will be used (or as much as you provide with defaults for the rest). And you can pack the plan in the module if you don't want to track it separately. Second, you can undeploy using only the artifact ID (so in your example, you could undeploy test-ear-j2ee_1.4-1.2- SNAPSHOT) so long as there aren't conflicts. The default artifact ID is the JAR name minus the extension. Thanks, Aaron On 9/13/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know how to get predictable moduleIds when using DeploymentManager.distribute()? I'd like to figure out how to get the moduleIds to be the same as the artifactId for the archive that is deployed, so that we can undeploy it after tests have been run. How can I do this? Do I need to specify a plan for the archive to tie it to a specific moduleId? I have been playing with test-ear-j2ee_1.4.ear, and it keeps generating stuff like 'default/test-ear-j2ee_1.4-1.2-SNAPSHOT/ 1158129807807/car' which is kinda hard to undeploy after that state has been lost. If I do need to specify a plan, can I tuck that into the .ear so that Maven does not need to worry about 2 artifacts for one deployment? --jason
[jira] Commented: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12434790 ] David Jencks commented on GERONIMO-2163: Greg and Jan can we take your comments as at least one binding +1 and poke gianni to improve the docs after commit? WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Priority: Minor Attachments: GERONIMO-2163-v3.patch, GERONIMO-2163-v3b.patch, GERONIMO-2163-v4-old.patch, GERONIMO-2163-v4.patch, GERONIMO-2163-v5-partial.patch, GERONIMO-2163-v5-plus.patch, GERONIMO-2163-v6.patch, GERONIMO-2163-v6b.patch, GERONIMO-2163-v6c.patch, geronimo-wadi-integration-preview.patch, geronimo-wadi-integration-RTC.patch, geronimo.patch, setUpServers.tar.gz, wadi-geronimo-integration-preview.patch, wadi.patch, wadi.zip Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- 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: We might need aliased modules/configurations/artifactIds
We definitely need some form of type/function/interface/whatever based dependencies. I'm working on a new core framework assembly (little-G without the containers ... micro-G? ) that we could use as a base for user created assemblies via plugins. This is really the same item that I think could solve the assembly proliferation issue (per the recent jetty 5 vs. jetty 6 discussion). One of the things that would be helpful for this micro-G is type based dependencies as mentioned here. We could then create plugins that had a requirement on a servlet container without the need to create two or more plugins for the various container we support). We could also define plugins that had cardinality rules associated with them (only install if no other plugin of similar type is installed) so that we won't end up with 2 web container vying for the same ports, etc... How we go about doing this is something that I haven't dug into yet but I think it would require some fundamental changes to the gBean infrastructure. Sorry to get so long winded. I hope this is still relevant to the thread you intended to start David. :-) Joe Aaron Mulder wrote: I sure wouldn't mind if a module could say I provide javax.foo.Bar and a separate module could say I require a parent that provides javax.foo.Bar... As in, interface dependencies instead of name-based dependencies. Thanks, Aaron On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I started working on a version of geronimo that uses the jta11 transaction manager in the sandbox. So, I wrote a new transaction configuration using the new gbean and started trying to assemble a server. My new config has gbeans with exactly the same names (except for artifactId) as the old jta 1.0.1B configuration (present in GERONIMO-2398, please vote). Now it turns out that in order to swap these configs I am going to need to change almost all the other configs so they depend on my new one instead of the old one. This highlights a need for more functional-based dependencies. Conceptually we kind of want to say, this module depends on a module supplying services A, B, C One idea I had that might be pretty easy to implement would be to expand the explicit-versions resolving code a bit so that you can supply a properties file that says replace requests for artifactId X with artifactId Y and plug it in the the artifact resolver, configuration, and kernel so that when you ask for a gbean with artifactId X you get one with the same name map and interfaces but with artifactId Y. I think of this as aliasing X as Y (or maybe its vice-versa). I'm starting to try to implement this since I'm kind of blocked without something like this... but this might not be the best possible solution or even the easiest. Anyone want to comment or suggest better ideas? thanks david jencks
[jira] Assigned: (AMQ-924) Patch to make activemq-cpp compile under sun studio 11
[ https://issues.apache.org/activemq/browse/AMQ-924?page=all ] Timothy Bish reassigned AMQ-924: Assignee: Timothy Bish Patch to make activemq-cpp compile under sun studio 11 -- Key: AMQ-924 URL: https://issues.apache.org/activemq/browse/AMQ-924 Project: ActiveMQ Issue Type: Improvement Components: CMS (C++ client) Environment: Sun Solaris 10 (SunOS chi-dev-chris1 5.10 Generic_118855-15 i86pc i386 i86pc Solaris) Studio 11 (Sun C++ 5.8 Patch 121018-04 2006/08/02) Reporter: Chris Knight Assigned To: Timothy Bish Priority: Minor Fix For: 4.x Attachments: PATCH Original Estimate: 0 minutes Remaining Estimate: 0 minutes Fixes compilation of activemq-cpp for studio 11 C++ compiler. Mostly additions of #include string.h and added namespace qualifiers std:: -- 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: Possible workspace for jetty 6 work and other jee5 stuff
On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I'm trying to get a jpa-aware server constructed so I can see if my code actually works so I've been setting up sandbox/jee5-jta so we can have jee5 modules, configs, and assemblies. I think this might be an ok place to work on other jee5 stuff like the jetty6 integration without duplicating the entire server and dealing with the associated update headaches. thoughts? Sounds good. BTW: Why do you use Donald Woods (JIRA) dev@geronimo.apache.org in the To: field? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: ApacheCon Attendance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: Who is planning on being at ApacheCon in Austin? I'll be there. - -- #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 iQCVAwUBRQm70prNPMCpn3XdAQJ9uQQAxCSsIGCeORaRlPSXI6dIt0yoecS9G/gG JeTK/ubKHsX+7CHtm2iT4co8VLdfUcU/ldLZIQeQglseu0cRO5Ml3WX8tyVCxvR4 96nLQcCvPqOyyvxgedZo0pwnJLUi+Gc91Wkn5c77igqExkgDAmzbdYQtMigJgViq qT3C+0C/7K4= =TEb6 -END PGP SIGNATURE-
[jira] Updated: (AMQ-924) Patch to make activemq-cpp compile under sun studio 11
[ https://issues.apache.org/activemq/browse/AMQ-924?page=all ] Chris Knight updated AMQ-924: - Attachment: PATCH makefile-solaris-debug.cfg makefile-solaris-release.cfg The 2nd patch fixes the unit tests. I have also included makefiles for studio 11. Patch to make activemq-cpp compile under sun studio 11 -- Key: AMQ-924 URL: https://issues.apache.org/activemq/browse/AMQ-924 Project: ActiveMQ Issue Type: Improvement Components: CMS (C++ client) Environment: Sun Solaris 10 (SunOS chi-dev-chris1 5.10 Generic_118855-15 i86pc i386 i86pc Solaris) Studio 11 (Sun C++ 5.8 Patch 121018-04 2006/08/02) Reporter: Chris Knight Assigned To: Timothy Bish Priority: Minor Fix For: 4.x Attachments: makefile-solaris-debug.cfg, makefile-solaris-release.cfg, PATCH, PATCH Original Estimate: 0 minutes Remaining Estimate: 0 minutes Fixes compilation of activemq-cpp for studio 11 C++ compiler. Mostly additions of #include string.h and added namespace qualifiers std:: -- 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: Possible workspace for jetty 6 work and other jee5 stuff
On Sep 14, 2006, at 4:27 PM, Jacek Laskowski wrote: On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I'm trying to get a jpa-aware server constructed so I can see if my code actually works so I've been setting up sandbox/jee5-jta so we can have jee5 modules, configs, and assemblies. I think this might be an ok place to work on other jee5 stuff like the jetty6 integration without duplicating the entire server and dealing with the associated update headaches. thoughts? Sounds good. BTW: Why do you use Donald Woods (JIRA) dev@geronimo.apache.org in the To: field? because I haven't figured out how to get apple mail to quit putting that in. Anyone have a clue about how to fix this? Help! Help! thanks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Possible workspace for jetty 6 work and other jee5 stuff
Open your address book, see if there is an entry that is being binded to that name.On Sep 14, 2006, at 4:37 PM, David Jencks wrote:On Sep 14, 2006, at 4:27 PM, Jacek Laskowski wrote: On 9/14/06, David Jencks [EMAIL PROTECTED] wrote: I'm trying to get a jpa-aware server constructed so I can see if mycode actually works so I've been setting up sandbox/jee5-jta so wecan have jee5 modules, configs, and assemblies. I think this mightbe an ok place to work on other jee5 stuff like the jetty6integration without duplicating the entire server and dealing withthe associated update headaches.thoughts? Sounds good.BTW: Why do you use "Donald Woods (JIRA)" dev@geronimo.apache.org inthe To: field? because I haven't figured out how to get apple mail to quit putting that in. Anyone have a clue about how to fix this? Help! Help!thanksdavid jencks Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
Bill Dudney wrote: This is great news! Feels like we are getting very close to being able to move to J2SE 5 and Java EE 5! 1) Leave the Sun ORB code in the tree, make the yoko package a separate module that with a dependency on the openejb2 code. The existing build works ok, and the tests can be built for the Sun ORB. The build of the yoko package could then have its own versions of the tests, which would work find. 2) Replace the Sun ORB code with the yoko code and kick the Sun code into a separate module. Same things apply with the test. 3) Place both ORB adapters in outside modules, each with their own builds and tests. I prefer option 3 if I understand you correctly with this we can have an assembly that is intended to run on Sun JDK and one intended to run on Sun or anywhere else. You can get that capability with all 3 of these. However, with option 1, the openejb2 code can only be built using the Sun 1.4.2 JDK. Option 1 has the smallest disruption to the existing code though, which is the only reason I included it in the list. We basically can jump in to the pool from the shallow end (option 1) or the deep end (option 3). My personal preference is 3 also. On Issue #3 is it just a build problem? From the sound of it the code won't run if the Sun ORB code is in the bootstrap class path (as it would be on the Sun 1.4 JDK). If we go with option #3 above and completely remove our dependence on the Sun ORB then we could run just fine on the 1.4 JDK correct? If that is the case then I think dropping the Sun ORB ASAP (getting past the TCK etc.) is the way to go. Issue #3 is a runtime issue, not just a built problem. The Sun ORB code is ALWAYS on the bootclass path, since it is part of the JVM. In particularly, the versions of the org.omg.* classes that come with the JVM are back level to (and incompatible with) the version that comes with Yoko. As a result, the Yoko code cannot run unless it is placed in endorsed.dir. However, when things are set up that way, then the Sun code has the same problemit won't run because of the same incompatibility. I was also just looking at 2180 and noticed that the yoko dependencies are in maven, is it safe to pull them from there instead of using the attached zip file? Yes...I hadn't realized that we'd been publishing Yoko snapshots to the repository yet. Assuming the snapshots are reasonably up-to-date, that version should work ok. I'm applying the patch now to play around with this, thanks again! TTFN, -bd- On Sep 14, 2006, at 12:56 PM, David Jencks wrote: Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non-Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee-corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this
multiple consumer threads in same program in STOMP issue
Hi, I am running into a strange issue, I created a consumer program using STOMP C which actually creates two separate consumer threads and both threads are reading from the same queue in the AMQ server using their own selectors on a header property. I was expecting that each thread will keep on consuming messages those who satisfy the selector conditions. But what happening here is at a time only one consumer thread is able to get its messages, another one just hangs. If I call disconnect in the thread which is working then only the hanged thread starts getting its messages. I will appreciate any explanation. Thanks! Vik
[jira] Commented: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12434823 ] Christopher M. Cardona commented on GERONIMO-2333: -- Thanks David for checking out the patch. Dojo needs to be unpacked since the browser needs to load those javascript files including some bitmap files used by the widgets. I also agree that a separate plugin/module will be a cleaner solution. Regarding horizontal versus vertical splitter, switching from one to the other is a simple change to the code. The reason why I decided to go with the horizontal orientation is because it's a common practice for GUIs to have the tree navigation on the leftmost area but I'm open to changing it if that's what we want. You made a very good point about data readability issues. We definitely need to address them as we go along. Thanks again for your help. Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2163) WADI Integration for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2163?page=comments#action_12434824 ] Greg Wilkins commented on GERONIMO-2163: Definitely a +1 from me. WADI Integration for Jetty -- Key: GERONIMO-2163 URL: http://issues.apache.org/jira/browse/GERONIMO-2163 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Priority: Minor Attachments: GERONIMO-2163-v3.patch, GERONIMO-2163-v3b.patch, GERONIMO-2163-v4-old.patch, GERONIMO-2163-v4.patch, GERONIMO-2163-v5-partial.patch, GERONIMO-2163-v5-plus.patch, GERONIMO-2163-v6.patch, GERONIMO-2163-v6b.patch, GERONIMO-2163-v6c.patch, geronimo-wadi-integration-preview.patch, geronimo-wadi-integration-RTC.patch, geronimo.patch, setUpServers.tar.gz, wadi-geronimo-integration-preview.patch, wadi.patch, wadi.zip Email sent to the dev@ list. Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts - geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above - geronimo-clustering-wadi; * new module to capture clustering builder contracts - geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above - Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted. Having said that, I have opened a JIRA such that people can have a look to the integration. Thanks, Gianny -- 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: gcache imlementation ideas[long]
On Sep 14, 2006, at 7:56 AM, Jeff Genender wrote: The JMS provider would be a pluggable comm strategy. For performance reasons, I want to start with TCP communication. Why do you think that AMQ will not perform well? I definitely want to have a JMS strategy...maybe next. But initially I don't want any dependencies on other servers or brokers. With that said, after looking at openwire, the comm marshaller for ActiveMQ, there is a lot to leverage there and will prevent a rewrite of the comm layer. So, there will be some use of that code base initially. IMO, AMQ already provides a rich clustering environment, with failover, master-slave, dynamic discovery, firewall-happy transports, monitoring and a heck of a lot more. Seems like it would be a waste to go and re-implement all of that. It also seems that if you wanted to get something up sooner, that it would be much easier to design a AMQ strategy first, which means that you only have to worry about the message passing to sync up and invalidate state, rather than all of the details of who is in what cluster, failing over, blah, blah... And, I guess that if after that was implemented you still thought it was not fast enough, then it might be better to get AMQ fixed to perform better, though I don't think that the performance using AMQ will differ all that much from a custom socket protocol to pass messages. I am a huge fan of AMQ and would really like to see G exploit its network communications facilities as much as possible. IMO, this is the best way to get the most features for clustering up and running sooner, with less code to maintain. --jason
[jira] Updated: (AMQ-918) Inactivity Monitor timeout does not on disconnected client does not cause blocked dispatch to client to fail.
[ https://issues.apache.org/activemq/browse/AMQ-918?page=all ] Jonas Lim updated AMQ-918: -- Fix Version/s: (was: 4.0.1) (was: 4.0.2) Edited fix versions to 4.1 and 4.0 only. 4.1 trunk (r443267) 4.0 branch (r443273) Inactivity Monitor timeout does not on disconnected client does not cause blocked dispatch to client to fail. - Key: AMQ-918 URL: https://issues.apache.org/activemq/browse/AMQ-918 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.0, 4.1 The cause is that inactivity timeout cause an async thread to call TransportConnection.stop() but it in turn tries to do a transport.oneway(new ShutdownInfo()); before a transport.stop(); Since another thread is currently stuck in the oneway() call (due to the client having disconnected but the OS has not thrown an IOException up to us yet), our ShutdownInfo message blocks too. So in essence the InactivityMonitor is not currently shutitng down the failed connections. -- 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-922) Add the ability to remove transport connectors dynamically
[ https://issues.apache.org/activemq/browse/AMQ-922?page=all ] Jonas Lim resolved AMQ-922. --- Resolution: Fixed fix applied to trunk (443534) Add the ability to remove transport connectors dynamically -- Key: AMQ-922 URL: https://issues.apache.org/activemq/browse/AMQ-922 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 Add a removeConnector() to BrokerServer to remove added transport connectors. -- 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
