Re: How to get memory statistics from a remote Geronimo runtime?
On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
It is not clear to me if this is part of the earlier code or a
separate program. If it is part of the JMX code, then Runtime is from
the local jvm not remote. The non heap Memory for this program in
either case is negligible.
You could start G with -Dcom.sun.management.jmxremote. Start
jconsole and click on the Memory tab to get the whole picture.
I have started G with the said option and hooked up jconsole. The
HeapMemoryUsage is showing exactly what Runtime is returning.
It is only the heap memory exhaustion that results in OOME. I guess I am ok
for now as this is what I am interested in.
Hope this is helpful
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know why the non heap memory is missing in the equations.
The
equations I gave are based what I observed by running the following
code.
MemoryMXBean memmxbean =
ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory.
In
other words you need to add contribution from non heap Memory to
all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from
Runtime.
Here is
the relationship I see between the stats from Runtime and those
got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() ==
MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- 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
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: svn commit: r601152 [3/4] - in /geronimo/server/trunk: ./ applications/welcome/geronimo-welcome/src/main/java/org/apache/geronimo/welcome/ assemblies/geronimo-boilerplate-minimal/src/main/underlay
On Dec 4, 2007, at 6:26 PM, Anita Kulshreshtha wrote:
Is the version temporary? Could you have used geronimoVersion
property instead of 2.1-SNAPSHOT?
I hope I can get rid of the version element again. I'm hoping to fix
up the plugin repo code so that file system plugin repositories work
at which point a lot of explicit versions won't be required. If that
doesn't work then all the 2.1-SNAPSHOTS need to be turned into $
{version} or ${geronimoVersion}. I'm not sure which would work better?
thanks
david jencks
Thanks
Anita
--- [EMAIL PROTECTED] wrote:
Modified:
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
ExplicitDefaultArtifactResolver.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-system/src/main/java/org/apache/geronimo/system/
resolver/ExplicitDefaultArtifactResolver.java?
rev=601152r1=601151r2=601152view=diff
==
---
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
ExplicitDefaultArtifactResolver.java
(original)
+++
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
ExplicitDefaultArtifactResolver.java
Tue Dec 4 15:49:03 2007
@@ -38,14 +38,14 @@
/**
* @version $Rev$ $Date$
*/
-public class ExplicitDefaultArtifactResolver extends
DefaultArtifactResolver implements AliasedArtifactResolver {
+public class ExplicitDefaultArtifactResolver extends
DefaultArtifactResolver implements LocalAliasedArtifactResolver {
private static final String COMMENT = #You can use this file to
indicate that you want to substitute one module for another.\n +
#format is oldartifactid=newartifactId e.g.\n +
#org.apache.geronimo.configs/transaction//
car=org.apache.geronimo.configs/transaction-jta11/1.2-SNAPSHOT/car\n
+
#versions can be ommitted on the left side but not the
right.\n +
#This can also specify explicit versions in the same
format.;
-private final String versionMapLocation;
+private final String artifactAliasesFile;
private final ServerInfo serverInfo;
public ExplicitDefaultArtifactResolver(String
versionMapLocation,
@@ -53,10 +53,15 @@
Collection? extends ListableRepository repositories,
ServerInfo serverInfo ) throws IOException {
super(artifactManager, repositories,
buildExplicitResolution(versionMapLocation, serverInfo));
-this.versionMapLocation = versionMapLocation;
+this.artifactAliasesFile = versionMapLocation;
this.serverInfo = serverInfo;
}
+
+public String getArtifactAliasesFile() {
+return artifactAliasesFile;
+}
+
private static MapArtifact, Artifact
buildExplicitResolution(String versionMapLocation, ServerInfo
serverInfo) throws IOException {
if (versionMapLocation == null) {
return null;
@@ -123,7 +128,7 @@
public synchronized void addAliases(Properties properties)
throws IOException {
MapArtifact, Artifact explicitResolutions =
propertiesToArtifactMap(properties);
getExplicitResolution().putAll(explicitResolutions);
-saveExplicitResolution(getExplicitResolution(),
versionMapLocation, serverInfo);
+saveExplicitResolution(getExplicitResolution(),
artifactAliasesFile, serverInfo);
}
public static final GBeanInfo GBEAN_INFO;
Added:
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
LocalAliasedArtifactResolver.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-system/src/main/java/org/apache/geronimo/system/
resolver/LocalAliasedArtifactResolver.java?rev=601152view=auto
==
---
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
LocalAliasedArtifactResolver.java
(added)
+++
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
LocalAliasedArtifactResolver.java
Tue Dec 4 15:49:03 2007
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR
[jira] Updated: (GERONIMO-3673) MessageDrivenBean injection issue
[ https://issues.apache.org/jira/browse/GERONIMO-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Mazan updated GERONIMO-3673: --- Attachment: ejb-jar.xml MessageDrivenBean injection issue - Key: GERONIMO-3673 URL: https://issues.apache.org/jira/browse/GERONIMO-3673 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2 Reporter: Tomasz Mazan Attachments: ejb-jar.xml, JmsRequestFeedbackBean.java, metadata-complete-dd.xml, openejb-jar.xml I found problem with injecting Jms ConnectionFactory to my MDB, which needs it to send message to queue different to that it's listening to. During deployment I get only WARN in my logs: iWARN [OpenEJB] Injection data not found in enc: jndiName='DispatcherJmsXAConnectionFactory', target=class myapp.dispatcher.feedback.JmsRequestFeedbackBean/jmsConnFactory/i and during application's work NullPointerException when I try to access this jmsConnFactory property. With David Jenks we investingated strange form of metadata complete deployment descriptor. It indicates a kind of bug with deploying application regards Beniamin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3673) MessageDrivenBean injection issue
[ https://issues.apache.org/jira/browse/GERONIMO-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Mazan updated GERONIMO-3673: --- Attachment: JmsRequestFeedbackBean.java MessageDrivenBean injection issue - Key: GERONIMO-3673 URL: https://issues.apache.org/jira/browse/GERONIMO-3673 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2 Reporter: Tomasz Mazan Attachments: ejb-jar.xml, JmsRequestFeedbackBean.java, metadata-complete-dd.xml, openejb-jar.xml I found problem with injecting Jms ConnectionFactory to my MDB, which needs it to send message to queue different to that it's listening to. During deployment I get only WARN in my logs: iWARN [OpenEJB] Injection data not found in enc: jndiName='DispatcherJmsXAConnectionFactory', target=class myapp.dispatcher.feedback.JmsRequestFeedbackBean/jmsConnFactory/i and during application's work NullPointerException when I try to access this jmsConnFactory property. With David Jenks we investingated strange form of metadata complete deployment descriptor. It indicates a kind of bug with deploying application regards Beniamin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3673) MessageDrivenBean injection issue
[ https://issues.apache.org/jira/browse/GERONIMO-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Mazan updated GERONIMO-3673: --- Attachment: openejb-jar.xml MessageDrivenBean injection issue - Key: GERONIMO-3673 URL: https://issues.apache.org/jira/browse/GERONIMO-3673 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2 Reporter: Tomasz Mazan Attachments: ejb-jar.xml, JmsRequestFeedbackBean.java, metadata-complete-dd.xml, openejb-jar.xml I found problem with injecting Jms ConnectionFactory to my MDB, which needs it to send message to queue different to that it's listening to. During deployment I get only WARN in my logs: iWARN [OpenEJB] Injection data not found in enc: jndiName='DispatcherJmsXAConnectionFactory', target=class myapp.dispatcher.feedback.JmsRequestFeedbackBean/jmsConnFactory/i and during application's work NullPointerException when I try to access this jmsConnFactory property. With David Jenks we investingated strange form of metadata complete deployment descriptor. It indicates a kind of bug with deploying application regards Beniamin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3673) MessageDrivenBean injection issue
[ https://issues.apache.org/jira/browse/GERONIMO-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Mazan updated GERONIMO-3673: --- Attachment: metadata-complete-dd.xml MessageDrivenBean injection issue - Key: GERONIMO-3673 URL: https://issues.apache.org/jira/browse/GERONIMO-3673 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2 Reporter: Tomasz Mazan Attachments: ejb-jar.xml, JmsRequestFeedbackBean.java, metadata-complete-dd.xml, openejb-jar.xml I found problem with injecting Jms ConnectionFactory to my MDB, which needs it to send message to queue different to that it's listening to. During deployment I get only WARN in my logs: iWARN [OpenEJB] Injection data not found in enc: jndiName='DispatcherJmsXAConnectionFactory', target=class myapp.dispatcher.feedback.JmsRequestFeedbackBean/jmsConnFactory/i and during application's work NullPointerException when I try to access this jmsConnFactory property. With David Jenks we investingated strange form of metadata complete deployment descriptor. It indicates a kind of bug with deploying application regards Beniamin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3673) MessageDrivenBean injection issue
MessageDrivenBean injection issue - Key: GERONIMO-3673 URL: https://issues.apache.org/jira/browse/GERONIMO-3673 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.2 Reporter: Tomasz Mazan Attachments: ejb-jar.xml, JmsRequestFeedbackBean.java, metadata-complete-dd.xml, openejb-jar.xml I found problem with injecting Jms ConnectionFactory to my MDB, which needs it to send message to queue different to that it's listening to. During deployment I get only WARN in my logs: iWARN [OpenEJB] Injection data not found in enc: jndiName='DispatcherJmsXAConnectionFactory', target=class myapp.dispatcher.feedback.JmsRequestFeedbackBean/jmsConnFactory/i and during application's work NullPointerException when I try to access this jmsConnFactory property. With David Jenks we investingated strange form of metadata complete deployment descriptor. It indicates a kind of bug with deploying application regards Beniamin -- 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
Excellent news. Congrats Jay! Joe 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
[BUILD] 2.1: Failed for Revision: 601339
OpenEJB trunk at 601323 Geronimo Revision: 601339 built with tests included See the full build-0900.log file at http://people.apache.org/~prasad/binaries/trunk/20071205/build-0900.log from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Path to dependency: 1) org.apache.geronimo.modules:geronimo-webservices:jar:2.1-SNAPSHOT at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information: Unable to read the metadata file for artifact 'org.apache.ws.scout:scout:jar': Cannot find parent: org.apache.ws.scout:scout-parent for project: null:scout:jar:1.0rc1 for project null:scout:jar:1.0rc1 org.apache.ws.scout:scout:jar:1.0rc1 from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Path to dependency: 1) org.apache.geronimo.modules:geronimo-webservices:jar:2.1-SNAPSHOT at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:362) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file for artifact 'org.apache.ws.scout:scout:jar': Cannot find parent: org.apache.ws.scout:scout-parent for project: null:scout:jar:1.0rc1 for project null:scout:jar:1.0rc1 at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:134) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:339) ... 22 more Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.ws.scout:scout-parent for project: null:scout:jar:1.0rc1 for project null:scout:jar:1.0rc1 at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1261) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:747) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository
[jira] Created: (GERONIMO-3675) monitoring client incorrectly pads graph's statistics
monitoring client incorrectly pads graph's statistics - Key: GERONIMO-3675 URL: https://issues.apache.org/jira/browse/GERONIMO-3675 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Critical Attachments: geronimo-3675.patch The monitoring client has problems when it attempts to pad some graph's stats with 0's. The result is that only a couple of snapshots are retained at the end of the process. Thus, the graph cannot be drawn at times. Additionally, if the timeframe of a graph is specified to be anywhere from greater than 7 days to less than 30 days, the graph will pull a lot of snapshots, because of the hardcoded number of snapshots for a weekly and monthly timeframe. There needs to be some sort of default number of pulled snapshots so this case will not happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
I agree and would support adding Yoko as a subproject and adding the 3 new committers. -Donald Kevan Miller wrote: On Dec 3, 2007, at 1:45 PM, Rick McGuire wrote: Below is a proposal that Matt Hogstrom, one of the mentors of the Yoko project, has put forward for moving on with the Yoko project. In a nutshell, the Yoko community has basically decided there is not a lot of continuing interesting in moving this project forward. This decision does have a major impact on Geronimo, as Geronimo uses the Yoko ORB was a key element to allow Geronimo 1.2 to support both the 1.4 and 1.5 JVMs, and also was a necessary element for achieving j2ee5 certification. The Yoko ORB gives Geronimo cross JVM portability which was not available before. At the current time, there's probably no suitable replacement that has all of the advantages that the Yoko ORB provides. In a nutshell, Matt's proposal is for the core ORB elements of the Yoko project become a subproject of the Geronimo project. These are the pieces of Yoko that Geronimo has a dependency upon. These are essentially the org.omg.* clases, the javax.rmi.* classes, plus the implementation classes backing those spec interfaces. Along with the subproject, there are 6 committers who have expressed interest in continuing to work on the core ORB code. 3 of the interested commiters are already Geronimo committers. Matt's proposal would grant the remaining 3 Geronimo committer status as well. There's one important caveat in assuming owership of this package. The core ORB is also used by the Harmony project to add CORBA and RMI support to the Harmony JVM. Included with assuming ownership of the package would be a commitment to keep the core ORB a standalone component. This means not adding direct dependencies on Geronimo and keeping dependencies on other packages to a minimum. This code is fairly stable now, and has already passed certification on multiple JVM instances, so I don't expect there will be a lot of overhead in supporting this. The bulk of the recent work to get this to pass certification have been done by Geronimo committers, so Geronimo is probably the most appropriate new home for this code. Anyway, this needs to have some discussion and be put to a vote. Below is the proposal that Matt posted to the Yoko dev mailing list about this move. The Yoko community seems very much in agreement that project does not have sufficient momentum to graduate from the incubator. Thanks for the summary, Rick. I'm certainly interested in seeing support for Yoko move forward. This seems like a positive move. It would have my support. After a brief review of the Yoko dev list archives and based on Matt's, and Alan's recommendations, I would support adding Lars, Alexey, and Darren to as Geronimo committers. Keeping Yoko as a standalone component is an easy decision, IMO. Hard to see it any other way... --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! Jarek On Dec 4, 2007 11:26 PM, Kevan Miller [EMAIL PROTECTED] 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
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Gratulacje! Jacek On Dec 5, 2007 5:26 AM, Kevan Miller [EMAIL PROTECTED] 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 -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Updated: (GERONIMO-3675) monitoring client incorrectly pads graph's statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3675: --- Attachment: geronimo-3675.patch monitoring client incorrectly pads graph's statistics - Key: GERONIMO-3675 URL: https://issues.apache.org/jira/browse/GERONIMO-3675 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Critical Attachments: geronimo-3675.patch The monitoring client has problems when it attempts to pad some graph's stats with 0's. The result is that only a couple of snapshots are retained at the end of the process. Thus, the graph cannot be drawn at times. Additionally, if the timeframe of a graph is specified to be anywhere from greater than 7 days to less than 30 days, the graph will pull a lot of snapshots, because of the hardcoded number of snapshots for a weekly and monthly timeframe. There needs to be some sort of default number of pulled snapshots so this case will not happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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 The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- 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 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
Re: [jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0
What if you use naming like we do with the Specs, where you include the Dojo version and a maven build version? geronimo-dojo_1.0.1-2.1-SNAPSHOT That way, we could have a geronimo-dojo_0.4.3-geronimoVersion and a geronimo-dojo_1.0.1-geronimoVersion and corresponding Tomcat/Jetty versions. -Donald Jay D. McHugh wrote: Hello all, I am in need of a little help on this. I have added everything that I believe I need to -add- Dojo 1.0.1 to the build. But, in the process, maven starts to ignore the fact that the 0.4.3 version is in the local repository directory. So, the build for 0.4.3 fails if you have a clean maven repo. If you have a maven repo that already contains 0.4.3, then the new 1.0.1 is added and everything works. How can I get maven to include both versions? I don't want to check in these changes though, because they break the build if you have a clean repo. Jay Jay D. McHugh (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3300: Description: Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. was: The new Dojo 0.9 Beta was just released. It will reduce the footprint of the main dojo.js to under 50k - But will require that some of the console screens to be reworked because the widget system was completely redesigned and is incompatible. Affects Version/s: (was: 2.0-M7) 2.1 Summary: Upgrade Dojo to 1.0 (was: Upgrade Dojo to 0.9) Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. smime.p7s Description: S/MIME Cryptographic Signature
[jira] Resolved: (GERONIMO-3675) monitoring client incorrectly pads graph's statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3675. Resolution: Fixed Fix Version/s: 2.1 monitoring client incorrectly pads graph's statistics - Key: GERONIMO-3675 URL: https://issues.apache.org/jira/browse/GERONIMO-3675 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 Priority: Critical Fix For: 2.1 Attachments: geronimo-3675.patch The monitoring client has problems when it attempts to pad some graph's stats with 0's. The result is that only a couple of snapshots are retained at the end of the process. Thus, the graph cannot be drawn at times. Additionally, if the timeframe of a graph is specified to be anywhere from greater than 7 days to less than 30 days, the graph will pull a lot of snapshots, because of the hardcoded number of snapshots for a weekly and monthly timeframe. There needs to be some sort of default number of pulled snapshots so this case will not happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3673) MessageDrivenBean injection issue
[ https://issues.apache.org/jira/browse/GERONIMO-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548749 ] Tomasz Mazan commented on GERONIMO-3673: It looks like Geronimo-Eclipse integration issue. Eclipse: If I starts Geronimo (using Eclipse's run) with deployed application all is working fine. The problem appears if I redeploy (or undeploy + deploy) application. What could be important - I deploy EAR application containing JAR. If then I shutdown server and start it again, all is working Ant: If I deploy/undeploy/redeploy ejb.jar using ant task that uses geronimo deployer.jar all works fine. regards Beniamin MessageDrivenBean injection issue - Key: GERONIMO-3673 URL: https://issues.apache.org/jira/browse/GERONIMO-3673 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2 Reporter: Tomasz Mazan Attachments: ejb-jar.xml, JmsRequestFeedbackBean.java, metadata-complete-dd.xml, openejb-jar.xml I found problem with injecting Jms ConnectionFactory to my MDB, which needs it to send message to queue different to that it's listening to. During deployment I get only WARN in my logs: iWARN [OpenEJB] Injection data not found in enc: jndiName='DispatcherJmsXAConnectionFactory', target=class myapp.dispatcher.feedback.JmsRequestFeedbackBean/jmsConnFactory/i and during application's work NullPointerException when I try to access this jmsConnFactory property. With David Jenks we investingated strange form of metadata complete deployment descriptor. It indicates a kind of bug with deploying application regards Beniamin -- 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
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
Re: Build broken?
FYI for all those not in the know... This is caused by Maven 2.0.8...so be sure you are using 2.0.7 and this problem goes away. I am not sure what causes it...but I thought I would share this with all just in case it's encountered. Jeff Jeff Genender wrote: Here is the error...don't know whats up: issing dependency: org.apache.geronimo.configs/transaction//car [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: load of org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: load of org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed at org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:300) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:281) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:256) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.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.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$9b238d66.loadConfiguration(generated) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:489) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute(PackageMojo.java:309) at org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:122) ... 18 more Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.configs/transaction//car at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:111) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:104) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
[jira] Updated: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
[ https://issues.apache.org/jira/browse/GERONIMO-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3676: --- Attachment: (was: geronimo-3676.patch) monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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-3676.patch The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
[ https://issues.apache.org/jira/browse/GERONIMO-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3676: --- Attachment: geronimo-3676.patch this new patch also changes a little bit of the UI stuff. It's not important in terms of functionality, but it looks better, and makes more sense monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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-3676.patch The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3668) monitoring client should encrypt all passwords
[ https://issues.apache.org/jira/browse/GERONIMO-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3668. Resolution: Fixed Fix Version/s: 2.1 monitoring client should encrypt all passwords -- Key: GERONIMO-3668 URL: https://issues.apache.org/jira/browse/GERONIMO-3668 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubuntu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Critical Fix For: 2.1 Attachments: geronimo-3668.patch We need to encrypt all passwords that are stored in the DB. Right now, they are not encrypted in any way. I suggest we use the EncryptionManager to encrypt/decrypt these passwords. -- 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
Welcome aboard! Regards, Alan On Dec 4, 2007, at 8:26 PM, 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] Updated: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
[ https://issues.apache.org/jira/browse/GERONIMO-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3676: --- Attachment: geronimo-3676.patch monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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-3676.patch The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3672) org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent
[ https://issues.apache.org/jira/browse/GERONIMO-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasily Zakharov closed GERONIMO-3672. - Thanks, Jarek, that fixes the problem! Closing the issue. org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent --- Key: GERONIMO-3672 URL: https://issues.apache.org/jira/browse/GERONIMO-3672 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 2.0.2 Reporter: Vasily Zakharov Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 Test org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest may fail on non-Sun implementation, because it assumes the order in which Class.getFields() returns the fields, while specification doesn't specify the particular order. The problem occurs in method PersistenceUnitAnnotationHelper.processPersistenceUnit() which gets the fields and adds them to the annotatedApp, that is later compared (in the tests themselves) with expected XML - at this point the tests may as the order of elements in the resulting XML may be different. The following assertions fail on Apache Harmony because of this fact: testPersistenceContextAnnotationHelper testPersistenceUnitAnnotationHelper testWebServiceRefAnnotationHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3675) monitoring client incorrectly pads graph's statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548719 ] Erik B. Craig commented on GERONIMO-3675: - Committed revision 601401. Thanks Viet! monitoring client incorrectly pads graph's statistics - Key: GERONIMO-3675 URL: https://issues.apache.org/jira/browse/GERONIMO-3675 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 Priority: Critical Attachments: geronimo-3675.patch The monitoring client has problems when it attempts to pad some graph's stats with 0's. The result is that only a couple of snapshots are retained at the end of the process. Thus, the graph cannot be drawn at times. Additionally, if the timeframe of a graph is specified to be anywhere from greater than 7 days to less than 30 days, the graph will pull a lot of snapshots, because of the hardcoded number of snapshots for a weekly and monthly timeframe. There needs to be some sort of default number of pulled snapshots so this case will not happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GShell 1.0-alpha-1 update
FYI, I've had a look at GSHELL-60 and committed a fix for it so that the remote part of gshell can be used in ServiceMix 4.0. Lots of these changes are about adding constructors to classes (because spring does not support field injection). The only real changes are: * introduce a new exception to remove the ComponentLookupException (plexus) thrown from TransportFactoryLocator * refactor TransportFactoryLocator as an interface and rename the previous class to DefaultTransportFactoryLocator http://svn.apache.org/viewvc?view=revrevision=601529 https://issues.apache.org/jira/browse/GSHELL-60 On Nov 29, 2007 9:18 AM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, I've halted any significant changes to GShell so we can push out a stable release for Geronimo to consume in the next week or so. Right now it is pending some dependency releases: * plexus-cdc-anno * plexus-component-annotations * maven-remote-resources-plugin * groovy-maven-plugin * cobertura-maven-plugin I've got the ball rolling on each of those and with a wee bit of luck and probably a healthy dose of pestering folks, we should get all of these resolved to facilitate the first *official* GShell release... yay! I'm hoping to get GShell 1.0-alpha-1 out in the next week or so, really as soon as the deps are published I will start the ball moving. I could use a little help in the mean time for things like legal oversight and anything else I might have missed to help make the vote+release as smooth as possible, So if you have a few minutes spare it would be nice if you could build the tree and poke around a bit er something. Should be as easy as: svn co https://svn.apache.org/repos/asf/geronimo/gshell/trunk gshell cd gshell mvn install and to test the shell, something like: gunzip -c ./gshell-assembly/target/gshell-*-bin.tar.gz | tar xf - ./gshell-*/bin/gsh (and then just make sure that the 'help' command and 'exit' work should be sufficient probs). If ya find anything please file blocker issues for 1.1-alpha-1 here: * https://issues.apache.org/jira/browse/GSHELL And I'll get it sorted out ASAP * * * I've got a lot of plans to improve the plugability (and extensibility) of the shell as well as tidy up some of the GShell (BASH-like) syntax, get the remote shell muck stable and get some scripting examples up and running too... but I have to get this release out first before I can continue as those are relatively destabilizing changes. Lastly, a wee shout out to folks that have been in active with da'shell... * David Jencks - Your insight is, IMO, invaluable... and I really appreciate you taking to time to poke around and enjoy the bliss which is GShell :-P * Jason Warner - I really appreciate the extra pair of eyes (well, and patches too), don't be afraid to laid down some pimp ideas or rants, whatever, I don't bite, no matter what you might have heard :-P And... well, to the rest of you too. GShell has been a dream I've had er since back in the dark days, and its really starting to becoming something useful. So thanks for giving my vision a shot to thrive (and well, ya know... kick ass) :-) Aight, more to come later... Cheers, --jason -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Updated: (GSHELL-60) whisper and remote heavily rely on plexus
[ https://issues.apache.org/jira/browse/GSHELL-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-60: -- Summary: whisper and remote heavily rely on plexus (was: whisper and remote heavily relies on plexus) whisper and remote heavily rely on plexus - Key: GSHELL-60 URL: https://issues.apache.org/jira/browse/GSHELL-60 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Remote Shell, Whisper Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-1 OpenShellHandler is relying on plexus to create a new container so it makes it unusable in spring/osgi. But it may be ok if I can just mimic its behavior using spring. I will try to take a look and see if this is doable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-60) whisper and remote heavily relies on plexus
[ https://issues.apache.org/jira/browse/GSHELL-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-60: -- Component/s: Whisper Summary: whisper and remote heavily relies on plexus (was: OpenShellHandler heavily relies on plexus) whisper and remote heavily relies on plexus --- Key: GSHELL-60 URL: https://issues.apache.org/jira/browse/GSHELL-60 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Remote Shell, Whisper Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-1 OpenShellHandler is relying on plexus to create a new container so it makes it unusable in spring/osgi. But it may be ok if I can just mimic its behavior using spring. I will try to take a look and see if this is doable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.1: Failed for Revision: 601494
OpenEJB trunk at 601470 Geronimo Revision: 601494 built with tests included See the full build-1500.log file at http://people.apache.org/~prasad/binaries/trunk/20071205/build-1500.log Building Geronimo trunk at Revision: 601494 Building OpenEJB trunk at 601470 + Error stacktraces are turned on. [INFO] Scanning for projects... Downloading: http://download.java.net/maven/1//org.apache.geronimo.genesis.config/poms/project-config-1.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/project-config/1.2/project-config-1.2.pom 21K downloaded Downloading: http://download.java.net/maven/1//org.apache.geronimo.genesis.config/poms/config-1.2.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/genesis/config/config/1.2/config-1.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/config/1.2/config-1.2.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.geronimo.genesis.config ArtifactId: config Version: 1.2 Reason: Unable to download the artifact from any repository org.apache.geronimo.genesis.config:config:pom:1.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.geronimo.genesis.config:config for project: null:project-config:pom:null for project null:project-config:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.geronimo.genesis.config:config for project: null:project-config:pom:null for project null:project-config:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1261) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1278) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:747) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.geronimo.genesis.config:config' not found in repository: Unable to download the artifact from any repository org.apache.geronimo.genesis.config:config:pom:1.2 from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) for project org.apache.geronimo.genesis.config:config at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1257) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository
[jira] Updated: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
[ https://issues.apache.org/jira/browse/GERONIMO-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3676: --- Attachment: geronimo-3676.patch monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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-3676.patch The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- 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! -Donald 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 smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-3675) monitoring client incorrectly pads graph's statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3675: Component/s: monitoring monitoring client incorrectly pads graph's statistics - Key: GERONIMO-3675 URL: https://issues.apache.org/jira/browse/GERONIMO-3675 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 Priority: Critical Attachments: geronimo-3675.patch The monitoring client has problems when it attempts to pad some graph's stats with 0's. The result is that only a couple of snapshots are retained at the end of the process. Thus, the graph cannot be drawn at times. Additionally, if the timeframe of a graph is specified to be anywhere from greater than 7 days to less than 30 days, the graph will pull a lot of snapshots, because of the hardcoded number of snapshots for a weekly and monthly timeframe. There needs to be some sort of default number of pulled snapshots so this case will not happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to get a meta-data complete ejb-jar.xml from an EJB jar?
I am currently working on an Admin Console wizard to auto-generate openejb-jar.xml http://issues.apache.org/jira/browse/GERONIMO-3432 and one problem where I am currently stuck is given an EJB jar how do I get it's meta-data complete ejb-jar.xml? I have some code in Plan Creator portlet of Admin Console which can process a web-app and provide it's meta-data complete web.xml. http://www.mail-archive.com/dev@geronimo.apache.org/msg47965.html shows this code and how it was developed. This code is however insufficient for discovering EJB annotations. Tim told on irc http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20071205 that for EJBs a lot of the annotation processing is done in openejb side -- not geronimo. Any further hints/help? -- Thanks, Shiva
[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: GShell 1.0-alpha-1 update
Btw, while doing some testing, I found that running remote/rshd throws an exception: ERROR NotFoundException: rsh-server So I've fixed the alias to point to remote/rsh-server instead. I suppose the alias resolution could try with the prefix the alias is defined in, but this is not the case, so I've just fixed the alias for now. On Dec 5, 2007 10:24 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: FYI, I've had a look at GSHELL-60 and committed a fix for it so that the remote part of gshell can be used in ServiceMix 4.0. Lots of these changes are about adding constructors to classes (because spring does not support field injection). The only real changes are: * introduce a new exception to remove the ComponentLookupException (plexus) thrown from TransportFactoryLocator * refactor TransportFactoryLocator as an interface and rename the previous class to DefaultTransportFactoryLocator http://svn.apache.org/viewvc?view=revrevision=601529 https://issues.apache.org/jira/browse/GSHELL-60 On Nov 29, 2007 9:18 AM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, I've halted any significant changes to GShell so we can push out a stable release for Geronimo to consume in the next week or so. Right now it is pending some dependency releases: * plexus-cdc-anno * plexus-component-annotations * maven-remote-resources-plugin * groovy-maven-plugin * cobertura-maven-plugin I've got the ball rolling on each of those and with a wee bit of luck and probably a healthy dose of pestering folks, we should get all of these resolved to facilitate the first *official* GShell release... yay! I'm hoping to get GShell 1.0-alpha-1 out in the next week or so, really as soon as the deps are published I will start the ball moving. I could use a little help in the mean time for things like legal oversight and anything else I might have missed to help make the vote+release as smooth as possible, So if you have a few minutes spare it would be nice if you could build the tree and poke around a bit er something. Should be as easy as: svn co https://svn.apache.org/repos/asf/geronimo/gshell/trunk gshell cd gshell mvn install and to test the shell, something like: gunzip -c ./gshell-assembly/target/gshell-*-bin.tar.gz | tar xf - ./gshell-*/bin/gsh (and then just make sure that the 'help' command and 'exit' work should be sufficient probs). If ya find anything please file blocker issues for 1.1-alpha-1 here: * https://issues.apache.org/jira/browse/GSHELL And I'll get it sorted out ASAP * * * I've got a lot of plans to improve the plugability (and extensibility) of the shell as well as tidy up some of the GShell (BASH-like) syntax, get the remote shell muck stable and get some scripting examples up and running too... but I have to get this release out first before I can continue as those are relatively destabilizing changes. Lastly, a wee shout out to folks that have been in active with da'shell... * David Jencks - Your insight is, IMO, invaluable... and I really appreciate you taking to time to poke around and enjoy the bliss which is GShell :-P * Jason Warner - I really appreciate the extra pair of eyes (well, and patches too), don't be afraid to laid down some pimp ideas or rants, whatever, I don't bite, no matter what you might have heard :-P And... well, to the rest of you too. GShell has been a dream I've had er since back in the dark days, and its really starting to becoming something useful. So thanks for giving my vision a shot to thrive (and well, ya know... kick ass) :-) Aight, more to come later... Cheers, --jason -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Resolved: (GSHELL-60) whisper and remote heavily rely on plexus
[ https://issues.apache.org/jira/browse/GSHELL-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-60. --- Resolution: Fixed Sending gshell-remote/gshell-remote-common/src/main/java/org/apache/geronimo/gshell/remote/crypto/CryptoContext.java Sending gshell-remote/gshell-remote-server/src/main/java/org/apache/geronimo/gshell/remote/server/DefaultRemoteShell.java Sending gshell-remote/gshell-remote-server/src/main/java/org/apache/geronimo/gshell/remote/server/RshServer.java Sending gshell-remote/gshell-remote-server/src/main/java/org/apache/geronimo/gshell/remote/server/handler/ConnectHandler.java Sending gshell-remote/gshell-remote-server/src/main/java/org/apache/geronimo/gshell/remote/server/handler/LoginHandler.java Adding gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/transport/DefaultTransportFactoryLocator.java Adding gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/transport/LookupException.java Replacing gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/transport/TransportFactoryLocator.java Sending gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/transport/ssl/SslTransport.java Sending gshell-whisper/src/main/java/org/apache/geronimo/gshell/whisper/transport/ssl/SslTransportServer.java Sending gshell-whisper/src/test/java/org/apache/geronimo/gshell/whisper/transport/TransportFactoryLocatorTest.java Sending gshell-whisper/src/test/java/org/apache/geronimo/gshell/whisper/transport/vm/VmTransportTest.java Transmitting file data Committed revision 601529. URL: http://svn.apache.org/viewvc?rev=601529view=rev whisper and remote heavily rely on plexus - Key: GSHELL-60 URL: https://issues.apache.org/jira/browse/GSHELL-60 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Remote Shell, Whisper Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-1 OpenShellHandler is relying on plexus to create a new container so it makes it unusable in spring/osgi. But it may be ok if I can just mimic its behavior using spring. I will try to take a look and see if this is doable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
[ https://issues.apache.org/jira/browse/GERONIMO-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548815 ] Erik B. Craig commented on GERONIMO-3676: - Committed revision 601520. Yay viet. monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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-3676.patch The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache Geronimo Context
Hi, i mean that when we look at Geronimo as a Blackbox, then how does it communicate with other Applications : for example wirth the Client tier; what kind of portocols, services and modules does it use therefore: GBeans, Connectors, EJB I hope that it is now clear Thanks nezha wrote: Hi, I want to kown how Apache Geronimo communicate with the other Applications and Servers, what does it use for this communication? I mean the different media, protocols and Data format, that Geronimo uses for the exanchange of information with its extern environment. Thank you -- View this message in context: http://www.nabble.com/Apache-Geronimo-Context-tf4938237s134.html#a14181185 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GSHELL-46) Add flag to show exception stacktraces
[
https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548848
]
Jason Dillon commented on GSHELL-46:
The idea is to show the stack traces w/o increasing any other output. So,
basically use like {{mvn -e}}.
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 Warner
Priority: Trivial
Fix For: 1.0-alpha-2
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.
[jira] Updated: (GSHELL-60) OpenShellHandler heavily relies on plexus
[ https://issues.apache.org/jira/browse/GSHELL-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-60: -- Fix Version/s: (was: 1.0-alpha-2) 1.0-alpha-1 OpenShellHandler heavily relies on plexus - Key: GSHELL-60 URL: https://issues.apache.org/jira/browse/GSHELL-60 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Remote Shell Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-1 OpenShellHandler is relying on plexus to create a new container so it makes it unusable in spring/osgi. But it may be ok if I can just mimic its behavior using spring. I will try to take a look and see if this is doable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3624) Update start-server rc.d/ handling to prevent problems with ':' on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548853 ] Jason Dillon commented on GERONIMO-3624: I'm gonna go back to what it was before... for now. Update start-server rc.d/ handling to prevent problems with ':' on Windows -- Key: GERONIMO-3624 URL: https://issues.apache.org/jira/browse/GERONIMO-3624 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Environment: Windows Reporter: Hernan Cunico Assignee: Jason Dillon Priority: Blocker Fix For: 2.1 Issue brought up by Jarek on dev@, I'm having the same problem too. Windows users cannot check out trunk from SVN because of unsupported characters (: and ,) in file names. See svn log below svn: In directory 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d' svn: Can't move source to dest svn: Can't move 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,default.groovy.svn-base' to 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base': No such file or directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory
[ https://issues.apache.org/jira/browse/GSHELL-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-90. -- Resolution: Duplicate GShell code does not pick up and execute files in the etc/rc.d directory Key: GSHELL-90 URL: https://issues.apache.org/jira/browse/GSHELL-90 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Jeff Genender Assignee: Jason Dillon Priority: Blocker GShell is not executing the rc.d script in the etc/rc.d directory in Geronimo. Files were named start-server,terracotta-client.groovy start-server,terracotta-config.groovy Reneamed to what I found there to match the default file: geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy And they are not being executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3677) Add support for cli options for host/port and user/pass for commands
Add support for cli options for host/port and user/pass for commands Key: GERONIMO-3677 URL: https://issues.apache.org/jira/browse/GERONIMO-3677 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Jason Dillon Assignee: Jason Dillon Priority: Blocker Fix For: 2.1 -- 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! Gianny On 05/12/2007, at 3:26 PM, 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
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
On Dec 5, 2007, at 2:22 AM, Rick McGuire wrote: Kevan Miller wrote: On Dec 3, 2007, at 1:45 PM, Rick McGuire wrote: Below is a proposal that Matt Hogstrom, one of the mentors of the Yoko project, has put forward for moving on with the Yoko project. In a nutshell, the Yoko community has basically decided there is not a lot of continuing interesting in moving this project forward. This decision does have a major impact on Geronimo, as Geronimo uses the Yoko ORB was a key element to allow Geronimo 1.2 to support both the 1.4 and 1.5 JVMs, and also was a necessary element for achieving j2ee5 certification. The Yoko ORB gives Geronimo cross JVM portability which was not available before. At the current time, there's probably no suitable replacement that has all of the advantages that the Yoko ORB provides. In a nutshell, Matt's proposal is for the core ORB elements of the Yoko project become a subproject of the Geronimo project. These are the pieces of Yoko that Geronimo has a dependency upon. These are essentially the org.omg.* clases, the javax.rmi.* classes, plus the implementation classes backing those spec interfaces. Along with the subproject, there are 6 committers who have expressed interest in continuing to work on the core ORB code. 3 of the interested commiters are already Geronimo committers. Matt's proposal would grant the remaining 3 Geronimo committer status as well. There's one important caveat in assuming owership of this package. The core ORB is also used by the Harmony project to add CORBA and RMI support to the Harmony JVM. Included with assuming ownership of the package would be a commitment to keep the core ORB a standalone component. This means not adding direct dependencies on Geronimo and keeping dependencies on other packages to a minimum. This code is fairly stable now, and has already passed certification on multiple JVM instances, so I don't expect there will be a lot of overhead in supporting this. The bulk of the recent work to get this to pass certification have been done by Geronimo committers, so Geronimo is probably the most appropriate new home for this code. Anyway, this needs to have some discussion and be put to a vote. Below is the proposal that Matt posted to the Yoko dev mailing list about this move. The Yoko community seems very much in agreement that project does not have sufficient momentum to graduate from the incubator. Thanks for the summary, Rick. I'm certainly interested in seeing support for Yoko move forward. This seems like a positive move. It would have my support. After a brief review of the Yoko dev list archives and based on Matt's, and Alan's recommendations, I would support adding Lars, Alexey, and Darren to as Geronimo committers. Keeping Yoko as a standalone component is an easy decision, IMO. Hard to see it any other way... Actually, I have a whole laundry list of things that could be done to Yoko to make it work better in the Geronimo environment that could mess it's ability to function as a standalone server if not done correctly. For example, it would be nice if Yoko could hook into the Geronimo thread pooling APIs. It's easier to ensure things like this are done in the correct fashion if the constraint of needing to remain standalone is stated right up front. You make a good point. We should be very explicit about the requirement that Yoko be standalone. Regards, Alan
Re: How to get a meta-data complete ejb-jar.xml from an EJB jar?
Shiva, I don't know if this is any help, but I'm currently working on some code to generate annotations based on a JAXB tree generated from an ejb-jar.xml. As I understand it, OpenEJB does all its annotation scraping and processing in org.apache.openejb.config.AnnotationDeployer (https://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/AnnotationDeployer.java) - I'm effectively doing the reverse of what this class does to generate the annotations :-) Hope that helps - apologies if its not what you're after. Jon Shiva Kumar H R wrote: I am currently working on an Admin Console wizard to auto-generate openejb-jar.xml http://issues.apache.org/jira/browse/GERONIMO-3432 and one problem where I am currently stuck is given an EJB jar how do I get it's meta-data complete ejb-jar.xml? I have some code in Plan Creator portlet of Admin Console which can process a web-app and provide it's meta-data complete web.xml. http://www.mail-archive.com/dev@geronimo.apache.org/msg47965.html shows this code and how it was developed. This code is however insufficient for discovering EJB annotations. Tim told on irc http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20071205 that for EJBs a lot of the annotation processing is done in openejb side -- not geronimo. Any further hints/help?
[jira] Updated: (GSHELL-78) Upgrade cobertura-maven-plugin to 2.2
[ https://issues.apache.org/jira/browse/GSHELL-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-78: --- Fix Version/s: (was: 1.0-alpha-1) 1.0-alpha-2 Upgrade cobertura-maven-plugin to 2.2 - Key: GSHELL-78 URL: https://issues.apache.org/jira/browse/GSHELL-78 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Blocker Fix For: 1.0-alpha-2 This is required to generate cobertura for groovy projects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
Kevan Miller wrote: On Dec 3, 2007, at 1:45 PM, Rick McGuire wrote: Below is a proposal that Matt Hogstrom, one of the mentors of the Yoko project, has put forward for moving on with the Yoko project. In a nutshell, the Yoko community has basically decided there is not a lot of continuing interesting in moving this project forward. This decision does have a major impact on Geronimo, as Geronimo uses the Yoko ORB was a key element to allow Geronimo 1.2 to support both the 1.4 and 1.5 JVMs, and also was a necessary element for achieving j2ee5 certification. The Yoko ORB gives Geronimo cross JVM portability which was not available before. At the current time, there's probably no suitable replacement that has all of the advantages that the Yoko ORB provides. In a nutshell, Matt's proposal is for the core ORB elements of the Yoko project become a subproject of the Geronimo project. These are the pieces of Yoko that Geronimo has a dependency upon. These are essentially the org.omg.* clases, the javax.rmi.* classes, plus the implementation classes backing those spec interfaces. Along with the subproject, there are 6 committers who have expressed interest in continuing to work on the core ORB code. 3 of the interested commiters are already Geronimo committers. Matt's proposal would grant the remaining 3 Geronimo committer status as well. There's one important caveat in assuming owership of this package. The core ORB is also used by the Harmony project to add CORBA and RMI support to the Harmony JVM. Included with assuming ownership of the package would be a commitment to keep the core ORB a standalone component. This means not adding direct dependencies on Geronimo and keeping dependencies on other packages to a minimum. This code is fairly stable now, and has already passed certification on multiple JVM instances, so I don't expect there will be a lot of overhead in supporting this. The bulk of the recent work to get this to pass certification have been done by Geronimo committers, so Geronimo is probably the most appropriate new home for this code. Anyway, this needs to have some discussion and be put to a vote. Below is the proposal that Matt posted to the Yoko dev mailing list about this move. The Yoko community seems very much in agreement that project does not have sufficient momentum to graduate from the incubator. Thanks for the summary, Rick. I'm certainly interested in seeing support for Yoko move forward. This seems like a positive move. It would have my support. After a brief review of the Yoko dev list archives and based on Matt's, and Alan's recommendations, I would support adding Lars, Alexey, and Darren to as Geronimo committers. Keeping Yoko as a standalone component is an easy decision, IMO. Hard to see it any other way... Actually, I have a whole laundry list of things that could be done to Yoko to make it work better in the Geronimo environment that could mess it's ability to function as a standalone server if not done correctly. For example, it would be nice if Yoko could hook into the Geronimo thread pooling APIs. It's easier to ensure things like this are done in the correct fashion if the constraint of needing to remain standalone is stated right up front. Rick --kevan
[jira] Updated: (GSHELL-69) gsh -c should soak up all remaining arguments and build a command-line
[
https://issues.apache.org/jira/browse/GSHELL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated GSHELL-69:
---
Fix Version/s: (was: 1.0-alpha-1)
1.0-alpha-2
gsh -c should soak up all remaining arguments and build a command-line
--
Key: GSHELL-69
URL: https://issues.apache.org/jira/browse/GSHELL-69
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: CLI
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Minor
Fix For: 1.0-alpha-2
Right now {{-c}} takes a list of arguments to run non-interactively. It
should instead take all remaining arguments for execution non-interactively.
This means that {{-c}} can contain easily quoted arguments if needed and
should simplify usage of gsh for non-interactive usage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-60) OpenShellHandler heavily relies on plexus
[ https://issues.apache.org/jira/browse/GSHELL-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GSHELL-60: - Assignee: Guillaume Nodet OpenShellHandler heavily relies on plexus - Key: GSHELL-60 URL: https://issues.apache.org/jira/browse/GSHELL-60 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Remote Shell Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 OpenShellHandler is relying on plexus to create a new container so it makes it unusable in spring/osgi. But it may be ok if I can just mimic its behavior using spring. I will try to take a look and see if this is doable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3676) monitoring client throws an error message when there are no graphs present
[ https://issues.apache.org/jira/browse/GERONIMO-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3676: --- Attachment: (was: geronimo-3676.patch) monitoring client throws an error message when there are no graphs present -- Key: GERONIMO-3676 URL: https://issues.apache.org/jira/browse/GERONIMO-3676 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 The monitoring client throws displays Error updating View Jetty Web Connector 60 mins null when it is trying to update a Views page without any graphs. This is not the desired behavior. Additionally, when a graph is deleted, the number of graphs in the Views table is not updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r601152 [3/4] - in /geronimo/server/trunk: ./ applications/welcome/geronimo-welcome/src/main/java/org/apache/geronimo/welcome/ assemblies/geronimo-boilerplate-minimal/src/main/underlay
${geronimoVersion} is guaranteed to work like 2.1-SNAPSHOT. There
is no such guarantee for ${version}, i.e. it may evaluate to 2.1-.
Thanks
Anita
--- David Jencks [EMAIL PROTECTED] wrote:
On Dec 4, 2007, at 6:26 PM, Anita Kulshreshtha wrote:
Is the version temporary? Could you have used geronimoVersion
property instead of 2.1-SNAPSHOT?
I hope I can get rid of the version element again. I'm hoping to fix
up the plugin repo code so that file system plugin repositories work
at which point a lot of explicit versions won't be required. If that
doesn't work then all the 2.1-SNAPSHOTS need to be turned into $
{version} or ${geronimoVersion}. I'm not sure which would work
better?
thanks
david jencks
Thanks
Anita
--- [EMAIL PROTECTED] wrote:
Modified:
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
ExplicitDefaultArtifactResolver.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-system/src/main/java/org/apache/geronimo/system/
resolver/ExplicitDefaultArtifactResolver.java?
rev=601152r1=601151r2=601152view=diff
==
---
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
ExplicitDefaultArtifactResolver.java
(original)
+++
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
ExplicitDefaultArtifactResolver.java
Tue Dec 4 15:49:03 2007
@@ -38,14 +38,14 @@
/**
* @version $Rev$ $Date$
*/
-public class ExplicitDefaultArtifactResolver extends
DefaultArtifactResolver implements AliasedArtifactResolver {
+public class ExplicitDefaultArtifactResolver extends
DefaultArtifactResolver implements LocalAliasedArtifactResolver {
private static final String COMMENT = #You can use this file
to
indicate that you want to substitute one module for another.\n +
#format is oldartifactid=newartifactId e.g.\n +
#org.apache.geronimo.configs/transaction//
car=org.apache.geronimo.configs/transaction-jta11/1.2-SNAPSHOT/car\n
+
#versions can be ommitted on the left side but not
the
right.\n +
#This can also specify explicit versions in the same
format.;
-private final String versionMapLocation;
+private final String artifactAliasesFile;
private final ServerInfo serverInfo;
public ExplicitDefaultArtifactResolver(String
versionMapLocation,
@@ -53,10 +53,15 @@
Collection? extends ListableRepository
repositories,
ServerInfo serverInfo ) throws IOException {
super(artifactManager, repositories,
buildExplicitResolution(versionMapLocation, serverInfo));
-this.versionMapLocation = versionMapLocation;
+this.artifactAliasesFile = versionMapLocation;
this.serverInfo = serverInfo;
}
+
+public String getArtifactAliasesFile() {
+return artifactAliasesFile;
+}
+
private static MapArtifact, Artifact
buildExplicitResolution(String versionMapLocation, ServerInfo
serverInfo) throws IOException {
if (versionMapLocation == null) {
return null;
@@ -123,7 +128,7 @@
public synchronized void addAliases(Properties properties)
throws IOException {
MapArtifact, Artifact explicitResolutions =
propertiesToArtifactMap(properties);
getExplicitResolution().putAll(explicitResolutions);
-saveExplicitResolution(getExplicitResolution(),
versionMapLocation, serverInfo);
+saveExplicitResolution(getExplicitResolution(),
artifactAliasesFile, serverInfo);
}
public static final GBeanInfo GBEAN_INFO;
Added:
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
LocalAliasedArtifactResolver.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-system/src/main/java/org/apache/geronimo/system/
resolver/LocalAliasedArtifactResolver.java?rev=601152view=auto
==
---
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
LocalAliasedArtifactResolver.java
(added)
+++
geronimo/server/trunk/framework/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/resolver/
LocalAliasedArtifactResolver.java
Tue Dec 4 15:49:03 2007
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! Anita --- Kevan Miller [EMAIL PROTECTED] 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 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congrats Jay...your hard work payed off! 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
Re: GShell 1.0-alpha-1 update
Thats fine. The who lookup and path searching stuff needs to be revisited for the next release, so for now that works. --jason On Dec 5, 2007, at 1:29 PM, Guillaume Nodet wrote: Btw, while doing some testing, I found that running remote/rshd throws an exception: ERROR NotFoundException: rsh-server So I've fixed the alias to point to remote/rsh-server instead. I suppose the alias resolution could try with the prefix the alias is defined in, but this is not the case, so I've just fixed the alias for now. On Dec 5, 2007 10:24 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: FYI, I've had a look at GSHELL-60 and committed a fix for it so that the remote part of gshell can be used in ServiceMix 4.0. Lots of these changes are about adding constructors to classes (because spring does not support field injection). The only real changes are: * introduce a new exception to remove the ComponentLookupException (plexus) thrown from TransportFactoryLocator * refactor TransportFactoryLocator as an interface and rename the previous class to DefaultTransportFactoryLocator http://svn.apache.org/viewvc?view=revrevision=601529 https://issues.apache.org/jira/browse/GSHELL-60 On Nov 29, 2007 9:18 AM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, I've halted any significant changes to GShell so we can push out a stable release for Geronimo to consume in the next week or so. Right now it is pending some dependency releases: * plexus-cdc-anno * plexus-component-annotations * maven-remote-resources-plugin * groovy-maven-plugin * cobertura-maven-plugin I've got the ball rolling on each of those and with a wee bit of luck and probably a healthy dose of pestering folks, we should get all of these resolved to facilitate the first *official* GShell release... yay! I'm hoping to get GShell 1.0-alpha-1 out in the next week or so, really as soon as the deps are published I will start the ball moving. I could use a little help in the mean time for things like legal oversight and anything else I might have missed to help make the vote+release as smooth as possible, So if you have a few minutes spare it would be nice if you could build the tree and poke around a bit er something. Should be as easy as: svn co https://svn.apache.org/repos/asf/geronimo/gshell/trunk gshell cd gshell mvn install and to test the shell, something like: gunzip -c ./gshell-assembly/target/gshell-*-bin.tar.gz | tar xf - ./gshell-*/bin/gsh (and then just make sure that the 'help' command and 'exit' work should be sufficient probs). If ya find anything please file blocker issues for 1.1-alpha-1 here: * https://issues.apache.org/jira/browse/GSHELL And I'll get it sorted out ASAP * * * I've got a lot of plans to improve the plugability (and extensibility) of the shell as well as tidy up some of the GShell (BASH-like) syntax, get the remote shell muck stable and get some scripting examples up and running too... but I have to get this release out first before I can continue as those are relatively destabilizing changes. Lastly, a wee shout out to folks that have been in active with da'shell... * David Jencks - Your insight is, IMO, invaluable... and I really appreciate you taking to time to poke around and enjoy the bliss which is GShell :-P * Jason Warner - I really appreciate the extra pair of eyes (well, and patches too), don't be afraid to laid down some pimp ideas or rants, whatever, I don't bite, no matter what you might have heard :-P And... well, to the rest of you too. GShell has been a dream I've had er since back in the dark days, and its really starting to becoming something useful. So thanks for giving my vision a shot to thrive (and well, ya know... kick ass) :-) Aight, more to come later... Cheers, --jason -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
+1 Jacek On Dec 5, 2007 10:36 PM, Viet Nguyen [EMAIL PROTECTED] wrote: 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 -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
Alan D. Cabrera wrote: On Dec 5, 2007, at 2:22 AM, Rick McGuire wrote: Kevan Miller wrote: snip Keeping Yoko as a standalone component is an easy decision, IMO. Hard to see it any other way... Actually, I have a whole laundry list of things that could be done to Yoko to make it work better in the Geronimo environment that could mess it's ability to function as a standalone server if not done correctly. For example, it would be nice if Yoko could hook into the Geronimo thread pooling APIs. It's easier to ensure things like this are done in the correct fashion if the constraint of needing to remain standalone is stated right up front. You make a good point. We should be very explicit about the requirement that Yoko be standalone. Yep, Corba is a significant part of the Java SE spec too and Harmony has been taking Yoko drops as part of our implementation. IMHO it doesn't make sense for us to fork the code and maintain it independently of Geronimo. Alexey (one of the proposed new committers) is on the Harmony PMC so can help keep things honest. Regards, Tim
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
+1 I am definitely in favor of this, and would also like to see this make it to trunk before the 2.1 branch occurs. It would be great if we could get a few extra pairs of eyes to take a look at things and make sure it's all peachy. Thanks, Erik B. Craig [EMAIL PROTECTED] Viet Nguyen wrote: 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
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? 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. Additionally... do you have an example of the graphs for TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong? On Dec 5, 2007, at 7: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. The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: 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 Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[jira] Closed: (GERONIMO-3434) Use GShell to launch to server process and provide rc.d configuration support for customization required by plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GERONIMO-3434. -- Resolution: Fixed Use GShell to launch to server process and provide rc.d configuration support for customization required by plugins --- Key: GERONIMO-3434 URL: https://issues.apache.org/jira/browse/GERONIMO-3434 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 601239
Geronimo Revision: 601239 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/2.0/20071205/build-0300.log Building Geronimo branches/2.0 at Revision: 601239 + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.2/maven-resources-plugin-2.2.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/maven-plugins-1.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-parent-1.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.2/maven-resources-plugin-2.2.jar 13K downloaded [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/8/maven-plugins-8.pom 5K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven-parent-5.pom 14K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.2/maven-compiler-plugin-2.0.2.jar 17K downloaded [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3/maven-surefire-plugin-2.3.pom 4K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire/2.3/surefire-2.3.pom 5K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3/maven-surefire-plugin-2.3.jar 14K downloaded [INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-jar-plugin/2.1/maven-jar-plugin-2.1.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/3/maven-plugins-3.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/4/maven-parent-4.pom 9K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-jar-plugin/2.1/maven-jar-plugin-2.1.jar 18K downloaded [INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.jar 15K downloaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congrats Jay ! Cheers Prasad On Dec 4, 2007 11:26 PM, Kevan Miller [EMAIL PROTECTED] 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
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
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. The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: 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 Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[BUILD] 2.1: Failed for Revision: 601239
OpenEJB trunk at 601228
Geronimo Revision: 601239 built with tests included
See the full build-0300.log file at
http://people.apache.org/~prasad/binaries/trunk/20071205/build-0300.log
Download the binaries from
http://people.apache.org/~prasad/binaries/trunk/20071205
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 28 minutes 33 seconds
[INFO] Finished at: Wed Dec 05 03:39:45 EST 2007
[INFO] Final Memory: 289M/1008M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/~prasad/binaries/trunk/20071205/logs-0300-tomcat/test.log
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 5 source files to
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ejb/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] No sources to compile
[INFO] [INFO] [surefire:test]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [surefire:test {execution: test}]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [ejb:ejb]
[INFO] [INFO] Building ejb corba-marshal-ejb-2.1-SNAPSHOT with ejbVersion 2.1
[INFO] [INFO] Building jar:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ejb/target/corba-marshal-ejb-2.1-SNAPSHOT.jar
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in: corba-marshal-ejb-2.1-SNAPSHOT.jar
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ejb/target/corba-marshal-ejb-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/testsuite/corba-marshal-ejb/2.1-SNAPSHOT/corba-marshal-ejb-2.1-SNAPSHOT.jar
[INFO] [INFO] [testsuite:generate-surefire-xml {execution:
generate-surefire-xml}]
[INFO] [INFO] Updating directory:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/target/surefire-reports
[INFO] [INFO] No surefire-reports directory here
[INFO] [INFO]
[INFO] [INFO] Building Geronimo TestSuite :: CORBA TestSuite :: Marshal Client
[INFO] [INFO]task-segment: [install]
[INFO] [INFO]
[INFO] [INFO] [enforcer:enforce {execution: default}]
[INFO] [INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [INFO] Created dir:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/classes/META-INF
[INFO] [INFO] Copying 2 files to
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/classes/META-INF
[INFO] [INFO] [resources:resources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 6 source files to
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] No sources to compile
[INFO] [INFO] [surefire:test]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [surefire:test {execution: test}]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [jar:jar]
[INFO] [INFO] Building jar:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-2.1-SNAPSHOT.jar
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in: corba-marshal-client-2.1-SNAPSHOT.jar
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/testsuite/corba-marshal-client/2.1-SNAPSHOT/corba-marshal-client-2.1-SNAPSHOT.jar
[INFO] [INFO] [testsuite:generate-surefire-xml {execution:
generate-surefire-xml}]
[INFO] [INFO] Updating directory:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/target/surefire-reports
[INFO] [INFO] No surefire-reports directory here
[INFO] [INFO]
[INFO] [INFO] Building Geronimo
[jira] Closed: (GERONIMO-3624) Update start-server rc.d/ handling to prevent problems with ':' on Windows
[
https://issues.apache.org/jira/browse/GERONIMO-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GERONIMO-3624.
--
Resolution: Fixed
Dropped the groupId muck from the path (ie. no more {{:}}, but we still have
{{,}}).
Update start-server rc.d/ handling to prevent problems with ':' on Windows
--
Key: GERONIMO-3624
URL: https://issues.apache.org/jira/browse/GERONIMO-3624
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: buildsystem
Environment: Windows
Reporter: Hernan Cunico
Assignee: Jason Dillon
Priority: Blocker
Fix For: 2.1
Issue brought up by Jarek on dev@, I'm having the same problem too. Windows
users cannot check out trunk from SVN because of unsupported characters (:
and ,) in file names. See svn log below
svn: In directory
'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d'
svn: Can't move source to dest
svn: Can't move
'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,default.groovy.svn-base'
to
'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base':
No such file or directory
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3674) Create a private build of pluto 1.2.0-SNAPSHOT for Geronimo release
Create a private build of pluto 1.2.0-SNAPSHOT for Geronimo release --- Key: GERONIMO-3674 URL: https://issues.apache.org/jira/browse/GERONIMO-3674 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1 Pluto will not be able to release 1.2.0 prior to our Geronimo 2.1 release. We can not release with a dependency on the 1.2.0-SNAPSHOT. Therefore, we must build our own pluto and record the revision #. $ svn info Path: . URL: https://svn.apache.org/repos/asf/portals/pluto/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 601060 Node Kind: directory Schedule: normal Last Changed Author: cdoremus Last Changed Rev: 586586 Last Changed Date: 2007-10-19 15:33:58 -0400 (Fri, 19 Oct 2007) Properties Last Updated: 2007-11-28 11:37:48 -0500 (Wed, 28 Nov 2007) -- 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
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. thanks david jencks The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: 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 __ __ 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
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 was going to say the same but you beat me to it. +1 with your comment...new functionality is the way to go on this. This is a huge step in the right direction and gives the user more power than they had before. It may not be perfect but it certainly is wickedly cool ;-) Anita, can you please technically show why this is not ready or should not be released? Can you explain/show where the graphs are wrong? This may help move things along. Jeff thanks david jencks The Graph builder plots CountStatistics correctly. It does not provide a way (minor point) to choose/plot both the raw count and the throughput, i.e. count/sec. The graphs for TimeStatistics and BoundedRangeStatistics are wrong. This is a serious shortcoming. I would like it to be fixed before we can talk about releasing it. Thanks Anita --- Viet Nguyen [EMAIL PROTECTED] wrote: 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 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
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? You mention MEJB connections. Can you help me understand where the MEJB is running? The local server or the remote servers? --kevan
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
On Dec 3, 2007, at 8:04 PM, Gianny Damour wrote: On 04/12/2007, at 11:45 AM, Jason Dillon wrote: On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote: A bit harder to apples-to-apples compare the longer term growth. lib/gshell accounts for a 5 meg growth (unpacked). So, that would help account for most of the growth in the minimal assembly... I wonder if we should consider allowing gshell to be optional... I'd recommend *not*, though if we aren't happy with the additional bloat from the current impl, we can re-implement in pure-java and remove the dependency on Groovy. Its possible, though not very elegant IMO, as the AntBuilder syntax is ideal for launching new processes. Hi, I am actually quite a fan of Groovy commands and really would like Groovy to stick around. Beside the fact that the AntBuilder syntax is neat, Groovy commands could provide a very neat and simple way to dynamically introduce new commands w/o going through a compile cycle. I believe many Geronimo users are Java savvy enough, and hence also Groovy savvy enough to directly implement their commands in Groovy. It is in my understanding that gshell provides a gsh-bsf command (not tried, just read the code) and this is a first way to launch Groovy scripts; however, it would be great to directly map commands to groovy scripts out-of-the-box. Understood. Playing a bit of the devil's advocate here... A high percentage of Geronimo users will never create a custom Geronimo command, nor create or use GShell scripting capabilities. They'll want to start/stop Geronimo and deploy/undeploy applications. For these capabilities, geronimo-boilerplate-minimal-2.1.jar has grown by nearly 200% (3.0 meg - 8.3 meg). Also, most users will never generate new server assemblies. Yet, for this capability, we're increasing the minimal server size by 8.3 megs (essentially including the boilerplate-minimal jar twice). At the moment, minimal assembly has grown from 16 megs to 31 megs. IMO one of Geronimo's major advantages is that it's lightweight and flexible. We're still flexible, but we seem to have put on a few holiday pounds... I'd like to think about how we can slim things back down... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
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.. --- 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: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Anita, can you please technically show why this is not ready or should not be released? Can you explain/show where the graphs are wrong? This may help move things along. Jeff Don't I get 24 hours to respond :) Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! Regards, John 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
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: Our 2.1 assemblies are nearly 2x the size of 2.0.2
On Dec 5, 2007, at 6:50 PM, Kevan Miller wrote: On Dec 3, 2007, at 8:04 PM, Gianny Damour wrote: On 04/12/2007, at 11:45 AM, Jason Dillon wrote: On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote: A bit harder to apples-to-apples compare the longer term growth. lib/gshell accounts for a 5 meg growth (unpacked). So, that would help account for most of the growth in the minimal assembly... I wonder if we should consider allowing gshell to be optional... I'd recommend *not*, though if we aren't happy with the additional bloat from the current impl, we can re-implement in pure-java and remove the dependency on Groovy. Its possible, though not very elegant IMO, as the AntBuilder syntax is ideal for launching new processes. Hi, I am actually quite a fan of Groovy commands and really would like Groovy to stick around. Beside the fact that the AntBuilder syntax is neat, Groovy commands could provide a very neat and simple way to dynamically introduce new commands w/o going through a compile cycle. I believe many Geronimo users are Java savvy enough, and hence also Groovy savvy enough to directly implement their commands in Groovy. It is in my understanding that gshell provides a gsh-bsf command (not tried, just read the code) and this is a first way to launch Groovy scripts; however, it would be great to directly map commands to groovy scripts out-of-the-box. Understood. Playing a bit of the devil's advocate here... A high percentage of Geronimo users will never create a custom Geronimo command, nor create or use GShell scripting capabilities. They'll want to start/stop Geronimo and deploy/undeploy applications. For these capabilities, geronimo-boilerplate-minimal-2.1.jar has grown by nearly 200% (3.0 meg - 8.3 meg). Also, most users will never generate new server assemblies. Yet, for this capability, we're increasing the minimal server size by 8.3 megs (essentially including the boilerplate-minimal jar twice). At the moment, minimal assembly has grown from 16 megs to 31 megs. IMO one of Geronimo's major advantages is that it's lightweight and flexible. We're still flexible, but we seem to have put on a few holiday pounds... I'd like to think about how we can slim things back down... So I think there are 2 issues here: 1. duplication of stuff in the boilerplate plugin. 2. Inclusion of a couple hefty jars. 1: We could remove all or almost all the code jars from lib and get them into the gshell classpath with explicit paths into the geronimo repository. This would mean we'd only have one copy of groovy and ant, the 2 largest jars AFAIK. I don't know how upgrade-proof we can make this with path wildcards, but it would work at least until someone wanted to upgrade groovy, ant, or one of the other jars. IIUC after a conversation with jdillon on IRC he's ok with this, so I'll see if I can get it to work. 2. a. groovy is cool but we could rewrite our current groovy code in java in, probably, a couple of days. I'm inclined to support leaving the groovy stuff in there but if we can make groovy optional -- usable if present -- then I wouldn't object if someone wanted to do this rewrite. I definitely think we should make it possible to have groovy gshell commands, whether or not the ones we supply are in groovy. 2.b. I also wonder if we really need all of core ant to use the launcher. Is there some way of maybe extracting the classes we actually need and just including them? thanks david jencks --kevan
