[jira] Created: (GERONIMO-3662) Provide JCA Resource statistics
Provide JCA Resource statistics --- Key: GERONIMO-3662 URL: https://issues.apache.org/jira/browse/GERONIMO-3662 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: connector Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Provide JCAResource statistics defined by JCAStats JRR77.6.18 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3660) monitoring collecting agent needs to have a local interface for the MRC
[ https://issues.apache.org/jira/browse/GERONIMO-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3660. Resolution: Fixed Fix Version/s: 2.1 monitoring collecting agent needs to have a local interface for the MRC --- Key: GERONIMO-3660 URL: https://issues.apache.org/jira/browse/GERONIMO-3660 Project: Geronimo Issue Type: Improvement 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-3660.patch The collecting agent (server side) needs to have a local interface. This will allow the collecting agent to get a hold of the ejb to process some data too. As a temporary solution, I used a RemoteInitialContextFactory to get a hold of the EJB which resides locally on that machine. However, Jarek submitted a patch to openEJB which now allows LocalInitialContextFactory to authenticate an EJB lookup, so we need to make use of it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plan Creator for Web Apps - Implementation Complete!
On Nov 16, 2007 9:15 PM, Shiva Kumar H R [EMAIL PROTECTED] wrote: The Plan Creator portlet/wizard in Admin Console is now complete. https://issues.apache.org/jira/browse/GERONIMO-3254 Features: a) EJB, EJB Local, JDBC Connection Pool, JMS Connection Factory, JMS Destination, JavaMail Session Web Service *References *declared in the web-apps are auto discovered and users are asked to resolve them by listing Available Resources in the server environment to which they can be linked. b) Above type of references declared inside the Java classes through *Annotations *are also auto discovered. c) Simplified configuration of *Security*. I have only done limited testing so please raise any issues you might face while using. I am next working on handling EJB jars. Since most of the infrastructure code is already in place, this should be complete in the next 1 or 2 weeks (ready to be included in 2.1 release). A lot of work is still pending w.r.t. handling EJB-jars. I am not sure how much time it might take. Comments/Feedback/Suggestions Welcome. -- Thanks, Shiva -- Thanks, Shiva
Releasing the parent spec pom.
I was just starting the release process for the latest activation and javamail spec jars. The parent pom for the current trunk version is listed as being 1.2-SNAPSHOT. Previous releases used a 1.2 version number. However, the current trunk version will not build with the 1.2 parent pom. It appears that when the OSGI changes were introduced, the parent pom version was made 1.2-SNAPSHOT when it should have been 1.3-SNAPSHOT. Is that correct? I can deal with that, but now I'm trying to figure out the release process for the parent pom. How is this done? In the past, we released all of the specs as a group, so the 1_1 tag branch contained the 1.1 parent POM. I don't see anything in our branches to indicate that a 1.2 parent pom release was ever made, but we have current released specs that have it as a dependency. Additionally, the specs pom in trunk explicitly lists each of the submodules in the pom, which is a bit of a problem if it is to be built from a branch containing just the pom and not the subprojects. So anyway, I'm guessing the first step needs to be to update the parent pom version to 1.3-SNAPSHOT. Once that's done, whats the procedure for creating a non-snapshot version for newly released spec jars to use as a parent? Rick
[jira] Created: (GERONIMO-3663) Spec trunk version number needs to be 1.3-SNAPSHOT.
Spec trunk version number needs to be 1.3-SNAPSHOT. --- Key: GERONIMO-3663 URL: https://issues.apache.org/jira/browse/GERONIMO-3663 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Affects Versions: 2.1 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 2.1 The current trunk parent pom for the specs is at a 1.2-SNAPSHOT level. Unfortunately, the most recent released version of the pom is 1.2, which will cause a conflict when releasing a new version. This needs to be 1.3-SNAPSHOT and released as 1.3 before new spec releases can be made from that tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3663) Spec trunk version number needs to be 1.3-SNAPSHOT.
[ https://issues.apache.org/jira/browse/GERONIMO-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3663. -- Resolution: Fixed Committed revision 600574. Spec trunk version number needs to be 1.3-SNAPSHOT. --- Key: GERONIMO-3663 URL: https://issues.apache.org/jira/browse/GERONIMO-3663 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.1 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: 2.1 The current trunk parent pom for the specs is at a 1.2-SNAPSHOT level. Unfortunately, the most recent released version of the pom is 1.2, which will cause a conflict when releasing a new version. This needs to be 1.3-SNAPSHOT and released as 1.3 before new spec releases can be made from that tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-87) Create ghell commands for wsgen and wsimport tools
Create ghell commands for wsgen and wsimport tools -- Key: GSHELL-87 URL: https://issues.apache.org/jira/browse/GSHELL-87 Project: GShell Issue Type: New Feature Security Level: public (Regular issues) Components: Commands Reporter: Jarek Gawor Assignee: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3664) JNDIView Portlet should list ResourceAdaptors and its JCAManagedConnectionFactories for RAR Modules
JNDIView Portlet should list ResourceAdaptors and its JCAManagedConnectionFactories for RAR Modules --- Key: GERONIMO-3664 URL: https://issues.apache.org/jira/browse/GERONIMO-3664 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha JNDI portlet should display at least the following information for RARs: ResourceAdapterModule- ResourceAdapters- JCAResources- JCAConnectoinFactories- names e.g.the system-database.../car will have two entries - NoTxDatasource and SystemDatasource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-66) Auto-generate cli syntax/usage string when displaying --help
[
https://issues.apache.org/jira/browse/GSHELL-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik B. Craig reassigned GSHELL-66:
---
Assignee: Erik B. Craig
Auto-generate cli syntax/usage string when displaying --help
Key: GSHELL-66
URL: https://issues.apache.org/jira/browse/GSHELL-66
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Support - CLP
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Erik B. Craig
Priority: Minor
Fix For: 1.0-alpha-2
When generating a commands --help, the syntax/usage should be auto-generated.
For example take the {{help}} command's {{--help}}:
{noformat}
[EMAIL PROTECTED]:/ help --help
help
--
VALCommand name
-h (--help)Display this help message
{noformat}
Ideally this should be rendered as:
{noformat}
[EMAIL PROTECTED]:/ help --help
syntax: help [options] [COMMAND]
arguments:
COMMANDCommand name
options:
-h (--help) Display this help message
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Apache Geronimo Context
Hi, I want to kown how Apache Geronimo communicate with the other Applications and Servers, what does it use for this communication? I mean the different media, protocols and Data format, that Geronimo uses for the exanchange of information with its extern environment. Thank you -- View this message in context: http://www.nabble.com/Apache-Geronimo-Context-tf4938237s134.html#a14134941 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Created: (GSHELL-88) Source command does not ignore empty lines or does not support comments
Source command does not ignore empty lines or does not support comments --- Key: GSHELL-88 URL: https://issues.apache.org/jira/browse/GSHELL-88 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Commands - Builtins Reporter: Jarek Gawor Assignee: Jason Dillon Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[
https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GSHELL-88:
--
Attachment: GSHELL-88.patch
Added a patch that adds support for comments ('#') and ignores empty lines.
Source command does not ignore empty lines or does not support comments
---
Key: GSHELL-88
URL: https://issues.apache.org/jira/browse/GSHELL-88
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Commands - Builtins
Reporter: Jarek Gawor
Assignee: Jason Dillon
Attachments: GSHELL-88.patch
Source command does not ignore empty lines or does not support comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
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 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
How to get memory statistics from a remote Geronimo runtime?
I am wondering if the following (which works) is the correct way to get
maxHeapSize and usedMemory from a remote Geronimo server.
import org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user, password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector = JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats) mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic = (BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
[jira] Resolved: (GSHELL-87) Create ghell commands for wsgen and wsimport tools
[ https://issues.apache.org/jira/browse/GSHELL-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GSHELL-87. --- Resolution: Invalid Moved this bug to Geronimo project as most work will be done there: https://issues.apache.org/jira/browse/GERONIMO-3665. Create ghell commands for wsgen and wsimport tools -- Key: GSHELL-87 URL: https://issues.apache.org/jira/browse/GSHELL-87 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Commands Reporter: Jarek Gawor Assignee: Jarek Gawor -- 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 memory statistics from a remote Geronimo runtime?
You can do it that way or do it the JSR-77 way.
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.RemoteInitialContextFactory);
props.setProperty(Context.PROVIDER_URL, ejbd://localhost:4201);
props.setProperty(Context.SECURITY_PRINCIPAL, username);
props.setProperty(Context.SECURITY_CREDENTIALS, password);
props.setProperty(openejb.authentication.realmName,
geronimo-admin);
InitialContext ctx = new InitialContext(p);
ManagementHome mejbHome =
(ManagementHome)ctx.lookup(ejb/mgmt/MEJBRemoteHome);
mejb = mejbHome.create();
Stats stats = (Stats)mejb.getAttribute(new
ObjectName(mbean_name_here), stats);
Hope this helps,
Viet Nguyen
On Dec 3, 2007 1:52 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to get
maxHeapSize and usedMemory from a remote Geronimo server.
import org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user, password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector = JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName =
ObjectName.getInstance(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats) mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic = (BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
[jira] Assigned: (GERONIMO-3665) Create ghell commands for wsgen and wsimport tools
[ https://issues.apache.org/jira/browse/GERONIMO-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3665: - Assignee: Jarek Gawor Create ghell commands for wsgen and wsimport tools -- Key: GERONIMO-3665 URL: https://issues.apache.org/jira/browse/GERONIMO-3665 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3665) Create ghell commands for wsgen and wsimport tools
[ https://issues.apache.org/jira/browse/GERONIMO-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547943 ] Jarek Gawor commented on GERONIMO-3665: --- Added basic GShell commands to trunk (revision 600633) but they are not registered with gshell yet. Create ghell commands for wsgen and wsimport tools -- Key: GERONIMO-3665 URL: https://issues.apache.org/jira/browse/GERONIMO-3665 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3665) Create ghell commands for wsgen and wsimport tools
Create ghell commands for wsgen and wsimport tools -- Key: GERONIMO-3665 URL: https://issues.apache.org/jira/browse/GERONIMO-3665 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Jarek Gawor -- 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 memory statistics from a remote Geronimo runtime?
That worked too. Thanks.
++Vamsi
On Dec 4, 2007 12:29 AM, Viet Nguyen [EMAIL PROTECTED] wrote:
You can do it that way or do it the JSR-77 way.
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.RemoteInitialContextFactory);
props.setProperty(Context.PROVIDER_URL,
ejbd://localhost:4201);
props.setProperty(Context.SECURITY_PRINCIPAL, username);
props.setProperty(Context.SECURITY_CREDENTIALS, password);
props.setProperty(openejb.authentication.realmName,
geronimo-admin);
InitialContext ctx = new InitialContext(p);
ManagementHome mejbHome =
(ManagementHome)ctx.lookup(ejb/mgmt/MEJBRemoteHome);
mejb = mejbHome.create();
Stats stats = (Stats)mejb.getAttribute(new
ObjectName(mbean_name_here), stats);
Hope this helps,
Viet Nguyen
On Dec 3, 2007 1:52 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to get
maxHeapSize and usedMemory from a remote Geronimo server.
import org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector = JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName =
ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats) mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
[jira] Created: (GERONIMO-3666) monitoring plugin to provide for a way to access archive data
monitoring plugin to provide for a way to access archive data - Key: GERONIMO-3666 URL: https://issues.apache.org/jira/browse/GERONIMO-3666 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubnutu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen We need to modify the Graphs table schema a little bit to account for the archiving option. Additionally, we need to update the edit/add jsp pages to allow this to be configured. Finally, we need to fill the numbers by pulling from the Archived database (on the mrc-server side) in the case where the user is wanting to view the archived data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3666) monitoring plugin to provide for a way to access archive data
[ https://issues.apache.org/jira/browse/GERONIMO-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3666: --- Attachment: geronimo-3666.patch this patch requires an svn delete mrc-server/mrc-ejb/src/main/java/org/apache/geronimo/monitor/SMP.java Thanks, Viet monitoring plugin to provide for a way to access archive data - Key: GERONIMO-3666 URL: https://issues.apache.org/jira/browse/GERONIMO-3666 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubnutu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3666.patch We need to modify the Graphs table schema a little bit to account for the archiving option. Additionally, we need to update the edit/add jsp pages to allow this to be configured. Finally, we need to fill the numbers by pulling from the Archived database (on the mrc-server side) in the case where the user is wanting to view the archived data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.1: Failed for Revision: 600650
OpenEJB trunk at 600635 Geronimo Revision: 600650 built with tests included See the full build-1500.log file at http://people.apache.org/~prasad/binaries/trunk/20071203/build-1500.log central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.geronimo.specs:geronimo-el_1.0_spec:jar:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-el_1.0_spec \ -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-el_1.0_spec \ -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.configs:jee-specs:car:2.1-SNAPSHOT 2) org.apache.geronimo.specs:geronimo-el_1.0_spec:jar:1.0 -- 1 required artifact is missing. for artifact: org.apache.geronimo.configs:jee-specs:car:2.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.geronimo.specs:geronimo-el_1.0_spec:jar:1.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-el_1.0_spec \ -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-el_1.0_spec \ -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.configs:jee-specs:car:2.1-SNAPSHOT 2) org.apache.geronimo.specs:geronimo-el_1.0_spec:jar:1.0 -- 1 required artifact is missing. for artifact: org.apache.geronimo.configs:jee-specs:car:2.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository
[jira] Commented: (GERONIMO-3666) monitoring plugin to provide for a way to access archive data
[ https://issues.apache.org/jira/browse/GERONIMO-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547990 ] Erik B. Craig commented on GERONIMO-3666: - Patch Committed revision 600692. Thanks Viet. monitoring plugin to provide for a way to access archive data - Key: GERONIMO-3666 URL: https://issues.apache.org/jira/browse/GERONIMO-3666 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubnutu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3666.patch We need to modify the Graphs table schema a little bit to account for the archiving option. Additionally, we need to update the edit/add jsp pages to allow this to be configured. Finally, we need to fill the numbers by pulling from the Archived database (on the mrc-server side) in the case where the user is wanting to view the archived data. -- 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
On Dec 1, 2007, at 8:30 PM, Jason Dillon wrote: Okay, I put it back in... publishing new snaps now. Thanks. So, first the NOTICE files in all of the jars are full of useless/ misleading gunk. Is it possible to lose them? All they need to contain is the following: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for GShell CLI // -- GShell CLI Copyright 2003-2007 Apache Software Foundation This product includes software developed at Apache Software Foundation (http://www.apache.org). And nothing else. Guidance is welcome... The assemblies are another matter. License text is needed for non-ASL2 licensed jar files. The NOTICE file needs to reproduce the notice files from embedded jar files (ASL2) and give appropriate attribution to their project (this is license dependent). I'll take a look at the jar files for license/notice info. --kevan
[jira] Created: (GERONIMO-3667) JNDI is not available in servlet.destroy() or ServletContextListener.contextDestroyed() callbacks
JNDI is not available in servlet.destroy() or ServletContextListener.contextDestroyed() callbacks - Key: GERONIMO-3667 URL: https://issues.apache.org/jira/browse/GERONIMO-3667 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-3609: Fix seems to have removed jndi from servlet listeners. JNDI lookup problem on fowarded calls in Jetty -- Key: GERONIMO-3609 URL: https://issues.apache.org/jira/browse/GERONIMO-3609 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor Assignee: David Jencks Fix For: 2.1 Attachments: GERONIMO-3609.patch I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3609: --- Attachment: GERONIMO-3609-2.patch Possible approach for getting jndi in the right places. This is completely untested, all I know is it compiles for me. JNDI lookup problem on fowarded calls in Jetty -- Key: GERONIMO-3609 URL: https://issues.apache.org/jira/browse/GERONIMO-3609 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x, 2.1 Reporter: Jarek Gawor Assignee: David Jencks Fix For: 2.1 Attachments: GERONIMO-3609-2.patch, GERONIMO-3609.patch I am having trouble looking up a DataSource from an EAR containing a WAR (which is where the lookup takes place) using JNDI. I find it to be really weird, because I can look up the DataSource fine if I do it through a JSP page or a servlet. However, when I try to look it up in portlet code, the jndi name does not seem to be visible, although it is visible in the JNDI viewer. Additionally, I have successfully looked it up through jsp and servlets. This is only a problem in Jetty, because the same code works fine for Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3554) monitoring plugin: client should use an ArrayList instead of a Vector
[ https://issues.apache.org/jira/browse/GERONIMO-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen reassigned GERONIMO-3554: -- Assignee: Viet Hung Nguyen monitoring plugin: client should use an ArrayList instead of a Vector - Key: GERONIMO-3554 URL: https://issues.apache.org/jira/browse/GERONIMO-3554 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Trivial There are some places in the client code where Vectors are used. ArrayLists would be a better type for this particular instance because of efficiency. Vectors are used for synchronization purposes, which the client does not need to do. ArrayLists would be faster and serve the same purpose in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3666) monitoring plugin to provide for a way to access archive data
[ https://issues.apache.org/jira/browse/GERONIMO-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen resolved GERONIMO-3666. Resolution: Fixed Fix Version/s: 2.1 monitoring plugin to provide for a way to access archive data - Key: GERONIMO-3666 URL: https://issues.apache.org/jira/browse/GERONIMO-3666 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubnutu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3666.patch We need to modify the Graphs table schema a little bit to account for the archiving option. Additionally, we need to update the edit/add jsp pages to allow this to be configured. Finally, we need to fill the numbers by pulling from the Archived database (on the mrc-server side) in the case where the user is wanting to view the archived data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3668) monitoring client should encrypt all passwords
[ https://issues.apache.org/jira/browse/GERONIMO-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3668: --- Attachment: geronimo-3668.patch monitoring client should encrypt all passwords -- Key: GERONIMO-3668 URL: https://issues.apache.org/jira/browse/GERONIMO-3668 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubuntu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Critical Attachments: geronimo-3668.patch We need to encrypt all passwords that are stored in the DB. Right now, they are not encrypted in any way. I suggest we use the EncryptionManager to encrypt/decrypt these passwords. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GShell 1.0-alpha-1 update
I will look at creating a custom resource bundle to correct this for gshell. And if it works well, we can move it to genesis and use it for the rest of the projects. --jason On Dec 3, 2007, at 1:59 PM, Kevan Miller wrote: On Dec 1, 2007, at 8:30 PM, Jason Dillon wrote: Okay, I put it back in... publishing new snaps now. Thanks. So, first the NOTICE files in all of the jars are full of useless/ misleading gunk. Is it possible to lose them? All they need to contain is the following: // -- // NOTICE file corresponding to the section 4d of The Apache License, // Version 2.0, in this case for GShell CLI // -- GShell CLI Copyright 2003-2007 Apache Software Foundation This product includes software developed at Apache Software Foundation (http://www.apache.org). And nothing else. Guidance is welcome... The assemblies are another matter. License text is needed for non- ASL2 licensed jar files. The NOTICE file needs to reproduce the notice files from embedded jar files (ASL2) and give appropriate attribution to their project (this is license dependent). I'll take a look at the jar files for license/notice info. --kevan
Re: svn commit: r600692 - in /geronimo/sandbox/monitoring: client/client-war/src/main/java/org/apache/geronimo/plugins/monitoring/client/ client/client-war/src/main/java/org/apache/geronimo/plugins/mo
Hi, I quickly had a look to the monitoring components. I think it is going well. Though, I have one comment: is it possible to increase unit testing? Thanks, Gianny On 04/12/2007, at 8:16 AM, [EMAIL PROTECTED] wrote: Author: ecraig Date: Mon Dec 3 13:16:49 2007 New Revision: 600692 URL: http://svn.apache.org/viewvc?rev=600692view=rev Log: GERONIMO-3666 monitoring plugin to provide for a way to access archive data Patch by Viet Nguyen.
[jira] Created: (GERONIMO-3668) monitoring client should encrypt all passwords
monitoring client should encrypt all passwords -- Key: GERONIMO-3668 URL: https://issues.apache.org/jira/browse/GERONIMO-3668 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: ubuntu Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Priority: Critical Attachments: geronimo-3668.patch We need to encrypt all passwords that are stored in the DB. Right now, they are not encrypted in any way. I suggest we use the EncryptionManager to encrypt/decrypt these passwords. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[ https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548068 ] Jason Dillon commented on GSHELL-88: I had planned to put this into the grammar, but for now this will work fine. Thx, will apply shortly. Source command does not ignore empty lines or does not support comments --- Key: GSHELL-88 URL: https://issues.apache.org/jira/browse/GSHELL-88 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Builtins Reporter: Jarek Gawor Assignee: Jason Dillon Attachments: GSHELL-88.patch Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-86) command groups in help screen
[ https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-86: --- Fix Version/s: 1.0-alpha-1 Assignee: (was: Jason Dillon) command groups in help screen - Key: GSHELL-86 URL: https://issues.apache.org/jira/browse/GSHELL-86 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Reporter: Jarek Gawor Fix For: 1.0-alpha-1 The help screen shows the following: ... /deploy list-plugins Install plugins into a geronimo server connect Connect to a Geronimo server disconnectDisconnect from a Geronimo server .. which I would interpret that I need to type /deploy/connect to execute the command. But that does not work but deploy/connect works. So I would propose updating the help screen to show the slash at the end of the group name instead of the front. e.g.: ... deploy/ list-plugins Install plugins into a geronimo server connect Connect to a Geronimo server disconnectDisconnect from a Geronimo server .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-86) command groups in help screen
[
https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548070
]
Jason Dillon commented on GSHELL-86:
I really need to fix the handling of {{/}} and {{../}} but ya, for the initial
release since that doesn't work I'll change the help page (which is horrible
ATM, but its not so important to fix for this release).
command groups in help screen
-
Key: GSHELL-86
URL: https://issues.apache.org/jira/browse/GSHELL-86
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Reporter: Jarek Gawor
Assignee: Jason Dillon
Fix For: 1.0-alpha-1
The help screen shows the following:
...
/deploy
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
which I would interpret that I need to type /deploy/connect to execute the
command. But that does not work but deploy/connect works. So I would
propose updating the help screen to show the slash at the end of the group
name instead of the front. e.g.:
...
deploy/
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
--
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
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. Thanks, Gianny As I mentioned before, the size of the core of GShell is a little more than a megabyte, and with out the XStream bits its just under a megabyte, but again the custom XML parsing bits are not very elegant so I'd rather just keep XStream around. There are a few optimizations that can be done for Geronimo integration however. Like for example GShell includes a _diet_ version of Log4j, which excludes all the ancillary muck that comes with its arifact. Since we already include the full log4j.jar we can omit the diet version thin things down. Also, as I mentioned before I've not yet peeped at what is already included in the repository and what is duplicated in the lib/gshell directory, though I did try to re-sure bits from lib/* And lets also keep in mind that the next version of GShell will behave a lot like Maven2 wrt dependency resolution for commands, which means that we can configure commands and then GShell will re- use bits from the repo or download them as needed from central. --jason
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
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. As I mentioned before, the size of the core of GShell is a little more than a megabyte, and with out the XStream bits its just under a megabyte, but again the custom XML parsing bits are not very elegant so I'd rather just keep XStream around. There are a few optimizations that can be done for Geronimo integration however. Like for example GShell includes a _diet_ version of Log4j, which excludes all the ancillary muck that comes with its arifact. Since we already include the full log4j.jar we can omit the diet version thin things down. Also, as I mentioned before I've not yet peeped at what is already included in the repository and what is duplicated in the lib/gshell directory, though I did try to re- sure bits from lib/* And lets also keep in mind that the next version of GShell will behave a lot like Maven2 wrt dependency resolution for commands, which means that we can configure commands and then GShell will re-use bits from the repo or download them as needed from central. --jason
[jira] Updated: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[ https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-88: --- Fix Version/s: 1.0-alpha-1 Source command does not ignore empty lines or does not support comments --- Key: GSHELL-88 URL: https://issues.apache.org/jira/browse/GSHELL-88 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Builtins Reporter: Jarek Gawor Assignee: Jason Dillon Fix For: 1.0-alpha-1 Attachments: GSHELL-88.patch Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-80) Upgrade maven-remote-resources-plugin to 1.0-beta-1
[ https://issues.apache.org/jira/browse/GSHELL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-80: --- Summary: Upgrade maven-remote-resources-plugin to 1.0-beta-1 (was: Upgrade maven-remote-resources-plugin to 1.0-alpha-7) Upgrade maven-remote-resources-plugin to 1.0-beta-1 --- Key: GSHELL-80 URL: https://issues.apache.org/jira/browse/GSHELL-80 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 is required to allow the javacc-maven-plugin to build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-88) Source command does not ignore empty lines or does not support comments
[ https://issues.apache.org/jira/browse/GSHELL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-88. -- Resolution: Fixed Source command does not ignore empty lines or does not support comments --- Key: GSHELL-88 URL: https://issues.apache.org/jira/browse/GSHELL-88 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Builtins Reporter: Jarek Gawor Assignee: Jason Dillon Fix For: 1.0-alpha-1 Attachments: GSHELL-88.patch Source command does not ignore empty lines or does not support comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-80) Upgrade maven-remote-resources-plugin to 1.0-beta-1
[ https://issues.apache.org/jira/browse/GSHELL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-80. -- Resolution: Fixed Upgrade maven-remote-resources-plugin to 1.0-beta-1 --- Key: GSHELL-80 URL: https://issues.apache.org/jira/browse/GSHELL-80 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 is required to allow the javacc-maven-plugin to build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3667) JNDI is not available in servlet.destroy() or ServletContextListener.contextDestroyed() callbacks
[ https://issues.apache.org/jira/browse/GERONIMO-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3667. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Committed fixes to trunk (revision 600788) and branches/2.0 (revision 600789). JNDI is not available in servlet.destroy() or ServletContextListener.contextDestroyed() callbacks - Key: GERONIMO-3667 URL: https://issues.apache.org/jira/browse/GERONIMO-3667 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.1: Failed for Revision: 600769
OpenEJB trunk at 600757 Geronimo Revision: 600769 built with tests included See the full build-2100.log file at http://people.apache.org/~prasad/binaries/trunk/20071203/build-2100.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071203 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 37 minutes 55 seconds [INFO] Finished at: Mon Dec 03 21:51:26 EST 2007 [INFO] Final Memory: 275M/1010M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071203/logs-2100-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071203/logs-2100-jetty/test.log [INFO] Running web-testsuite.forward [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.604 sec FAILURE!
Re: svn commit: r600692 - in /geronimo/sandbox/monitoring: client/client-war/src/main/java/org/apache/geronimo/plugins/monitoring/client/ client/client-war/src/main/java/org/apache/geronimo/plugins/mo
Hi Gianny, I'm glad you have been following the monitoring plugin progress. Testing was actually my next step. Thanks, Viet On Dec 3, 2007 7:14 PM, Gianny Damour [EMAIL PROTECTED] wrote: Hi, I quickly had a look to the monitoring components. I think it is going well. Though, I have one comment: is it possible to increase unit testing? Thanks, Gianny On 04/12/2007, at 8:16 AM, [EMAIL PROTECTED] wrote: Author: ecraig Date: Mon Dec 3 13:16:49 2007 New Revision: 600692 URL: http://svn.apache.org/viewvc?rev=600692view=rev Log: GERONIMO-3666 monitoring plugin to provide for a way to access archive data Patch by Viet Nguyen.
Re: Apache Geronimo Context
Not clear what you want to know. Can you be more specific? ++Vamsi On Dec 3, 2007 11:11 PM, nezha [EMAIL PROTECTED] wrote: Hi, I want to kown how Apache Geronimo communicate with the other Applications and Servers, what does it use for this communication? I mean the different media, protocols and Data format, that Geronimo uses for the exanchange of information with its extern environment. Thank you -- View this message in context: http://www.nabble.com/Apache-Geronimo-Context-tf4938237s134.html#a14134941 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Migrate Project Yoko from Incubator to Geronimo / CXF
Thanks Matt. It seems that no one objects. Is the next step to have the recipient PMCs vote on receiving the code and developers? Regards, Alan On Nov 30, 2007, at 9:54 AM, Matt Hogstrom wrote: 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.
