Re: [PROPOSAL] Migrate Project Yoko from Incubator to Geronimo / CXF
Opps. Mail threading is borked. There seems to be some discussion going on still. Regards, Alan On Dec 3, 2007, at 11:20 PM, Alan D. Cabrera wrote: 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.
[BUILD] 2.1: Failed for Revision: 600828
OpenEJB trunk at 600810 Geronimo Revision: 600828 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/trunk/20071204/build-0300.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071204 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 30 minutes 39 seconds [INFO] Finished at: Tue Dec 04 03:40:01 EST 2007 [INFO] Final Memory: 288M/998M [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/20071204/logs-0300-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071204/logs-0300-jetty/test.log [INFO] Running web-testsuite.forward [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.611 sec FAILURE!
[jira] Created: (GERONIMO-3669) Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted
Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted - Key: GERONIMO-3669 URL: https://issues.apache.org/jira/browse/GERONIMO-3669 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Add a couple of gshell commands to simplify the remote control of servers. The commands being added are: * alias: used to alias a commond along with some options and arguments. etc/layout.xml provides a first aliasing mechanism: a hierarchical name is mapped to a command. alias suplements this first aliasing mechanism with the ability to alias a command along with its typical options and arguments. * unalias: to remove an alias * execute-alias: to execute an alias * remote/rsh to start an rsh client * remote/rsh-server to start an rsh-server * remote-control/server-control to control a server Samples for the aliasing commands: // create the alias 'st' for the quoted command alias st 'geronimo/start-server -G server.name=yellow -D property=value' // execute the alias 'st'. This executes the command in quote above excute-alias st // display defined aliases alias // remove the alias 'st' unalias st Samples for the remote server control commands: // start an rsh-server: remote/rsh-server tcp://localhost: // remote 'start' the server 'defaultServer' remote-control/server-control start defaultServer // remote 'stop' the server 'defaultServer' remote-control/server-control stop defaultServer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3669) Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted
[ https://issues.apache.org/jira/browse/GERONIMO-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3669. --- Resolution: Fixed This is now implemented. Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted - Key: GERONIMO-3669 URL: https://issues.apache.org/jira/browse/GERONIMO-3669 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Add a couple of gshell commands to simplify the remote control of servers. The commands being added are: * alias: used to alias a commond along with some options and arguments. etc/layout.xml provides a first aliasing mechanism: a hierarchical name is mapped to a command. alias suplements this first aliasing mechanism with the ability to alias a command along with its typical options and arguments. * unalias: to remove an alias * execute-alias: to execute an alias * remote/rsh to start an rsh client * remote/rsh-server to start an rsh-server * remote-control/server-control to control a server Samples for the aliasing commands: // create the alias 'st' for the quoted command alias st 'geronimo/start-server -G server.name=yellow -D property=value' // execute the alias 'st'. This executes the command in quote above excute-alias st // display defined aliases alias // remove the alias 'st' unalias st Samples for the remote server control commands: // start an rsh-server: remote/rsh-server tcp://localhost: // remote 'start' the server 'defaultServer' remote-control/server-control start defaultServer // remote 'stop' the server 'defaultServer' remote-control/server-control stop defaultServer -- 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.
My apologies if this is a duplicate. I was surprised that there had been no reaction at all to this proposal, and discovered that no copy of this was in the dev list archives. So, let's try this again. Rick 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
Remote control of Geronimo instances - feature preview is in
Hi, As described a couple of days ago, I have just added a couple of commands to simplify the remote control of servers. This is an excerpt of the commit message: Add a couple of gshell commands to simplify the remote control of servers. The commands being added are: * alias: used to alias a commond along with some options and arguments. etc/layout.xml provides a first aliasing mechanism: a hierarchical name is mapped to a command. alias suplements this first aliasing mechanism with the ability to alias a command along with its typical options and arguments. * unalias: to remove an alias * execute-alias: to execute an alias * remote/rsh to start an rsh client * remote/rsh-server to start an rsh-server * remote-control/server-control to control a server Samples for the aliasing commands: // create the alias 'st' for the quoted command alias st 'geronimo/start-server -G server.name=yellow -D property=value' // execute the alias 'st'. This executes the command in quote above excute-alias st // display defined aliases alias // remove the alias 'st' unalias st Samples for the remote server control commands: // start an rsh-server: remote/rsh-server tcp://localhost: // remote 'start' the server 'defaultServer' remote-control/server-control start defaultServer // remote 'stop' the server 'defaultServer' remote-control/server-control stop defaultServer I think this is sufficient at the moment to simplify the life of people who are managing many Geronimo instances. I will now work on the clustering of Tomcat web-applications over WADI. If people want to work on OpenEJB clustering over WADI, then please feel free to ping me as this is the next stuff I would like to work on after the Tomcat integration. Thanks, Gianny
Re: Releasing the parent spec pom.
On Dec 3, 2007 4:11 PM, Rick McGuire [EMAIL PROTECTED] wrote: 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 suppose so. My bad. 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. I guess this is the reason why I used 1.2-SNAPSHOT, because I missed the fact that the 1.2 has already been released. 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? I think the way it has been done is to remove the list of modules from the parent pom and release it as 1.3. Then we can release each spec one at a time by pointing to the released 1.3pom instead of the snapshot. Another way would be to OSGify *all* the specs and release them at one. If people agree, I can spare some time to osgify the remaining ones (corba_3.0, el_1.0, j2ee_deployment_1.1, jsp_2.1). Anyway, I guess this may be useful at some point, so I will put them back in trunk and osgify them now. Rick -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
On Dec 3, 2007, at 1:45 PM, Rick McGuire wrote: Below is a proposal that Matt Hogstrom, one of the mentors of the Yoko project, has put forward for moving on with the Yoko project. In a nutshell, the Yoko community has basically decided there is not a lot of continuing interesting in moving this project forward. This decision does have a major impact on Geronimo, as Geronimo uses the Yoko ORB was a key element to allow Geronimo 1.2 to support both the 1.4 and 1.5 JVMs, and also was a necessary element for achieving j2ee5 certification. The Yoko ORB gives Geronimo cross JVM portability which was not available before. At the current time, there's probably no suitable replacement that has all of the advantages that the Yoko ORB provides. In a nutshell, Matt's proposal is for the core ORB elements of the Yoko project become a subproject of the Geronimo project. These are the pieces of Yoko that Geronimo has a dependency upon. These are essentially the org.omg.* clases, the javax.rmi.* classes, plus the implementation classes backing those spec interfaces. Along with the subproject, there are 6 committers who have expressed interest in continuing to work on the core ORB code. 3 of the interested commiters are already Geronimo committers. Matt's proposal would grant the remaining 3 Geronimo committer status as well. There's one important caveat in assuming owership of this package. The core ORB is also used by the Harmony project to add CORBA and RMI support to the Harmony JVM. Included with assuming ownership of the package would be a commitment to keep the core ORB a standalone component. This means not adding direct dependencies on Geronimo and keeping dependencies on other packages to a minimum. This code is fairly stable now, and has already passed certification on multiple JVM instances, so I don't expect there will be a lot of overhead in supporting this. The bulk of the recent work to get this to pass certification have been done by Geronimo committers, so Geronimo is probably the most appropriate new home for this code. Anyway, this needs to have some discussion and be put to a vote. Below is the proposal that Matt posted to the Yoko dev mailing list about this move. The Yoko community seems very much in agreement that project does not have sufficient momentum to graduate from the incubator. Thanks for the summary, Rick. I'm certainly interested in seeing support for Yoko move forward. This seems like a positive move. It would have my support. After a brief review of the Yoko dev list archives and based on Matt's, and Alan's recommendations, I would support adding Lars, Alexey, and Darren to as Geronimo committers. Keeping Yoko as a standalone component is an easy decision, IMO. Hard to see it any other way... --kevan
Re: How to get memory statistics from a remote Geronimo runtime?
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
[jira] Commented: (GERONIMO-3645) Monitoring plugins build fails
[ https://issues.apache.org/jira/browse/GERONIMO-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548260 ] Anita Kulshreshtha commented on GERONIMO-3645: -- You could try removing all unnecessary dependencies from all the poms and use 'provided' scope for the ones available from the server. Monitoring plugins build fails -- Key: GERONIMO-3645 URL: https://issues.apache.org/jira/browse/GERONIMO-3645 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig Monitoring plugins build fails when there is a clean (empty) local maven repository due to lack of the artifacts org.apache.geronimo.modules:modules and org.apache.geronimo.configs:configs Need to sift through poms and clean up to prevent this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Deploying to multiple instances of G
Currently when an app is deployed to an instance of G (say A), it show up as 'stopped' in other instances. IIRC the relevant config.xml had load=false for this config. If the app is deleted from A and all the servers are shutdown. The other servers can not be started (NoSuchConfigException) because the config (app) has been removed from the repository. What should be the correct behavior? Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Geronimo not ready for Application Server ADF Runtime libraries
I have a simple ADF project that call a jsp with: Configuration.createRootApplicationModule After deploy in WAR format, at Geronimo it says: #Star log HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: oracle.jbo.common.ampool.ApplicationPoolException: JBO-30003: O pool de aplicações (soparatestar.AppModuleLocal) não conseguiu registar a saída do módulo da aplicação devido à seguinte excepção: org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause oracle.jbo.common.ampool.ApplicationPoolException: JBO-30003: O pool de aplicações (soparatestar.AppModuleLocal) não conseguiu registar a saída do módulo da aplicação devido à seguinte excepção: oracle.jbo.common.ampool.ApplicationPoolImpl.doCheckout(ApplicationPoolImpl.java:2002) oracle.jbo.common.ampool.ApplicationPoolImpl.useApplicationModule(ApplicationPoolImpl.java:2793) oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:453) oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:424) oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:419) oracle.jbo.client.Configuration.getApplicationModule(Configuration.java:1546) oracle.jbo.client.Configuration.createRootApplicationModule(Configuration.java:1504) oracle.jbo.client.Configuration.createRootApplicationModule(Configuration.java:1476) org.apache.jsp.index2_jsp._jspService(index2_jsp.java:66) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) note The full stack trace of the root cause is available in the Apache Tomcat/6.0-snapshot logs. ##End log In Tomcat with works. I've looked at Oracle help and put all then ADF jars in Geronimo repository and defined the dependencies, but still doesn't work. Is Geronimo not ready for ADF? -- View this message in context: http://www.nabble.com/Geronimo-not-ready-for-Application-Server-ADF-Runtime-libraries-tf4943468s134.html#a14151744 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Build broken?
I am not able to build the latest trunk...any ideas?
[INFO]
[INFO] Building Geronimo Configs :: System Database
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/Users/jeffgenender/Projects/geronimo/plugins/system-database/system-database/target/resources/META-INF/plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
/Users/jeffgenender/Projects/geronimo/plugins/system-database/system-database/target/resources/META-INF/plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] load of
org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed
Re: Build broken?
Build seems to be happy here:
http://people.apache.org/~prasad/binaries/trunk/20071204/build-0300.log
Thanks
Anita
--- Jeff Genender [EMAIL PROTECTED] wrote:
I am not able to build the latest trunk...any ideas?
[INFO]
[INFO] Building Geronimo Configs :: System Database
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/Users/jeffgenender/Projects/geronimo/plugins/system-database/system-database/target/resources/META-INF/plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
/Users/jeffgenender/Projects/geronimo/plugins/system-database/system-database/target/resources/META-INF/plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] load of
org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Re: How to get memory statistics from a remote Geronimo runtime?
I don't know if it is necessary to add the statistics from Runtime. Here is
the relationship I see between the stats from Runtime and those got from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() - MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() == MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Re: Deploying to multiple instances of G
On Dec 4, 2007 7:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Currently when an app is deployed to an instance of G (say A), it show up as 'stopped' in other instances. IIRC the relevant config.xml had load=false for this config. There shouldn't be any entry for this app in config.xml in the other instances of the server. Atleast it does not get added at deployment time. Even if it gets added with load=false, it does not result in a server startup failure whether or not the app is uninstalled from the server instance it is originally installed. If the app is deleted from A and all the servers are shutdown. The other servers can not be started (NoSuchConfigException) because the config (app) has been removed from the repository. What should be the correct behavior? If the app is installed from instance A and uninstalled from instance B then instance A is in trouble. I raised this concern a while ago and David Jencks said it is expected. As long as the app is installed and uninstalled from the same server instance, it should not (and does not currently) affect other instances. Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: How to get memory statistics from a remote Geronimo runtime?
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory. In
other words you need to add contribution from non heap Memory to all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from Runtime.
Here is
the relationship I see between the stats from Runtime and those got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() == MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Re: Deploying to multiple instances of G
yes, I uninstalled it from the wrong server despite being aware of the behavior... Another version of the same problem is that the same app can not be deployed in another instance. am I correct? Thanks Anita --- Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On Dec 4, 2007 7:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Currently when an app is deployed to an instance of G (say A), it show up as 'stopped' in other instances. IIRC the relevant config.xml had load=false for this config. There shouldn't be any entry for this app in config.xml in the other instances of the server. Atleast it does not get added at deployment time. Even if it gets added with load=false, it does not result in a server startup failure whether or not the app is uninstalled from the server instance it is originally installed. If the app is deleted from A and all the servers are shutdown. The other servers can not be started (NoSuchConfigException) because the config (app) has been removed from the repository. What should be the correct behavior? If the app is installed from instance A and uninstalled from instance B then instance A is in trouble. I raised this concern a while ago and David Jencks said it is expected. As long as the app is installed and uninstalled from the same server instance, it should not (and does not currently) affect other instances. Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: How to get memory statistics from a remote Geronimo runtime?
I don't know why the non heap memory is missing in the equations. The
equations I gave are based what I observed by running the following code.
MemoryMXBean memmxbean = ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory. In
other words you need to add contribution from non heap Memory to all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from Runtime.
Here is
the relationship I see between the stats from Runtime and those got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() == MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Re: Releasing the parent spec pom.
Well, i did not notice we were not on the dev list... Anoher option is to not release everything in a single shot (i.e. have separate tags, etc...) but still have a single vote. On Dec 4, 2007 4:46 PM, Rick McGuire [EMAIL PROTECTED] wrote: Except of course, we decided some time ago not to release all of the specs as a single release that way. Definitely something that needs to be discussed on the dev list. Rick Guillaume Nodet wrote: I've added the missing specs (but the corba one) in trunk. I'm thinking we could create a branch, change all spec numbers to their released version, create tags for the parent and all children and vote on the whole thing. I suppose the prerequisite would be that Geronimo does not break ;-) So i'm trying to build it using these snapshtos jars. On Dec 4, 2007 12:08 PM, Rick McGuire [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Guillaume Nodet wrote: On Dec 3, 2007 4:11 PM, Rick McGuire [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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 suppose so. My bad. 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. I guess this is the reason why I used 1.2-SNAPSHOT, because I missed the fact that the 1.2 has already been released. 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? I think the way it has been done is to remove the list of modules from the parent pom and release it as 1.3. Then we can release each spec one at a time by pointing to the released 1.3 pom instead of the snapshot. Another way would be to OSGify *all* the specs and release them at one. If people agree, I can spare some time to osgify the remaining ones (corba_3.0, el_1.0, j2ee_deployment_1.1, jsp_2.1). Anyway, I guess this may be useful at some point, so I will put them back in trunk and osgify them now. I wouldn't bother with the corba_3.0 one. That's been supplanted by the spec jar from yoko. Rick Rick -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Deploying to multiple instances of G
Yes, the application can not be installed from other instances as all the instances are sharing the same repository. But, nothing prevents you from starting the app in the other instances. Only thing is that before you to uninstall the application from one instance, it has to be stopped in the other instances or else those instances will end up with startup failure. I have not experimented with each instance using its own repository for applications and using common repository for core components. In this case, one may have to use command line deployer and use the target option to specify the repo to which app is to be deployed. ++Vamsi On Dec 4, 2007 9:29 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: yes, I uninstalled it from the wrong server despite being aware of the behavior... Another version of the same problem is that the same app can not be deployed in another instance. am I correct? Thanks Anita --- Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On Dec 4, 2007 7:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Currently when an app is deployed to an instance of G (say A), it show up as 'stopped' in other instances. IIRC the relevant config.xml had load=false for this config. There shouldn't be any entry for this app in config.xml in the other instances of the server. Atleast it does not get added at deployment time. Even if it gets added with load=false, it does not result in a server startup failure whether or not the app is uninstalled from the server instance it is originally installed. If the app is deleted from A and all the servers are shutdown. The other servers can not be started (NoSuchConfigException) because the config (app) has been removed from the repository. What should be the correct behavior? If the app is installed from instance A and uninstalled from instance B then instance A is in trouble. I raised this concern a while ago and David Jencks said it is expected. As long as the app is installed and uninstalled from the same server instance, it should not (and does not currently) affect other instances. Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Build broken?
Here is the error...don't know whats up: issing dependency: org.apache.geronimo.configs/transaction//car [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: load of org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: load of org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed at org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:300) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:281) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:256) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$9b238d66.loadConfiguration(generated) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:489) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute(PackageMojo.java:309) at org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:122) ... 18 more Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.configs/transaction//car at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:111) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:104) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at
[BUILD] 2.1: Failed for Revision: 600958
OpenEJB trunk at 600925 Geronimo Revision: 600958 built with tests included See the full build-0900.log file at http://people.apache.org/~prasad/binaries/trunk/20071204/build-0900.log Download the binaries from http://people.apache.org/~prasad/binaries/trunk/20071204 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 39 minutes [INFO] Finished at: Tue Dec 04 09:47:31 EST 2007 [INFO] Final Memory: 285M/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/20071204/logs-0900-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/trunk/20071204/logs-0900-jetty/test.log [INFO] Running web-testsuite.forward [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.569 sec FAILURE!
Re: Geronimo not ready for Application Server ADF Runtime libraries
One of your posts on the user list had enough stack trace to lead me to believe you have run into https://issues.apache.org/jira/browse/ GERONIMO-3243 and as noted there this is a bug in both Activemq and ADF. We should do something to fix this problem in 2.1, either upgrade to a newer amq if available without this problem or include the equivalent of -Dorg.apache.activeio.journal.active.DisableLocking=true in an appropriate SystemPropertieds gbean. Is anyone interested in looking into this further? thanks david jencks On Dec 4, 2007, at 6:33 AM, JAR wrote: I have a simple ADF project that call a jsp with: Configuration.createRootApplicationModule After deploy in WAR format, at Geronimo it says: #Star log HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: oracle.jbo.common.ampool.ApplicationPoolException: JBO-30003: O pool de aplicações (soparatestar.AppModuleLocal) não conseguiu registar a saída do módulo da aplicação devido à seguinte excepção: org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:432) org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:320) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause oracle.jbo.common.ampool.ApplicationPoolException: JBO-30003: O pool de aplicações (soparatestar.AppModuleLocal) não conseguiu registar a saída do módulo da aplicação devido à seguinte excepção: oracle.jbo.common.ampool.ApplicationPoolImpl.doCheckout (ApplicationPoolImpl.java:2002) oracle.jbo.common.ampool.ApplicationPoolImpl.useApplicationModule (ApplicationPoolImpl.java:2793) oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule (SessionCookieImpl.java:453) oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule (SessionCookieImpl.java:424) oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule (SessionCookieImpl.java:419) oracle.jbo.client.Configuration.getApplicationModule (Configuration.java:1546) oracle.jbo.client.Configuration.createRootApplicationModule (Configuration.java:1504) oracle.jbo.client.Configuration.createRootApplicationModule (Configuration.java:1476) org.apache.jsp.index2_jsp._jspService(index2_jsp.java:66) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:388) org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:320) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) note The full stack trace of the root cause is available in the Apache Tomcat/6.0-snapshot logs. ##End log In Tomcat with works. I've looked at Oracle help and put all then ADF jars in Geronimo repository and defined the dependencies, but still doesn't work. Is Geronimo not ready for ADF? -- View this message in context: http://www.nabble.com/Geronimo-not- ready-for-Application-Server-ADF-Runtime-libraries- tf4943468s134.html#a14151744 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: How to get memory statistics from a remote Geronimo runtime?
It is not clear to me if this is part of the earlier code or a
separate program. If it is part of the JMX code, then Runtime is from
the local jvm not remote. The non heap Memory for this program in
either case is negligible.
You could start G with -Dcom.sun.management.jmxremote. Start
jconsole and click on the Memory tab to get the whole picture.
Hope this is helpful
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know why the non heap memory is missing in the equations.
The
equations I gave are based what I observed by running the following
code.
MemoryMXBean memmxbean =
ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory.
In
other words you need to add contribution from non heap Memory to
all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from
Runtime.
Here is
the relationship I see between the stats from Runtime and those
got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() ==
MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct
way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : +
port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[jira] Created: (GERONIMO-3670) java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException with jaxws-tools wsimport
java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException with jaxws-tools wsimport - Key: GERONIMO-3670 URL: https://issues.apache.org/jira/browse/GERONIMO-3670 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.0.x, 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-3670) java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException with jaxws-tools wsimport
[ https://issues.apache.org/jira/browse/GERONIMO-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548332 ] Jarek Gawor commented on GERONIMO-3670: --- The exception: Exception in thread main java.lang.NoClassDefFoundError: javax/xml/stream/XMLS treamException at com.sun.xml.bind.v2.runtime.JAXBContextImpl.createUnmarshaller(JAXBCo ntextImpl.java:690) at com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryIm pl$1.init(AnnotationParserFactoryImpl.java:103) at com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryIm pl.create(AnnotationParserFactoryImpl.java:102) at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.createAnnotationParser(NGC CRuntimeEx.java:320) at com.sun.xml.xsom.impl.parser.state.annotation.action0(annotation.java :48) at com.sun.xml.xsom.impl.parser.state.annotation.enterElement(annotation .java:68) at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCR untime.java:378) at com.sun.xml.xsom.impl.parser.state.NGCCHandler.spawnChildFromEnterEle ment(NGCCHandler.java:74) at com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:21 3) at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCR untime.java:378) at com.sun.xml.xsom.impl.parser.state.NGCCHandler.revertToParentFromEnte rElement(NGCCHandler.java:111) at com.sun.xml.xsom.impl.parser.state.foreignAttributes.enterElement(for eignAttributes.java:50) at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCR untime.java:378) at com.sun.xml.xsom.impl.parser.state.NGCCHandler.spawnChildFromEnterEle ment(NGCCHandler.java:74) at com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:43 6) at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCR untime.java:378) at com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:20 5) at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCR untime.java:378) at com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:18 java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException with jaxws-tools wsimport - Key: GERONIMO-3670 URL: https://issues.apache.org/jira/browse/GERONIMO-3670 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.x, 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] Resolved: (GERONIMO-3670) java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException with jaxws-tools wsimport
[ https://issues.apache.org/jira/browse/GERONIMO-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3670. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Committed fixes to trunk (revision 601022) and branches/2.0 (revision 601024). java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException with jaxws-tools wsimport - Key: GERONIMO-3670 URL: https://issues.apache.org/jira/browse/GERONIMO-3670 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.x, 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.
[jira] Created: (GERONIMO-3671) JNDI is not available in filter.init() and filter.destroy() on Jetty
JNDI is not available in filter.init() and filter.destroy() on Jetty Key: GERONIMO-3671 URL: https://issues.apache.org/jira/browse/GERONIMO-3671 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty 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-3671) JNDI is not available in filter.init() and filter.destroy() on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548368 ] Jarek Gawor commented on GERONIMO-3671: --- Committed a fix to trunk (revision 601045). Also, updated test-web-forward tests to test for jndi availability in more places (revision 601047). JNDI is not available in filter.init() and filter.destroy() on Jetty Key: GERONIMO-3671 URL: https://issues.apache.org/jira/browse/GERONIMO-3671 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty 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.
Re: svn commit: r601048 [1/5] - in /geronimo/specs/trunk: ./ geronimo-jsp_2.1_spec/src/main/resources/javax/servlet/jsp/resources/ geronimo-saaj_1.1_spec/ geronimo-saaj_1.3_spec/ geronimo-saaj_1.3_spe
I agree with Guilllaume. I'd prefer a single place to look for spec jars. There is already a 1.1 version of saaj in geronimo-specs, why shouldn't there be a 1.3 version? Dan On Tuesday 04 December 2007, you wrote: Actually, this *is* the axis2 saaj 1.3 spec. I've done that for two reasons: * the spec jar becomes an osgi bundle (along with all the other specs) * it provides a single location for all specs I guess this is the same problem as the stax api which is available in public repo with an ASL license. If these reasons do not seem sufficient, I can easily remove it though. On Dec 4, 2007 8:33 PM, Jarek Gawor [EMAIL PROTECTED] wrote: In Geronimo we use Axis2 SAAJ 1.3 API... I would rather not introduce yet another version of this spec API. Why is this necessary? Jarek On Dec 4, 2007 2:25 PM, [EMAIL PROTECTED] wrote: Author: gnodet Date: Tue Dec 4 11:25:44 2007 New Revision: 601048 URL: http://svn.apache.org/viewvc?rev=601048view=rev Log: Add missing jsp resources, upgrade saaj to 1.3 spec Added: -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: svn commit: r601048 [1/5] - in /geronimo/specs/trunk: ./ geronimo-jsp_2.1_spec/src/main/resources/javax/servlet/jsp/resources/ geronimo-saaj_1.1_spec/ geronimo-saaj_1.3_spec/ geronimo-saaj_1.3_spe
On Dec 4, 2007 2:38 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: Actually, this *is* the axis2 saaj 1.3 spec. I've done that for two reasons: * the spec jar becomes an osgi bundle (along with all the other specs) Ok but we can work with the Axis2 community to get this done. * it provides a single location for all specs We pull two specs from Axis2 so we would have to replicate them both. But in general, I don't think we need to replicate the specs although I do understand the reason to keep things in one place. I did mention this idea on the Axis2 list (to move the spec api to Geronimo) a while ago but nothing much came out if it (and I didn't really push it). Maybe something to consider again. I guess this is the same problem as the stax api which is available in public repo with an ASL license. Right, but if I remember correctly we actaully had a good reason for that. I think the published version had some tck issues. Jarek
[jira] Commented: (GERONIMO-3668) monitoring client should encrypt all passwords
[ https://issues.apache.org/jira/browse/GERONIMO-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548384 ] Erik B. Craig commented on GERONIMO-3668: - Committed revision 601062. Thanks Viet 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: svn commit: r601048 [1/5] - in /geronimo/specs/trunk: ./ geronimo-jsp_2.1_spec/src/main/resources/javax/servlet/jsp/resources/ geronimo-saaj_1.1_spec/ geronimo-saaj_1.3_spec/ geronimo-saaj_1.3_spe
On Dec 4, 2007 8:57 PM, Jarek Gawor [EMAIL PROTECTED] wrote: On Dec 4, 2007 2:38 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: Actually, this *is* the axis2 saaj 1.3 spec. I've done that for two reasons: * the spec jar becomes an osgi bundle (along with all the other specs) Ok but we can work with the Axis2 community to get this done. * it provides a single location for all specs We pull two specs from Axis2 so we would have to replicate them both. But in general, I don't think we need to replicate the specs although I do understand the reason to keep things in one place. I did mention this idea on the Axis2 list (to move the spec api to Geronimo) a while ago but nothing much came out if it (and I didn't really push it). Maybe something to consider again. What's the other one ? I guess this is the same problem as the stax api which is available in public repo with an ASL license. Right, but if I remember correctly we actaully had a good reason for that. I think the published version had some tck issues. Jarek -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: svn commit: r601048 [1/5] - in /geronimo/specs/trunk: ./ geronimo-jsp_2.1_spec/src/main/resources/javax/servlet/jsp/resources/ geronimo-saaj_1.1_spec/ geronimo-saaj_1.3_spec/ geronimo-saaj_1.3_spe
On Dec 4, 2007 3:00 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: We pull two specs from Axis2 so we would have to replicate them both. But in general, I don't think we need to replicate the specs although I do understand the reason to keep things in one place. I did mention this idea on the Axis2 list (to move the spec api to Geronimo) a while ago but nothing much came out if it (and I didn't really push it). Maybe something to consider again. What's the other one ? axis2-jaxws-api Jarek
Re: svn commit: r601048 [1/5] - in /geronimo/specs/trunk: ./ geronimo-jsp_2.1_spec/src/main/resources/javax/servlet/jsp/resources/ geronimo-saaj_1.1_spec/ geronimo-saaj_1.3_spec/ geronimo-saaj_1.3_spe
Interesting. I did not even know there was one at the ASF. I was using the sun one which is binary compatible with ASL. On Dec 4, 2007 9:03 PM, Jarek Gawor [EMAIL PROTECTED] wrote: On Dec 4, 2007 3:00 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: We pull two specs from Axis2 so we would have to replicate them both. But in general, I don't think we need to replicate the specs although I do understand the reason to keep things in one place. I did mention this idea on the Axis2 list (to move the spec api to Geronimo) a while ago but nothing much came out if it (and I didn't really push it). Maybe something to consider again. What's the other one ? axis2-jaxws-api Jarek -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Resolved: (GERONIMO-3671) JNDI is not available in filter.init() and filter.destroy() on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3671. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Ported the fix to branches/2.0 (revision 601068). JNDI is not available in filter.init() and filter.destroy() on Jetty Key: GERONIMO-3671 URL: https://issues.apache.org/jira/browse/GERONIMO-3671 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty 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.
[jira] Updated: (GERONIMO-3243) ActiveMQ violates System Properties
[
https://issues.apache.org/jira/browse/GERONIMO-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller updated GERONIMO-3243:
---
Priority: Blocker (was: Major)
Affects Version/s: (was: 2.0-M3)
(was: 1.2)
(was: 2.0-M4)
2.0.1
2.0.2
Fix Version/s: 2.1
ActiveMQ violates System Properties
---
Key: GERONIMO-3243
URL: https://issues.apache.org/jira/browse/GERONIMO-3243
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.0.1, 2.0.2
Reporter: solprovider
Priority: Blocker
Fix For: 2.1
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to
error.
{code:title=Test Code|borderStyle=solid}
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
{code}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on
Windows, add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Geronimo not ready for Application Server ADF Runtime libraries
On Dec 4, 2007, at 12:28 PM, David Jencks wrote: One of your posts on the user list had enough stack trace to lead me to believe you have run into https://issues.apache.org/jira/browse/GERONIMO-3243 and as noted there this is a bug in both Activemq and ADF. We should do something to fix this problem in 2.1, either upgrade to a newer amq if available without this problem or include the equivalent of -Dorg.apache.activeio.journal.active.DisableLocking=true in an appropriate SystemPropertieds gbean. Is anyone interested in looking into this further? As noted in the jira, current users should set GERONIMO opts (e.g. 'export GERONIMO_OPTS=- Dorg.apache.activeio.journal.active.DisableLocking=true') and then start geronimo (e.g. 'geronimo.sh run') Agreed that we should configure the property using the SystemProperties GBean. IIRC, this problem is actually caused by ActiveIO. ActiveMQ 5 doesn't include ActiveIO, but isn't released yet and I don't think we want to move to a new release, anyway... I moved the jira to 2.1 and set the priority to blocker... --kevan
[BUILD] 2.1: Failed for Revision: 601066
OpenEJB trunk at 601039 Geronimo Revision: 601066 built with tests included See the full build-1500.log file at http://people.apache.org/~prasad/binaries/trunk/20071204/build-1500.log apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Path to dependency: 1) org.apache.geronimo.modules:geronimo-commands:jar:2.1-SNAPSHOT 2) org.apache.geronimo.gshell:gshell-core:jar:1.0-alpha-1-SNAPSHOT at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information: Unable to read the metadata file for artifact 'org.codehaus.plexus:plexus-container-default:jar': Cannot find parent: org.codehaus.plexus:plexus-containers for project: null:plexus-container-default:jar:1.0-alpha-32 for project null:plexus-container-default:jar:1.0-alpha-32 org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-32 from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Path to dependency: 1) org.apache.geronimo.modules:geronimo-commands:jar:2.1-SNAPSHOT 2) org.apache.geronimo.gshell:gshell-core:jar:1.0-alpha-1-SNAPSHOT at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:362) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file for artifact 'org.codehaus.plexus:plexus-container-default:jar': Cannot find parent: org.codehaus.plexus:plexus-containers for project: null:plexus-container-default:jar:1.0-alpha-32 for project null:plexus-container-default:jar:1.0-alpha-32 at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:134) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:339) ... 23 more Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.codehaus.plexus:plexus-containers for project: null:plexus-container-default:jar:1.0-alpha-32 for project null:plexus
[jira] Created: (GERONIMO-3672) org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent
org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent --- Key: GERONIMO-3672 URL: https://issues.apache.org/jira/browse/GERONIMO-3672 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: testsuite Affects Versions: 2.0.2 Reporter: Vasily Zakharov Test org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest may fail on non-Sun implementation, because it assumes the order in which Class.getFields() returns the fields, while specification doesn't specify the particular order. The problem occurs in method PersistenceUnitAnnotationHelper.processPersistenceUnit() which gets the fields and adds them to the annotatedApp, that is later compared (in the tests themselves) with expected XML - at this point the tests may as the order of elements in the resulting XML may be different. The following assertions fail on Apache Harmony because of this fact: testPersistenceContextAnnotationHelper testPersistenceUnitAnnotationHelper testWebServiceRefAnnotationHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-89) Install thread specific System.out and System.err adapters
Install thread specific System.out and System.err adapters -- Key: GSHELL-89 URL: https://issues.apache.org/jira/browse/GSHELL-89 Project: GShell Issue Type: Task Security Level: public (Regular issues) Reporter: Jarek Gawor Assignee: Jason Dillon Some integrated tools such as wsgen and wsimport insist on outputting stuff directly to System.out and System.err. So the only way to capture their output is to install System.err/System.out adapters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-89) Install thread specific System.out and System.err adapters
[ https://issues.apache.org/jira/browse/GSHELL-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-89: --- Fix Version/s: 1.0-alpha-2 Assignee: (was: Jason Dillon) Install thread specific System.out and System.err adapters -- Key: GSHELL-89 URL: https://issues.apache.org/jira/browse/GSHELL-89 Project: GShell Issue Type: Task Security Level: public(Regular issues) Reporter: Jarek Gawor Fix For: 1.0-alpha-2 Some integrated tools such as wsgen and wsimport insist on outputting stuff directly to System.out and System.err. So the only way to capture their output is to install System.err/System.out adapters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-89) Install thread specific System.out and System.err adapters
[ https://issues.apache.org/jira/browse/GSHELL-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548441 ] Jason Dillon commented on GSHELL-89: Should probably use this: * http://svn.codehaus.org/mojo/trunk/mojo/shitty-maven-plugin/src/main/java/org/codehaus/mojo/shitty/SystemOutputHijacker.java Install thread specific System.out and System.err adapters -- Key: GSHELL-89 URL: https://issues.apache.org/jira/browse/GSHELL-89 Project: GShell Issue Type: Task Security Level: public(Regular issues) Reporter: Jarek Gawor Assignee: Jason Dillon Fix For: 1.0-alpha-2 Some integrated tools such as wsgen and wsimport insist on outputting stuff directly to System.out and System.err. So the only way to capture their output is to install System.err/System.out adapters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
PLugin installation broken?
Hi, On the latest trun, it seems plugin installation is broken. When I try to install plugins...I get this. Any ideas?: 5:20:44,138 ERROR [PluginInstallerGBean] Unable to install plugin. java.io.IOException: No such file or directory at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:850) at org.apache.geronimo.system.plugin.PluginInstallerGBean.copyFile(PluginInstallerGBean.java:1000) at org.apache.geronimo.system.plugin.PluginInstallerGBean.extractPluginFiles(PluginInstallerGBean.java:914) at org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:904) at org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:889) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:470) at org.apache.geronimo.system.plugin.PluginInstallerGBean$2.run(PluginInstallerGBean.java:533) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:613) 15:20:44,712 WARN [DefaultRemoter] Method execution failed: java.lang.Exception: Unable to install configuration at org.apache.geronimo.console.ajax.ProgressMonitor.getProgressInfo(ProgressMonitor.java:62) 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.directwebremoting.impl.ExecuteAjaxFilter.doFilter(ExecuteAjaxFilter.java:34) at org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428) at org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:431) at org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:283) at org.directwebremoting.servlet.PlainCallHandler.handle(PlainCallHandler.java:52) at org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:101) at org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:146) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.geronimo.console.servlet.ForwardDispatchFilter.doFilter(ForwardDispatchFilter.java:59) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.apache.geronimo.console.servlet.ContextForwardServlet.doPost(ContextForwardServlet.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
Application client launcher throws NoSuchMethodError: org.omg.PortableInterceptor...
Hi, Upon successful EAR deployment with an application client that uses @EJB I run it with the following command: java -jar bin/client.jar sampleear/sample-ear_SampleAppClient.jar/1.0/jar It worked fine as far as the application's concerned, but the following exception's thrown on the client's side. What's wrong? I run it on Geronimo 2.1-SNAPSHOT built a week ago on Sun JDK 1.5.0_14-b03. 23:54:46,218 ERROR [GBeanInstance] Problem in doStop of org.apache.geronimo.configs/client-corba-yoko/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client-corba-yoko/2.1-SN APSHOT/car,j2eeType=CORBABean,name=Server java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_changed(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.java:532) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.deactivate(POAManager_impl.java:360) at org.apache.yoko.orb.OBPortableServer.POAManagerFactory_impl._OB_deactivate(POAManagerFactory_impl.java:342) at org.apache.yoko.orb.OB.ORBControl.completeServerShutdown(ORBControl.java:100) at org.apache.yoko.orb.OB.ORBControl.shutdownServer(ORBControl.java:427) at org.apache.yoko.orb.OB.ORBControl.shutdownServerClient(ORBControl.java:455) at org.apache.yoko.orb.OBCORBA.ORB_impl.destroy(ORB_impl.java:1390) at org.apache.geronimo.corba.CORBABean.doStop(CORBABean.java:260) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1159) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:339) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:561) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:561) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:561) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:561) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:316) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper$1.run(MainConfigurationBootstrapper.java:76) Exception in thread Yoko:Server:StarterThread java.lang.NoClassDefFoundError: org/apache/yoko/orb/OB/GIOPConnectionThreaded$ReceiverThread at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerStarterThreaded.java:243) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPServerStarterThreaded.java:34) On the server's no exception's thrown. 23:35:28,171 INFO [config] Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) 23:35:28,171 INFO [config] Configuring Service(id=Default Stateful Container, type=Container, provider-id=Default Stateful Container) 23:35:28,171 INFO [config] Configuring Service(id=Default BMP Container, type=Container, provider-id=Default BMP Container) 23:35:28,171 INFO [config] Configuring Service(id=Default CMP Container, type=Container, provider-id=Default CMP Container) 23:35:28,171 INFO [config] Configuring app: sampleear/sample-ear/1.0/ear 23:35:28,375 INFO [OpenEJB] Auto-deploying ejb MyStatelessSessionBean: EjbDeployment(deployment-id=SampleEJB.jar/MyStatelessSessionBean) 23:35:28,796 INFO [config] Loaded Module: sampleear/sample-ear/1.0/ear 23:35:31,453 INFO [Enhance] You have enabled runtime enhancement, but have not specified the set of persistent classes. OpenJPA must look for metadata for every loaded class, which mi ght increase class load times significantly. 23:35:31,875 INFO [startup] Assembling app: c:\geronimo\var\temp\geronimo-deploymentUtil10007.jar 23:35:32,000 INFO [startup] Jndi(name=MyStatelessSessionBeanRemote) -- Ejb(deployment-id=SampleEJB.jar/MyStatelessSessionBean) 23:35:32,000 INFO [startup] Created Ejb(deployment-id=SampleEJB.jar/MyStatelessSessionBean,
[jira] Commented: (GERONIMO-3243) ActiveMQ violates System Properties
[
https://issues.apache.org/jira/browse/GERONIMO-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548463
]
solprovider commented on GERONIMO-3243:
---
ActiveMQ-4.1.1 is broken. The fix was committed to ActiveMQ in July.
ActiveMQ-5.0 is fixed and available as snapshots.
Geronimo-2.0.1 and 2.0.2 have been released with ActiveMQ-4.1.1; this issue was
unresolved. Does the Geronimo project believe releasing broken code is more
important than not releasing snapshots of library dependencies?
Kevan Miller removed that this issue affects Geronimo-1.2 so administrators of
the older Geronimo will be unaware the issue affects their servers. Kevan
reassigned this issue to Geronimo-2.1. (Is 2.0.3 or 2.1 the next release?)
ActiveMQ violates System Properties
---
Key: GERONIMO-3243
URL: https://issues.apache.org/jira/browse/GERONIMO-3243
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.0.1, 2.0.2
Reporter: solprovider
Priority: Blocker
Fix For: 2.1
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to
error.
{code:title=Test Code|borderStyle=solid}
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
{code}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on
Windows, add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (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 closed GERONIMO-3609. -- Resolution: Fixed The patch seems to work and ith the other new uses of LifecycleMethod I don't think the code can be simplified more so I committed it in rev 601149. 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] Commented: (GERONIMO-3607) export a server including a set of plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548467 ] David Jencks commented on GERONIMO-3607: rev 601152 implements pack up a server and uses it from car-maven-plugin and from gshell. Console not done yet. This includes a bunch of hacks such as using versions on all plugin dependencies. One way to solve this and a lot of similar problems would be to improve plugin repo handling by implementing several source plugin repo for file system repos (don't need maven metadata since they are listable) and (remote) http urls that can be expected to have maven metadata xml. export a server including a set of plugins -- Key: GERONIMO-3607 URL: https://issues.apache.org/jira/browse/GERONIMO-3607 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Provide the ablility to package a server that includes a set of plugins, accessible through the console and through gshell. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory
GShell code does not pick up and execute files in the etc/rc.d directory Key: GSHELL-90 URL: https://issues.apache.org/jira/browse/GSHELL-90 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Reporter: Jeff Genender Assignee: Jason Dillon Priority: Blocker GShell is not executing the rc.d script in the etc/rc.d directory in Geronimo. Files were named start-server,terracotta-client.groovy start-server,terracotta-config.groovy Reneamed to what I found there to match the default file: geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy And they are not being executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory
[ https://issues.apache.org/jira/browse/GSHELL-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548496 ] Jeff Genender commented on GSHELL-90: - Sounds like this may be a dupe and probably belongs over in the Geronimo space...feel free to mark it as such ;-) GShell code does not pick up and execute files in the etc/rc.d directory Key: GSHELL-90 URL: https://issues.apache.org/jira/browse/GSHELL-90 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Jeff Genender Assignee: Jason Dillon Priority: Blocker GShell is not executing the rc.d script in the etc/rc.d directory in Geronimo. Files were named start-server,terracotta-client.groovy start-server,terracotta-config.groovy Reneamed to what I found there to match the default file: geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy And they are not being executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory
[ https://issues.apache.org/jira/browse/GSHELL-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548500 ] Kevan Miller commented on GSHELL-90: I renamed the original file with the COLON and COMMA in it's name. Files with ':' character in the file name made it impossible for people to checkout our source code from svn. Jira https://issues.apache.org/jira/browse/GERONIMO-3624 contains description of the original problem. I didn't expect my change to work (other than enable svn access for windows users). Can fix the problem under 3624 or here... Don't care which... GShell code does not pick up and execute files in the etc/rc.d directory Key: GSHELL-90 URL: https://issues.apache.org/jira/browse/GSHELL-90 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Jeff Genender Assignee: Jason Dillon Priority: Blocker GShell is not executing the rc.d script in the etc/rc.d directory in Geronimo. Files were named start-server,terracotta-client.groovy start-server,terracotta-config.groovy Reneamed to what I found there to match the default file: geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy And they are not being executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r601152 [3/4] - in /geronimo/server/trunk: ./ applications/welcome/geronimo-welcome/src/main/java/org/apache/geronimo/welcome/ assemblies/geronimo-boilerplate-minimal/src/main/underlay
Is the version temporary? Could you have used geronimoVersion
property instead of 2.1-SNAPSHOT?
Thanks
Anita
--- [EMAIL PROTECTED] wrote:
Modified:
geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/ExplicitDefaultArtifactResolver.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/ExplicitDefaultArtifactResolver.java?rev=601152r1=601151r2=601152view=diff
==
---
geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/ExplicitDefaultArtifactResolver.java
(original)
+++
geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/ExplicitDefaultArtifactResolver.java
Tue Dec 4 15:49:03 2007
@@ -38,14 +38,14 @@
/**
* @version $Rev$ $Date$
*/
-public class ExplicitDefaultArtifactResolver extends
DefaultArtifactResolver implements AliasedArtifactResolver {
+public class ExplicitDefaultArtifactResolver extends
DefaultArtifactResolver implements LocalAliasedArtifactResolver {
private static final String COMMENT = #You can use this file to
indicate that you want to substitute one module for another.\n +
#format is oldartifactid=newartifactId e.g.\n +
#org.apache.geronimo.configs/transaction//car=org.apache.geronimo.configs/transaction-jta11/1.2-SNAPSHOT/car\n
+
#versions can be ommitted on the left side but not the
right.\n +
#This can also specify explicit versions in the same
format.;
-private final String versionMapLocation;
+private final String artifactAliasesFile;
private final ServerInfo serverInfo;
public ExplicitDefaultArtifactResolver(String
versionMapLocation,
@@ -53,10 +53,15 @@
Collection? extends ListableRepository repositories,
ServerInfo serverInfo ) throws IOException {
super(artifactManager, repositories,
buildExplicitResolution(versionMapLocation, serverInfo));
-this.versionMapLocation = versionMapLocation;
+this.artifactAliasesFile = versionMapLocation;
this.serverInfo = serverInfo;
}
+
+public String getArtifactAliasesFile() {
+return artifactAliasesFile;
+}
+
private static MapArtifact, Artifact
buildExplicitResolution(String versionMapLocation, ServerInfo
serverInfo) throws IOException {
if (versionMapLocation == null) {
return null;
@@ -123,7 +128,7 @@
public synchronized void addAliases(Properties properties)
throws IOException {
MapArtifact, Artifact explicitResolutions =
propertiesToArtifactMap(properties);
getExplicitResolution().putAll(explicitResolutions);
-saveExplicitResolution(getExplicitResolution(),
versionMapLocation, serverInfo);
+saveExplicitResolution(getExplicitResolution(),
artifactAliasesFile, serverInfo);
}
public static final GBeanInfo GBEAN_INFO;
Added:
geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/LocalAliasedArtifactResolver.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/LocalAliasedArtifactResolver.java?rev=601152view=auto
==
---
geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/LocalAliasedArtifactResolver.java
(added)
+++
geronimo/server/trunk/framework/modules/geronimo-system/src/main/java/org/apache/geronimo/system/resolver/LocalAliasedArtifactResolver.java
Tue Dec 4 15:49:03 2007
@@ -0,0 +1,28 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+
+package org.apache.geronimo.system.resolver;
+
+/**
+ * @version $Rev:$ $Date:$
+ */
+public interface LocalAliasedArtifactResolver extends
AliasedArtifactResolver {
+String getArtifactAliasesFile();
[jira] Commented: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory
[ https://issues.apache.org/jira/browse/GSHELL-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548520 ] Jeff Genender commented on GSHELL-90: - Maybe for another JIRA, but I think the colon and comma stuff should go and we use something a bit more generic? These names are a bit long IMHO. GShell code does not pick up and execute files in the etc/rc.d directory Key: GSHELL-90 URL: https://issues.apache.org/jira/browse/GSHELL-90 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Jeff Genender Assignee: Jason Dillon Priority: Blocker GShell is not executing the rc.d script in the etc/rc.d directory in Geronimo. Files were named start-server,terracotta-client.groovy start-server,terracotta-config.groovy Reneamed to what I found there to match the default file: geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy And they are not being executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3624) Update start-server rc.d/ handling to prevent problems with ':' on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548521 ] Jeff Genender commented on GERONIMO-3624: - How about getting rid of the commas an colon and come up with something a bit more realistic and short? Update start-server rc.d/ handling to prevent problems with ':' on Windows -- Key: GERONIMO-3624 URL: https://issues.apache.org/jira/browse/GERONIMO-3624 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Environment: Windows Reporter: Hernan Cunico Assignee: Jason Dillon Priority: Blocker Fix For: 2.1 Issue brought up by Jarek on dev@, I'm having the same problem too. Windows users cannot check out trunk from SVN because of unsupported characters (: and ,) in file names. See svn log below svn: In directory 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d' svn: Can't move source to dest svn: Can't move 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,default.groovy.svn-base' to 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base': No such file or directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.1: Failed for Revision: 601186
OpenEJB trunk at 601178
Geronimo Revision: 601186 built with tests included
See the full build-2100.log file at
http://people.apache.org/~prasad/binaries/trunk/20071204/build-2100.log
Download the binaries from
http://people.apache.org/~prasad/binaries/trunk/20071204
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 30 minutes 35 seconds
[INFO] Finished at: Tue Dec 04 21:36:30 EST 2007
[INFO] Final Memory: 293M/1013M
[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/20071204/logs-2100-tomcat/test.log
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 5 source files to
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ejb/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] No sources to compile
[INFO] [INFO] [surefire:test]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [surefire:test {execution: test}]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [ejb:ejb]
[INFO] [INFO] Building ejb corba-marshal-ejb-2.1-SNAPSHOT with ejbVersion 2.1
[INFO] [INFO] Building jar:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ejb/target/corba-marshal-ejb-2.1-SNAPSHOT.jar
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in: corba-marshal-ejb-2.1-SNAPSHOT.jar
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-ejb/target/corba-marshal-ejb-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/testsuite/corba-marshal-ejb/2.1-SNAPSHOT/corba-marshal-ejb-2.1-SNAPSHOT.jar
[INFO] [INFO] [testsuite:generate-surefire-xml {execution:
generate-surefire-xml}]
[INFO] [INFO] Updating directory:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/target/surefire-reports
[INFO] [INFO] No surefire-reports directory here
[INFO] [INFO]
[INFO] [INFO] Building Geronimo TestSuite :: CORBA TestSuite :: Marshal Client
[INFO] [INFO]task-segment: [install]
[INFO] [INFO]
[INFO] [INFO] [enforcer:enforce {execution: default}]
[INFO] [INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [INFO] Created dir:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/classes/META-INF
[INFO] [INFO] Copying 2 files to
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/classes/META-INF
[INFO] [INFO] [resources:resources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 6 source files to
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] No sources to compile
[INFO] [INFO] [surefire:test]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [surefire:test {execution: test}]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [jar:jar]
[INFO] [INFO] Building jar:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-2.1-SNAPSHOT.jar
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in: corba-marshal-client-2.1-SNAPSHOT.jar
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/corba-marshal-client/target/corba-marshal-client-2.1-SNAPSHOT.jar
to
/home/prasad/.m2/repository/org/apache/geronimo/testsuite/corba-marshal-client/2.1-SNAPSHOT/corba-marshal-client-2.1-SNAPSHOT.jar
[INFO] [INFO] [testsuite:generate-surefire-xml {execution:
generate-surefire-xml}]
[INFO] [INFO] Updating directory:
/home/prasad/geronimo/trunk/testsuite/corba-testsuite/corba-marshal/target/surefire-reports
[INFO] [INFO] No surefire-reports directory here
[INFO] [INFO]
[INFO] [INFO] Building Geronimo
[jira] Commented: (GSHELL-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548525 ] Jason Warner commented on GSHELL-46: I just type up a whole long thing for this and then lost it when I clicked add and my session had timed out, so I'll be brief. I found I can get the exception stack traces by setting the verbosity level to VERBOSE. I'm not sure if this is what you were looking for or not, even though it seems to accomplish the goal. My only issue is that the only difference between this and --verbose is --verbose also alters the log level. I also looked into setting a system property. Assuming changing the verbosity is sufficient, it would only be a matter of checking this property at set points and then changing the verbosity accordingly. I thought this check could be done on ever output, but then realized that output is done through PrintWriters that have already been defined. Is there a good place to perform this check? If you don't actually know of a place off hand, let me know and I'll do my own leg work. I just thought it'd be fun to leverage the knowledge of someone with a ton more GShell experience than myself. Finally, I like the idea of persistent options loaded from the preferences but think that probably should be covered in a separate jira as it's work effort is outside the scope of this one. If there isn't one already, I'll open one up myself. Ok, that wasn't too brief. My mistake. Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! On Dec 4, 2007 11:26 PM, Kevan Miller [EMAIL PROTECTED] wrote: All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan
[jira] Assigned: (GERONIMO-3672) org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent
[ https://issues.apache.org/jira/browse/GERONIMO-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3672: - Assignee: Jarek Gawor org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent --- Key: GERONIMO-3672 URL: https://issues.apache.org/jira/browse/GERONIMO-3672 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 2.0.2 Reporter: Vasily Zakharov Assignee: Jarek Gawor Test org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest may fail on non-Sun implementation, because it assumes the order in which Class.getFields() returns the fields, while specification doesn't specify the particular order. The problem occurs in method PersistenceUnitAnnotationHelper.processPersistenceUnit() which gets the fields and adds them to the annotatedApp, that is later compared (in the tests themselves) with expected XML - at this point the tests may as the order of elements in the resulting XML may be different. The following assertions fail on Apache Harmony because of this fact: testPersistenceContextAnnotationHelper testPersistenceUnitAnnotationHelper testWebServiceRefAnnotationHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3672) org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent
[ https://issues.apache.org/jira/browse/GERONIMO-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548535 ] Jarek Gawor commented on GERONIMO-3672: --- Fixed the tests in trunk (revision 601205). org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent --- Key: GERONIMO-3672 URL: https://issues.apache.org/jira/browse/GERONIMO-3672 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 2.0.2 Reporter: Vasily Zakharov Assignee: Jarek Gawor Test org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest may fail on non-Sun implementation, because it assumes the order in which Class.getFields() returns the fields, while specification doesn't specify the particular order. The problem occurs in method PersistenceUnitAnnotationHelper.processPersistenceUnit() which gets the fields and adds them to the annotatedApp, that is later compared (in the tests themselves) with expected XML - at this point the tests may as the order of elements in the resulting XML may be different. The following assertions fail on Apache Harmony because of this fact: testPersistenceContextAnnotationHelper testPersistenceUnitAnnotationHelper testWebServiceRefAnnotationHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3672) org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent
[ https://issues.apache.org/jira/browse/GERONIMO-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3672. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Fixed tests in branches/2.0 (revision 601208). org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest is implementation-dependent --- Key: GERONIMO-3672 URL: https://issues.apache.org/jira/browse/GERONIMO-3672 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 2.0.2 Reporter: Vasily Zakharov Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 Test org.apache.geronimo.j2ee.deployment.annotation.AnnotationHelperTest may fail on non-Sun implementation, because it assumes the order in which Class.getFields() returns the fields, while specification doesn't specify the particular order. The problem occurs in method PersistenceUnitAnnotationHelper.processPersistenceUnit() which gets the fields and adds them to the annotatedApp, that is later compared (in the tests themselves) with expected XML - at this point the tests may as the order of elements in the resulting XML may be different. The following assertions fail on Apache Harmony because of this fact: testPersistenceContextAnnotationHelper testPersistenceUnitAnnotationHelper testWebServiceRefAnnotationHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! On Dec 5, 2007 9:56 AM, Kevan Miller [EMAIL PROTECTED] wrote: All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan -- Thanks, Shiva
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! ++Vamsi On Dec 5, 2007 9:56 AM, Kevan Miller [EMAIL PROTECTED] wrote: All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan
[jira] Commented: (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:comment-tabpanel#action_12548556 ] Kan Ogawa commented on GERONIMO-3667: - Jarek, I reported a similar issue before, which is GERONIMO-3528. After a few days, I will try to test it by using both trunk and branches/2.0 builds. 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.
Re: [DISCUSS] Proposal to make the Yoko ORB a subproject of Geronimo.
On Dec 4, 2007, at 4:56 AM, Kevan Miller wrote: On Dec 3, 2007, at 1:45 PM, Rick McGuire wrote: Below is a proposal that Matt Hogstrom, one of the mentors of the Yoko project, has put forward for moving on with the Yoko project. In a nutshell, the Yoko community has basically decided there is not a lot of continuing interesting in moving this project forward. This decision does have a major impact on Geronimo, as Geronimo uses the Yoko ORB was a key element to allow Geronimo 1.2 to support both the 1.4 and 1.5 JVMs, and also was a necessary element for achieving j2ee5 certification. The Yoko ORB gives Geronimo cross JVM portability which was not available before. At the current time, there's probably no suitable replacement that has all of the advantages that the Yoko ORB provides. In a nutshell, Matt's proposal is for the core ORB elements of the Yoko project become a subproject of the Geronimo project. These are the pieces of Yoko that Geronimo has a dependency upon. These are essentially the org.omg.* clases, the javax.rmi.* classes, plus the implementation classes backing those spec interfaces. Along with the subproject, there are 6 committers who have expressed interest in continuing to work on the core ORB code. 3 of the interested commiters are already Geronimo committers. Matt's proposal would grant the remaining 3 Geronimo committer status as well. There's one important caveat in assuming owership of this package. The core ORB is also used by the Harmony project to add CORBA and RMI support to the Harmony JVM. Included with assuming ownership of the package would be a commitment to keep the core ORB a standalone component. This means not adding direct dependencies on Geronimo and keeping dependencies on other packages to a minimum. This code is fairly stable now, and has already passed certification on multiple JVM instances, so I don't expect there will be a lot of overhead in supporting this. The bulk of the recent work to get this to pass certification have been done by Geronimo committers, so Geronimo is probably the most appropriate new home for this code. Anyway, this needs to have some discussion and be put to a vote. Below is the proposal that Matt posted to the Yoko dev mailing list about this move. The Yoko community seems very much in agreement that project does not have sufficient momentum to graduate from the incubator. Thanks for the summary, Rick. I'm certainly interested in seeing support for Yoko move forward. This seems like a positive move. It would have my support. After a brief review of the Yoko dev list archives and based on Matt's, and Alan's recommendations, I would support adding Lars, Alexey, and Darren to as Geronimo committers. Keeping Yoko as a standalone component is an easy decision, IMO. Hard to see it any other way... These reflect my sentiments as well. Regards, Alan
Re: How to get memory statistics from a remote Geronimo runtime?
On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
It is not clear to me if this is part of the earlier code or a
separate program. If it is part of the JMX code, then Runtime is from
the local jvm not remote. The non heap Memory for this program in
either case is negligible.
I got the code to run in a jsp. So, the statistics it shows are indeed from
Geronimo's JVM.
You could start G with -Dcom.sun.management.jmxremote. Start
jconsole and click on the Memory tab to get the whole picture.
Will try this. Thank you.
Hope this is helpful
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know why the non heap memory is missing in the equations.
The
equations I gave are based what I observed by running the following
code.
MemoryMXBean memmxbean =
ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory.
In
other words you need to add contribution from non heap Memory to
all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from
Runtime.
Here is
the relationship I see between the stats from Runtime and those
got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() ==
MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct
way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : +
port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
