Re: xbean 2.2.1 release?
Once those things are done, it'd be great to get a new release out. (At some point we need to figure out how to deal with Spring 2.x's non backward compatability with the xbean-spring module) James On 4/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I'd like at least http://issues.apache.org/jira/browse/XBEAN-2 to be fixed before the release. Just have to apply the patch. There are also patches for XBEAN-4 (m2 plugin for mapping generation) and XBEAN-6 (bad dependencies scope) pending. Cheers, Guillaume Nodet Dan Diephouse wrote: Are people up for a 2.2.1 XBean release? Guillaume fixed a critical bug with Spring 1.2.7 and XBean which prevent them from working together. I'd like to see it released soon so users can use it... Regards, - Dan -- James --- http://radio.weblogs.com/0112098/
[jira] Closed: (GERONIMO-1844) Precompile jsp pages in console
[ http://issues.apache.org/jira/browse/GERONIMO-1844?page=all ] Dain Sundstrom closed GERONIMO-1844: Resolution: Fixed Thanks. The console is very snappy now. Precompile jsp pages in console --- Key: GERONIMO-1844 URL: http://issues.apache.org/jira/browse/GERONIMO-1844 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Reporter: Dain Sundstrom Assignee: Dain Sundstrom Fix For: 1.1 Attachments: deployment_version_change.patch, jsp-precompile.patch The maven script for precompiling jsp pages in console-framework and console-standard is broken so I commented it out. The following article explains how to use jsp precompliation: http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html In addition to this, we need to jar the compiled files to reduce the overall path length. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Precompiled JSPs
Thanks to Prasad we now have percompiled jsps in the console, and the console is much snappier on initial load. The difference is so drastic on my g4 mac, I'd like to see us preprocess the welcome application also since it is the very first impression of our users. Thanks for working on this one, -dain
Re: Precompiled JSPs
Way to go Prasad! A big old +1 to faster startup improvements. -David On Apr 20, 2006, at 11:54 PM, Dain Sundstrom wrote: Thanks to Prasad we now have percompiled jsps in the console, and the console is much snappier on initial load. The difference is so drastic on my g4 mac, I'd like to see us preprocess the welcome application also since it is the very first impression of our users. Thanks for working on this one, -dain
[jira] Created: (GERONIMO-1880) To Allow configurable password digests during REALM Deployment.
To Allow configurable password digests during REALM Deployment. --- Key: GERONIMO-1880 URL: http://issues.apache.org/jira/browse/GERONIMO-1880 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: security Versions: 1.1 Environment: Geronimo1.1 Reporter: Phani Balaji Madgula Hi, I observed REALM deployments in TOMCAT, I feel to have same kind of flexibility in specifying password DIGESTs for realms. Tomcat allows password DIGEST to be specified while declaring REALM in server.xml. GlobalNamingResources Resource name=PhaniUserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users-1.xml / /GlobalNamingResources Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=PhaniUserDatabase digest=MD5/ /Engine Now, user can store MD5 digested passwords for the users in tomcat-users-1.xml file as follows. ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=role2/ role rolename=role4/ role rolename=role1/ role rolename=role3/ user username=nag password=9fdc8b3f3027472d64e26a8e88fa2727 roles=role3,role4/ user username=phani password=c49f410c89f1031f816031ba60215f50 roles=role1,role2/ user username=balaji password=e75c1a66ae406db7d2f451b216b10664 roles=role3,role4/ /tomcat-users If user accesses any web application that declared security constraints with role1,role2,role3,role4, Tomcat will challenge the user for authentication where the user needs to specify userid and clear text password. Tomcat will digest the supplied password and compare it with what is specified in the file. Can we have same kind of feature in Geronimo also? That is, to specify DIGEST in REALM deployment plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1881) Remove obsolete interop module
Remove obsolete interop module -- Key: GERONIMO-1881 URL: http://issues.apache.org/jira/browse/GERONIMO-1881 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: general Versions: 1.2, 1.1 Reporter: Rick McGuire Assigned to: Rick McGuire Priority: Minor Fix For: 1.2, 1.1 The interop module has not been used or updated for multiple releases, and the new Yoko project will be filling the role originally intended by this code. People are mistakenly attempting to use pieces of this code, so it needs to be removed from the code tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1881) Remove obsolete interop module
[ http://issues.apache.org/jira/browse/GERONIMO-1881?page=comments#action_12375535 ] Rick McGuire commented on GERONIMO-1881: Committed version 395839 for 1.1 branch. Remove obsolete interop module -- Key: GERONIMO-1881 URL: http://issues.apache.org/jira/browse/GERONIMO-1881 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.2, 1.1 Reporter: Rick McGuire Assignee: Rick McGuire Priority: Minor Fix For: 1.2, 1.1 The interop module has not been used or updated for multiple releases, and the new Yoko project will be filling the role originally intended by this code. People are mistakenly attempting to use pieces of this code, so it needs to be removed from the code tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Issues Closed: week of 04-21-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1845] Add minimal-tomcat-server assembly (little-G) to Geronimo 1.1 ** Bug * [GERONIMO-1878] Cannot redeploy the console * [GERONIMO-1763] default config.xml does not list Jetty AJP connector * [GERONIMO-1853] modules/j2ee DomainTest failure * [GERONIMO-1503] keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners * [GERONIMO-1877] Tomcat Console throws ClassCast Exception when selecting the Tomcat Web Connector * [GERONIMO-1790] Long Geronimo path and file names cause problems on Windows * [GERONIMO-1828] JSR-88 treats AbstractName like an ObjectName * [GERONIMO-1872] Two meanings of META-INF/geronimo-service.xml * [GERONIMO-973] Add security to /console-standard * [GERONIMO-1575] JMX service doesn't start up when server hostname does not resolve correctly * [GERONIMO-1330] MBeans registered on the MBeanServer can not be viewed * [GERONIMO-1329] Cannot connect to Geronimo with jconsole * [GERONIMO-1839] Stopping or unloading a configuration with 2 or more dependent configurations is broken * [GERONIMO-1457] Change trunk version to 1.1-SNAPSHOT * [GERONIMO-1599] HOWLLog throws NPE because XidFactory is missing * [GERONIMO-1850] environment merge problem between ear and ejb modules (at least) * [GERONIMO-1863] Don't save enhanced classes, cglib is going to remove support for saving classes. ** Improvement * [GERONIMO-1844] Precompile jsp pages in console * [GERONIMO-1199] Keystore portlet should display certificate finger print before importing trusted certificates * [GERONIMO-1809] Remove GBeanName * [GERONIMO-1814] Add version number XStream serialized configuration files * [GERONIMO-1778] Commits that shoud be merged from HEAD to 1.1 ** Task * [GERONIMO-1876] backport console progress bar from 1.2 to 1.1 ** Wish * [GERONIMO-1653] User friendly error message from GBeanInstance
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
On 4/21/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: But then the only real vote that counts is Aaron I really need this feature Mulder's. ;) Aww, you know you'll thank me when the release notes come out. :) Thanks, Aaron Matt Hogstrom wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
[X] +1 - Close development for 1.1 on Monday 4/24 0600 PT Matt Hogstrom wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt
[jira] Created: (GERONIMO-1882) Deploy from web console fails with NoSuchOperationException
Deploy from web console fails with NoSuchOperationException --- Key: GERONIMO-1882 URL: http://issues.apache.org/jira/browse/GERONIMO-1882 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assigned to: Aaron Mulder Fix For: 1.1 Following exception is thrown when attempting to deploy from the web console portlet: 09:01:07,467 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:139) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.geronimo.kernel.NoSuchOperationException: Unknown operation deploy(java.io.File, java.io.File) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:836) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:244) at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:112) ... 38 more Nested Exception is org.apache.geronimo.kernel.NoSuchOperationException: Unknown operation deploy(java.io.File, java.io.File) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:836) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:244) at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:112) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at
[jira] Updated: (GERONIMO-1882) Deploy from web console fails with NoSuchOperationException
[ http://issues.apache.org/jira/browse/GERONIMO-1882?page=all ] Aaron Mulder updated GERONIMO-1882: --- Priority: Blocker (was: Major) Deploy from web console fails with NoSuchOperationException --- Key: GERONIMO-1882 URL: http://issues.apache.org/jira/browse/GERONIMO-1882 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Following exception is thrown when attempting to deploy from the web console portlet: 09:01:07,467 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:139) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.geronimo.kernel.NoSuchOperationException: Unknown operation deploy(java.io.File, java.io.File) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:836) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:244) at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:112) ... 38 more Nested Exception is org.apache.geronimo.kernel.NoSuchOperationException: Unknown operation deploy(java.io.File, java.io.File) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:836)
[jira] Updated: (GERONIMO-1875) More work to port little-g to 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1875?page=all ] Joe Bohn updated GERONIMO-1875: --- Attachment: 1875_axis+builder.patch This patch splits out axis from j2ee-server and axis-builder from j2ee-deployer More work to port little-g to 1.1 - Key: GERONIMO-1875 URL: http://issues.apache.org/jira/browse/GERONIMO-1875 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 1875_axis+builder.patch, 1875_littleg.patch, 1875_openejb-deployer.diff This issue will be used to hold more patches for little-g modularization of geronimo 1.1. Some pieces: - additional plans for new configs - turning single valued references to ejb builder, axis builder, client builder, connector builder etc into something that will work. The problem is that all these builders can't be in the ancestor tree of j2ee-deployer, or we'd always be pulling them into the server. Therefore they need to be collection valued references. We can make a collection wrapper that returns a single element or null, or objects to the presence of more than one element, and use this to hold many of these 0..1 valued references. Both EarConfigBuilder and ClientModuleBuilder need this modification. - modify existing plans to remove gbeans now in the new plans. Be sure to update the defaultEnvironments as appropriate. - modify the assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [WARNING] - Mac users
On 20 Apr 2006, at 21:58, Bruce Snyder wrote: On 4/20/06, Jim Jagielski [EMAIL PROTECTED] wrote: A short shell script which adjusts CurrentJDK back and forth between 1.5.0 and 1.4.2 is all that's needed. The Java Preferences panel in Utilities doesn't cut it. Thanks for David Blevins, here is what I use: http://docs.codehaus.org/display/ninja/setjdk Bruce that's nice and neat but does it also need to set $JAVA_VERSION? I've had builds of different projects get all upset when the java version on the path is 1.4.2 but the JAVA_VERSION env var is set to the 1.5. rgds Conrad
Error in building 1.1 - Getting error for missing class MergeXML
This problem has been fixed. You need to do an update and rebuild the plugins.
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
+1 - sachin On Apr 20, 2006, at 4:45 PM, Matt Hogstrom wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
+1 On 4/20/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt -- James --- http://radio.weblogs.com/0112098/
Re: xbean 2.2.1 release?
OK that sounds good. - Dan Guillaume Nodet wrote: I'd like at least http://issues.apache.org/jira/browse/XBEAN-2 to be fixed before the release. Just have to apply the patch. There are also patches for XBEAN-4 (m2 plugin for mapping generation) and XBEAN-6 (bad dependencies scope) pending. Cheers, Guillaume Nodet Dan Diephouse wrote: Are people up for a 2.2.1 XBean release? Guillaume fixed a critical bug with Spring 1.2.7 and XBean which prevent them from working together. I'd like to see it released soon so users can use it... Regards, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
[jira] Resolved: (GERONIMO-1881) Remove obsolete interop module
[ http://issues.apache.org/jira/browse/GERONIMO-1881?page=all ] Rick McGuire resolved GERONIMO-1881: Resolution: Fixed Commited revision 395903 in head branch. Remove obsolete interop module -- Key: GERONIMO-1881 URL: http://issues.apache.org/jira/browse/GERONIMO-1881 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.2, 1.1 Reporter: Rick McGuire Assignee: Rick McGuire Priority: Minor Fix For: 1.2, 1.1 The interop module has not been used or updated for multiple releases, and the new Yoko project will be filling the role originally intended by this code. People are mistakenly attempting to use pieces of this code, so it needs to be removed from the code tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
[X] +1 - Close development for 1.1 on Monday 4/24 0600 PT Cheers! Hernan Matt Hogstrom wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt
Re: svn commit: r395697 - in /geronimo/branches/1.1: applications/console-ear/ applications/console-ear/src/application/META-INF/ applications/daytrader/ applications/daytrader/ear/ applications/daytr
I'm trying to understand the significance of this modification. Is this considered a short term
fix? If not, then my take is we are communicating that folks building J2EE application should *NOT*
be using Maven as it generated artifacts whose names are too large. Or we are communicating that
Geronimo cannot consume them.
I'm -1 on this change until we can clarify the project's position on using Maven to build J2EE
applications.
[EMAIL PROTECTED] wrote:
Author: dain
Date: Thu Apr 20 14:07:47 2006
New Revision: 395697
URL: http://svn.apache.org/viewcvs?rev=395697view=rev
Log:
Applied patch GERONIMO-1790 to shorten the paths of ear files. Thanks Joe Bohn.
Modified:
geronimo/branches/1.1/applications/console-ear/project.xml
geronimo/branches/1.1/applications/console-ear/src/application/META-INF/application.xml
geronimo/branches/1.1/applications/daytrader/dayTrader-plan.xml
geronimo/branches/1.1/applications/daytrader/ear/project.xml
geronimo/branches/1.1/applications/daytrader/ear/src/application/META-INF/application.xml
geronimo/branches/1.1/applications/daytrader/streamer/project.xml
geronimo/branches/1.1/applications/daytrader/streamer/src/client/META-INF/MANIFEST.MF
geronimo/branches/1.1/applications/daytrader/web/src/webapp/WEB-INF/web.xml
geronimo/branches/1.1/applications/daytrader/wsappclient/src/client/META-INF/MANIFEST.MF
geronimo/branches/1.1/configs/console-jetty/src/plan/plan.xml
geronimo/branches/1.1/configs/console-tomcat/src/plan/plan.xml
geronimo/branches/1.1/configs/daytrader-jetty/src/plan/plan.xml
geronimo/branches/1.1/configs/daytrader-tomcat/src/plan/plan.xml
geronimo/branches/1.1/modules/kernel/src/java/org/apache/geronimo/kernel/Kernel.java
Modified: geronimo/branches/1.1/applications/console-ear/project.xml
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/applications/console-ear/project.xml?rev=395697r1=395696r2=395697view=diff
==
--- geronimo/branches/1.1/applications/console-ear/project.xml (original)
+++ geronimo/branches/1.1/applications/console-ear/project.xml Thu Apr 20
14:07:47 2006
@@ -14,6 +14,7 @@
typewar/type
properties
ear.bundletrue/ear.bundle
+ear.bundle.nameframework.war/ear.bundle.name
ear.appxml.war.context-root/console/ear.appxml.war.context-root
/properties
/dependency
@@ -24,6 +25,7 @@
typewar/type
properties
ear.bundletrue/ear.bundle
+ear.bundle.namestandard.war/ear.bundle.name
ear.appxml.war.context-root/console-standard/ear.appxml.war.context-root
/properties
/dependency
Modified:
geronimo/branches/1.1/applications/console-ear/src/application/META-INF/application.xml
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/applications/console-ear/src/application/META-INF/application.xml?rev=395697r1=395696r2=395697view=diff
==
---
geronimo/branches/1.1/applications/console-ear/src/application/META-INF/application.xml
(original)
+++
geronimo/branches/1.1/applications/console-ear/src/application/META-INF/application.xml
Thu Apr 20 14:07:47 2006
@@ -6,13 +6,13 @@
display-nameGeronimo Console Application/display-name
module
web
-
web-urigeronimo-console-framework-${pom.currentVersion}.war/web-uri
+web-uriframework.war/web-uri
context-root/console/context-root
/web
/module
module
web
-
web-urigeronimo-console-standard-${pom.currentVersion}.war/web-uri
+web-uristandard.war/web-uri
context-root/console-standard/context-root
/web
/module
Modified: geronimo/branches/1.1/applications/daytrader/dayTrader-plan.xml
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/applications/daytrader/dayTrader-plan.xml?rev=395697r1=395696r2=395697view=diff
==
--- geronimo/branches/1.1/applications/daytrader/dayTrader-plan.xml (original)
+++ geronimo/branches/1.1/applications/daytrader/dayTrader-plan.xml Thu Apr 20
14:07:47 2006
@@ -3,7 +3,7 @@
configId=Trade
module
-webdaytrader-web-1.1-SNAPSHOT.war/web
+webweb.war/web
web-app xmlns=http://geronimo.apache.org/xml/ns/web;
configId=Web parentId=Trade
context-priority-classloaderfalse/context-priority-classloader
@@ -30,7 +30,7 @@
##
--
module
-ejbdaytrader-ejb-1.1-SNAPSHOT.jar/ejb !-- Note this must match
the --
+ejbdt-ejb.jar/ejb !-- Note this must match the --
openejb-jar xmlns=http://www.openejb.org/xml/ns/openejb-jar;
configId=TradeEJBs
Re: [VOTE] Release Axis 1.4 final branch
David, I've just run the saaj tck and jaxrpc tck (both standalone) on the branch mentioned below. All Green. Thanks, dims On 3/13/06, David Blevins [EMAIL PROTECTED] wrote: Dims created an Axis 1.4 final branch in early Dec at: http://svn.apache.org/repos/asf/webservices/axis/branches/AXIS_1_4_FINAL There was a vote to release this that went through but the binaries were never produced. Geronimo, Jonas and others are using this code and it would be great to see it made official. I am volunteering as Release Manager and would like to kicked this release out the door before the month is through. Here is my +1 for me as Release Manager and seeing 1.4 released this month. -David -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Created: (GERONIMO-1883) Make sure all documentation is clearly marked as G 1.0 or G 1.1
Make sure all documentation is clearly marked as G 1.0 or G 1.1 --- Key: GERONIMO-1883 URL: http://issues.apache.org/jira/browse/GERONIMO-1883 Project: Geronimo Type: Bug Security: public (Regular issues) Components: documentation Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1 As we roll out 1.1, with different deployment plan syntax, it'll be extremely import that *all* documentation clearly states (e.g. in big bold text at the top) which Geronimo version it applies to. We can go ahead and mark all the 1.0 content as 1.0 now, and just update the marker as the content itself is updated to 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Precompiled JSPs
Dain, In that case, should we consider moving the goal:precompile up to the /etc level ? This can then be generically used by any application wanting to precompile. Initially I left them in console-framework and console-standard thinking they'd be the only ones. But now I see that there is a scope for us to reuse this for others too in the future. Cheers Prasad On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Thanks to Prasad we now have percompiled jsps in the console, and the console is much snappier on initial load. The difference is so drastic on my g4 mac, I'd like to see us preprocess the welcome application also since it is the very first impression of our users. Thanks for working on this one, -dain
Re: Precompiled JSPs
Sounds good to me. -dain On Apr 21, 2006, at 8:48 AM, Prasad Kashyap wrote: Dain, In that case, should we consider moving the goal:precompile up to the /etc level ? This can then be generically used by any application wanting to precompile. Initially I left them in console-framework and console-standard thinking they'd be the only ones. But now I see that there is a scope for us to reuse this for others too in the future. Cheers Prasad On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Thanks to Prasad we now have percompiled jsps in the console, and the console is much snappier on initial load. The difference is so drastic on my g4 mac, I'd like to see us preprocess the welcome application also since it is the very first impression of our users. Thanks for working on this one, -dain
[jira] Updated: (GERONIMO-1875) More work to port little-g to 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1875?page=all ] Joe Bohn updated GERONIMO-1875: --- Attachment: 1875_axis+builder+clientDeploy.patch David, Please apply this patch with the really long name (C:\GeronimoPatches\1875_axis+builder+clientDeploy.patch) rather than the previous one (C:\GeronimoPatches\1875_axis+builder.patch). This new patch includes everthing from the previous plus the client-deployer changes. More work to port little-g to 1.1 - Key: GERONIMO-1875 URL: http://issues.apache.org/jira/browse/GERONIMO-1875 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 1875_axis+builder+clientDeploy.patch, 1875_axis+builder.patch, 1875_littleg.patch, 1875_openejb-deployer.diff This issue will be used to hold more patches for little-g modularization of geronimo 1.1. Some pieces: - additional plans for new configs - turning single valued references to ejb builder, axis builder, client builder, connector builder etc into something that will work. The problem is that all these builders can't be in the ancestor tree of j2ee-deployer, or we'd always be pulling them into the server. Therefore they need to be collection valued references. We can make a collection wrapper that returns a single element or null, or objects to the presence of more than one element, and use this to hold many of these 0..1 valued references. Both EarConfigBuilder and ClientModuleBuilder need this modification. - modify existing plans to remove gbeans now in the new plans. Be sure to update the defaultEnvironments as appropriate. - modify the assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
help with build instructions from wiki
I have been attempting to build from source for 2 days following the instructions on the wiki. I keeps failing while executing maven new with unsatisfied dependencies. Can someone please work with me off line (maybe via aim) to help me resolve this? I am not super familiar with maven but I suspect that could manually prime the repository to satisfy the dependencies. Anyway a little assistance would be greatly appreciated. Thanks Ryan
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
+1 and I agree with Aaron about being flexible about ship date Any interest in releasing/announcing at JavaOne? geir Matt Hogstrom wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt
Re: help with build instructions from wiki
Hi Ryan, I don't have AIM but I could try to help you if you come on IRC. I also have Yahoo msngr. You may send me a mail directly. Cheers Prasad On 4/21/06, Ryan Ovrevik [EMAIL PROTECTED] wrote: I have been attempting to build from source for 2 days following the instructions on the wiki. I keeps failing while executing maven new with unsatisfied dependencies. Can someone please work with me off line (maybe via aim) to help me resolve this? I am not super familiar with maven but I suspect that could manually prime the repository to satisfy the dependencies. Anyway a little assistance would be greatly appreciated. Thanks Ryan
[jira] Created: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
Samples not installed properly in G1.1 - several issues --- Key: GERONIMO-1884 URL: http://issues.apache.org/jira/browse/GERONIMO-1884 Project: Geronimo Type: Bug Security: public (Regular issues) Components: sample apps Versions: 1.1 Reporter: Dave Colasurdo Priority: Critical IT appears that the Geronimo samples have recently been removed from the default distributions and replaced with the ability to download them through the admin console. There are several issues that need to be addressed: 1) The Sample links on the Geronimo welcome page are dead.. This needs to be updated with instructions on how to download, start and access the samples.. 2) Assuming that the admin console plugins is the correct spot to download the samples.. 2a) The initial panel presented to the user is a bit confusing and is missing the ldap-demo.. 2b) After downloading the jsp or servlet examples.. The user is presented with a start examples box.. Selecting this does not work and results in an exception (attached below) 2c) start examples box does not return any status 2d) Manually starting the example via the command line also does not work. and results in an exception... Exception for 2b Geronimo Application Server started # Installed configuration # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car # location = /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car java.lang.ClassCastException at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210) 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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) 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$$a14ba351.loadConfiguration(generated) at org.apache.geronimo.console.car.ResultsHandler.actionAfterView(ResultsHandler.java:75) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:116) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at
[jira] Created: (GERONIMO-1885) Resource/EJB Refs search top-level deployments (or change docs)
Resource/EJB Refs search top-level deployments (or change docs) --- Key: GERONIMO-1885 URL: http://issues.apache.org/jira/browse/GERONIMO-1885 Project: Geronimo Type: Bug Security: public (Regular issues) Components: naming Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 In 1.0 if you declare a resource-link in a Geronimo deployment plan, the deployer will search your own configuration, (any parent configurations?), and any top-level deployments in the server. In 1.1, we reportedly current search only the parent configurations to resolve references, no longer checking all top-level deployments in the server. I would like to search top-level deployments like we did before, and if we find something not in the parent path emit a warning that this application cannot be safely exported as a plugin or to other Geronimo servers due to an unrecorded dependency. If we instead keep the new behavior of searching only parents, we need to ensure that all documentation is updated accordingly (including the DB pool usage screen in the console). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1886) NPE on simple web app deployment
NPE on simple web app deployment Key: GERONIMO-1886 URL: http://issues.apache.org/jira/browse/GERONIMO-1886 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Fix For: 1.1 Recieving the following message execption below when deploying a simple web app. The contents of the geronimo-web.xml is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1; xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; sys:environment sys:configId sys:groupIddefault/sys:groupId sys:artifactIdeee/sys:artifactId sys:version1.0/sys:version sys:typewar/sys:type /sys:configId /sys:environment context-root/eee/context-root context-priority-classloaderfalse/context-priority-classloader /web-app Error: Unable to distribute fdsf.war: java.lang.NullPointerException 14:06:31,245 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.j2ee.deployment.RefContext.getHandleDelegateReference(RefContext.java:69) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:664) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.buildComponentContext(TomcatModuleBuilder.java:459) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:294) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder$$FastClassByCGLIB$$6f85ec2c.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$2d305758.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:161) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$2d305758.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:510) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$391d5fca.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:333) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:120) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at
[jira] Assigned: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
[ http://issues.apache.org/jira/browse/GERONIMO-1884?page=all ] Aaron Mulder reassigned GERONIMO-1884: -- Assign To: Aaron Mulder Issue #2 is known -- the samples have to be exported and added to the plugin download site, and all the ones there were broken by changes since they were last exported. We're also hoping to add the ability to package the necessary plugin XML descriptors into the CARs as they're built to make the export process less manual. For Issue #1, it would be nice to take users to a page that would prompt them to install the sample if they click a link to it and it's not present. However, automating this would require us to be able to construct a link into a portlet, which does not seem easy. For now, the welcome app can include pages at the locations where the sample apps will be bound, with text to the effect of: This sample has not yet been installed. To install it, visit the (URL)console(/URL) and select the Plugins page, click the Search for Plugins button, and select the (NAME HERE) sample to install. Then visit this same URL again to view the (NAME HERE) example. Samples not installed properly in G1.1 - several issues --- Key: GERONIMO-1884 URL: http://issues.apache.org/jira/browse/GERONIMO-1884 Project: Geronimo Type: Bug Security: public(Regular issues) Components: sample apps Versions: 1.1 Reporter: Dave Colasurdo Assignee: Aaron Mulder Priority: Critical IT appears that the Geronimo samples have recently been removed from the default distributions and replaced with the ability to download them through the admin console. There are several issues that need to be addressed: 1) The Sample links on the Geronimo welcome page are dead.. This needs to be updated with instructions on how to download, start and access the samples.. 2) Assuming that the admin console plugins is the correct spot to download the samples.. 2a) The initial panel presented to the user is a bit confusing and is missing the ldap-demo.. 2b) After downloading the jsp or servlet examples.. The user is presented with a start examples box.. Selecting this does not work and results in an exception (attached below) 2c) start examples box does not return any status 2d) Manually starting the example via the command line also does not work. and results in an exception... Exception for 2b Geronimo Application Server started # Installed configuration # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car # location = /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car java.lang.ClassCastException at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210) at
Re: [VOTE] 1.1 Code Freeze to start Monday 0600 PT - Ship 1.1 on Cinco De Mayo
Let's plan on a 1.1-beta some time between May 1 and May 8 if we think most of the functional errors are fixed, then a 1.1-rc as soon as we're comfortable with any fixes to the beta and we think all the softer things like documentation and stuff are fixed, and then a 1.1 as soon after that as possible. I'd be fine if we don't publicize the beta but just use that as a milestone to the RC (and to work out the issues around making sure there aren't dangling SNAPSHOT references in our source and so on). I definitely want to release no later than JavaOne, but earlier would be totally fine with me if the stability is there and the docs have caught up (so we won't be confusing people with the 1.0/1.1 syntax differences, etc.). Thanks, Aaron On 4/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: +1 and I agree with Aaron about being flexible about ship date Any interest in releasing/announcing at JavaOne? geir Matt Hogstrom wrote: All, I'd like to propose we close 1.1 and start putting the wrapping tape on the box. There have been new features / functions coming in and at some point we need to collectively get this one out the door and focus on 1.2. So here is the vote to agree to close features and focus on bugs / JIRAs so we can complete this one. [ ] +1 - Close development for 1.1 on Monday 4/24 0600 PT [ ] 0 - No preference [ ] -1 - Let's cram as much in as we can Of course this doesn't mean that we don't fix bugs. Matt
[jira] Resolved: (GERONIMO-1886) NPE on simple web app deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1886?page=all ] Aaron Mulder resolved GERONIMO-1886: Resolution: Fixed Assign To: David Jencks This was fixed in the Jetty distribution by a change late in the day 5/20 and in the Tomcat distribution overnight some time between 5/20 and 5/21. Please update Geronimo and do a full build (maven -o clean new) and reopen this issue if you still see the problem. NPE on simple web app deployment Key: GERONIMO-1886 URL: http://issues.apache.org/jira/browse/GERONIMO-1886 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Assignee: David Jencks Fix For: 1.1 Recieving the following message execption below when deploying a simple web app. The contents of the geronimo-web.xml is: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1; xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; sys:environment sys:configId sys:groupIddefault/sys:groupId sys:artifactIdeee/sys:artifactId sys:version1.0/sys:version sys:typewar/sys:type /sys:configId /sys:environment context-root/eee/context-root context-priority-classloaderfalse/context-priority-classloader /web-app Error: Unable to distribute fdsf.war: java.lang.NullPointerException 14:06:31,245 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.j2ee.deployment.RefContext.getHandleDelegateReference(RefContext.java:69) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:664) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.buildComponentContext(TomcatModuleBuilder.java:459) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:294) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder$$FastClassByCGLIB$$6f85ec2c.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$2d305758.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:161) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$2d305758.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:510) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) 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
[jira] Created: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: http://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.x Reporter: Paul McMahan Priority: Minor Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[announce] Welcome Apache Geronimo's newest committer - Rick McGuire
In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC
pooling message driven pojo's thru spring
Hello, I am looking for a way allow for a pool of MessageDriven pojo's to act on a queue. I am porting over code that allowed for a thread pool to read from a queue and am looking to do similar behavior with ActiveMQ. Would I simply have to set maxMessagesPerSession and/or maxMessagesPerBatch. Below is an example of our spring configuration? So in my example below would this mean that there is a pool of 5 (MDP's) that will read from this queue? Also could you explain the difference between maxMessagesPerSession and maxMessagesPerBatch. Is there another site that documents the ActiveMQ API in greater detail than the online javadoc? Thanks !-- tell JCAContainer to set up a connector that listens to the named queue and map messages that are received to your named 'message driven pojo' -- bean id=exampleConnector class=org.jencks.JCAConnector property name=jcaContainer ref=jencks/ !-- subscription details -- property name=activationSpec bean class=org.apache.activemq.ra.ActiveMQActivationSpec property name=destination value=Example.Queue/ property name=destinationType value=javax.jms.Queue/ property name=enableBatch value=true/ property name=maxMessagesPerBatch value=5/ /bean /property property name=ref value=exampleMDP/ /bean -- View this message in context: http://www.nabble.com/pooling-message-driven-pojo%27s-thru-spring-t1488572.html#a4032665 Sent from the ActiveMQ - Dev forum at Nabble.com.
Verbiage: Change configuration to module?
All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a module instead? It seems like configuration can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what two different configurations presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the unit with an ID and classloader holding many components as a module. What do you think? Thanks, Aaron
[jira] Commented: (GERONIMO-1875) More work to port little-g to 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1875?page=comments#action_12375631 ] David Jencks commented on GERONIMO-1875: first 4 patches applied by rev 395993. Needed a couple tweaks and a fix to UnavailableEJBReferenceBuilder. More work to port little-g to 1.1 - Key: GERONIMO-1875 URL: http://issues.apache.org/jira/browse/GERONIMO-1875 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 1875_axis+builder+clientDeploy.patch, 1875_axis+builder.patch, 1875_littleg.patch, 1875_openejb-deployer.diff This issue will be used to hold more patches for little-g modularization of geronimo 1.1. Some pieces: - additional plans for new configs - turning single valued references to ejb builder, axis builder, client builder, connector builder etc into something that will work. The problem is that all these builders can't be in the ancestor tree of j2ee-deployer, or we'd always be pulling them into the server. Therefore they need to be collection valued references. We can make a collection wrapper that returns a single element or null, or objects to the presence of more than one element, and use this to hold many of these 0..1 valued references. Both EarConfigBuilder and ClientModuleBuilder need this modification. - modify existing plans to remove gbeans now in the new plans. Be sure to update the defaultEnvironments as appropriate. - modify the assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Verbiage: Change configuration to module?
+1 and I think I had a hand in calling them configurations I have found people very very confused (blank stares) when I start talking about configurations. One issue with this change is it should be reflected in the XML, and console. This would mean renaming configId in the xml to moduleId, which should be a minor change. -dain On Apr 21, 2006, at 1:03 PM, David Blevins wrote: Anything is better than configuration. I've never liked that term. Module is fine. Nice term from the apache httpd lexicon. -David On Apr 21, 2006, at 12:54 PM, Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a module instead? It seems like configuration can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what two different configurations presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the unit with an ID and classloader holding many components as a module. What do you think? Thanks, Aaron
Re: [WARNING] - Mac users
On 4/21/06, Conrad O'Dea [EMAIL PROTECTED] wrote: that's nice and neat but does it also need to set $JAVA_VERSION? I've had builds of different projects get all upset when the java version on the path is 1.4.2 but the JAVA_VERSION env var is set to the 1.5. I have never bothered to set JAVA_VERSION, ever, and I've never had a problem. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Verbiage: Change configuration to module?
+1 - sachin On Apr 21, 2006, at 3:54 PM, Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a module instead? It seems like configuration can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what two different configurations presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the unit with an ID and classloader holding many components as a module. What do you think? Thanks, Aaron
Re: Verbiage: Change configuration to module?
On 4/21/06, Aaron Mulder [EMAIL PROTECTED] wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a module instead? It seems like configuration can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what two different configurations presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the unit with an ID and classloader holding many components as a module. What do you think? Yay! +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
[jira] Created: (GERONIMO-1888) Better help for bad references
Better help for bad references -- Key: GERONIMO-1888 URL: http://issues.apache.org/jira/browse/GERONIMO-1888 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: usability Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 If a GBean can't start beacuse of a missing reference, it would be great to give a more helpful error message. Like if the reference included the name Foo, print a list of all AbstractNames including name=Foo in the format you'd expect for the reference in question (slightly different for GBean-to-GBean references vs J2EE Component-to-Resource references, etc.). It would be great if it came out like this: Unable to resolve reference to artifactIdbar/artifactIdnameFoo/name. Did you mean one of these instead? * artifactIdbaz/artifactIdnameFoo/name * artifactIdother/artifactIdnameFoo/name Unable to resolve reference to artifactIdbar/artifactIdnameFoo/name. There are no components with nameFoo/name in this module or any of its dependencies. Perhaps you need to add a dependency to this module and point it to one of the following modules which has a component with nameFoo/name: * mygroup/myartifact/1.0/car * other/something/3.4/rar This is aggravated by the fact that our resource target names are no longer JMX names, so we can't tell people to look up the component in the JMX debug tool. However, it's mitigated by the fact that you have to declare dependencies explicitly and can more often just use nameFoo/name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1890) Support zip files in sharedir in addition to jars
Support zip files in sharedir in addition to jars - Key: GERONIMO-1890 URL: http://issues.apache.org/jira/browse/GERONIMO-1890 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: general Versions: 1.1 Reporter: Joe Bohn Assigned to: Joe Bohn Priority: Minor Fix For: 1.1 Users have expressed a need to include zip files in the shared lib in addition to jars. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1890) Support zip files in sharedir in addition to jars
[ http://issues.apache.org/jira/browse/GERONIMO-1890?page=all ] Joe Bohn updated GERONIMO-1890: --- Attachment: 1890_sharedlibzip.patch Support zip files in sharedir in addition to jars - Key: GERONIMO-1890 URL: http://issues.apache.org/jira/browse/GERONIMO-1890 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.1 Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Fix For: 1.1 Attachments: 1890_sharedlibzip.patch Users have expressed a need to include zip files in the shared lib in addition to jars. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congratulations Rick!!! Great work and certainly well deserved. Joe Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Created: (GERONIMO-1891) Meaningless ERROR printed by attribute manager during redeploy
Meaningless ERROR printed by attribute manager during redeploy -- Key: GERONIMO-1891 URL: http://issues.apache.org/jira/browse/GERONIMO-1891 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment, kernel Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 When redeploying the console, the server always prints: ERROR [LocalAttributeManager] Trying to stop unknown configuration: geronimo/webconsole-jetty/1.1-SNAPSHOT/car There is no actual problem, however. Why does the attribute manager not know about the console configuration? It's listed in config.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1890) Support zip files in sharedir in addition to jars
[ http://issues.apache.org/jira/browse/GERONIMO-1890?page=all ] David Jencks closed GERONIMO-1890: -- Resolution: Fixed Applied rev 396018 Support zip files in sharedir in addition to jars - Key: GERONIMO-1890 URL: http://issues.apache.org/jira/browse/GERONIMO-1890 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: general Versions: 1.1 Reporter: Joe Bohn Assignee: David Jencks Priority: Minor Fix For: 1.1 Attachments: 1890_sharedlibzip.patch Users have expressed a need to include zip files in the shared lib in addition to jars. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Verbiage: Change configuration to module?
+1 It is easier to grasp - J2EE module : deployable unit with deployment descriptor geronimo module : serialized deployable unit created with a plan --- Dain Sundstrom [EMAIL PROTECTED] wrote: +1 and I think I had a hand in calling them configurations I have found people very very confused (blank stares) when I start talking about configurations. One issue with this change is it should be reflected in the XML, and console. This would mean renaming configId in the xml to moduleId, which should be a minor change. We will also have to do 'mar' instead of car. Thnaks Anita -dain On Apr 21, 2006, at 1:03 PM, David Blevins wrote: Anything is better than configuration. I've never liked that term. Module is fine. Nice term from the apache httpd lexicon. -David On Apr 21, 2006, at 12:54 PM, Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a module instead? It seems like configuration can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what two different configurations presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the unit with an ID and classloader holding many components as a module. What do you think? Thanks, Aaron __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Build failed
Hi Guys, The build failed with the following errors. Any ideas??Btw I was on revision 396023 when I did svn up.---Build Errors-test:compile: [javac] Compiling 13 source files to /opt/workspace/geronimo/modules/security/target/test-classes /opt/workspace/geronimo/modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:20: package com.sun.security.auth.login does not existimport com.sun.security.auth.login.ConfigFile ; ^/opt/workspace/geronimo/modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:209: cannot resolve symbolsymbol : class ConfigFile location: class org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest Configuration.setConfiguration(new ConfigFile()); ^2 errors Regards,Rajith
[jira] Commented: (GERONIMO-1802) Console breakage in 1.1 branch
[ http://issues.apache.org/jira/browse/GERONIMO-1802?page=comments#action_12375647 ] Aaron Mulder commented on GERONIMO-1802: Patches dbpools.patch, jms.patch, and webserver.patch (or equivalent) have been applied. Thanks! Console breakage in 1.1 branch -- Key: GERONIMO-1802 URL: http://issues.apache.org/jira/browse/GERONIMO-1802 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.1 Attachments: dbpools.patch, jms.patch, webserver.patch Here's my first stab at evaluating the console state (including the Welcome, Server/* and Services/* pages): [Second pass made by Paul on 4/13/2006] Welcome: OK Server/Information: OK Server/JVM: OK Server/Server Logs: OK Server/Shutdown: OK Server/Web Server: BROKEN - error in web server manager portlet - trying to stop a listener fails - very unstable in general java.lang.ClassCastException at org.apache.geronimo.console.webmanager.WebManagerPortlet.doView(WebManagerPortlet.java:112) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)Server/JMS Server: BROKEN - portlets show up but most controls don't work, e,g, trying to create a new activeio listener yields java.lang.IllegalArgumentException: uri does not contain a path part used for the artifact at org.apache.geronimo.gbean.AbstractName.init(AbstractName.java:78) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:65) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) and trying to stop an activeio listener yields: java.lang.NullPointerException at java.net.URI$Parser.parse(URI.java:2946) at java.net.URI.init(URI.java:574) at java.net.URI.create(URI.java:836) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:65) Services/Common Libraries: OK Services/Database Pools: patch provided Services/JMS Resources: patch provided Deploy New: OK Application EARs: OK Web Applications: OK EJB JARS: not sure J2EE Connectors: WORKS PARTIALLY Stops ok, but trying to restart system database yields: 17:17:03,241 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1-SNAPSHOT/car?configurationName=geronimo/activemq-broker/1.1-SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency geronimo/system-database/1.1-SNAPSHOT/car at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:347) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:294) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:261) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:915) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:508) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) App Clients: OK System Modules: OK Console Realm: OK Security Realm: WORKS PARTIALLY Fails when saving plan with exception: org.apache.geronimo.common.DeploymentException: Unable to create configuration for deployment at
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congratulations! Rick. Anita --- Paul McMahan [EMAIL PROTECTED] wrote: Congrats Rick!! Well deserved. I saw your commits earlier today on scm and thought something must be up :-) On 4/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Remove jmx-debug application
Works for me. Could someone put together a detailed howto on hooking JConsole up to Geronimo and doing some typical things there? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain
Re: Remove jmx-debug application
jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector username: system password: manager Click on the tree to see mbeans... edit them on the right -dain On Apr 21, 2006, at 4:37 PM, Aaron Mulder wrote: Works for me. Could someone put together a detailed howto on hooking JConsole up to Geronimo and doing some typical things there? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain
Re: Remove jmx-debug application
OK, but what can you do with it? Just poke MBeans? Or can you set up charts of property values and alerts if certain thresholds are exceeded and so on? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector username: system password: manager Click on the tree to see mbeans... edit them on the right -dain On Apr 21, 2006, at 4:37 PM, Aaron Mulder wrote: Works for me. Could someone put together a detailed howto on hooking JConsole up to Geronimo and doing some typical things there? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain
Re: Remove jmx-debug application
The extent if my playing was to poke mbeans. I have no idea if it can graph data. If it can't maybe someone knows of a better one that can. -dain On Apr 21, 2006, at 4:52 PM, Aaron Mulder wrote: OK, but what can you do with it? Just poke MBeans? Or can you set up charts of property values and alerts if certain thresholds are exceeded and so on? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector username: system password: manager Click on the tree to see mbeans... edit them on the right -dain On Apr 21, 2006, at 4:37 PM, Aaron Mulder wrote: Works for me. Could someone put together a detailed howto on hooking JConsole up to Geronimo and doing some typical things there? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain
[jira] Commented: (GERONIMO-1891) Meaningless ERROR printed by attribute manager during redeploy
[ http://issues.apache.org/jira/browse/GERONIMO-1891?page=comments#action_12375658 ] Sachin Patel commented on GERONIMO-1891: I'm seeing this message when undeploying any application. Meaningless ERROR printed by attribute manager during redeploy -- Key: GERONIMO-1891 URL: http://issues.apache.org/jira/browse/GERONIMO-1891 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, kernel Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 When redeploying the console, the server always prints: ERROR [LocalAttributeManager] Trying to stop unknown configuration: geronimo/webconsole-jetty/1.1-SNAPSHOT/car There is no actual problem, however. Why does the attribute manager not know about the console configuration? It's listed in config.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Remove jmx-debug application
If no body started work on this JMX portlet I can start working on it. --- Dain Sundstrom [EMAIL PROTECTED] wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Closed: (GERONIMO-1866) Make the packaging plugin output to target/ then JAR that into the local repo
[ http://issues.apache.org/jira/browse/GERONIMO-1866?page=all ] David Jencks closed GERONIMO-1866: -- Resolution: Fixed step 2 in rev 396048 Make the packaging plugin output to target/ then JAR that into the local repo - Key: GERONIMO-1866 URL: http://issues.apache.org/jira/browse/GERONIMO-1866 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: Maven Plugins for G Versions: 1.0 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.1 It would help the Geronimo plugin process if I could insert an XML file into the CAR during CAR construction. It would help XML-based config stuff to review the contents of a CAR without needing to manually unpack it out of the local Maven repo after construction In both cases, it would be nice if the packaging plugin wrote to a directory under target/ and then separately JAR'd that into the local repository (with a hook to add some Jelly in between to copy in my XML file). It seems like this could be done by set up a repo in target, building directly into it in unpacked mode, and then packing/copying somehow into the real local repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Remove jmx-debug application
mc4j might work too, though it may need some updates to support 1.x, not sure: http://mc4j.org/ --jason On Apr 21, 2006, at 4:37 PM, Aaron Mulder wrote: Works for me. Could someone put together a detailed howto on hooking JConsole up to Geronimo and doing some typical things there? Thanks, Aaron On 4/21/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain
Re: Remove jmx-debug application
+1 --jason On Apr 21, 2006, at 4:13 PM, Dain Sundstrom wrote: I think we should completely remove the jmx-debug application. The application is very ugly and hard to us. Also doesn't allow you to execute simple operations like setAttribute or invoke, so it is really only useful for display purposes. Instead a user can connect to the server with jconsole in Java 5 or any of the other JMX consoles out there. For geronimo 1.2, I think we should look at integrating the new jmx console that was donted by Simon Godik in GERONIMO-1163 into the console as a portlet. This will also remove one of the biggest users of the deprecated ObjectName methods on the kernel. What do you think? -dain
Re: Verbiage: Change configuration to module?
+1, module is better. --jason On Apr 21, 2006, at 12:54 PM, Aaron Mulder wrote: All, How would you feel about referring to configurations (e.g. a group of GBeans with own ID and classloader) as a module instead? It seems like configuration can be confusing, as it more traditionally refers to a larger scope like an entire installation. For example, if you say you have two different WebLogic configurations or two different Apache (HTTP) configurations, you're saying either you have two installations, or you have two totally separate product configurations available for the same product installation. You're not saying you have an app and a database pool within one runtime, but that's what two different configurations presently would mean in relation to Geronimo. It seems like it would be clearer to say that a Geronimo installation loads many modules, and each module includes many components (GBeans). I'm not proposing that we go changing class names and stuff, but I'm proposing that we make a concerted effort in our documentation and presentations to present the name of the unit with an ID and classloader holding many components as a module. What do you think? Thanks, Aaron
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
CONGRATS Rick !!! Very well deserved Cheers! Hernan Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC
[jira] Created: (GERONIMO-1893) Corba failures on startup
Corba failures on startup - Key: GERONIMO-1893 URL: http://issues.apache.org/jira/browse/GERONIMO-1893 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Environment: 1.1 Reporter: Kevan Miller Priority: Critical Fix For: 1.1 If you enable Corba in an out-of-the-box config -- you'll receive the following exceptions: 23:07:59,456 ERROR [SunORBConfigAdapter] org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 209 completed: No 23:07:59,624 WARN [CORBABean] Failed CORBABean 23:07:59,628 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server org.openejb.corba.security.config.ConfigException: org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 209 completed: No at org.openejb.corba.sunorb.SunORBConfigAdapter.postProcess(SunORBConfigAdapter.java:211) at org.openejb.corba.CORBABean.doStart(CORBABean.java:160) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:980) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:539) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:389) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:350) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:168) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:483) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:464) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) 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
Cutting 1.4 Release (Re: [VOTE] Release Axis 1.4 final branch)
David, Thanks to Bjorn, i've update the docs as well in the AXIS_1_4_FINAL branch. AFAICT, you need to run dist and srcdist targets to generate the zips, then sign the release and upload them to /www/www.apache.org/dist/ws/axis/1_4. You will need to add your key to the KEYS [1] file as well. Please upload the new jars to the maven repo as well [2]. Glen, Please chime in if i missed something. thanks, dims [1] /www/www.apache.org/dist/ws/axis/KEYS on minotaur.apache.org [2] /www.apache.org/dist/java-repository/axis/jars/ on minotaur.apache.org On 4/21/06, David Blevins [EMAIL PROTECTED] wrote: Excellent. I'll hook up with you on IRC and see what else we need to do to button this up. Thanks, David On Apr 21, 2006, at 8:01 AM, Davanum Srinivas wrote: David, I've just run the saaj tck and jaxrpc tck (both standalone) on the branch mentioned below. All Green. Thanks, dims On 3/13/06, David Blevins [EMAIL PROTECTED] wrote: Dims created an Axis 1.4 final branch in early Dec at: http://svn.apache.org/repos/asf/webservices/axis/branches/ AXIS_1_4_FINAL There was a vote to release this that went through but the binaries were never produced. Geronimo, Jonas and others are using this code and it would be great to see it made official. I am volunteering as Release Manager and would like to kicked this release out the door before the month is through. Here is my +1 for me as Release Manager and seeing 1.4 released this month. -David -- Davanum Srinivas : http://wso2.com/blogs/ -- Davanum Srinivas : http://wso2.com/blogs/
