Re: [ANNOUNCE] Welcoming Ted Kirby as a Geronimo Committer
Congrats Ted --Viet
Re: [VOTE] Server Repository plugin for Geronimo 2.1.1
+1 Viet
Re: [VOTE] ASF hosted machines for TCK Proposal
+1 Viet
Re: Google Analytics
can someone add me also ... [EMAIL PROTECTED] Thanks, Viet
Re: Questions about monitoring app/plugins
Hi David, You are right about not needing to wrap the ejb app inside an EAR. I think your patch attached with geronimo-4014 looks great. Regarding the JNDI look up in the jmx-jar, I resorted to using something like jca:/org.apache.geronimo.plugins/agent-ds/JCAManagedConnectionFactory/jdbc/ActiveDS because of the discussion taken place here: http://www.nabble.com/how-to-get-Datasource-from-a-non-j2ee-module-td15081831s134.html It also looks be to consistent with the format given on the wiki. Which JNDI string do you see a problem with? Thanks, Viet
Re: trunk build failre?
I cleaned my repo and rebuilt it just fine. -Viet On Thu, May 1, 2008 at 2:33 PM, Joe Bohn [EMAIL PROTECTED] wrote: I'm getting the following failures attempting to build trunk starting from a clean repo. Is it just me? [INFO] [compiler:compile] [INFO] Compiling 3 source files to /Users/bohn/geronimo/testsupport/testsupport-selenium/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/bohn/geronimo/testsupport/testsupport-selenium/src/main/java/org/apache/geronimo/testsupport/SeleniumTestSupport.java:[24,33] package com.thoughtworks.selenium does not exist /Users/bohn/geronimo/testsupport/testsupport-selenium/src/main/java/org/apache/geronimo/testsupport/SeleniumTestSupport.java:[26,34] package org.openqa.selenium.server does not exist /Users/bohn/geronimo/testsupport/testsupport-selenium/src/main/java/org/apache/geronimo/testsupport/SeleniumTestSupport.java:[28,30] package org.testng.annotations does not exist etc...
Re: [VOTE] Geronimo Server 2.1.1 Release - RC2
+1 --Viet On Sat, Apr 26, 2008 at 9:32 PM, Gianny Damour [EMAIL PROTECTED] wrote: +1 Thanks, Gianny On 24/04/2008, at 9:41 PM, Joe Bohn wrote: All, I've prepared a second release candidate of Geronimo Server 2.1.1 for your review and vote. The source for the Geronimo Server 2.1.1 release currently resides here: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.1 When the release vote is approved, I will svn mv the code to https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.1 An archive of this source code can be found here: http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo-2.1.1-src.tar.gz http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/ contains the 10 Java EE, Minimal, and Framework server binary distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES and source code archives for the release. For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo-jetty6-javaee5-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo-jetty6-minimal-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo-tomcat6-javaee5-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo-tomcat6-minimal-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo-framework-2.1.1-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.1-rc2/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Geronimo 2.1.1 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.1.1 (please provide rationale) I'll plan on calling this vote on Sunday evening (11 PM EST). I will start tck runs shortly on these images. Joe Bohn
Re: Dequeue count in JMS Resource portlet
Anish, Those statistics sounds great, but I do not think we should give the admin wrong statistics (esp if we know it's wrong). However, maybe you could include it for now, but disable them, so that when the bug is fixed you can enable it later. Thanks, Viet On Fri, Apr 18, 2008 at 8:37 AM, anish pathadan [EMAIL PROTECTED] wrote: Hi, I am trying to update the JMS Resource portlet with the queue statistics. I am adding the following information Consumer Count, Enqueue Count ,Dequeue Count and Queue Size. There is a bug in ActiveMQ https://issues.apache.org/activemq/browse/AMQ-1368 due to which each time after browsing messages the dequeue count becomes wrong. I want to know whether I should create the patch with the dequeue count hoping somebody will solve the issue later or not to show the dequeue count at all. -- Best Regards, Anish Pathadan
Re: [ANNOUNCE] Jason Warner as Geronimo's most recent committer
Congratulations Jason. -Viet
Re: svn commit: r639303 - in /geronimo/server/trunk/plugins/monitoring/agent-jar: ./ src/main/java/org/apache/geronimo/monitoring/snapshot/ src/xsd/
Thanks Donald, I took out the version tag and inserted
scopeprovided/scope.
--Viet
On Thu, Mar 20, 2008 at 8:35 PM, Donald Woods [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: viet
Date: Thu Mar 20 07:56:56 2008
New Revision: 639303
URL: http://svn.apache.org/viewvc?rev=639303view=rev
Log:
Fix for Geronimo-3925. Uses JAXB to manipulate XML.
Added:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
(with props)
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfig.java
(with props)
geronimo/server/trunk/plugins/monitoring/agent-jar/src/xsd/
geronimo/server/trunk/plugins/monitoring/agent-jar/src/xsd/SnapshotConfig.xsd
(with props)
Modified:
geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/SnapshotConfigXMLBuilder.java
Modified: geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml?rev=639303r1=639302r2=639303view=diff
==
--- geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml (original)
+++ geronimo/server/trunk/plugins/monitoring/agent-jar/pom.xml Thu Mar 20
07:56:56 2008
@@ -53,6 +53,18 @@
artifactIdgeronimo-j2ee-management_1.1_spec/artifactId
scopeprovided/scope
/dependency
+
+dependency
+groupIdjavax.xml.bind/groupId
+artifactIdjaxb-api/artifactId
+version2.0/version
Can you remove the explicit version and use the one set by
trunk/server/pom.xml?
+exclusions
+exclusion
+groupIdjavax.xml.bind/groupId
+artifactIdjsr173_api/artifactId
+/exclusion
+/exclusions
+/dependency
/dependencies
/project
Added:
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java?rev=639303view=auto
==
---
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
(added)
+++
geronimo/server/trunk/plugins/monitoring/agent-jar/src/main/java/org/apache/geronimo/monitoring/snapshot/ObjectFactory.java
Thu Mar 20 07:56:56 2008
@@ -0,0 +1,57 @@
+//
+// This file was generated by the JavaTM Architecture for XML
Binding(JAXB) Reference Implementation, v2.0-b26-ea3
+// See a
href=http://java.sun.com/xml/jaxb;http://java.sun.com/xml/jaxb/a
+// Any modifications to this file will be lost upon recompilation of the
source schema.
+// Generated on: 2008.03.18 at 12:52:02 AM GMT-05:00
+//
+
+
+package org.apache.geronimo.monitoring.snapshot;
+
+import javax.xml.bind.annotation.XmlRegistry;
+import org.apache.geronimo.monitoring.snapshot.SnapshotConfig;
+import org.apache.geronimo.monitoring.snapshot.SnapshotConfig.Mbeans;
+
+
+/**
+ * This object contains factory methods for each
+ * Java content interface and Java element interface
+ * generated in the org.apache.geronimo package.
+ * pAn ObjectFactory allows you to programatically
+ * construct new instances of the Java representation
+ * for XML content. The Java representation of XML
+ * content can consist of schema derived interfaces
+ * and classes representing the binding of schema
+ * type definitions, element declarations and model
+ * groups. Factory methods for each of these are
+ * provided in this class.
+ *
+ */
[EMAIL PROTECTED]
+public class ObjectFactory {
+
+
+/**
+ * Create a new ObjectFactory that can be used to create new
instances of schema derived classes for package: org.apache.geronimo
+ *
+ */
+public ObjectFactory() {
+}
+
+/**
+ * Create an instance of [EMAIL PROTECTED] Mbeans }
+ *
+ */
+public Mbeans createSnapshotConfigMbeans() {
+return new Mbeans();
+}
+
+/**
+ * Create an instance of [EMAIL PROTECTED] SnapshotConfig }
+ *
+ */
+public SnapshotConfig createSnapshotConfig() {
+return new SnapshotConfig();
+}
+
+}
Propchange:
Re: [DISCUSS] Geronimo 2.1 samples
On Tue, Mar 11, 2008 at 3:08 PM, Joe Bohn [EMAIL PROTECTED] wrote: Joe Bohn wrote: 3) Managing sample source. IMO the only place we should maintain source for the samples is in svn. I think Jarek managed to update all of the sample doc with references to the svn repo for each sample but I think there might be a place or two where we include a zip of the source in the wiki in addition to the SVN reference (at least I recall seeing some not too long ago). I plan to hunt them out and remove those attachments where they are already checked into svn. I deleted one reference to a sample source zip file in the wiki (ldap-sample-app) and then thought I should check into this a little more. :-) I spoke with Hernan and he indicated that we should have the zip files so that a user can download the source without having to install SVN. I can see the value in this but it is difficult to maintain. One option would be to create a zip per sample in the maven build and release them as additional artifacts along with the sample plugins, jars, ears, wars, etc... We could then reference the mirror locations of these zip files in the wiki pages. One other thing ... the zip file for the ldap sample seemed to contain more than just the source - it also included docs, javadoc, even copies of the wiki content. The jms-mdb-sample has similar contents. Does anybody know how/why all of this is included in the zip and if it is essential? If memory serves me, the included docs and wiki content is included as part of the new template that you will see once you view the sample web page. I think this is useful for users who want to understand the code better, faster, since javadocs aren't provided on the wiki itself. These docs are generated through maven, so inclusion or exclusion of them it easy. Regards, Viet Joe
Re: Diagnostic Utility For AG
Yo Joe, This is a really subjective problem that we're trying to tackle. There's not any type of barometer that will be able to tell us how well the Diagnostic Utility is working until we have significant participation from end-users. I think a good way to implement something like this is to have broad categories for different types of issues. There was a mention of using an md5 hash to map one person's problem to a wiki page. I do not think this is the best solution because it will be too issue-specific. If we imagine each wiki page as a bucket and each problem reported as an element which will belong to 1+ buckets, then we can see that when we have 1000 buckets each with 1 element, then it will be really hard to diagnose anything. However, if we have only 100 buckets (meaning broader categories) each with 10 elements, the problem will be (hopefully) easier to detect and fix. Maybe someone with more data mining experience can help out (because I have none), but I think we should break down a reported issue into certain keywords, and use those as a search criteria for the wiki. I think I got off topic...but I like Jason's answer. Thanks, Viet Also, I think this post is related to the topic here too: http://www.nabble.com/exception-handling---first-failure-diagnostic-capture-to15505337.html#a15505337.
Re: Diagnostic Utility For AG
On Feb 18, 2008 2:52 PM, Jason Warner [EMAIL PROTECTED] wrote: On Feb 18, 2008 2:46 PM, Viet Nguyen [EMAIL PROTECTED] wrote: Yo Joe, This is a really subjective problem that we're trying to tackle. There's not any type of barometer that will be able to tell us how well the Diagnostic Utility is working until we have significant participation from end-users. I think a good way to implement something like this is to have broad categories for different types of issues. There was a mention of using an md5 hash to map one person's problem to a wiki page. I do not think this is the best solution because it will be too issue-specific. If we imagine each wiki page as a bucket and each problem reported as an element which will belong to 1+ buckets, then we can see that when we have 1000 buckets each with 1 element, then it will be really hard to diagnose anything. However, if we have only 100 buckets (meaning broader categories) each with 10 elements, the problem will be (hopefully) easier to detect and fix. Use exception package names to create a reporting structure? That, but also the method calls in the stack trace should be somewhat similar (e.g. similar function calls from the same classes). I think it should be a mixture of things, not just one. Maybe someone with more data mining experience can help out (because I have none), but I think we should break down a reported issue into certain keywords, and use those as a search criteria for the wiki. I think I got off topic...but I like Jason's answer. Thanks, Viet Also, I think this post is related to the topic here too: http://www.nabble.com/exception-handling---first-failure-diagnostic-capture-to15505337.html#a15505337. -- ~Jason Warner
Re: Public Static Var, AG Server Path?
Joe, try this... System.getProperty(org.apache.geronimo.home.dir) -Viet On Feb 11, 2008 10:58 AM, Joseph Leong [EMAIL PROTECTED] wrote: Hi Everyone, Is there a public static variable or something globally accessible or located where i can grab the absolute path value for where AG is installed? Thanks! -Joseph leong
Re: branches/2.1 freeze notice
Erik, I do not think we should prevent this stack trace. I think it's important that the user knows what's up. So we should at least write it to a log. Thanks, Viet On Feb 8, 2008 12:14 PM, Erik B. Craig [EMAIL PROTECTED] wrote: Kevan, I have a very small change to make to mconsole-war/src/main/java/org/apache/geronimo/monitoring/console/MonitoringPortlet.java to prevent a potential stack trace if the user clicks the portlet 'edit' button at the top of the portlet. Would it be possible to get this in? Thanks, Erik B. Craig [EMAIL PROTECTED] On Feb 8, 2008 11:01 AM, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 6, 2008, at 10:29 AM, Kevan Miller wrote: All, In preparation for our 2.1 release, please hold off on any commits to branches/2.1. If you have something that you feel absolutely *must* be fixed, please check with me. I'll be working on generating a 2.1 release candidate later this afternoon/eveniing. OK. I've created branches/2.1.0 for the final release work. I've updated the versions on branches/2.1 to be 2.1.1-SNAPSHOT. So, branches/2.1 is open for business. Please don't make any updates to branches/2.1.0 --kevan
Re: branches/2.1 freeze notice
Erik, I thought you were talking about something else. And I like the change, thanks for noticing it. --Viet On Feb 8, 2008 12:41 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 8, 2008, at 12:14 PM, Erik B. Craig wrote: Kevan, I have a very small change to make to mconsole-war/src/main/java/org/ apache/geronimo/monitoring/console/MonitoringPortlet.java to prevent a potential stack trace if the user clicks the portlet 'edit' button at the top of the portlet. Would it be possible to get this in? Erik, You can commit to branches/2.1. If you and Viet are both happy with the change, and it's only within the monitoring console, then I may be able to merge it into release branch. --kevan
Re: Unable to shutdown G 2.1 server
Vamsi, I just tried it and it shuts down fine for me. -Viet On Jan 27, 2008 5:02 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I am unable to shutdown G 2.1 Tomcat server either from admin console or by pressing Ctrl+C in the command window on Windows XP. Has anyone else run into this situation? ++Vamsi
install-plugin option does not seem to be working
Hi All, I just checked out the latest trunk and am having trouble using the install-plugin option. Here is the stack trace 22:27:02,812 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/c ar?configurationName=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.configs/system-database/2.1-SNAPSHOT/car at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:160) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:312) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:633) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:559) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:799) at org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:730) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) 22:27:02,828 ERROR [PluginInstallerGBean] Unable to install plugin. org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:327) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:633) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:559) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:799) at org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:730) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car at
problems installing plugins
Hi All, Has anyone been able to install the mejb plugin onto a minimal assembly? I also tried to install openejb to see if it was just mejb, but I cannot successfully install the openejb plugin either. I get this : $ java -jar ./deployer.jar -u system -p manager install-plugin ../../../trunk/plugins/openejb/openejb/target/openejb-2.1-SNAPSHOT.car 16:40:07,703 WARN [AbstractGBeanReference] GBean references are not using proxies Checking for status every 1000ms: Finished downloading org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car (36 kB) (100%) Installation FAILED: null Is there something wrong with the plugin installer? -Viet
Re: Unable to add jar to Geronimo classpath
On Jan 2, 2008 12:24 PM, gersek [EMAIL PROTECTED] wrote: Hi, I am trying to deploy an ejb/web project and my ejb uses some utility classes from realMethodsFramework.jar. Below mentioned class FrameworkDAOSessionBean(com/framework/business/ejb/FrameworkDAOSessionBean) is inside the jar mentioned above. 1. I have added realMethodsFramework.jar to EJB project as J2EE module dependency. 2. It is in EAR root folder. 3. Tried to add to geronimo.bat as part of the classpath but no luck, I still get classnot found error. Can you please help me. Thanks Sekhar Hi Sekhar, Try moving the realMethodsFramework.jar to the root_dir/lib folder. It will make it into the classloader. Hope this helps, Viet Geronimo Application Server started 11:29:19,226 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: com/framework/business/ejb/FrameworkDAOSessionBean at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at org.apache.geronimo.kernel.classloader.TemporaryClassLoader.loadClass(TemporaryClassLoader.java:118) at org.apache.geronimo.kernel.classloader.TemporaryClassLoader.loadClass(TemporaryClassLoader.java:62) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at org.apache.geronimo.kernel.classloader.TemporaryClassLoader.loadClass(TemporaryClassLoader.java:118) at org.apache.geronimo.kernel.classloader.TemporaryClassLoader.loadClass(TemporaryClassLoader.java:62) at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:424) at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:330) at org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:152) at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:118) at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:332) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java:614) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.getEjbJarInfo(EjbModuleBuilder.java:551) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext(EjbModuleBuilder.java:473) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$$FastClassByCGLIB$$cd80af20.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:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$418759ca.initContext(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:576) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) 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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$42ad36bd.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:304) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
[DISCUSS] Monitoring Plugin to get stats through JMX or MEJB
Hi All, There was a recent discussion on whether the monitoring plugin should use JMX or MEJB to fetch Geronimo's statistics. Since we want to be able to monitor any type of Geronimo server, including little-G, it is not preferred that we have to pull in OpenEJB in order to monitor that server. Therefore, the JMX method looks like a potential alternative, because I do not think it will need to pull in any additional components. The idea of using JMX and MEJB is the same, and that is, we want to get a hold of the MBeanServer to query that for statistics. The concept of MEJB was defined in JSR-77, which is the only reason I am hesitant to start migrating over to using the JMX method. Should we strictly follow the JSR? or should we branch off and customize a little? Any thoughts or comments? Regards, Viet
Re: Monitoring console deadlock
Anita,
Thanks for testing the monitoring plugin, because we could definitely
use more of that. Have you been able to reproduce this problem lately?
I remember experiencing the same problem because the connections
weren't be closed at the right time, so I'm wondering if I didn't
catch all of the closes that should have been there.
Thanks,
Viet
On Dec 13, 2007 9:25 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
I was running monitoring console on G(portoffset=10) and the agent
on default G instance. I saw this trace on the screen at a later time.
So I can not describe what exactly I was doing.. This can probably be
fixed by ordering the sql operations correctly.
Thanks
Anita
14:48:27,968 ERROR [SnapshotDBHelper] A lock could not be obtained due
to a dead
lock, cycle of locks and waiters is:
Lock : ROW, SYSCOLUMNS, (4,17)
Waiting XID : {691, S} , MONITOR, INSERT INTO Statistics
(snapshot_time, stats
ValueList, mbeanId) VALUES
(119747609,'23209078,30091640,34628360,32094576',
5)
Granted XID : {693, X}
Lock : ROW, STATISTICS, (4,7)
Waiting XID : {693, S} , MONITOR, SELECT DISTINCT snapshot_time FROM
Statistic
s WHERE snapshot_time 1194896887609
Granted XID : {691, X}
. The selected victim is XID : 691.
ERROR 40001: A lock could not be obtained due to a deadlock, cycle of
locks and
waiters is:
Lock : ROW, SYSCOLUMNS, (4,17)
Waiting XID : {691, S} , MONITOR, INSERT INTO Statistics
(snapshot_time, stats
ValueList, mbeanId) VALUES
(119747609,'23209078,30091640,34628360,32094576',
5)
Granted XID : {693, X}
Lock : ROW, STATISTICS, (4,7)
Waiting XID : {693, S} , MONITOR, SELECT DISTINCT snapshot_time FROM
Statistic
s WHERE snapshot_time 1194896887609
Granted XID : {691, X}
. The selected victim is XID : 691.
at
org.apache.derby.iapi.error.StandardException.newException(Unknown So
urce)
at
org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown
Source)
at
org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Sourc
e)
at
org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown
Source)
at
org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown So
urce)
at
org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(Un
known Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknow
n Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknow
n Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRow
OnPage(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockSc
anRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockSc
anRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(U
nknown Source)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.TabInfoImpl.getRowInternal(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.TabInfoImpl.getRowLocation(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.computeRowLocati
on(Unknown Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.computeAutoincRo
wLocations(Unknown Source)
at org.apache.derby.impl.sql.compile.InsertNode.bind(Unknown
Source)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
Source)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepa
reInternalStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Sourc
e)
at
org.tranql.connector.jdbc.StatementHandle.executeUpdate(StatementHand
le.java:166)
at
org.apache.geronimo.monitor.snapshot.SnapshotDBHelper.addSnapshotToDB
(SnapshotDBHelper.java:229)
at
org.apache.geronimo.monitor.snapshot.SnapshotProcessor.takeSnapshot(S
napshotProcessor.java:79)
at
org.apache.geronimo.monitor.MasterRemoteControl.handleTimeout(MasterR
emoteControl.java:205)
at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invoc
ation.invoke(ReflectionInvocationContext.java:146)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proce
ed(ReflectionInvocationContext.java:129)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(Intercept
orStack.java:67)
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I am still unsure of why having the monitoring plugin in trunk is such a bad thing. It is in no way a perfect solution, but once it's in trunk we can engage users and other devs to better it. I do not see any dominating issues that should keep this plugin outside of trunk. Should we vote for this? Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? There are goods and bads to both sides to this. If we strictly follow JSR 77, which means we will use MEJB and are forced to have OpenEJB as a pre-req, we won't have to worry if our architecture is good or not (I hope this is right), because we're following a standard for monitoring and management. On the flip side, if we use JMX to get a hold of the statistics, we will be able to monitor any type of server. Doesn't necessarily have to be a Geronimo server either, as long as we can connect to it via JMX, which I think is a huge plus. With that said, I think if we decide to take the alternative JMX path, it can be changed later (even though this was originally how we implemented it). I think the important thing now, is to determine whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Monitoring Client may need a new graphing engine
I agree with Joe. I think having the x/y axis labels are very important, especially if we wish to allow the admin to customize these graphs. It will be rather confusing without them (unless we can write an extension for Simile to add this feature). Also, I like the curved lines. --Viet
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congrats Jay On Dec 5, 2007 12:47 PM, Erik B. Craig [EMAIL PROTECTED] wrote: Yay Jay! Thanks, Erik B. Craig [EMAIL PROTECTED] 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
[DISCUSS] Moving the Monitoring Plugin Into Trunk
Hi All, There has been a lot of work done on the monitoring plugin lately. I think it is now time to move it from sandbox into trunk, in time for the 2.1 release. I am unsure of the timeline for 2.1, but I feel as though the monitoring plugin should be moved to trunk around this time, so that the little kinks can be worked out before it is too late for the release. Erik and I have worked together along with the help of many others to provide a monitoring collecting agent and monitoring portlet. To briefly go over what the monitoring plugin can do: -monitor multiple servers -securely connects to remote servers that are monitored (via MEJB and encryption of the password using Geronimo's EncryptionManager) -keeps an on going history of user-chosen statistics -provides the ability to view current and past statistics -customizable graphs (e.g. I can choose which stats I want to graph, and much more) -the ability to group certain graphs together into what we call a view. The idea is to allow an administrator to view only those graphs that he cares about...all in one place! -editable server, graphs, and views option -provides the ability to keep track of any mbean that is declared as a StatisticsProvider -administrator can custom define the elapsed time period before each snapshot is taken -everything is packaged into plugins (separate plugins and a bundled plugin with both pieces), so deploying is made easier I hope that some of you can take some time to test out the plugin which can be pulled from sandbox at http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and provide some feedback. If there are no objections, I hope that a committer can soon move the monitoring plugin into trunk. One of the new features that I would like to see listed for the 2.1 release is this monitoring plugin. I believe it will attract a lot of attention and users. Thanks, Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007 9:23 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Dec 5, 2007, at 9:07 PM, David Jencks wrote: On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote: Viet, Thanks for working on the monitoring console. A lot still remains to be done. There are architectural issues which need to be addressed: Currently the agent (aka mrc-server) needs to reside in same jvm as the server being monitored. It consumes significant DB resources. While this might not be ideal (I don't know one way or another) does this make it useless? I'd be in favor of getting something out with some useful functionality now, and improving it as it gets used. I tend to agree. I'd like to give it a whirl. Erik/Viet are the installation instructions? The installation is pretty simple. Since everything is packaged into plugins there are two ways to do it. 1a. Just install the bundled (has both server and client) pluginit is monitor-tomcat/monitor-jetty 1b. Install the client plugin on a monitoring machine and the mrc-server on the server to be monitored. 2. Then you add the server to the list of monitored machines via the portlet You mention MEJB connections. Can you help me understand where the MEJB is running? The local server or the remote servers? The MEJB connections are done on the remote servers (those that are being monitored with the collecting agent). The collecting agent authenticates itself by having the client pass in the credentials. Then this collecting agent acts as the thin layer between the client and the MEJB, with additional functionality. --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Eric, For this discussion I will use MC for monitoring console (aka client), and agent for mrc-server. It is possible to use 3 G instances (I used this method until GERONIMO-3660). G1 with MC on remote or local m/c, G2 with agent on local m/c, and G3 the instance to be monitored. This is the ideal solution but will be most difficult to implement efficiently. The advantage is that the instance to be monitored is not corrupted in any way. The second option is to use 2 G instances. G1 with MC on remote or local m/c, G2 the instance to be monitored. The agent is loaded in G2. This is what we have now. we need to reduce DB activity. We can improve upon this as we go. The TimeSatistics has 4 values named count, max, min and totaltime. The graph treats count as the current value of time. This is because the information that it is a TimeStatistics is lost in the DB. All four values appear as separate statistics, and the graph would draw each one separately as value, min, max! The same is true for BoundedRangeStatistics. A single graph should show all 5 values. More inline.. The current implementation only allows for one statistic to be shown at a time on a graph, but if you wanted to have the max or min statistics that could be easily obtained since those numbers are there. I think allowing the admin to graph all 4 values on the same graph is a very useful feature and should definitely be added; However, this is not necessarily a stop ship issue. --- Erik B. Craig [EMAIL PROTECTED] wrote: Anita, You mentioned that the collecting agent running within the same jvm (I.E. under a Geronimo instance being monitored as a plugin) is an issue due to resource consumption... however I am unsure what a good alternative approach would be? Are you suggesting we have a separate instance of G to monitor a target instance? Or are you suggesting that the mrc-server be a standalone java app that runs in it's own JVM? This is a possibility too.. Currently the graph builder will plot any data being grabbed as snapshots in any method defined by the user. In the current graph creation page, the user has the option to differentiate between raw count vs. count/time or even count/some other count. There are a lot of options configurable by the user. When I added ErrorCount and ErrorCount/sec graphs to a single view, The other views got corrupted. This is a minor issue and can be easily fixed. Thanks Anita Additionally... do you have an example of the graphs for TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: How to get memory statistics from a remote Geronimo runtime?
You can do it that way or do it the JSR-77 way.
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.RemoteInitialContextFactory);
props.setProperty(Context.PROVIDER_URL, ejbd://localhost:4201);
props.setProperty(Context.SECURITY_PRINCIPAL, username);
props.setProperty(Context.SECURITY_CREDENTIALS, password);
props.setProperty(openejb.authentication.realmName,
geronimo-admin);
InitialContext ctx = new InitialContext(p);
ManagementHome mejbHome =
(ManagementHome)ctx.lookup(ejb/mgmt/MEJBRemoteHome);
mejb = mejbHome.create();
Stats stats = (Stats)mejb.getAttribute(new
ObjectName(mbean_name_here), stats);
Hope this helps,
Viet Nguyen
On Dec 3, 2007 1:52 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to get
maxHeapSize and usedMemory from a remote Geronimo server.
import org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user, password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector = JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName =
ObjectName.getInstance(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats) mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic = (BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Re: svn commit: r600692 - in /geronimo/sandbox/monitoring: client/client-war/src/main/java/org/apache/geronimo/plugins/monitoring/client/ client/client-war/src/main/java/org/apache/geronimo/plugins/mo
Hi Gianny, I'm glad you have been following the monitoring plugin progress. Testing was actually my next step. Thanks, Viet On Dec 3, 2007 7:14 PM, Gianny Damour [EMAIL PROTECTED] wrote: Hi, I quickly had a look to the monitoring components. I think it is going well. Though, I have one comment: is it possible to increase unit testing? Thanks, Gianny On 04/12/2007, at 8:16 AM, [EMAIL PROTECTED] wrote: Author: ecraig Date: Mon Dec 3 13:16:49 2007 New Revision: 600692 URL: http://svn.apache.org/viewvc?rev=600692view=rev Log: GERONIMO-3666 monitoring plugin to provide for a way to access archive data Patch by Viet Nguyen.
Re: [jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0
Hi Jay, Is there a reason why you just want Dojo 1.0 and scratch 0.4.3? I think it's easier for users who have already tuned their applications to use 0.4.3, to have both versions in there. I do not think Dojo will take up a significant amount of space. This way, we don't have to necessarily rewrite all modules that use Dojo 0.4.3. Regards, Viet
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: Can we deal generically with container specific jsr77 statistics?
I believe Anita is correct on this one. The specs define that we need the getXYZ() methods for each statistics named XYZ. At this point, I think we need to move forward with a decision a) put everything in g-management or b) split jetty/tomcat stats apart. As for me, I say let's just go with option A. In order for the monitoring plugin to work on both assemblies this issue needs to be resolved. If we plan on releasing the monitoring plugin with 2.1, we'll need to have time to test it on both assemblies. Thanks, Viet
Re: Can we deal generically with container specific jsr77 statistics?
I suggest we have in geronimo-management a StatsImpl class similar to the existing one but taking the name-statistic map in its constructor and being immutable. Then the jetty/tomcat specific stats classes won't implement Stats at all but just the container specific method. Instead of extending StatsImpl they will delegate to an instance they create in their constructor. The MEJB can return the delegate StatsImpl objects, thus avoiding any need for any container specific classes, and the container specific adapters can be in with the containers. I noticed that in the JSR 77 spec, the generic classes such as EJBModuleStats extends Stats. Meaning the EJBModuleStatsImpl will extend StatsImpl, the way things are with the Jetty/Tomcat specific stats right now. So if we took the specific Jetty/Tomcat stats code (something that is not defined by JSR-77) and used the technique you suggested, David, do you think that will be a tolerable inconsistency? I have tested your idea and everything works fine. If there are no objections I can put a create a new jira along with the patch. -Viet Comments? thanks david jencks
Re: problems with installing plugin
) at org.apache.geronimo.kernel.util.MainBootstrapper.loadPersistentConfigurations(MainBootstrapper.java:56) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:58) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) David, have you tried to install a plugin through the commandline? Thanks, Viet On Nov 4, 2007 3:41 AM, David Jencks [EMAIL PROTECTED] wrote: On Nov 3, 2007, at 1:48 PM, Viet Nguyen wrote: Hi All, Since yesterday, when I pulled down the latest trunk with the new structure, I have been unable to install any plugins. I get these warnings from the server's console [INFO] 15:45:06,864 WARN [PropertiesFileLoginModule] Ignoring option: org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL. Not supported. [INFO] 15:45:06,865 WARN [PropertiesFileLoginModule] Ignoring option: org.apache.geronimo.security.realm.GenericSecurityRealm.CLASSLOADER. Not supported. [INFO] 15:45:06,865 WARN [PropertiesFileLoginModule] Ignoring option: org.apache.geronimo.security.realm.GenericSecurityRealm.SERVERINFO. Not supported. These don't indicate that anything is wrong except perhaps that we are now checking too much in our login modules. and this error message from the terminal in which I tried to install the plugin [EMAIL PROTECTED]:~/g/trunk/target/geronimo-tomcat6- javaee5-2.1-SNAPSHOT/bin$ java -jar ./deployer.jar -u system -p manager install-plugin /home/vhnguy2/Desktop/activemq.car Checking for status every 1000ms: Finished downloading org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car (32 kB) (100%) Installation FAILED: No server instance configuration set up for name default I made a couple dumb mistakes in the ServerInstance gbean that I believe I've now fixed (rev 591737). I could install a plugin using the console with these changes (most of which are not relevant to this problem). Is anyone else having this problem? I did :-) thanks for pointing this out! david jencks Thanks, Viet
problems with installing plugin
Hi All, Since yesterday, when I pulled down the latest trunk with the new structure, I have been unable to install any plugins. I get these warnings from the server's console [INFO] 15:45:06,864 WARN [PropertiesFileLoginModule] Ignoring option: org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL. Not supported. [INFO] 15:45:06,865 WARN [PropertiesFileLoginModule] Ignoring option: org.apache.geronimo.security.realm.GenericSecurityRealm.CLASSLOADER. Not supported. [INFO] 15:45:06,865 WARN [PropertiesFileLoginModule] Ignoring option: org.apache.geronimo.security.realm.GenericSecurityRealm.SERVERINFO. Not supported. and this error message from the terminal in which I tried to install the plugin [EMAIL PROTECTED]:~/g/trunk/target/geronimo-tomcat6-javaee5-2.1-SNAPSHOT/bin$ java -jar ./deployer.jar -u system -p manager install-plugin /home/vhnguy2/Desktop/activemq.car Checking for status every 1000ms: Finished downloading org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car (32 kB) (100%) Installation FAILED: No server instance configuration set up for name default Is anyone else having this problem? Thanks, Viet
Re: Question about a sample Application
On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi , we are working on the geronimo one project. We were looking at a sample application that connects to the database in geronimo . Upone studying it we stumbled upon a syntax that has a little confused In your DBManager.java for the inventory application we found this line of code. DataSource ds = (DataSource)context.lookup(java:comp/env/jdbc/InventoryDS); The parameter represents the JNDI name of a datasource. Once you deploy the application, go to the Administration Console, then click on JNDI Viewer on the left panel. It will show you a tree of the JNDI names. We know what the function does . We just don't know what the parameter represents. Which part of the parameter represents the database we are connecting to? We need to know the nature of the parameter so that we can use it in our own application. The parameter does not specify which DB you are connecting to. What it does, is specify which DataSource you wish to use. The DataSource will specify which DB to connect to. So it's YourApp -- DataSource -- Database The DataSource is defined by 'InventoryPool.xml.' Hope this helps, Viet
Re: Interested in Contributing
Hey Joe, You can contribute all you want. Just make sure that jira is actually still valid though, since it was opened a while back. Regards, Viet On 10/22/07, Joseph Leong [EMAIL PROTECTED] wrote: I'm really interested in contributing to this project, and i saw Jira GERONIMO-2251 was available. Seems like a good one to get my feet wet. I'm not too familiar with what the etiquette is in the geronimo community... is it free game for me to take a stab at it? Thanks, Joseph Leong
Re: Jetty Connector Statistics?
After digging into Jetty's code for more information on how AbstractConnectors work, I found out that the statistics do not change unless the connection is closed. The only instances in their code where any of the statistics change are in statsReset(), connectionOpened(), and connectionClosed(). Therefore, the statistics that they provide will not be live stats because things such as number of requests are not updated until connectionClosed() is called. I used http://www.mortbay.org/xref/org/mortbay/jetty/AbstractConnector.htmlas my reference. Thanks, Viet On 10/2/07, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Jetty AbstractConnector provides many statistics. A few of these are listed as undefined if statsOn is false. Does this mean others are valid values at all time? If statsOn is true, how often are the value updated? Any help from Jetty experts will be greatly appreciated. TIA Anita Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433
JMS Statistics
Hi All, I have been poking around JMS (ActiveMQ) to see if we can surface some JSR-77 statistics. To my knowledge, there are not any JMS stats being surfaced right now. I have looked at modules/geronimo-activemq and am confused as to how I can get a hold of these statistics. I have looked at some API docs for ActiveMQ and found out that they actually implemented all of the JSR-77 stats on their side and all we should need to do is request it. Classes such as ActiveMQConnection ( http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/ActiveMQConnection.html) will keep track of some of the stats. By calling getConnectionStats() the JSR-77 stats for JMSConnectionStats will be returned in its updated state. I am not a JMS/ActiveMQ expert so, if someone could tell me if tying classes such as ActiveMQConnection into Geronimo's source is a viable proposal, it will be much appreciated. Also, I've noticed that there are implementation classes for JCA stats in ActiveMQ too. Is there a way to get these into Geronimo? Thanks, Viet
Re: Adding j2g to site
let's move it to dev tools first, +1
Re: Adding j2g to site
With the recent activity and interest on the user/dev list with people who are actually USING the j2g migration tool, I think we really need to make these documents easily available asap. I believe that the J2G link should reside under the Subprojects category on our main page. This way the tool itself will get more exposure and hopefully be easier to find for those who are interested in developing and/or testing it out. Maybe even post something about J2G under the News section to make sure it will be more visible to those who are new. Thanks, Viet Nguyen
