Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 On Dec 6, 2007 3:43 PM, Rick McGuire [EMAIL PROTECTED] wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release activation and jsvamail spec jars + javamail provider jars.
+1 On Dec 7, 2007 1:01 PM, Rick McGuire [EMAIL PROTECTED] wrote: [ ] +1 - Release the jars [ ] 0 - No opinion [ ] -1 - Do not release the jars We're voting on the following which are required for the Geronimo 2.1 release: 1) Release 1.0.0 of the activation 1.1 spec API. The artifact in question is geronimo-activation_1.1_spec-1.0.1. This is the OSGIfied jar file, needed because of the javamail dependency. The release archive is located here: http://people.apache.org/~rickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-activation_1.1_spec-1.0.1.tar.gz The current branch used to build the release candidate is at https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1 The tag will be created at https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-activation_1.1_spec-1.0.1 2) Release 1.2 of the javamail 1.4 spec API. The artifact in question is geronimo-javamail_1.4_spec-1.2. This jar has the OSGI changes, plus a number of bug fixes. The release archive is located here: http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_spec-1.2.tar.gz The current branch used to build the release candidate is at https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.4_spec-1.2 The tag will be created at https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.2 3) Release 1.3 of the javamail 1.4 mail package. This package includes new providers for the imap, imaps, and pop3s protocols and a significantly rewritten version of the pop3 provider. This package has a top level pom and two child artifacts: top level pom: geronimo-javamail_1.4-1.3 javamail providers: geroinimo_javamail_1.4_provider-1.3 javamail mail:geroinimo_javamail_1.4_mail-1.3 The geroinimo_javamail_1.4_mail-1.3 artifact is the uber-jar containing the merged spec and provider class files. The release archive is located here: http://people.apache.org/~rickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gzhttp://people.apache.org/%7Erickmcguire/releases/geronimo-javamail_1.4_-1.3.tar.gz The source used to build this is located at https://svn.apache.org/repos/asf/geronimo/javamail/branches/geronimo-javamail_1.4-1.3 The tag will be created at https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.3 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (GERONIMO-3653) Getting java.lang.NoClassDefFoundError while starting geronimo as windows service
[ https://issues.apache.org/jira/browse/GERONIMO-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549989 ] Hirohsi.T commented on GERONIMO-3653: - Yes, I install Geronimo c:\geronimo-tomcat6-jee5-2.0.2 and Geronimo starts up fine without the wrapper. Getting java.lang.NoClassDefFoundError while starting geronimo as windows service -- Key: GERONIMO-3653 URL: https://issues.apache.org/jira/browse/GERONIMO-3653 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0.2 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.2, wrapper-windows-x86-32-3.2.3,Sun java 1.5.0_14 Reporter: Hirohsi.T Assignee: Jarek Gawor I am getting the following error while starting geronimo as a windows service. I am referring the following link. http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html Geronimo-tomcat6-jee5-2.0.1 startes well as a windows service, but with Geronimo-tomcat6-jee5-2.0.2, following error occurs. wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0_11)... jvm 1| Starting Geronimo Application Server v2.0.2 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apach... jvm 1| [*- ] 0% 1s Loading org.apach... jvm 1| [* ] 6% 1s Loading org.apach... jvm 1| [* ] 6% 1s Starting org.apach... jvm 1| [* ] 6% 2s Starting org.apach... jvm 1| [** ] 8% 2s Starting org.apach... jvm 1| [**- ] 8% 2s Loading org.apach... jvm 1| [** ] 9% 2s Loading org.apach... jvm 1| [*** ] 10% 2s Starting org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [*** ] 11% 2s Loading org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [ ] 13% 3s Starting org.apach... jvm 1| [-] 13% 3s Loading org.apach... jvm 1| [] 14% 3s Loading org.apach... jvm 1| [*] 15% 3s Starting org.apach... jvm 1| [*- ] 15% 3s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 5s Loading org.apach... jvm 1| [* ] 17% 5s Loading org.apach... jvm 1| [* ] 17% 5s Starting org.apach... jvm 1| [** ] 18% 5s Starting org.apach... jvm 1| [**- ] 18% 5s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [** ] 19% 6s Loading org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 11s Starting org.apach... jvm 1| [** ] 19% 11s
Re: [jira] Created: (GERONIMO-3687) classloader deadlock during server startup
Kevan, Your fix might have made the problem go way, but I think there's something else here that might merit a a second look. Look at the stack trace for the finalizer thread. Why is the finalizer calling the transform() method on the object getting finalized? I'm not even certain I understand this stack trace, as I would expect to see a finalize() method in the trace, but it jumps directly to the transform() method in sun.instrument.InstrumentationImpl. Rick Kevan Miller (JIRA) wrote: classloader deadlock during server startup -- Key: GERONIMO-3687 URL: https://issues.apache.org/jira/browse/GERONIMO-3687 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.2, 2.1 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.0.x, 2.1 I've been seeing regular deadlocks running Geronimo on Leopard. It's the same basic scenario as found in GERONIMO-3141. For some reason, the work around in 3141 doesn't work for me on Leopard. Just another hack and I'm sure we can fix this... Here's background info... $ ./geronimo.sh run Using GERONIMO_BASE: /Users/kevan/geronimo-jetty6-jee5-2.0.2 Using GERONIMO_HOME: /Users/kevan/geronimo-jetty6-jee5-2.0.2 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home You can then send the java process a QUIT signal (kill -3 pid) to have java dump out the thread stack traces. The deadlock occurs during a load of an Iterator class (IIRC). The JVM is not well behaved, IMO. Here's the thread stack traces that I get: Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode): Low Memory Detector daemon prio=5 tid=0x01009d60 nid=0x858800 runnable [0x..0x] CompilerThread0 daemon prio=9 tid=0x01009330 nid=0x857a00 waiting on condition [0x..0x] Signal Dispatcher daemon prio=9 tid=0x01008e60 nid=0x855e00 waiting on condition [0x..0x] Finalizer daemon prio=8 tid=0x01007d10 nid=0x81ba00 waiting for monitor entry [0xb0a05000..0xb0a05d90] at org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35) at sun.instrument.TransformerManager.transform(TransformerManager.java:122) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82) at java.lang.ref.Finalizer.access$100(Finalizer.java:14) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) Reference Handler daemon prio=10 tid=0x01007910 nid=0x81a200 in Object.wait() [0xb0984000..0xb0984d90] at java.lang.Object.wait(Native Method) - waiting on 0x05a735f8 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0x05a735f8 (a java.lang.ref.Reference$Lock) main prio=5 tid=0x010018b0 nid=0xb0801000 waiting for monitor entry [0xb07ff000..0xb0800188] at java.lang.ClassLoader.findBootstrapClass(Native Method) at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946) at java.lang.ClassLoader.loadClass(ClassLoader.java:308) - locked 0x05a75b78 (a sun.misc.Launcher$ExtClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280) - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374) - locked 0x05a73660 (a sun.misc.Launcher$AppClassLoader) VM Thread prio=9 tid=0x01007060 nid=0x809800 runnable VM Periodic Task Thread prio=9 tid=0x0100aa00 nid=0x859c00 waiting on condition Exception Catcher Thread prio=10 tid=0x01001b00 nid=0x80ae00 runnable Found one Java-level deadlock: = Finalizer: waiting to lock monitor 0x0081b070 (object 0x05a73660, a sun.misc.Launcher$AppClassLoader), which is held by main main: waiting to lock monitor 0x0081b094 (object 0x09584b40, a [[I), which is held by Finalizer Java stack information for the threads listed above: === Finalizer: at org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:35) at sun.instrument.TransformerManager.transform(TransformerManager.java:122) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82) at java.lang.ref.Finalizer.access$100(Finalizer.java:14) at
[RESULT] [VOTE] Make Yoko core orb a Yoko subproject.
The proposal to incorporate the Yoko core orb as a subproject of Geronimo has passed with 20 +1 votes and no 0 or -1 votes. Lars Kuhne, Alexey Petrenko, and Darren Middlemen will be extended invitations to become Geronimo commiters. Work to get the code moved into the Geronimo build tree should begin shortly. Rick
[jira] Created: (GERONIMO-3691) Unable to create Geronimo as a Windows Service using wrapper.exe
Unable to create Geronimo as a Windows Service using wrapper.exe Key: GERONIMO-3691 URL: https://issues.apache.org/jira/browse/GERONIMO-3691 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.1 Environment: Windows 2003, Intel Xeon , 2GB Ram, IBM Blade Server Reporter: Mark Salem Priority: Minor When trying to configure Geronimo as a windows service using the Instructions for wrapper and editing wrapper.conf when running g_service.bat to test the wrapper it fails when trying to calculate the checksum on config.ser, is this a known error or a configuration step that has been missed in the documentation? full error below C:\Documents and Settings\AdministratorC:\geronimo-jetty6-jee5-2.0.1\bin\g_service.bat wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0)... jvm 1| Starting Geronimo Application Server v2.0.1 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apache.ge...12:21:05,913 ERROR [ConfigurationStoreUtil] Unable to calculate checksum for configuration file: C:\geronimo-jetty6-jee 5-2.0.1\repository\org\apache\geronimo\configs\rmi-naming\2.0.1\rmi-naming-2.0.1.car\META-INF\config .ser jvm 1| java.security.NoSuchAlgorithmException: SHA-1 MessageDigest not available jvm 1| at sun.security.jca.GetInstance.getInstance(GetInstance.java:158) jvm 1| at java.security.Security.getImpl(Security.java:691) jvm 1| at java.security.MessageDigest.getInstance(MessageDigest.java:145) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote: 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. I'm not sure it really matters where the code goes in the interim. Plugins makes sense but I would move it to trunk first. Trunk is certainly viable and would likely get more people to look at the code, report issues, and most likely ooh and awe about cool looking graphs and statistics. If it turns out that the monitoring bloats the server in an unacceptable way, has incorrect statistics or consumes too many resources then I would think that moving it to plugins would be a reasonable approach. I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. But that is just my opinion.. Thanks Anita Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I'm with Matt on this. Since it is not perfect to everybody's satisfaction, let us move it to the /plugins tree (at least for now). Sandbox is definitely not the place for it. Erik, contrary to your belief, the /plugins tree does not contain only those plugins that work independent of G. It *mostly* contains plugins that integrate independent projects (like Liferay, ApacheDS, roller etc) with G. Now the monitoring plugin does not actually fit that bill. Neverthless, that is still a step above sandbox, and still on the road to trunk/plugins. It can still be released with 2.1 and still available in the plugins catalog for possible installation. Cheers Prasad On Dec 8, 2007 12:00 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote: 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I was thinking of plugins.. I'm not sure it really matters where the code goes in the interim. Plugins makes sense but I would move it to trunk first. Trunk is certainly viable and would likely get more people to look at the code, report issues, and most likely ooh and awe about cool looking graphs and statistics. If it turns out that the monitoring bloats the server in an unacceptable way, has incorrect statistics or consumes too many resources then I would think that moving it to plugins would be a reasonable approach.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 10, 2007, at 8:25 AM, Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. But that is just my opinion.. You make a good point. I think the correct decision would be what do the users want in terms of it being an integral part of what they do they would prefer to not go and install it but have it as part of the base install. I'd be ok with either approach. Most AppServers that I know of do ship their project with some minimal level of monitoring. Perhaps that is the JMXViewer. Although, I'd personally prefer the GUI of the console over the viewer but that is personal preferece.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Matt Hogstrom wrote: I think the correct decision would be what do the users want in terms of it being an integral part of what they do they would prefer to not go and install it but have it as part of the base install. I'd be ok with either approach. Most AppServers that I know of do ship their project with some minimal level of monitoring. Perhaps that is the JMXViewer. Although, I'd personally prefer the GUI of the console over the viewer but that is personal preferece. +1...these are my sentiments as well.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Anita Kulshreshtha wrote: I see Monitoring Console as a tool, a standard J2EE Application, that has been packaged for a convenient installation in Geronimo. It talks to a geronimo specific agent to discover and monitor a geronimo instance running elsewhere. I do not see it as an integral part of G, and hence prefer /plugins. Its location in svn does not affect the convenience of using it. It will always be installed from 'plugins' portlet and will be visible as an available plugin. IMHO, it should definitely be a plugin (as should everything we ship), but I think it should be a plugin that is installed by default. As pointed out in another email, monitoring is typically shipped and active in some form for most other application servers. If most of the users find it helpful to have automatically enabled, then its probably good that we do so. I would probably suggest as we get closer to a release date that we get more input from users on this subject so we can make a proper and informed decision. Jeff
[jira] Created: (GERONIMO-3692) Replace yoko snapshot version with known version from repository.
Replace yoko snapshot version with known version from repository. - Key: GERONIMO-3692 URL: https://issues.apache.org/jira/browse/GERONIMO-3692 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: CORBA Affects Versions: 2.1 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 2.1 2.1 is going to require a non-SNAPSHOT version of Yoko at ship. This will be replaced with a current build that resides in the Geronimo repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congrats Jay, welcome aboard! Cheers! Hernan Kevan Miller wrote: All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan
[jira] Commented: (GERONIMO-3605) GShell-ize deployer commands
[ https://issues.apache.org/jira/browse/GERONIMO-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550138 ] Jarek Gawor commented on GERONIMO-3605: --- Added wrappers for install-library, deploy, distribute, and redeploy commands (revision 602983). GShell-ize deployer commands Key: GERONIMO-3605 URL: https://issues.apache.org/jira/browse/GERONIMO-3605 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: Jarek Gawor Fix For: 2.1 make the cli deployer commands such as list-plugins accessible through gshell (and then remove the standalone deployer) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3693) monitoring client does not perform operations correctly
monitoring client does not perform operations correctly --- Key: GERONIMO-3693 URL: https://issues.apache.org/jira/browse/GERONIMO-3693 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Currently the second operand value is not being pulled from the mrc-server, instead there the second operand value is being assigned the first operand value. Additionally, the javascript that is generated from StatsGraph.java does not check to see if there is a division by zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3693) monitoring client does not perform operations correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3693: --- Attachment: geronimo-3693.patch monitoring client does not perform operations correctly --- Key: GERONIMO-3693 URL: https://issues.apache.org/jira/browse/GERONIMO-3693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3693.patch Currently the second operand value is not being pulled from the mrc-server, instead there the second operand value is being assigned the first operand value. Additionally, the javascript that is generated from StatsGraph.java does not check to see if there is a division by zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3692) Replace yoko snapshot version with known version from repository.
[ https://issues.apache.org/jira/browse/GERONIMO-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3692. -- Resolution: Fixed Committed revision 603021. Replace yoko snapshot version with known version from repository. - Key: GERONIMO-3692 URL: https://issues.apache.org/jira/browse/GERONIMO-3692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.1 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 2.1 2.1 is going to require a non-SNAPSHOT version of Yoko at ship. This will be replaced with a current build that resides in the Geronimo repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3605) GShell-ize deployer commands
[ https://issues.apache.org/jira/browse/GERONIMO-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550186 ] Jarek Gawor commented on GERONIMO-3605: --- Added wrapper for plugin-install command. Also improved list-plugins command and related code (mostly error checking and code reuse) (revision 603044). GShell-ize deployer commands Key: GERONIMO-3605 URL: https://issues.apache.org/jira/browse/GERONIMO-3605 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: Jarek Gawor Fix For: 2.1 make the cli deployer commands such as list-plugins accessible through gshell (and then remove the standalone deployer) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent
[ https://issues.apache.org/jira/browse/GERONIMO-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3686: -- Attachment: 3686.patch A suggested patch. It implements the features mentioned in the above comments. AsyncHttpClient does not reuse connection even if connections are persistent Key: GERONIMO-3686 URL: https://issues.apache.org/jira/browse/GERONIMO-3686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: 3686.patch Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is opened, even though connections may be kept alive per HTTP spec. If connections are kept open, they should be reused for more requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3693) monitoring client does not perform operations correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550221 ] Erik B. Craig commented on GERONIMO-3693: - Patch Committed revision 603080. Thanks Viet. monitoring client does not perform operations correctly --- Key: GERONIMO-3693 URL: https://issues.apache.org/jira/browse/GERONIMO-3693 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3693.patch Currently the second operand value is not being pulled from the mrc-server, instead there the second operand value is being assigned the first operand value. Additionally, the javascript that is generated from StatsGraph.java does not check to see if there is a division by zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GSHELL-46: -- Assignee: Jason Dillon (was: Jason Warner) Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Dillon Priority: Trivial Fix For: 1.0-alpha-2 Attachments: GShell-46.patch Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Minimal server startup issue
Jarek found a startup ordering issue in the minimal servers that I solved by explicitly specifying the property editor for the defaultEnvironment attributes. Rev. 603109. thanks david jencks
Re: Minimal server startup issue
Thanks for fixing this David! Jarek On Dec 10, 2007 9:14 PM, David Jencks [EMAIL PROTECTED] wrote: Jarek found a startup ordering issue in the minimal servers that I solved by explicitly specifying the property editor for the defaultEnvironment attributes. Rev. 603109. thanks david jencks
[jira] Commented: (GERONIMO-3653) Getting java.lang.NoClassDefFoundError while starting geronimo as windows service
[ https://issues.apache.org/jira/browse/GERONIMO-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550276 ] Hirohsi.T commented on GERONIMO-3653: - The problem was that wrapper.conf was incorrect. I added all jar-files of geronimo-tomcat6-jee5-2.0.2/lib to wrapper.java.classpath. I deleted some of them, and start up fine. Thanks. Getting java.lang.NoClassDefFoundError while starting geronimo as windows service -- Key: GERONIMO-3653 URL: https://issues.apache.org/jira/browse/GERONIMO-3653 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0.2 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.2, wrapper-windows-x86-32-3.2.3,Sun java 1.5.0_14 Reporter: Hirohsi.T Assignee: Jarek Gawor I am getting the following error while starting geronimo as a windows service. I am referring the following link. http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html Geronimo-tomcat6-jee5-2.0.1 startes well as a windows service, but with Geronimo-tomcat6-jee5-2.0.2, following error occurs. wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0_11)... jvm 1| Starting Geronimo Application Server v2.0.2 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apach... jvm 1| [*- ] 0% 1s Loading org.apach... jvm 1| [* ] 6% 1s Loading org.apach... jvm 1| [* ] 6% 1s Starting org.apach... jvm 1| [* ] 6% 2s Starting org.apach... jvm 1| [** ] 8% 2s Starting org.apach... jvm 1| [**- ] 8% 2s Loading org.apach... jvm 1| [** ] 9% 2s Loading org.apach... jvm 1| [*** ] 10% 2s Starting org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [*** ] 11% 2s Loading org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [ ] 13% 3s Starting org.apach... jvm 1| [-] 13% 3s Loading org.apach... jvm 1| [] 14% 3s Loading org.apach... jvm 1| [*] 15% 3s Starting org.apach... jvm 1| [*- ] 15% 3s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 5s Loading org.apach... jvm 1| [* ] 17% 5s Loading org.apach... jvm 1| [* ] 17% 5s Starting org.apach... jvm 1| [** ] 18% 5s Starting org.apach... jvm 1| [**- ] 18% 5s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [** ] 19% 6s Loading org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 11s Starting
[jira] Closed: (GERONIMO-3653) Getting java.lang.NoClassDefFoundError while starting geronimo as windows service
[ https://issues.apache.org/jira/browse/GERONIMO-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hirohsi.T closed GERONIMO-3653. --- Resolution: Invalid Getting java.lang.NoClassDefFoundError while starting geronimo as windows service -- Key: GERONIMO-3653 URL: https://issues.apache.org/jira/browse/GERONIMO-3653 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0.2 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.2, wrapper-windows-x86-32-3.2.3,Sun java 1.5.0_14 Reporter: Hirohsi.T Assignee: Jarek Gawor I am getting the following error while starting geronimo as a windows service. I am referring the following link. http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html Geronimo-tomcat6-jee5-2.0.1 startes well as a windows service, but with Geronimo-tomcat6-jee5-2.0.2, following error occurs. wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0_11)... jvm 1| Starting Geronimo Application Server v2.0.2 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apach... jvm 1| [*- ] 0% 1s Loading org.apach... jvm 1| [* ] 6% 1s Loading org.apach... jvm 1| [* ] 6% 1s Starting org.apach... jvm 1| [* ] 6% 2s Starting org.apach... jvm 1| [** ] 8% 2s Starting org.apach... jvm 1| [**- ] 8% 2s Loading org.apach... jvm 1| [** ] 9% 2s Loading org.apach... jvm 1| [*** ] 10% 2s Starting org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [*** ] 11% 2s Loading org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [ ] 13% 3s Starting org.apach... jvm 1| [-] 13% 3s Loading org.apach... jvm 1| [] 14% 3s Loading org.apach... jvm 1| [*] 15% 3s Starting org.apach... jvm 1| [*- ] 15% 3s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 5s Loading org.apach... jvm 1| [* ] 17% 5s Loading org.apach... jvm 1| [* ] 17% 5s Starting org.apach... jvm 1| [** ] 18% 5s Starting org.apach... jvm 1| [**- ] 18% 5s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [** ] 19% 6s Loading org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 11s Starting org.apach... jvm 1| [** ] 19% 11s Starting org.apach... jvm 1| [** ] 19% 12s Starting org.apach... jvm 1
[jira] Commented: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550278 ] Anita Kulshreshtha commented on GERONIMO-3678: -- This patch does not work. There is SQL error in 'insert into servers... at line 165 in o.a.g.plugin.monitoring.util.DBManager. The no. of columns do not match the no. of values supplied in the insert statement. Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550287 ] Viet Hung Nguyen commented on GERONIMO-3678: those sql statements should be deleted actually, that was why I did not update the statements. Right now, nothing shows up as being prepopulated in the DB. Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Minimal server startup issue
Hi, Thanks for having fixed this problem David. I may have introduced this bug while working on the property editor stuff. So, I will have a look at it and see if we can avoid this explicit registration of property editors. Thanks, Gianny On 11/12/2007, at 1:14 PM, David Jencks wrote: Jarek found a startup ordering issue in the minimal servers that I solved by explicitly specifying the property editor for the defaultEnvironment attributes. Rev. 603109. thanks david jencks
[jira] Created: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
gsh script in javaee5 server assemblies is not marked executable - Key: GERONIMO-3694 URL: https://issues.apache.org/jira/browse/GERONIMO-3694 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Kevan Miller Fix For: 2.1 'gsh' is not marked as executable. there seem to be different mechanisms for the different assemblies. looks like gsh is executable in framework/minimal assemblies (in fact all files are executable in the bin directory of these assemblies). Better if only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
[ https://issues.apache.org/jira/browse/GERONIMO-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550318 ] Kevan Miller commented on GERONIMO-3694: oops. that wasn't quite accurate Permissions are a problem if you use 'mvn -Ptools geronimo:install', seem to be ok, otherwise (would prefer that we only mark executable files as executable... gsh script in javaee5 server assemblies is not marked executable - Key: GERONIMO-3694 URL: https://issues.apache.org/jira/browse/GERONIMO-3694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Kevan Miller Fix For: 2.1 'gsh' is not marked as executable. there seem to be different mechanisms for the different assemblies. looks like gsh is executable in framework/minimal assemblies (in fact all files are executable in the bin directory of these assemblies). Better if only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3694) gsh script in javaee5 server assemblies is not marked executable
[ https://issues.apache.org/jira/browse/GERONIMO-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GERONIMO-3694: -- Assignee: Jason Dillon gsh script in javaee5 server assemblies is not marked executable - Key: GERONIMO-3694 URL: https://issues.apache.org/jira/browse/GERONIMO-3694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 2.1 'gsh' is not marked as executable. there seem to be different mechanisms for the different assemblies. looks like gsh is executable in framework/minimal assemblies (in fact all files are executable in the bin directory of these assemblies). Better if only shell scripts were marked executable... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3695) jaxws-tools (jar file, shell and bath files) disappeared from javaee assemblies
jaxws-tools (jar file, shell and bath files) disappeared from javaee assemblies --- Key: GERONIMO-3695 URL: https://issues.apache.org/jira/browse/GERONIMO-3695 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Jarek Gawor With some recent changes the jaxws-tools (jar file, shell and bath files) disappeared from javaee assemblies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
