[BUILD] 2.0: Failed for Revision: 601648
Geronimo Revision: 601648 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/2.0/20071206/build-0300.log Building Geronimo branches/2.0 at Revision: 601648 + 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: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007 5:43 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Don't I get 24 hours to respond :) Yes, you *did* ;-) It passed. Seriously, I'm in favor releasing what we've got so far as that's the best way to get people (end users and us) engaged in the development process of the monitoring plugin. It's not ideal, but if there're people who believe it serves well in some use cases let the puppy go out and see the sun ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: How to get a meta-data complete ejb-jar.xml from an EJB jar?
On Dec 5, 2007, at 8:26 AM, 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? The metadata complete tree is available in the EjbModule object created by the builders. You'd want org.apache.geronimo.openejb.deployment.EjbModule.getSpecDD() -David
[jira] Commented: (GERONIMO-3653) Getting java.lang.NoClassDefFoundError while starting geronimo as windows service
[ https://issues.apache.org/jira/browse/GERONIMO-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548961 ] Hirohsi.T commented on GERONIMO-3653: - Thanks, I downloaded Geronimo 2.0.2, checked MD5 hash again. but got the same error. May be my wrapper.conf was wrong. Above article shows a wrapper.conf for Geronimo 2.0, so I replaced wrapper.java.classpaths with jar-files of geronimo-tomcat6-jee5-2.0.2/lib folder. Do I need any other modification? Getting java.lang.NoClassDefFoundError while starting geronimo as windows service -- Key: GERONIMO-3653 URL: https://issues.apache.org/jira/browse/GERONIMO-3653 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0.2 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.2, wrapper-windows-x86-32-3.2.3,Sun java 1.5.0_14 Reporter: Hirohsi.T Assignee: Jarek Gawor I am getting the following error while starting geronimo as a windows service. I am referring the following link. http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html Geronimo-tomcat6-jee5-2.0.1 startes well as a windows service, but with Geronimo-tomcat6-jee5-2.0.2, following error occurs. wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0_11)... jvm 1| Starting Geronimo Application Server v2.0.2 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apach... jvm 1| [*- ] 0% 1s Loading org.apach... jvm 1| [* ] 6% 1s Loading org.apach... jvm 1| [* ] 6% 1s Starting org.apach... jvm 1| [* ] 6% 2s Starting org.apach... jvm 1| [** ] 8% 2s Starting org.apach... jvm 1| [**- ] 8% 2s Loading org.apach... jvm 1| [** ] 9% 2s Loading org.apach... jvm 1| [*** ] 10% 2s Starting org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [*** ] 11% 2s Loading org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [ ] 13% 3s Starting org.apach... jvm 1| [-] 13% 3s Loading org.apach... jvm 1| [] 14% 3s Loading org.apach... jvm 1| [*] 15% 3s Starting org.apach... jvm 1| [*- ] 15% 3s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 5s Loading org.apach... jvm 1| [* ] 17% 5s Loading org.apach... jvm 1| [* ] 17% 5s Starting org.apach... jvm 1| [** ] 18% 5s Starting org.apach... jvm 1| [**- ] 18% 5s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [** ] 19% 6s Loading org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [**
Re: svn commit: r601659 - in /geronimo/server/trunk/framework/modules: geronimo-deployment/src/main/java/org/apache/geronimo/deployment/xmlbeans/ geronimo-upgrade/src/main/java/org/apache/geronimo/upg
On Dec 6, 2007, at 12:50 AM, [EMAIL PROTECTED] wrote:
Author: dblevins
Date: Thu Dec 6 00:50:16 2007
New Revision: 601659
URL: http://svn.apache.org/viewvc?rev=601659view=rev
Log:
rolling back the change. can't seem to get it to build.
Modified:
geronimo/server/trunk/framework/modules/geronimo-deployment/src/
main/java/org/apache/geronimo/deployment/xmlbeans/XmlBeansUtil.java
geronimo/server/trunk/framework/modules/geronimo-upgrade/src/main/
java/org/apache/geronimo/upgrade/Upgrade1_0To1_1.java
geronimo/server/trunk/framework/modules/geronimo-upgrade/src/test/
data/appclient_ejb_1_result.xml
Can't seem to get this change to work. Seems like the packaging
plugin stuff is permanently stuck on the old namespace. I've tried re-
bootstrapping followed by a full build and still get no love.
Any ideas where I may be going wrong?
The error is below.
-David
[INFO]
[INFO] Building Geronimo Configs :: Management EJB (MEJB)
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /Users/dblevins/work/geronimo-trunk/
applications/mejb/mejb/target
[INFO] Deleting directory /Users/dblevins/work/geronimo-trunk/
applications/mejb/mejb/target/classes
[INFO] Deleting directory /Users/dblevins/work/geronimo-trunk/
applications/mejb/mejb/target/test-classes
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /Users/dblevins/work/geronimo-trunk/applications/
mejb/mejb/target/classes/META-INF
[INFO] Copying 2 files to /Users/dblevins/work/geronimo-trunk/
applications/mejb/mejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/dblevins/work/geronimo-trunk/applications/
mejb/mejb/target/resources/META-INF/plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/dblevins/work/geronimo-
trunk/applications/mejb/mejb/target/resources/META-INF/plan.xml
[severity=FATAL_ERROR,message=unexpected element (uri:http://openejb.apache.org/xml/ns/openejb-jar-2.3
, local:openejb-jar). Expected elements are {http://geronimo.apache.org/xml/ns/naming-1.2
}abstract-naming-entry,{http://geronimo.apache.org/xml/ns/j2ee/application-1.2
}application,{http://geronimo.apache.org/xml/ns/
deployment-1.2}client-environment,{http://geronimo.apache.org/xml/ns/j2ee/application-1.2
}clustering,{http://geronimo.apache.org/xml/ns/naming-1.2}cmp-
connection-factory,{http://geronimo.apache.org/xml/ns/
deployment-1.2}dependencies,{http://geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0
}ejb-jar,{http://geronimo.apache.org/xml/ns/naming-1.2}ejb-local-
ref,{http://geronimo.apache.org/xml/ns/naming-1.2}ejb-ref,{http://geronimo.apache.org/xml/ns/naming-1.2
}entity-manager-factory-ref,{http://geronimo.apache.org/xml/ns/deployment-1.2
}environment,{http://geronimo.apache.org/xml/ns/
deployment-1.2}gbean,{http://geronimo.apache.org/xml/ns/
naming-1.2}gbean-ref,{http://openejb.apache.org/xml/ns/openejb-
jar-2.2}jndi,{http://openejb.apache.org/xml/ns/pkgen-2.1}key-
generator,{http://geronimo.apache.org/xml/ns/naming-1.2}message-
destination,{http://geronimo.apache.org/xml/ns/
deployment-1.2}module,{http://openejb.apache.org/xml/ns/openejb-jar-2.2
}openejb-jar,{http://java.sun.com/xml/ns/persistence}persistence,{http://geronimo.apache.org/xml/ns/naming-1.2
}persistence-context-ref,{http://geronimo.apache.org/xml/ns/
naming-1.2}resource-adapter,{http://geronimo.apache.org/xml/ns/naming-1.2
}resource-env-ref,{http://geronimo.apache.org/xml/ns/
naming-1.2}resource-ref,{http://geronimo.apache.org/xml/ns/j2ee/application-1.2
}security,{http://geronimo.apache.org/xml/ns/
security-2.0}security,{http://geronimo.apache.org/xml/ns/deployment-1.2
}server-environment,{http://geronimo.apache.org/xml/ns/
deployment-1.2}service,{http://geronimo.apache.org/xml/ns/
naming-1.2}service-ref,{http://geronimo.apache.org/xml/ns/
naming-1.2}web-container,{http://geronimo.apache.org/xml/ns/
naming
-1.2
}workmanager
,locator=[node=null,object=null,url=null,line=1,col=71,offset=-1]]
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
--- Viet Nguyen [EMAIL PROTECTED] wrote: 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. Perhaps I am not making it clear. The graph that is shown as requestTime for tomcatWebConnector is incorrect. The value returned by tomcat is count not time. We need to have different methods to generate graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics. Thanks Anita --- 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 Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[jira] Created: (GERONIMO-3679) Montitoring console should display 'available statistics' in a more organized way
Montitoring console should display 'available statistics' in a more organized way - Key: GERONIMO-3679 URL: https://issues.apache.org/jira/browse/GERONIMO-3679 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Currently the Monitoring Console shows all statistics in a list. It is very hard to make out what they are for. We need to categorize them according to their J2EETypes, e.g. for J2EEType=WebModule, we should list them under Web Applications. The non standard J2EEtype, e.g WebConnectors should go under a separate category. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to get a meta-data complete ejb-jar.xml from an EJB jar?
Thanks for the hints Jon. On Dec 6, 2007 4:48 AM, Jonathan Gallimore [EMAIL PROTECTED] wrote: 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-generateopenejb-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 irchttp://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
[jira] Created: (GERONIMO-3680) The Monitoring agent should optimize DB activity
The Monitoring agent should optimize DB activity Key: GERONIMO-3680 URL: https://issues.apache.org/jira/browse/GERONIMO-3680 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Currently the agent needs to be loaded in the same JVM as the server being monitored. The agent skews the statistics being monitered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3680) The Monitoring agent should optimize DB activity
[ https://issues.apache.org/jira/browse/GERONIMO-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha updated GERONIMO-3680: - Attachment: view4.jpg This graph was drawn with Monitoring console running locally with portoffset=10. The agent was running in the default instance. The commiitted transaction graph shows Tx committed every interval (5 minutes). There was no other application running on G. The Monitoring agent should optimize DB activity Key: GERONIMO-3680 URL: https://issues.apache.org/jira/browse/GERONIMO-3680 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Attachments: view4.jpg Currently the agent needs to be loaded in the same JVM as the server being monitored. The agent skews the statistics being monitered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3681) The Monitoring Console should allow the type of graph to be chosen
[ https://issues.apache.org/jira/browse/GERONIMO-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha updated GERONIMO-3681: - Summary: The Monitoring Console should allow the type of graph to be chosen (was: The Monitoring Console should all the type of graph to be chosen) The Monitoring Console should allow the type of graph to be chosen -- Key: GERONIMO-3681 URL: https://issues.apache.org/jira/browse/GERONIMO-3681 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha The CountStatistics can be displayed in 2 ways, the raw count and the throughput/utilization (count/sec). For raw count like ErrorCount a bar graph is more appropriate. The curvedArea is good for throughput. The user should be able to choose which graph style (bar, curvedArea, etc) to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3682) The Monitoring Console should keep information about Stats available from a managed object
The Monitoring Console should keep information about Stats available from a managed object -- Key: GERONIMO-3682 URL: https://issues.apache.org/jira/browse/GERONIMO-3682 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha The monitoring console should do a getStats on each of the available StatisticsProvider (without the query being enabled). It should use this information to build a DB about the nature of the statistics. This information should be used to fill in the default values in 'add a graph page'. Currently the description, x label, y label show as empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3681) The Monitoring Console should all the type of graph to be chosen
The Monitoring Console should all the type of graph to be chosen Key: GERONIMO-3681 URL: https://issues.apache.org/jira/browse/GERONIMO-3681 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha The CountStatistics can be displayed in 2 ways, the raw count and the throughput/utilization (count/sec). For raw count like ErrorCount a bar graph is more appropriate. The curvedArea is good for throughput. The user should be able to choose which graph style (bar, curvedArea, etc) to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Make Yoko core orb a Yoko subproject.
The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 Implement the Yoko ORB subproject in Geronimo as proposed above. Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFHWAw5gNg6eWEDv1kRAuVKAJ9Gc2fCOtn3Jk0mv57aVNOrVeBDggCeKO13 1e5yFKqg3Pho6du93nO/Oj8= =vgMZ -END PGP SIGNATURE-
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 david jencks On Dec 6, 2007, at 6:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven- plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
My +1 Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 On Dec 6, 2007, at 9:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code- base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven- plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Anita --- Rick McGuire [EMAIL PROTECTED] wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Uninstalling an application
I installed a plugin using 'plugins' portlet in the admin console. It worked as expected. After the plugin is uninstalled it leaves its dependent cars and ears behind. I have tried it from both command line and console. Next time I install the plugin using 'plugins' I get old dependencies. I have to hand delete the stuff from G/repository and edit config.xml to install it correctly. Is there a better way to do this? Thanks Anita Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[jira] Resolved: (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 resolved GERONIMO-3676. Resolution: Fixed Fix Version/s: 2.1 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 Fix For: 2.1 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: Our 2.1 assemblies are nearly 2x the size of 2.0.2
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... I agree 100% and that is why I started this thread. Almost always, the initial question from users first looking at Geronimo is how big and complex is Geronimo. I think we have to explore ways to make these features optional for at least the minimal assemblies or we will loose one of our value propositions. Making them plugins would seem to fit our overall objectives of a customizable and configurable server. What are the inhibitors to making these two features pure plugins and excluding them from the minimal assemblies? Joe --kevan
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Joe Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: Uninstalling an application
I have noticed this irksome behavior too. AFAIK, there isn't a better way. For now, this is a gaping hole in our plugin design. Seems like when a plugin is uninstalled, we'll have to uninstall all the child components recursively. Cheers Prasad On Dec 6, 2007 10:04 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: I installed a plugin using 'plugins' portlet in the admin console. It worked as expected. After the plugin is uninstalled it leaves its dependent cars and ears behind. I have tried it from both command line and console. Next time I install the plugin using 'plugins' I get old dependencies. I have to hand delete the stuff from G/repository and edit config.xml to install it correctly. Is there a better way to do this? Thanks Anita Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
I agree. We should make GShell flexible like our Geronimo server. I don't know if this makes sense but I'll just think aloud. At it's core should be the most basic features like start/stop and deploy/undeploy. Since Groovy is the culprit, can Groovy sit this one out ? I believe we use goals from g-m-p anyways to achieve those basic features. Everything else should be optionally built up using G-shell plugins. Groovy support can be one such optional plugin. Cheers Prasad On Dec 5, 2007 9:50 PM, Kevan Miller [EMAIL PROTECTED] 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... --kevan
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Regards, Alan On Dec 6, 2007, at 6:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven- plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
A related question. We currently have a dependency in Geronimo 2.1 on Yoko 1.0-incubating-SNAPSHOT. We need to eliminate that snapshot dependency (and several others) before we can ship Geronimo 2.1. Assuming that active VOTE passes would is the possibility of releasing a 1.0 version of Yoko in time for Geronimo 2.1? I was just looking at the possibility of creating another local build for the Geronimo release but I think we could have an official release of Yoko in Geronimo if it becomes subproject of Geronimo. Does that sound feasible or should we create a private build for Geronimo 2.1? Joe 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. Rick The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Cheers Prasad On Dec 6, 2007 9:43 AM, Rick McGuire [EMAIL PROTECTED] wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: Uninstalling an application
Anita Kulshreshtha wrote: I installed a plugin using 'plugins' portlet in the admin console. It worked as expected. After the plugin is uninstalled it leaves its dependent cars and ears behind. I have tried it from both command line and console. Next time I install the plugin using 'plugins' I get old dependencies. I have to hand delete the stuff from G/repository and edit config.xml to install it correctly. Is there a better way to do this? I'm not sure why you would have to edit config.xml. You should be able to uninstall the dependencies manually via command line or the console without the need to modify config.xml manually. The catch is that you need to know what those dependencies are that were installed as a result of your deployment. At the moment there is nothing to remove the dependencies. In order to be able to remove dependencies that were installed we would need to keep some use counts or something similar. We had discussed this a while back with some proposals ... but at the moment nothing is implemented. Joe
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
On Dec 6, 2007, at 8:05 AM, Joe Bohn wrote: A related question. We currently have a dependency in Geronimo 2.1 on Yoko 1.0- incubating-SNAPSHOT. We need to eliminate that snapshot dependency (and several others) before we can ship Geronimo 2.1. Assuming that active VOTE passes would is the possibility of releasing a 1.0 version of Yoko in time for Geronimo 2.1? I was just looking at the possibility of creating another local build for the Geronimo release but I think we could have an official release of Yoko in Geronimo if it becomes subproject of Geronimo. Does that sound feasible or should we create a private build for Geronimo 2.1? Lars Kuhne has some concerns about releasing v1.0. Maybe those have changed now that Yoko is in a different place. Regards, Alan
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
I personally think we should go the local build route. Until the subproject's been integrated in Geronimo, it's still bound by the incubating release rules. I suspect getting a 1.0 release actually approved and out the door in time for 2.1 given the current state of the community is not something we'd want to depend on. The local build like we used for 2.0 is probably the best approach at this date. Rick Joe Bohn wrote: A related question. We currently have a dependency in Geronimo 2.1 on Yoko 1.0-incubating-SNAPSHOT. We need to eliminate that snapshot dependency (and several others) before we can ship Geronimo 2.1. Assuming that active VOTE passes would is the possibility of releasing a 1.0 version of Yoko in time for Geronimo 2.1? I was just looking at the possibility of creating another local build for the Geronimo release but I think we could have an official release of Yoko in Geronimo if it becomes subproject of Geronimo. Does that sound feasible or should we create a private build for Geronimo 2.1? Joe 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. Rick The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the
[jira] Updated: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3678: --- Attachment: geronimo-3678.patch Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3653) Getting java.lang.NoClassDefFoundError while starting geronimo as windows service
[ https://issues.apache.org/jira/browse/GERONIMO-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549085 ] Jarek Gawor commented on GERONIMO-3653: --- Where (what directory) did you install Geronimo? Try installing it directly under c:\ . Maybe you are running into a long path name problem on Windows. Also, does Geronimo start up fine when started in the usual way (without the wrapper)? Getting java.lang.NoClassDefFoundError while starting geronimo as windows service -- Key: GERONIMO-3653 URL: https://issues.apache.org/jira/browse/GERONIMO-3653 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0.2 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.2, wrapper-windows-x86-32-3.2.3,Sun java 1.5.0_14 Reporter: Hirohsi.T Assignee: Jarek Gawor I am getting the following error while starting geronimo as a windows service. I am referring the following link. http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html Geronimo-tomcat6-jee5-2.0.1 startes well as a windows service, but with Geronimo-tomcat6-jee5-2.0.2, following error occurs. wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0_11)... jvm 1| Starting Geronimo Application Server v2.0.2 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apach... jvm 1| [*- ] 0% 1s Loading org.apach... jvm 1| [* ] 6% 1s Loading org.apach... jvm 1| [* ] 6% 1s Starting org.apach... jvm 1| [* ] 6% 2s Starting org.apach... jvm 1| [** ] 8% 2s Starting org.apach... jvm 1| [**- ] 8% 2s Loading org.apach... jvm 1| [** ] 9% 2s Loading org.apach... jvm 1| [*** ] 10% 2s Starting org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [*** ] 11% 2s Loading org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [ ] 13% 3s Starting org.apach... jvm 1| [-] 13% 3s Loading org.apach... jvm 1| [] 14% 3s Loading org.apach... jvm 1| [*] 15% 3s Starting org.apach... jvm 1| [*- ] 15% 3s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 5s Loading org.apach... jvm 1| [* ] 17% 5s Loading org.apach... jvm 1| [* ] 17% 5s Starting org.apach... jvm 1| [** ] 18% 5s Starting org.apach... jvm 1| [**- ] 18% 5s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [** ] 19% 6s Loading org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1
Re: Uninstalling an application
--- Joe Bohn [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: .. I'm not sure why you would have to edit config.xml. You should be able to uninstall the dependencies manually via command line or the console without the need to modify config.xml manually. The catch is that you need to know what those dependencies are that were installed as a result of your deployment. At the moment there is nothing to remove the dependencies. In order to be able to remove dependencies that were installed we would need to keep some use counts or something similar. We had discussed this a while back with some proposals ... but at the moment nothing is implemented. Joe I was using mrc-server-car. it installs mrc-ds-car and an ear. IIRC, After uninstalling mrc-server-car, shutdown and hand deleting mrc-ds-car, ear from G/repository, the mrc-ds-car was left in config.xml. The server could not be restarted. Thanks Anita Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[jira] Created: (GERONIMO-3683) Unable to view the installed geronimo plugins
Unable to view the installed geronimo plugins - Key: GERONIMO-3683 URL: https://issues.apache.org/jira/browse/GERONIMO-3683 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.0.2, 2.0.1 Environment: Windows XP Reporter: anish pathadan I have installed a geronimo plugin created by myself in my geronimo server.When I tried to access the plugins from a different server using the following url http://server-ip:8080/console-standard/maven-repo/ I am getting the following exception. 11:27:24,296 ERROR [[maven-repo]] Servlet.service() for servlet maven-repo threw exception java.lang.ArrayIndexOutOfBoundsException: 0 at org.apache.geronimo.console.car.GeronimoAsMavenServlet.generateConfig File(GeronimoAsMavenServlet.java:243) at org.apache.geronimo.console.car.GeronimoAsMavenServlet.handleRequest( GeronimoAsMavenServlet.java:90) at org.apache.geronimo.console.car.GeronimoAsMavenServlet.doGet(Geronimo AsMavenServlet.java:78) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:353) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44 7) at java.lang.Thread.run(Thread.java:619) Thanks, Anish -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen reassigned GERONIMO-3678: -- Assignee: Viet Hung Nguyen Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I am still unsure of why having the monitoring plugin in trunk is such a bad thing. It is in no way a perfect solution, but once it's in trunk we can engage users and other devs to better it. I do not see any dominating issues that should keep this plugin outside of trunk. Should we vote for this? Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 5, 2007, at 11:43 PM, Anita Kulshreshtha wrote: 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 :) We've got lot's of time to discuss. Jeff was just eager to understand what your concerns are... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 12:01 PM, Viet Nguyen wrote: I am still unsure of why having the monitoring plugin in trunk is such a bad thing. It is in no way a perfect solution, but once it's in trunk we can engage users and other devs to better it. I do not see any dominating issues that should keep this plugin outside of trunk. Should we vote for this? No we shouldn't vote... Not while we're discussing the issue. Possible that there may be a vote later. Just as likely that we'll find a consensus. Let's make sure we understand each other, first. --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 1:27 AM, Viet Nguyen wrote: 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. So, remote servers must have OpenEJB installed? Hmmm. It be really nice to monitor any Geronimo server... Why aren't we using JMX? Perhaps I'm missing something? If that's what we have, that's what we have... Just trying to be sure I understand... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Isn't the JSR 77 spec JMX based? Jeff Viet Nguyen wrote: Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
[jira] Assigned: (GERONIMO-3679) Montitoring console should display 'available statistics' in a more organized way
[ https://issues.apache.org/jira/browse/GERONIMO-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen reassigned GERONIMO-3679: -- Assignee: Viet Hung Nguyen Montitoring console should display 'available statistics' in a more organized way - Key: GERONIMO-3679 URL: https://issues.apache.org/jira/browse/GERONIMO-3679 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Currently the Monitoring Console shows all statistics in a list. It is very hard to make out what they are for. We need to categorize them according to their J2EETypes, e.g. for J2EEType=WebModule, we should list them under Web Applications. The non standard J2EEtype, e.g WebConnectors should go under a separate category. -- 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
Never mind...yes looks like MEJB is a requirement. Jeff Jeff Genender wrote: Isn't the JSR 77 spec JMX based? Jeff Viet Nguyen wrote: Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
So I think we are kind of caught in a catch 22 here... The issue is, the server is pluggable for the most part. People may/may not want EJB, but definitely want the management capabilities. Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? Viet Nguyen wrote: Yes, with the current implementation we have, OpenEJB is a prerequisite. JMX is a good solution too, but I wanted to follow the JSR 77 spec, which tells us to communicate with the server through the usage of MEJB, which is why OpenEJB is needed in this case. --Viet
[jira] Commented: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549105 ] Erik B. Craig commented on GERONIMO-3678: - Patch Committed revision 601793. Thanks Viet. Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote: --- Viet Nguyen [EMAIL PROTECTED] wrote: 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. Perhaps I am not making it clear. The graph that is shown as requestTime for tomcatWebConnector is incorrect. The value returned by tomcat is count not time. We need to have different methods to generate graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics. OK. That's good information. But, IMO, that doesn't necessarily mean we shouldn't move the monitoring plugin out of sandbox. It might mean that we aren't ready to *release* the monitoring plugin. I don't think we're having a *release* discussion -- at least we shouldn't be. We can have the discussion that we don't want to hold up a Geronimo 2.1 release waiting for monitoring plugin problems to be resolved, but I'd prefer we discuss without a particular timeline in mind... IMO, we have the following questions to answer: 1. Are we ready to move monitoring plugin out of sandbox? 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? Anita, Your objections seem to be in category 3, but I may be wrong. So, help us understand what you're thinking... --kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? There are goods and bads to both sides to this. If we strictly follow JSR 77, which means we will use MEJB and are forced to have OpenEJB as a pre-req, we won't have to worry if our architecture is good or not (I hope this is right), because we're following a standard for monitoring and management. On the flip side, if we use JMX to get a hold of the statistics, we will be able to monitor any type of server. Doesn't necessarily have to be a Geronimo server either, as long as we can connect to it via JMX, which I think is a huge plus. With that said, I think if we decide to take the alternative JMX path, it can be changed later (even though this was originally how we implemented it). I think the important thing now, is to determine whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
I certainly believe it deserves a spot in trunk...this is an enhancement to what we don't have before. That's progress...and its pretty darn cool too ;-) I definitely don't want my ideas to hold up its movement...just food for thought for down the road. Jeff Viet Nguyen wrote: Whats your thought on an adapter interface that provides for full JSR-77 compatibility, thus requiring EJB, or a switch that allows for pure JMX remoting? This would allow for compliance or be able to leverage the management without EJB if so desired. Thoughts? There are goods and bads to both sides to this. If we strictly follow JSR 77, which means we will use MEJB and are forced to have OpenEJB as a pre-req, we won't have to worry if our architecture is good or not (I hope this is right), because we're following a standard for monitoring and management. On the flip side, if we use JMX to get a hold of the statistics, we will be able to monitor any type of server. Doesn't necessarily have to be a Geronimo server either, as long as we can connect to it via JMX, which I think is a huge plus. With that said, I think if we decide to take the alternative JMX path, it can be changed later (even though this was originally how we implemented it). I think the important thing now, is to determine whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 10:06 AM, Paul McMahan wrote: On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote: 1. Are we ready to move monitoring plugin out of sandbox? +1 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I would vote for server/trunk/plugins, if for no other reason than to synchronize the monitoring plugin release with the server release. When the plugin gets to be more mature and can support multiple versions of geronimo then maybe we would consider moving it to a separate subproject. Also, moving it to trunk ensures that it will be included in the plugin catalog (~/.m2/repo/geronimo- plugins.xml) when you build trunk and will make it very easy to add monitoring to an assembly by just editing that assembly's pom. I don't have a strong opinion yet on where this should go, but I'd like to point out that any plugin you build with the car-maven- plugin, such as the roller or apacheds plugins, will have its metadata added to your local maven repo's geronimo-plugins.xml catalog. Similarly, no matter where the plugin is in svn, you can add it to a maven-built assembly by editing the assemblies pom. thanks david jencks 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? I agree with Anita that it will need some testing feedback before releasing to the wild. IMO the best way to facilitate that type of exposure is to move it into trunk. I think that this new monitoring feature is important enough to justify holding up a 2.1 release if it actually comes down to that. Best wishes, Paul
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote: 1. Are we ready to move monitoring plugin out of sandbox? +1 2. If yes, then where should we move it to? Should it be in server/ trunk/plugins or should the monitoring plugin be a subproject. I would vote for server/trunk/plugins, if for no other reason than to synchronize the monitoring plugin release with the server release. When the plugin gets to be more mature and can support multiple versions of geronimo then maybe we would consider moving it to a separate subproject. Also, moving it to trunk ensures that it will be included in the plugin catalog (~/.m2/repo/geronimo- plugins.xml) when you build trunk and will make it very easy to add monitoring to an assembly by just editing that assembly's pom. 3. What bug fixes/new features need to be added to the monitoring plugin before it's ready to be released? I agree with Anita that it will need some testing feedback before releasing to the wild. IMO the best way to facilitate that type of exposure is to move it into trunk. I think that this new monitoring feature is important enough to justify holding up a 2.1 release if it actually comes down to that. Best wishes, Paul
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 David On Dec 6, 2007, at 6:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code- base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven- plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Jay Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
On Dec 6, 2007, at 9:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. +1 --kevan
[jira] Resolved: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3678. Resolution: Fixed Fix Version/s: 2.1 Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures
[ https://issues.apache.org/jira/browse/GERONIMO-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549143 ] Sangjin Lee commented on GERONIMO-3617: --- I have a patch ready that addresses this issue and also GERONIMO-3616. Essentially the sendRequest() method is modified to return a ResponseFuture instead of void. In addition, an overloaded version of sendRequest() is created to take an additional argument of BlockingQueueResponseFuture. The queue will serve as a completion queue on which a ResponseFuture object will be added as the request is complete. The semantics is entirely analogous to a familiar java.util.concurrent.CompletionService, although I thought creating a concrete CompletionService implementation was an overkill. I have also created a test class that exercises the new method. I'll be uploading the patch... AsyncHttpClient should support retries on connection failures - Key: GERONIMO-3617 URL: https://issues.apache.org/jira/browse/GERONIMO-3617 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee AsyncHttpClient should provide a way to support retries if initial connection attempts fail. There should be a configuration where connection retries are enabled and also the maximum number of attempts is specified. If these are set, connection attempts should be retried. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Thanks, Erik B. Craig [EMAIL PROTECTED] Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
[jira] Commented: (GERONIMO-3616) AsyncHttpClient should support a batch invocation method
[ https://issues.apache.org/jira/browse/GERONIMO-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549144 ] Sangjin Lee commented on GERONIMO-3616: --- I have a patch ready that addresses this issue and also GERONIMO-3617. Essentially the sendRequest() method is modified to return a ResponseFuture instead of void. In addition, an overloaded version of sendRequest() is created to take an additional argument of BlockingQueueResponseFuture. The queue will serve as a completion queue on which a ResponseFuture object will be added as the request is complete. The semantics is entirely analogous to a familiar java.util.concurrent.CompletionService, although I thought creating a concrete CompletionService implementation was an overkill. I have also created a test class that exercises the new method. I'll be uploading the patch... AsyncHttpClient should support a batch invocation method Key: GERONIMO-3616 URL: https://issues.apache.org/jira/browse/GERONIMO-3616 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip It is desirable to have a method on AsyncHttpClient that submits multiple URLs at once. For example, public void sendRequests(HttpRequestMessage[] requests); One would expect it to initiate all HTTP requests as soon as possible in a non-blocking manner and return. Furthermore, it would be even more powerful if it returned a list of futures or a completion queue of results. One idea would be to return something like a completion queue (blocking) so that results or futures are added as they are completed. In other words, public BlockingQueueHttpResponseMessage sendRequests(HttpRequestMessage[] requests); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3615: -- Attachment: patch.zip a suggested patch AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3616) AsyncHttpClient should support a batch invocation method
[ https://issues.apache.org/jira/browse/GERONIMO-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3616: -- Attachment: patch.zip a suggested patch AsyncHttpClient should support a batch invocation method Key: GERONIMO-3616 URL: https://issues.apache.org/jira/browse/GERONIMO-3616 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip It is desirable to have a method on AsyncHttpClient that submits multiple URLs at once. For example, public void sendRequests(HttpRequestMessage[] requests); One would expect it to initiate all HTTP requests as soon as possible in a non-blocking manner and return. Furthermore, it would be even more powerful if it returned a list of futures or a completion queue of results. One idea would be to return something like a completion queue (blocking) so that results or futures are added as they are completed. In other words, public BlockingQueueHttpResponseMessage sendRequests(HttpRequestMessage[] requests); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures
[ https://issues.apache.org/jira/browse/GERONIMO-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3617: -- Comment: was deleted AsyncHttpClient should support retries on connection failures - Key: GERONIMO-3617 URL: https://issues.apache.org/jira/browse/GERONIMO-3617 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee AsyncHttpClient should provide a way to support retries if initial connection attempts fail. There should be a configuration where connection retries are enabled and also the maximum number of attempts is specified. If these are set, connection attempts should be retried. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3616) AsyncHttpClient should support a batch invocation method
[ https://issues.apache.org/jira/browse/GERONIMO-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549144 ] sjlee0 edited comment on GERONIMO-3616 at 12/6/07 11:17 AM: - I have a patch ready that addresses this issue and also GERONIMO-3615. Essentially the sendRequest() method is modified to return a ResponseFuture instead of void. In addition, an overloaded version of sendRequest() is created to take an additional argument of BlockingQueueResponseFuture. The queue will serve as a completion queue on which a ResponseFuture object will be added as the request is complete. The semantics is entirely analogous to a familiar java.util.concurrent.CompletionService, although I thought creating a concrete CompletionService implementation was an overkill. I have also created a test class that exercises the new method. I'll be uploading the patch... was (Author: sjlee0): I have a patch ready that addresses this issue and also GERONIMO-3617. Essentially the sendRequest() method is modified to return a ResponseFuture instead of void. In addition, an overloaded version of sendRequest() is created to take an additional argument of BlockingQueueResponseFuture. The queue will serve as a completion queue on which a ResponseFuture object will be added as the request is complete. The semantics is entirely analogous to a familiar java.util.concurrent.CompletionService, although I thought creating a concrete CompletionService implementation was an overkill. I have also created a test class that exercises the new method. I'll be uploading the patch... AsyncHttpClient should support a batch invocation method Key: GERONIMO-3616 URL: https://issues.apache.org/jira/browse/GERONIMO-3616 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip It is desirable to have a method on AsyncHttpClient that submits multiple URLs at once. For example, public void sendRequests(HttpRequestMessage[] requests); One would expect it to initiate all HTTP requests as soon as possible in a non-blocking manner and return. Furthermore, it would be even more powerful if it returned a list of futures or a completion queue of results. One idea would be to return something like a completion queue (blocking) so that results or futures are added as they are completed. In other words, public BlockingQueueHttpResponseMessage sendRequests(HttpRequestMessage[] requests); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549147 ] Sangjin Lee commented on GERONIMO-3615: --- I have a patch ready that addresses this issue and also GERONIMO-3616. Essentially the sendRequest() method is modified to return a ResponseFuture instead of void. In addition, an overloaded version of sendRequest() is created to take an additional argument of BlockingQueueResponseFuture. The queue will serve as a completion queue on which a ResponseFuture object will be added as the request is complete. The semantics is entirely analogous to a familiar java.util.concurrent.CompletionService, although I thought creating a concrete CompletionService implementation was an overkill. I have also created a test class that exercises the new method. I'll be uploading the patch... AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549168 ] Jeff Genender commented on GERONIMO-3615: - Sangjin...thanks for the patch... Could you do a svn diff from the root of the source code and upload that, since those are easier to view and work with. Thanks! AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender closed GERONIMO-3615. --- Resolution: Fixed Never mind the last comment, I manually applied this patch, but the next one, if you could do a svn diff from the top directory, it will create the patch. For adding java or new files, just do an svn add and teh diff will pick those up. Thanks for the excellent patch! AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3616) AsyncHttpClient should support a batch invocation method
[ https://issues.apache.org/jira/browse/GERONIMO-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender closed GERONIMO-3616. --- Resolution: Fixed Patch applied from GERONIMO-3615. AsyncHttpClient should support a batch invocation method Key: GERONIMO-3616 URL: https://issues.apache.org/jira/browse/GERONIMO-3616 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip It is desirable to have a method on AsyncHttpClient that submits multiple URLs at once. For example, public void sendRequests(HttpRequestMessage[] requests); One would expect it to initiate all HTTP requests as soon as possible in a non-blocking manner and return. Furthermore, it would be even more powerful if it returned a list of futures or a completion queue of results. One idea would be to return something like a completion queue (blocking) so that results or futures are added as they are completed. In other words, public BlockingQueueHttpResponseMessage sendRequests(HttpRequestMessage[] requests); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Uninstalling an application
Anita Kulshreshtha wrote: --- Joe Bohn [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: .. I'm not sure why you would have to edit config.xml. You should be able to uninstall the dependencies manually via command line or the console without the need to modify config.xml manually. The catch is that you need to know what those dependencies are that were installed as a result of your deployment. At the moment there is nothing to remove the dependencies. In order to be able to remove dependencies that were installed we would need to keep some use counts or something similar. We had discussed this a while back with some proposals ... but at the moment nothing is implemented. Joe I was using mrc-server-car. it installs mrc-ds-car and an ear. IIRC, After uninstalling mrc-server-car, shutdown and hand deleting mrc-ds-car, ear from G/repository, the mrc-ds-car was left in config.xml. The server could not be restarted. Why not just uninstall all 3 using the command line or web console so that you don't have to manually delete or edit the config.xml? Joe
[jira] Assigned: (GERONIMO-3528) Cannot lookup JNDI context inside some servlet event listeners.
[ https://issues.apache.org/jira/browse/GERONIMO-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3528: - Assignee: Jarek Gawor Cannot lookup JNDI context inside some servlet event listeners. --- Key: GERONIMO-3528 URL: https://issues.apache.org/jira/browse/GERONIMO-3528 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: naming Affects Versions: 1.1.1, 2.0.1 Reporter: Kan Ogawa Assignee: Jarek Gawor Attachments: examples.war, TestedResults.html In some servlet event listeners, JNDI context lookup fails. I encountered this issue while testing the following use case: - When http session has became invalid by timeout, web container automatically updates the logoff datetime to database system. So I have made sample application to reproduce this issue and the tested results. This stack trace is one of NG results: 16:23:35,661 ERROR [[/examples]] Session event listener threw exception java.lang.NullPointerException at org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44) at org.apache.xbean.naming.context.ContextFederation.getFederatedBinding(ContextFederation.java:71) at org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:63) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:129) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) at javax.naming.InitialContext.lookup(InitialContext.java:351) at examples.DBConnector.testConnection(DBConnector.java:26) at examples.HttpSessionListenerImpl.sessionDestroyed(HttpSessionListenerImpl.java:15) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:702) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:592) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:682) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:667) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1316) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:595) If Geronimo v1.1, the stack trace is: [ERROR] HttpSession - SystemDatabase doesn't have been lookuped from JNDI Context. javax.naming.NameNotFoundException: comp/env/jdbc/SystemDatasource at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:45) at javax.naming.InitialContext.lookup(InitialContext.java:351) at examples.DBConnector.testConnection(DBConnector.java:26) at examples.HttpSessionListenerImpl.sessionDestroyed(HttpSessionListenerImpl.java:15) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:685) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:577) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:678) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:663) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1283) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3684) Upgrade Monitoring Client to use Dojo 1.0.1
Upgrade Monitoring Client to use Dojo 1.0.1 --- Key: GERONIMO-3684 URL: https://issues.apache.org/jira/browse/GERONIMO-3684 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Reporter: Erik B. Craig Assignee: Erik B. Craig Currently the Monitoring client us using Dojo 0.4.x and should be upgraded to utilize Dojo 1.0.1 which offers far superior charting abilities and browser compatibility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 Thanks, Gianny On 07/12/2007, at 1:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven- plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 --jason On Dec 6, 2007, at 6:43 AM, Rick McGuire wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code- base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven- plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
[jira] Created: (GSHELL-91) Release plexus-component-annotations
Release plexus-component-annotations Key: GSHELL-91 URL: https://issues.apache.org/jira/browse/GSHELL-91 Project: GShell Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Jason Dillon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-91) Release plexus-component-annotations
[ https://issues.apache.org/jira/browse/GSHELL-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GSHELL-91: -- Assignee: Jason Dillon Release plexus-component-annotations Key: GSHELL-91 URL: https://issues.apache.org/jira/browse/GSHELL-91 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Jason Dillon Assignee: Jason Dillon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3528) Cannot lookup JNDI context inside some servlet event listeners.
[ https://issues.apache.org/jira/browse/GERONIMO-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549197 ] Jarek Gawor commented on GERONIMO-3528: --- Committed fixes to trunk (revision 601860). Cannot lookup JNDI context inside some servlet event listeners. --- Key: GERONIMO-3528 URL: https://issues.apache.org/jira/browse/GERONIMO-3528 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: naming Affects Versions: 1.1.1, 2.0.1 Reporter: Kan Ogawa Assignee: Jarek Gawor Attachments: examples.war, TestedResults.html In some servlet event listeners, JNDI context lookup fails. I encountered this issue while testing the following use case: - When http session has became invalid by timeout, web container automatically updates the logoff datetime to database system. So I have made sample application to reproduce this issue and the tested results. This stack trace is one of NG results: 16:23:35,661 ERROR [[/examples]] Session event listener threw exception java.lang.NullPointerException at org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44) at org.apache.xbean.naming.context.ContextFederation.getFederatedBinding(ContextFederation.java:71) at org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:63) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:129) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) at javax.naming.InitialContext.lookup(InitialContext.java:351) at examples.DBConnector.testConnection(DBConnector.java:26) at examples.HttpSessionListenerImpl.sessionDestroyed(HttpSessionListenerImpl.java:15) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:702) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:592) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:682) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:667) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1316) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:595) If Geronimo v1.1, the stack trace is: [ERROR] HttpSession - SystemDatabase doesn't have been lookuped from JNDI Context. javax.naming.NameNotFoundException: comp/env/jdbc/SystemDatasource at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:45) at javax.naming.InitialContext.lookup(InitialContext.java:351) at examples.DBConnector.testConnection(DBConnector.java:26) at examples.HttpSessionListenerImpl.sessionDestroyed(HttpSessionListenerImpl.java:15) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:685) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:577) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:678) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:663) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1283) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-91) Upgrade to plexus-component-annotations 1.0-alpha-1
[ https://issues.apache.org/jira/browse/GSHELL-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-91: --- Summary: Upgrade to plexus-component-annotations 1.0-alpha-1 (was: Release plexus-component-annotations) Upgrade to plexus-component-annotations 1.0-alpha-1 --- Key: GSHELL-91 URL: https://issues.apache.org/jira/browse/GSHELL-91 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-91) Upgrade to plexus-component-annotations 1.0-alpha-1
[ https://issues.apache.org/jira/browse/GSHELL-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-91: --- Component/s: Build Fix Version/s: 1.0-alpha-1 Upgrade to plexus-component-annotations 1.0-alpha-1 --- Key: GSHELL-91 URL: https://issues.apache.org/jira/browse/GSHELL-91 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-83) Upgrade to plexus-cdc-anno 1.0-alpha-9
[ https://issues.apache.org/jira/browse/GSHELL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-83: --- Summary: Upgrade to plexus-cdc-anno 1.0-alpha-9 (was: Upgrade to plexus-cdc-anno 1.0-alpha-1) Upgrade to plexus-cdc-anno 1.0-alpha-9 -- Key: GSHELL-83 URL: https://issues.apache.org/jira/browse/GSHELL-83 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-83) Upgrade to plexus-cdc-anno 1.0-alpha-9
[ https://issues.apache.org/jira/browse/GSHELL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-83. -- Resolution: Fixed Upgrade to plexus-cdc-anno 1.0-alpha-9 -- Key: GSHELL-83 URL: https://issues.apache.org/jira/browse/GSHELL-83 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-91) Upgrade to plexus-component-annotations 1.0-alpha-1
[ https://issues.apache.org/jira/browse/GSHELL-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-91. -- Resolution: Fixed Upgrade to plexus-component-annotations 1.0-alpha-1 --- Key: GSHELL-91 URL: https://issues.apache.org/jira/browse/GSHELL-91 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3528) Cannot lookup JNDI context inside some servlet event listeners.
[ https://issues.apache.org/jira/browse/GERONIMO-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3528. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Committed fix to branches/2.0 (revision 601864). Btw Jetty does not have this problem (at least in trunk). Cannot lookup JNDI context inside some servlet event listeners. --- Key: GERONIMO-3528 URL: https://issues.apache.org/jira/browse/GERONIMO-3528 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: naming Affects Versions: 1.1.1, 2.0.1 Reporter: Kan Ogawa Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 Attachments: examples.war, TestedResults.html In some servlet event listeners, JNDI context lookup fails. I encountered this issue while testing the following use case: - When http session has became invalid by timeout, web container automatically updates the logoff datetime to database system. So I have made sample application to reproduce this issue and the tested results. This stack trace is one of NG results: 16:23:35,661 ERROR [[/examples]] Session event listener threw exception java.lang.NullPointerException at org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44) at org.apache.xbean.naming.context.ContextFederation.getFederatedBinding(ContextFederation.java:71) at org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:63) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:129) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152) at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597) at javax.naming.InitialContext.lookup(InitialContext.java:351) at examples.DBConnector.testConnection(DBConnector.java:26) at examples.HttpSessionListenerImpl.sessionDestroyed(HttpSessionListenerImpl.java:15) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:702) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:592) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:682) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:667) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1316) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:595) If Geronimo v1.1, the stack trace is: [ERROR] HttpSession - SystemDatabase doesn't have been lookuped from JNDI Context. javax.naming.NameNotFoundException: comp/env/jdbc/SystemDatasource at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:45) at javax.naming.InitialContext.lookup(InitialContext.java:351) at examples.DBConnector.testConnection(DBConnector.java:26) at examples.HttpSessionListenerImpl.sessionDestroyed(HttpSessionListenerImpl.java:15) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:685) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:577) at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:678) at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:663) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1283) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1568) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1577) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1557) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-77) Upgrade Groovy+Maven integreation to 1.0-beta-3
[ https://issues.apache.org/jira/browse/GSHELL-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549206 ] Jason Dillon commented on GSHELL-77: This is needed for the javacc-m-p Upgrade Groovy+Maven integreation to 1.0-beta-3 --- Key: GSHELL-77 URL: https://issues.apache.org/jira/browse/GSHELL-77 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-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3679) Montitoring console should display 'available statistics' in a more organized way
[ https://issues.apache.org/jira/browse/GERONIMO-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3679: --- Attachment: geronimo-3679.patch Montitoring console should display 'available statistics' in a more organized way - Key: GERONIMO-3679 URL: https://issues.apache.org/jira/browse/GERONIMO-3679 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Attachments: geronimo-3679.patch Currently the Monitoring Console shows all statistics in a list. It is very hard to make out what they are for. We need to categorize them according to their J2EETypes, e.g. for J2EEType=WebModule, we should list them under Web Applications. The non standard J2EEtype, e.g WebConnectors should go under a separate category. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r601659 - in /geronimo/server/trunk/framework/modules: geronimo-deployment/src/main/java/org/apache/geronimo/deployment/xmlbeans/ geronimo-upgrade/src/main/java/org/apache/geronimo/upg
On Dec 6, 2007, at 12:55 AM, David Blevins wrote: On Dec 6, 2007, at 12:50 AM, [EMAIL PROTECTED] wrote: Author: dblevins Date: Thu Dec 6 00:50:16 2007 New Revision: 601659 URL: http://svn.apache.org/viewvc?rev=601659view=rev Log: rolling back the change. can't seem to get it to build. Modified: geronimo/server/trunk/framework/modules/geronimo-deployment/src/ main/java/org/apache/geronimo/deployment/xmlbeans/XmlBeansUtil.java geronimo/server/trunk/framework/modules/geronimo-upgrade/src/main/ java/org/apache/geronimo/upgrade/Upgrade1_0To1_1.java geronimo/server/trunk/framework/modules/geronimo-upgrade/src/test/ data/appclient_ejb_1_result.xml Can't seem to get this change to work. Seems like the packaging plugin stuff is permanently stuck on the old namespace. I've tried re-bootstrapping followed by a full build and still get no love. Any ideas where I may be going wrong? Building with '-e' as David suggested showed me the way to resolution :) Had an issue in the namespace filtering on the openejb side. -David
[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
[ https://issues.apache.org/jira/browse/GERONIMO-3615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549227 ] Sangjin Lee commented on GERONIMO-3615: --- Thanks. I'll do that from now on... AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- 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
Aside from the legal bits and few itty-bitty things GShell is ready for a release. Will try to wrap this up tonight. --jason On Nov 30, 2007, at 8:42 AM, Kevan Miller wrote: On Nov 29, 2007, at 3:18 AM, Jason Dillon 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. Hi Jason, I took a look at the GShell source. Things look good. Two files had old-style src license headers. I'm updating those. Remaining work, legal-wise, is getting license/notice files in your jars (and updating notice/license file in the root directory). Let's sync up later today. Can discuss the maven-remote-resources plugin and see if we can get it working for GShell... --kevan
[jira] Closed: (GSHELL-77) Upgrade Groovy+Maven integration to 1.0-beta-3
[ https://issues.apache.org/jira/browse/GSHELL-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-77. -- Resolution: Fixed Upgrade Groovy+Maven integration to 1.0-beta-3 -- Key: GSHELL-77 URL: https://issues.apache.org/jira/browse/GSHELL-77 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-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-77) Upgrade Groovy+Maven integration to 1.0-beta-3
[ https://issues.apache.org/jira/browse/GSHELL-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-77: --- Summary: Upgrade Groovy+Maven integration to 1.0-beta-3 (was: Upgrade Groovy+Maven integreation to 1.0-beta-3) Upgrade Groovy+Maven integration to 1.0-beta-3 -- Key: GSHELL-77 URL: https://issues.apache.org/jira/browse/GSHELL-77 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-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSS] Monitoring Client may need a new graphing engine
All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. -- Thanks, Erik B. Craig [EMAIL PROTECTED]
[BUILD] 2.1: Failed for Revision: 601958
OpenEJB trunk at 601816
Geronimo Revision: 601958 built with tests included
See the full build-2100.log file at
http://people.apache.org/~prasad/binaries/trunk/20071206/build-2100.log
[INFO] Surefire report directory:
/home/prasad/geronimo/trunk/plugins/activemq/geronimo-activemq/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.activemq.ConnectorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.168 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/prasad/geronimo/trunk/plugins/activemq/geronimo-activemq/target/geronimo-activemq-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-activemq-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/plugins/activemq/geronimo-activemq/target/geronimo-activemq-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-activemq/2.1-SNAPSHOT/geronimo-activemq-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo Modules :: J2EE Schema
[INFO]task-segment: [install]
[INFO]
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.schema/poms/geronimo-schema-j2ee_1.4-1.2.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/schema/geronimo-schema-j2ee_1.4/1.2/geronimo-schema-j2ee_1.4-1.2.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/schema/geronimo-schema-j2ee_1.4/1.2/geronimo-schema-j2ee_1.4-1.2.pom
8K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.schema/poms/geronimo-schema-jee_5-1.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/schema/geronimo-schema-jee_5/1.1/geronimo-schema-jee_5-1.1.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/schema/geronimo-schema-jee_5/1.1/geronimo-schema-jee_5-1.1.pom
7K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.schema/jars/geronimo-schema-jee_5-1.1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/schema/geronimo-schema-jee_5/1.1/geronimo-schema-jee_5-1.1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/schema/geronimo-schema-jee_5/1.1/geronimo-schema-jee_5-1.1.jar
1424K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.schema/jars/geronimo-schema-j2ee_1.4-1.2.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/schema/geronimo-schema-j2ee_1.4/1.2/geronimo-schema-j2ee_1.4-1.2.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/schema/geronimo-schema-j2ee_1.4/1.2/geronimo-schema-j2ee_1.4-1.2.jar
1127K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/plugins/j2ee/geronimo-j2ee-schema/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/plugins/j2ee/geronimo-j2ee-schema/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 6 source files to
/home/prasad/geronimo/trunk/plugins/j2ee/geronimo-j2ee-schema/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
/home/prasad/geronimo/trunk/plugins/j2ee/geronimo-j2ee-schema/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/prasad/geronimo/trunk/plugins/j2ee/geronimo-j2ee-schema/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.schema.SchemaConversionUtilsTest
Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec
FAILURE!
Results :
Failed tests:
testGeronimoNamingNamespaceChange(org.apache.geronimo.schema.SchemaConversionUtilsTest)
Tests run: 9, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560
[jira] Commented: (GERONIMO-3679) Montitoring console should display 'available statistics' in a more organized way
[ https://issues.apache.org/jira/browse/GERONIMO-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549288 ] Erik B. Craig commented on GERONIMO-3679: - Patch Committed revision 601966. Thanks Viet! Montitoring console should display 'available statistics' in a more organized way - Key: GERONIMO-3679 URL: https://issues.apache.org/jira/browse/GERONIMO-3679 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Attachments: geronimo-3679.patch Currently the Monitoring Console shows all statistics in a list. It is very hard to make out what they are for. We need to categorize them according to their J2EETypes, e.g. for J2EEType=WebModule, we should list them under Web Applications. The non standard J2EEtype, e.g WebConnectors should go under a separate category. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Monitoring Client may need a new graphing engine
On Dec 6, 2007, at 9:29 PM, Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. I'll take a look at the license info for Timeplot. However, if Timeplot doesn't work in IE, that's a severe disadvantage. Can you explain what doesn't work? --kevan
Re: [DISCUSS] Monitoring Client may need a new graphing engine
On Dec 6, 2007, at 10:35 PM, Kevan Miller wrote: On Dec 6, 2007, at 9:29 PM, Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. I'll take a look at the license info for Timeplot. However, if Timeplot doesn't work in IE, that's a severe disadvantage. Can you explain what doesn't work? From what I understand as far as Timeplot goes, it's due to Timeplot using 'Canvas' to do the rendering, which is not something that Internet Explorer has support for, and they are looking to begin using an open sourced google library called 'explorer canvas' to enable internet explorer support in the next release (reference here on their site: http://simile.mit.edu/wiki/Timeplot_Limitations ) As far as current dojo (0.4.3) is concerned, from what i can tell - any browser on a Mac will not draw any of the surrounding text on a graph... at least as implemented in a portlet. (The Axis labels and values are absent). I have also been unable to get IE6 to draw the graphs in the current portlet as implemented. --kevan Thanks for taking a look at the license Kevan. -Thanks, Erik B. Craig
Re: [DISCUSS] Monitoring Client may need a new graphing engine
On Dec 6, 2007, at 9:29 PM, Erik B. Craig wrote: Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... K. License-wise, there's no problem with Timeplot. It's a straight BSD license... --kevan
Re: [DISCUSS] Monitoring Client may need a new graphing engine
On Dec 6, 2007, at 9:29 PM, Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. Errmmm, I stand corrected by myself, it looks like in 0.4.3 things are working as expected on Mac... at least in Firefox and Safari on OS 10.5.1, my experimentation was done with Dojo 0.4.2 previously. Internet Explorer is still hosed. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. -- Thanks, Erik B. Craig [EMAIL PROTECTED]
Re: [DISCUSS] Monitoring Client may need a new graphing engine
Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. The mouse-over feature is cool ... but considering all things listed as advantages/disadvantages it seems to me that the dojo 0.4.3 comes out ahead for now. After timeplot has addressed the IE issue and x/y axis labels (with min/max) then it would be much more compelling to consider a change. Just my opinion based upon the very nice summary you provided. Thanks, Joe
Re: [DISCUSS] Monitoring Client may need a new graphing engine
I agree with Joe. I think having the x/y axis labels are very important, especially if we wish to allow the admin to customize these graphs. It will be rather confusing without them (unless we can write an extension for Simile to add this feature). Also, I like the curved lines. --Viet
Re: [DISCUSS] Monitoring Client may need a new graphing engine
+100 for simile. IMO the curved lines in dojo 0.4.3 are really bogus and basically lie about how much data you have. I'd recommend you not use them if possible. The mouse-over feature is very useful, you can easily read actual numbers off the graph multi-series display is pretty much essential IMO to get a reasonable view of data on only one web page. The multi-series display example you point to indicates the meaning of each data series in text above the graph. How is this worse than labelling the y-axis? thanks david jencks On Dec 6, 2007, at 6:29 PM, Erik B. Craig wrote: All, Currently the monitoring client is using Dojo 0.4.3 charting, which does not necessarily behave as expected on Firefox/Safari on a mac, or on IE6 on Windows. I consider this to be a shortcoming, and given the new version of Dojo available (1.0.1), began investigating migrating the monitoring client over to the new version of Dojo, only to find that the new version of dojo appears to be a significant rewrite of the old code base, leaving out some features that I consider to be very visually pleasing and important for statistics viewing. While rummaging through the Dojo forums, I stumbled upon another Javascript graphing framework called Timeplot, which is part of the SIMILE project at MIT, and while this has it's own set of limitations... I'm trying to figure out the lesser of three evils before it comes a time that this monitoring plugin will be released, so that I have enough time (read: 3-5 days) to migrate the javascript generation over to something new if necessary. I have created a small demonstration page that shows all three options graphed with the same data series, as well as weighing some of the advantages/disadvantages I could come up with, Please have a look, and let me know your thoughts. http://people.apache.org/~ecraig/graphdemo/ Personally, I think it would be really cool if we could use the Timeplot graphing libraries, as it is all BSD licensed and therefore friendly I believe (right, Kevan?)... and also EXTREMELY cool for showing multiple data series in one chart. -- Thanks, Erik B. Craig [EMAIL PROTECTED]
