Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
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. At last! ;) Not that I couldn't manage the traffic of his patches, but it's much safer for Geronimo when his newest patches are applied once they're done. Keep'em coming, indeed! Welcome aboard Rick! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Closed: (GERONIMO-1307) JMX connector doesn't shut down cleanly
[ http://issues.apache.org/jira/browse/GERONIMO-1307?page=all ] Matt Hogstrom closed GERONIMO-1307: --- Resolution: Fixed Can't recreate > JMX connector doesn't shut down cleanly > --- > > Key: GERONIMO-1307 > URL: http://issues.apache.org/jira/browse/GERONIMO-1307 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment, eclipse-plugin, gbuild, general, installer, > JVM-compatibility, kernel, mail, management, naming, OpenEJB, sample apps, > security > Versions: 1.0 > Reporter: David Jencks > Assignee: Matt Hogstrom > Priority: Blocker > Fix For: 1.2 > > In the last day or two this stack trace has shown up on server shutdown: > 10:58:04,204 ERROR [GBeanInstance] Problem in doStop of > geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=GBean,name=JMXService > java.io.IOException: javax.naming.CommunicationException [Root exception is > java.rmi.NoSuchObjectException: no such object in table] > at mx4j.remote.resolver.rmi.Resolver.unbindServer(Resolver.java:279) > at > javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.java:172) > at > org.apache.geronimo.jmxremoting.JMXConnector.doStop(JMXConnector.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1079) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:395) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:200) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:213) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:192) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:213) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:192) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:213) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl$ShutdownHook.run(ConfigurationManagerImpl.java:277) > at > org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:406) > at > org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:383) > at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:272) > I think it appeared about the time Aaron changed the URI format for the jmx > deployer connection, but they might or might not be connected. -- 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-1278) Upgrade to XML Beans 2.1.0 from 2.0.0
[ http://issues.apache.org/jira/browse/GERONIMO-1278?page=all ] Matt Hogstrom closed GERONIMO-1278: --- Resolution: Fixed Will open a global package change JIRA for 1.2. > Upgrade to XML Beans 2.1.0 from 2.0.0 > - > > Key: GERONIMO-1278 > URL: http://issues.apache.org/jira/browse/GERONIMO-1278 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Versions: 1.0 > Reporter: Matt Hogstrom > Assignee: Matt Hogstrom > Fix For: 1.2 > > Get to a current version of XML Beans -- 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: (GBUILD-16) Improve GBuild agent JMS reconnect logic
[ http://issues.apache.org/jira/browse/GBUILD-16?page=all ] David Blevins closed GBUILD-16: --- Resolution: Fixed Assign To: David Blevins (was: Kevan Miller) The strategy is now: 1. Use ActiveMQ failover with exponential delay maxed at 30min 2. Retry every two hours there after up to four days The activemq maxDelay will be added to our reconnect times, so actually we have 5 days of tolerance. > Improve GBuild agent JMS reconnect logic > > > Key: GBUILD-16 > URL: http://issues.apache.org/jira/browse/GBUILD-16 > Project: GBuild > Type: Bug > Components: agent > Versions: 1.0.0 > Reporter: Kevan Miller > Assignee: David Blevins > Priority: Minor > > The gbuild agent reconnect logic has several problems. > User configuration settings for reconnect processing are ignored. Max retries > and delay time are all hard-coded. > If the initial connection fails, it seems that the client will never connect. > Also, we should be able to configure agents to attempt to reconnect forever. > There should be some retry backoff scheme or bimodal reconnect interval... > I seem to recall that ActiveMQ has similar features in their client api. It > might be simpler to remove what GBuild currently does and use the built-in > ActiveMQ support... > -- 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
Build Broken after change r396767
I did an SVN update and started getting the error below when building the configs. Aaron, it looks like it has something to do with your plan change in r396767. Here is the error: + | configurations ActiveMQ broker configuration | Memory: 37M/64M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download system-database-1.1-SNAPSHOT.car. Attempting to download activemq-gbean-g1_1-3.2.4-SNAPSHOT.jar. Attempting to download activemq-gbean-management-g1_1-3.2.4-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for ActiveMQ broker configuration car:prepare-plan: car:package: [delete] Deleting directory /home/hogstrom/geronimo/branches/1.1/configs/activemq-broker/target/repository [mkdir] Created dir: /home/hogstrom/geronimo/branches/1.1/configs/activemq-broker/target/repository Packaging configuration /home/hogstrom/geronimo/branches/1.1/configs/activemq-broker/target/plan/plan.xml 19173 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: No reference named JMSManager in gbean geronimo/activemq-broker/1.1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ org.apache.geronimo.common.DeploymentException: No reference named JMSManager in gbean geronimo/activemq-broker/1.1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ at org.apache.geronimo.deployment.service.GBeanBuilder.buildAbstractNameQuery(GBeanBuilder.java:153) at org.apache.geronimo.deployment.service.GBeanBuilder.setReference(GBeanBuilder.java:128) at org.apache.geronimo.deployment.service.GBeanBuilder.setReference(GBeanBuilder.java:122) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:267) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:231) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:218) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:182) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke() 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$$1d68ee16.buildConfiguration() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:301) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() 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:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:430) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:294) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:251) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.d
[jira] Resolved: (GERONIMO-1752) JMS Server portlet - Edits to JMS Network Listener are lost upon server restart
[ http://issues.apache.org/jira/browse/GERONIMO-1752?page=all ] Aaron Mulder resolved GERONIMO-1752: Fix Version: 1.1 (was: 1.2) Resolution: Fixed Assign To: Aaron Mulder I think the recent fix to ActiveMQ should have fixed this, but it still needs testing. > JMS Server portlet - Edits to JMS Network Listener are lost upon server > restart > --- > > Key: GERONIMO-1752 > URL: http://issues.apache.org/jira/browse/GERONIMO-1752 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.2 > Environment: Win Xp, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Assignee: Aaron Mulder > Fix For: 1.1 > > Edits to JMS Network Listeners through JMS Server portlet are lost upon > server restart. > Steps to reproduce this issue: > 1. Under Console Navigation, click on "JMS Server" link. > 2. Click on "edit" link provided against any JMS Network Listener. > 3. Modify host, port and click "Save" > 4. Restart the server and access JMS Server portlet again. Changes done in > step 3 are lost. -- 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] Resolved: (GERONIMO-1179) Update ActiveMQ Manager for Adding/Removing Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-1179?page=all ] Aaron Mulder resolved GERONIMO-1179: Fix Version: 1.1 (was: 1.x) Resolution: Fixed > Update ActiveMQ Manager for Adding/Removing Connectors > -- > > Key: GERONIMO-1179 > URL: http://issues.apache.org/jira/browse/GERONIMO-1179 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: management, kernel, ActiveMQ > Versions: 1.0-M5 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > Prerequisite: a fresh set of Geronimo JARs in the Maven repo, so independent > ActiveMQ builds see the latest Geronimo code. > Model this afrter the EditableConfigurationManager blocks in JettyManagerImpl > and TomcatManagerImpl. > Consider making the ActiveMQManager implement J2EEManagedObject while in > there, as this may be coming down the road. -- 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] Resolved: (GERONIMO-1773) Automatic driver download is duplicated
[ http://issues.apache.org/jira/browse/GERONIMO-1773?page=all ] Aaron Mulder resolved GERONIMO-1773: Fix Version: 1.1 Resolution: Fixed Assign To: Aaron Mulder Now goes to an AJAX wait page, so the page load isn't waiting on the download to complete. > Automatic driver download is duplicated > --- > > Key: GERONIMO-1773 > URL: http://issues.apache.org/jira/browse/GERONIMO-1773 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.0 > Reporter: Yiannis Mavroukakis > Assignee: Aaron Mulder > Priority: Trivial > Fix For: 1.1 > > If the page times out during the download and is refreshed, a second download > is initiated. This doesn't impact the installation of the driver. -- 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: org.apache.geronimo.feature.source feature and plug-in
It is helpful to confirm! Thanks Sachin. -Original Message- From: Sachin Patel [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 4:18 PM To: dev@geronimo.apache.org Subject: Re: org.apache.geronimo.feature.source feature and plug-in The source feature and plugins provide no function, so removing that will have no impact. The purpose of them is to package the source of all the plugins and they are wrapped inside their own plugin to integrate nicely with the PDE. - sachin On Apr 24, 2006, at 4:04 PM, Lin Sun wrote: > Hi Sachin, > > What is the use of this > features\org.apache.geronimo.source.feature_1.0.0 feature and its > associated plugins\org.apache.geronimo.feature.source_1.0.0 plug-in? > It looks a dummy test feature and plug-in to me. I removed them off > my eclipse home directory and everything worked fine from my limited > testing. Could you please advise? > > Thanks, Lin
[jira] Reopened: (GERONIMO-1333) [Daytrader] ejb module should not depend on wsappclient module
[ http://issues.apache.org/jira/browse/GERONIMO-1333?page=all ] Matt Hogstrom reopened GERONIMO-1333: - Oops...meant to comment and update...my bad. > [Daytrader] ejb module should not depend on wsappclient module > -- > > Key: GERONIMO-1333 > URL: http://issues.apache.org/jira/browse/GERONIMO-1333 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: sample apps > Versions: 1.0-M5 > Reporter: Vincent Massol > Assignee: Matt Hogstrom > Fix For: 1.1 > > There is dependency on the wsappclient jar in the ejb module. That doesn't > look right. Does it mean the wsappclient should be split into 2 modules? I > haven't investigated more but it smells like a circular depdency somewhere. -- 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-1333) [Daytrader] ejb module should not depend on wsappclient module
[ http://issues.apache.org/jira/browse/GERONIMO-1333?page=all ] Matt Hogstrom closed GERONIMO-1333: --- Fix Version: 1.1 (was: 1.2) Resolution: Fixed This is being addressed in version 1.2. > [Daytrader] ejb module should not depend on wsappclient module > -- > > Key: GERONIMO-1333 > URL: http://issues.apache.org/jira/browse/GERONIMO-1333 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: sample apps > Versions: 1.0-M5 > Reporter: Vincent Massol > Assignee: Matt Hogstrom > Fix For: 1.1 > > There is dependency on the wsappclient jar in the ejb module. That doesn't > look right. Does it mean the wsappclient should be split into 2 modules? I > haven't investigated more but it smells like a circular depdency somewhere. -- 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
DayTrader Update - 1.1 Release coming up
I am in the process of moving DayTrader out of the 1.1 Geronimo branch. Since this is a performance and J2EE sample I expect we'll be releasing it independently of Geronimo. Here are a few things to know so far. 1. You can checkout DayTrader at svn co http://svn.apache.org/repos/asf/geronimo/daytrader It is built nightly on the GBuild setup (thanks Mr. Blevins) 2. The only remaining modules left in the Geronimo tree is the database which I'll have converted to M2 this week. When that is complete DayTrader will be built completely on its own and will simply become a dependency that can be included if desired. (Vincent, if your interested in this piece I'll take your patches :) 3. DayTrader includes deployment descriptors for both Geronimo and JBoss. I have not been able to get JBoss working yet with messaging yet so please do not consider these artifacts the best performing ones. For the JBoss lurkers on our list, take a look and let me know if they can be improved; we know your out there ;-P I'm happy to accept donations for DD's and deployment instructions for other AppServers. 4. 1.1 will be versioned this week or early next week. This will be the basis for performance comparisons. SNAPSHOT versions are not comparable as changes in the project can affect performance results. 5. I'll be adding a performance section to the WebSite this week so we can answer the FAQs about Geronimo and performance. 6. I'm looking to get DayTrader into shape so it can be installed from the Geronimo Plugins site. This will make installing the sample easier and also reduce our download and startup time for the Geronimo distributions for 1.1. DayTrader Futures * Someone is looking at providing a Spring / JDBC function that will extend the modes of operation of DayTrader. There may be some work on EJBs as well. * Stan Cox from IBM indicated that he wanted to include some modifications to the benchmark to include AJAX primitives and functionality. Hopefully Stan will have some information soon to share on his recent exploits. * We need to upgrade the benchmark to provide a more flexible deployemnt. Right now all the modules are inter-related to some degree and have too strong of a dependency on each other. I want to break the benchmark up in a way that you can deploy only the WebComponents if you want (Tomcat / Jetty testing) and that kind of thing. * JEE 5 improvements to exercise EJB 3.0 and the new persistence API. OpenJPA will get engaged soon I hope so we should be ready for them. If you are working on something or have some interesting information to share, send it in. Cheers. Matt
[jira] Created: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed
Deploy command should redeploy if the app is already deployed - Key: GERONIMO-1907 URL: http://issues.apache.org/jira/browse/GERONIMO-1907 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: deployment, usability Versions: 1.1 Reporter: Aaron Mulder Assigned to: Aaron Mulder Fix For: 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
[jira] Updated: (GERONIMO-1802) Console breakage in 1.1 branch
[ http://issues.apache.org/jira/browse/GERONIMO-1802?page=all ] Paul McMahan updated GERONIMO-1802: --- Description: [This pass made on 4/24/2006] Welcome: OK Server/Information: OK Server/JVM: OK Server/Server Logs: OK Server/Shutdown: OK Server/Web Server: BROKEN - trying to stop a listener fails - unstable No stacktraces but frequently shows: [ConnectorPortlet] Incorrect connector reference Server/JMS Server: patch provided, also see GERONIMO-1906 Services/Common Libraries: OK Services/Database Pools: BROKEN Trying to deploy a db pool yields: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:970) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:333) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) Services/JMS Resources: BROKEN Trying to deploy a JMS resource yields: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(AbstractHandler.java:633) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBeforeView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) Applications/Deploy New: OK Applications/Application EARs: OK Applications/Web Apps: OK Applications/EJB JARS: looks OK but not thoroughly tested yet Applications/J2EE Connectors: OK Applications/App Clients: looks OK but not thoroughly tested yet Applications/System Modules: OK Applications/Plugins: OK Security/Console Realm: OK Security/Security Realm: BROKEN Fails when saving plan with exception: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.actionSaveRealm(SecurityRealmPortlet.java:470) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.processAction(SecurityRealmPortlet.java:215) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)DB Info: shows table but with no values. Log says: Security/Keystores: OK Misc/DB Info: BROKEN java.sql.SQLException Misc/DB Manager: OK was: 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.gero
[jira] Assigned: (GERONIMO-1904) Precompile JSPs for all apps by default
[ http://issues.apache.org/jira/browse/GERONIMO-1904?page=all ] Prasad Kashyap reassigned GERONIMO-1904: Assign To: Dain Sundstrom (was: Prasad Kashyap) > Precompile JSPs for all apps by default > --- > > Key: GERONIMO-1904 > URL: http://issues.apache.org/jira/browse/GERONIMO-1904 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Dain Sundstrom > Fix For: 1.1 > Attachments: jsp-precompile-apply-me.patch, jsp-precompile_for_all.patch > > Here's a patch that will precompile jsps for all apps by default. > This patch also removes the jasper jars (compiler and runtime) from being > bundled with the console. These jars exist in the repo anyways. Paul verified > that the console runs successfully without these. Moreover these 2 jars were > being bundled in 2 war modules, console-standard and console-framework. We > should be able to get rid of close to 2MB of redundant jars. > http://www.mail-archive.com/dev@geronimo.apache.org/msg20940.html -- 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-1904) Precompile JSPs for all apps by default
[ http://issues.apache.org/jira/browse/GERONIMO-1904?page=all ] Prasad Kashyap updated GERONIMO-1904: - Attachment: jsp-precompile-apply-me.patch Please use the jsp-precompile-apply-me.patch > Precompile JSPs for all apps by default > --- > > Key: GERONIMO-1904 > URL: http://issues.apache.org/jira/browse/GERONIMO-1904 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Prasad Kashyap > Fix For: 1.1 > Attachments: jsp-precompile-apply-me.patch, jsp-precompile_for_all.patch > > Here's a patch that will precompile jsps for all apps by default. > This patch also removes the jasper jars (compiler and runtime) from being > bundled with the console. These jars exist in the repo anyways. Paul verified > that the console runs successfully without these. Moreover these 2 jars were > being bundled in 2 war modules, console-standard and console-framework. We > should be able to get rid of close to 2MB of redundant jars. > http://www.mail-archive.com/dev@geronimo.apache.org/msg20940.html -- 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-1802) Console breakage in 1.1 branch
[ http://issues.apache.org/jira/browse/GERONIMO-1802?page=all ] Paul McMahan updated GERONIMO-1802: --- Attachment: jmsserver.patch Attaching patch for JMS server portlet (jmsserver.patch). GERONIMO-1906 will need to be resolved before new connectors can be created using the portlet. > 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, jmsserver.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.(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.(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.(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.g
[jira] Created: (GERONIMO-1906) Cannot add a new connector using ActiveMQManagerGBean
Cannot add a new connector using ActiveMQManagerGBean - Key: GERONIMO-1906 URL: http://issues.apache.org/jira/browse/GERONIMO-1906 Project: Geronimo Type: Bug Security: public (Regular issues) Components: ActiveMQ Versions: 1.1 Environment: Geronimo 1.1 build, rev 396619; activemq_version=3.2.4-SNAPSHOT Reporter: Paul McMahan Calling this API: myJMSManager.addConnector( myJMSBroker, name, protocol, host, port ); Produces the following ST: java.lang.AssertionError: javax.management.MalformedObjectNameException: Invalid value: geronimo/activemq-broker/1.1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ.activeio.0.0.0.0.61616-test at org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:98) at org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:66) at org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54) at org.activemq.gbean.management.ActiveMQManagerGBean.addConnector(ActiveMQManagerGBean.java:179) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.invoke() 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.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$2bdd185c.addConnector() at org.apache.geronimo.console.util.PortletManager.createJMSConnector(PortletManager.java:274) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 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) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) 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 javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:336) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catali
Re: org.apache.geronimo.feature.source feature and plug-in
The source feature and plugins provide no function, so removing that will have no impact. The purpose of them is to package the source of all the plugins and they are wrapped inside their own plugin to integrate nicely with the PDE. - sachin On Apr 24, 2006, at 4:04 PM, Lin Sun wrote: Hi Sachin, What is the use of this features\org.apache.geronimo.source.feature_1.0.0 feature and its associated plugins\org.apache.geronimo.feature.source_1.0.0 plug-in? It looks a dummy test feature and plug-in to me. I removed them off my eclipse home directory and everything worked fine from my limited testing. Could you please advise? Thanks, Lin
org.apache.geronimo.feature.source feature and plug-in
Hi Sachin, What is the use of this features\org.apache.geronimo.source.feature_1.0.0 feature and its associated plugins\org.apache.geronimo.feature.source_1.0.0 plug-in? It looks a dummy test feature and plug-in to me. I removed them off my eclipse home directory and everything worked fine from my limited testing. Could you please advise? Thanks, Lin
[jira] Created: (GERONIMO-1905) Confirm deploy/undeploy/redeploy for WARs with no configId
Confirm deploy/undeploy/redeploy for WARs with no configId -- Key: GERONIMO-1905 URL: http://issues.apache.org/jira/browse/GERONIMO-1905 Project: Geronimo Type: Test Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.1 Make sure it all works for WAR with no geronimo-web.xml and also WAR with geronimo-web.xml with environment with no configId. Reports seem to indicate that it doesn't work right now. -- 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] Assigned: (GERONIMO-1903) Add Spring to default class ignore list
[ http://issues.apache.org/jira/browse/GERONIMO-1903?page=all ] Jeff Genender reassigned GERONIMO-1903: --- Assign To: Jeff Genender > Add Spring to default class ignore list > --- > > Key: GERONIMO-1903 > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: web > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1 > > It's pretty dumb that anyone deploying a Spring app has to manually add > classloader excludes to their Geronimo plan. We should support Spring out of > the box. Which until we improve our CL structure means that we need to add > default excludes for Spring itself plus potentially any libraries commonly > shared between Spring/Acegi/etc. and Geronimo. > I guess we need a test app for this. -- 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: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
If you can do it today that would be great. Thanks, Aaron On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > Aaron, > > Ok..I agree...lets filter antlr and Spring for 1.1 and fix the > classloaders post 1.1. Do you want to take this one (filter) or should > I? If you don't think you can get to it today, I am happy to put in the > filters. > > Jeff > > Aaron Mulder wrote: > > I don't think the class loaders are fixable for 1.1, whereas the > > exclude list is. > > > > Dain and David J have some ideas for how to fix the classloaders to > > separate apps from server internals, which I'd like to do shortly post > > 1.1. I think there's a separate JIRA for that. > > > > Are there other things we know of beyond Spring, Commons Logging, Antlr? > > > > Thanks, > > Aaron > > > > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> This goes beyond Spring (and Commons Logging). It affects antlr too > >> when using Hibernate. I am sure there are a plethora of other > >> jar/packages this will affect too. > >> > >> Should we take a closer look at our classloaders and figure out why we > >> need to do this? > >> > >> Jeff > >> > >> Aaron Mulder (JIRA) wrote: > >>> Add Spring to default class ignore list > >>> --- > >>> > >>> Key: GERONIMO-1903 > >>> URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > >>> Project: Geronimo > >>> Type: Bug > >>> Security: public (Regular issues) > >>> Components: web > >>> Versions: 1.1 > >>> Reporter: Aaron Mulder > >>> Priority: Blocker > >>> Fix For: 1.1 > >>> > >>> > >>> It's pretty dumb that anyone deploying a Spring app has to manually add > >>> classloader excludes to their Geronimo plan. We should support Spring > >>> out of the box. Which until we improve our CL structure means that we > >>> need to add default excludes for Spring itself plus potentially any > >>> libraries commonly shared between Spring/Acegi/etc. and Geronimo. > >>> > >>> I guess we need a test app for this. > >>> >
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Welcome :-) --jason 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 >
[jira] Assigned: (GERONIMO-1904) Precompile JSPs for all apps by default
[ http://issues.apache.org/jira/browse/GERONIMO-1904?page=all ] Prasad Kashyap reassigned GERONIMO-1904: Assign To: Prasad Kashyap (was: Dain Sundstrom) > Precompile JSPs for all apps by default > --- > > Key: GERONIMO-1904 > URL: http://issues.apache.org/jira/browse/GERONIMO-1904 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Prasad Kashyap > Fix For: 1.1 > Attachments: jsp-precompile_for_all.patch > > Here's a patch that will precompile jsps for all apps by default. > This patch also removes the jasper jars (compiler and runtime) from being > bundled with the console. These jars exist in the repo anyways. Paul verified > that the console runs successfully without these. Moreover these 2 jars were > being bundled in 2 war modules, console-standard and console-framework. We > should be able to get rid of close to 2MB of redundant jars. > http://www.mail-archive.com/dev@geronimo.apache.org/msg20940.html -- 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: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
Aaron, Ok..I agree...lets filter antlr and Spring for 1.1 and fix the classloaders post 1.1. Do you want to take this one (filter) or should I? If you don't think you can get to it today, I am happy to put in the filters. Jeff Aaron Mulder wrote: > I don't think the class loaders are fixable for 1.1, whereas the > exclude list is. > > Dain and David J have some ideas for how to fix the classloaders to > separate apps from server internals, which I'd like to do shortly post > 1.1. I think there's a separate JIRA for that. > > Are there other things we know of beyond Spring, Commons Logging, Antlr? > > Thanks, > Aaron > > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> This goes beyond Spring (and Commons Logging). It affects antlr too >> when using Hibernate. I am sure there are a plethora of other >> jar/packages this will affect too. >> >> Should we take a closer look at our classloaders and figure out why we >> need to do this? >> >> Jeff >> >> Aaron Mulder (JIRA) wrote: >>> Add Spring to default class ignore list >>> --- >>> >>> Key: GERONIMO-1903 >>> URL: http://issues.apache.org/jira/browse/GERONIMO-1903 >>> Project: Geronimo >>> Type: Bug >>> Security: public (Regular issues) >>> Components: web >>> Versions: 1.1 >>> Reporter: Aaron Mulder >>> Priority: Blocker >>> Fix For: 1.1 >>> >>> >>> It's pretty dumb that anyone deploying a Spring app has to manually add >>> classloader excludes to their Geronimo plan. We should support Spring out >>> of the box. Which until we improve our CL structure means that we need to >>> add default excludes for Spring itself plus potentially any libraries >>> commonly shared between Spring/Acegi/etc. and Geronimo. >>> >>> I guess we need a test app for this. >>>
[jira] Updated: (GERONIMO-1904) Precompile JSPs for all apps by default
[ http://issues.apache.org/jira/browse/GERONIMO-1904?page=all ] Prasad Kashyap updated GERONIMO-1904: - Attachment: jsp-precompile_for_all.patch > Precompile JSPs for all apps by default > --- > > Key: GERONIMO-1904 > URL: http://issues.apache.org/jira/browse/GERONIMO-1904 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Dain Sundstrom > Fix For: 1.1 > Attachments: jsp-precompile_for_all.patch > > Here's a patch that will precompile jsps for all apps by default. > This patch also removes the jasper jars (compiler and runtime) from being > bundled with the console. These jars exist in the repo anyways. Paul verified > that the console runs successfully without these. Moreover these 2 jars were > being bundled in 2 war modules, console-standard and console-framework. We > should be able to get rid of close to 2MB of redundant jars. > http://www.mail-archive.com/dev@geronimo.apache.org/msg20940.html -- 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: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
I don't think the class loaders are fixable for 1.1, whereas the exclude list is. Dain and David J have some ideas for how to fix the classloaders to separate apps from server internals, which I'd like to do shortly post 1.1. I think there's a separate JIRA for that. Are there other things we know of beyond Spring, Commons Logging, Antlr? Thanks, Aaron On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > This goes beyond Spring (and Commons Logging). It affects antlr too > when using Hibernate. I am sure there are a plethora of other > jar/packages this will affect too. > > Should we take a closer look at our classloaders and figure out why we > need to do this? > > Jeff > > Aaron Mulder (JIRA) wrote: > > Add Spring to default class ignore list > > --- > > > > Key: GERONIMO-1903 > > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > > Project: Geronimo > > Type: Bug > > Security: public (Regular issues) > > Components: web > > Versions: 1.1 > > Reporter: Aaron Mulder > > Priority: Blocker > > Fix For: 1.1 > > > > > > It's pretty dumb that anyone deploying a Spring app has to manually add > > classloader excludes to their Geronimo plan. We should support Spring out > > of the box. Which until we improve our CL structure means that we need to > > add default excludes for Spring itself plus potentially any libraries > > commonly shared between Spring/Acegi/etc. and Geronimo. > > > > I guess we need a test app for this. > > >
[jira] Created: (GERONIMO-1904) Precompile JSPs for all apps by default
Precompile JSPs for all apps by default --- Key: GERONIMO-1904 URL: http://issues.apache.org/jira/browse/GERONIMO-1904 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Reporter: Prasad Kashyap Assigned to: Dain Sundstrom Fix For: 1.1 Here's a patch that will precompile jsps for all apps by default. This patch also removes the jasper jars (compiler and runtime) from being bundled with the console. These jars exist in the repo anyways. Paul verified that the console runs successfully without these. Moreover these 2 jars were being bundled in 2 war modules, console-standard and console-framework. We should be able to get rid of close to 2MB of redundant jars. http://www.mail-archive.com/dev@geronimo.apache.org/msg20940.html -- 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: [jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
This goes beyond Spring (and Commons Logging). It affects antlr too when using Hibernate. I am sure there are a plethora of other jar/packages this will affect too. Should we take a closer look at our classloaders and figure out why we need to do this? Jeff Aaron Mulder (JIRA) wrote: > Add Spring to default class ignore list > --- > > Key: GERONIMO-1903 > URL: http://issues.apache.org/jira/browse/GERONIMO-1903 > Project: Geronimo > Type: Bug > Security: public (Regular issues) > Components: web > Versions: 1.1 > Reporter: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > > > It's pretty dumb that anyone deploying a Spring app has to manually add > classloader excludes to their Geronimo plan. We should support Spring out of > the box. Which until we improve our CL structure means that we need to add > default excludes for Spring itself plus potentially any libraries commonly > shared between Spring/Acegi/etc. and Geronimo. > > I guess we need a test app for this. >
[jira] Created: (GERONIMO-1903) Add Spring to default class ignore list
Add Spring to default class ignore list --- Key: GERONIMO-1903 URL: http://issues.apache.org/jira/browse/GERONIMO-1903 Project: Geronimo Type: Bug Security: public (Regular issues) Components: web Versions: 1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 It's pretty dumb that anyone deploying a Spring app has to manually add classloader excludes to their Geronimo plan. We should support Spring out of the box. Which until we improve our CL structure means that we need to add default excludes for Spring itself plus potentially any libraries commonly shared between Spring/Acegi/etc. and Geronimo. I guess we need a test app for this. -- 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: Error starting j2ee-corba configuration !
Prasad, Yes. FYI -- http://issues.apache.org/jira/browse/GERONIMO-1893 Waiting to be worked on... ;-) --kevan On Apr 24, 2006, at 1:24 PM, Prasad Kashyap wrote: I believe there is a defect with our j2ee-corba configuration. I don't think it has been tested by starting it. I came across it when trying to start a plan that depends on the j2ee-corba. It tried to start j2ee-corba and spat out a bunch of errors like -- (See attached logs for full stacktrace) Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration geronimo/j2ee-corba/1.1-SNAPSHOT/car failed to start due to the following reasons: The service ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/ car,j2eeType=CORBATSS,name=SSLClientCert did not start because geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee- corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server did not start. The service ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/ car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity did not start because geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee- corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=UnprotectedServer did not start. The service ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/ car,j2eeType=CORBATSS,name=SSLClientCertIdentityToken did not start because geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee- corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server did not start. The service ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/ car,j2eeType=CORBABean,name=Server did not start because the doStart method threw an exception. Has anybody else tried starting the j2ee-corba ? Cheers Prasad
[jira] Commented: (GERONIMO-1884) Samples not installed properly in G1.1 - several issues
[ http://issues.apache.org/jira/browse/GERONIMO-1884?page=comments#action_12376064 ] Dave Colasurdo commented on GERONIMO-1884: -- Thanks Aaron!! The servlet and jsp examples seem to install and start fine with the latest build.. A few comments: - Is it possible to suppress the missing web containers examples (e.g. suppress jetty examples in the tomcat distribution and vice versa). There presence seems awkward.. - There seems to be a mismatch in terminology.. Title reads import/export configurations.. the details talk about installing a plugin.. - The Ldap example is missing from the list. - It would be nice if there were a few words documenting how to uninstall the config/plugin. Perhaps just a simple statement "imported configurations can be removed by uninstalling the appropriate application" It wasn't clear to me at first if the term "plugin" implied some uninstall step beyond a simple application uninstall. Thanks -Dave- > 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 > Fix For: 1.1 > > 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.(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.ja
Error starting j2ee-corba configuration !
I believe there is a defect with our j2ee-corba configuration. I don't
think it has been tested by starting it. I came across it when trying
to start a plan that depends on the j2ee-corba. It tried to start
j2ee-corba and spat out a bunch of errors like -- (See attached logs
for full stacktrace)
Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration geronimo/j2ee-corba/1.1-SNAPSHOT/car failed to start due
to the following reasons:
The service
ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBATSS,name=SSLClientCert
did not start because
geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server
did not start.
The service
ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
did not start because
geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=UnprotectedServer
did not start.
The service
ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBATSS,name=SSLClientCertIdentityToken
did not start because
geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server
did not start.
The service
ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server
did not start because the doStart method threw an exception.
Has anybody else tried starting the j2ee-corba ?
Cheers
Prasad
j2ee-corba-start.log
Description: Binary data
http://geronimo.apache.org/xml/ns/deployment-1.1";>
openejb
security
${openejb_version}
car
geronimo
system-database
${geronimo_version}
car
activeio
activeio
${activeio_version}
geronimo
geronimo-security
${geronimo_version}
geronimo
j2ee-security
${geronimo_version}
car
geronimo
j2ee-corba
${geronimo_version}
car
public-properties-realm
ServerInfo
JaasLoginService
http://geronimo.apache.org/xml/ns/loginconfig-1.1";>
public-login
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
var/security/public_users.properties
var/security/public_groups.properties
public
public-properties-realm
JaasLoginService
black-properties-realm
ServerInfo
JaasLoginService
http://geronimo.apache.org/xml/ns/loginconfig-1.1";>
black-login
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
var/security/black_users.properties
var/security/black_groups.properties
black
black-properties-realm
JaasLoginService
org/openejb/POA
Server
http://www.openejb.org/xml/ns/corba-tss-config-2.0"/>
DefaultThreadPool
TransactionContextManager
org.openejb.corba.sunorb.SunORBConfigAdapter
IOR7
http://www.openejb.org/xml/ns/corba-css-config-2.0";>
Integrity Confidentiality EstablishTrustInTarget EstablishTrustInClient
Integrity Confidentiality EstablishTrustInTarget
Re: Directory Update (Jeff?)
Aaron Mulder wrote: I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. Ya all including RC1 should be in the M2 repo if not let me know. Alex Thanks, Aaron On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Alex, Can you get the jars in ibiblio and I can get the integration going? I am only seeing 0.9.2 in ibiblio at the moment. Thanks, Jeff Alex Karasulu wrote: Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex
RE: Final fields serialization mechanism in Geronimo Corba RMI IIOP implementation
Thank you for information! I'll try to use Geronimo 1.1 for the problem solution. Nellya Udovichenko, Intel Middleware Products Division. -Original Message- From: Rick McGuire [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 2:14 PM To: dev@geronimo.apache.org Subject: Re: Final fields serialization mechanism in Geronimo Corba RMI IIOP implementation Udovichenko, Nellya wrote: > > Hello! > > My JDK version is Sun JDK 1.5. When I use Geronimo Corba RMI IIOP > implementation > > class org.apache.geronimo.interop.rmi.iiop.FinalFieldSetter throws > RuntimeException > > because the implementation of FinalFieldSetter interface cannot be found > > if JDK version differs 1.4. > I'm not sure what you're doing that uses this code, but the code in the org.apache.geronimo.interop package is obsolete and not even in use by Geronimo. In fact, we deleted this package this package from the current builds because the Yoko project is going to be filling the space that the interop code once attempted to fill. Rick > I have found that there is a class > org.apache.geronimo.interop.util.SystemUtil which chooses > > the adapter according to the current JDK version. This adapter is used > for FinalFieldSetter. > > The bug is also reproducible on BEA JRockit 1.4.2_04/1.5.0. > > Therefore, some questions appear: > > 1) What do you think it needs to be done if JDK version differs from 1.4? > > 2) Why JDK version is obtained from 'java.vm.version' parameter rather > than 'java.specification.version'? > > Can we avoid using of the adapter? > > 3) Сlass sun.misc.Unsafe in FinalFieldSetterJDK1.4 is used for object > recreation without > > invoking a constructor. Can we use default serialization mechanism > instead? > > I have also found reference to the bug in Sun JDK > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6379948 > > Does anyone have any ideas? > > Thanks, Nellya Udovichenko, > > Intel Middleware Products Division >
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congratulations Rick! It's very well deserved. thanks david jencks On Apr 21, 2006, at 11:59 AM, 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
download dependencies problem
hello,
I have installed servicemix-2.0.2 and i have tried to use it with maven
1.0.2;
at the end of maven process ('maven -Dmaven.test.skip=true' command), this
is the output message:
BUILD FAILED
File.. D:\Documents and
Settings\calcagno\.maven\cache\maven-multiproject-pl
ugin-1.3.1\plugin.jelly
Element... maven:reactor
Line.. 217
Column 9
La build non puo' continuare perche' non sono state soddisfatte le seguenti
dipendenze:
saaj-api-20050915.jar
saaj-impl-20050915.jar
wsif-2.0.1_IB3.jar
wsif-j2c-2.0.1_IB3.jar
jsr-223-1.0-pr.jar (try downloading from
http://www.jcp.org/en/jsr/detail?id=223
)
oraclexsql.jar
xmlparserv2.jar
xsu12.jar
ojdbc14.jar
and I not find these jar file (to add in 'project.property' fiel at the line
'maven.repo.remote', is this ok???).
can you help me???
Thank's you
--
View this message in context:
http://www.nabble.com/download-dependencies-problem-t1499526.html#a4064564
Sent from the ServiceMix - Dev forum at Nabble.com.
RE: Build failed
Hi, What JDK do you work on? It looks like internal Sun class com.sun.security.auth.login.ConfigFile isn’t included in your JDK library. This problem could occur if you have used non-Sun JDK. See Geronimo JIRA reference on patch for org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest. http://issues.apache.org/jira/browse/GERONIMO-1832 Thanks, Nellya Udovichenko, Intel Middleware Products Division. From: Rajith Attapattu [mailto:[EMAIL PROTECTED] Sent: Saturday, April 22, 2006 2:28 AM To: dev@geronimo.apache.org Subject: 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 exist import com.sun.security.auth.login.ConfigFile ; ^ /opt/workspace/geronimo/modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:209: cannot resolve symbol symbol : class ConfigFile location: class org.apache.geronimo.security.network.protocol.SubjectCarryingProtocolTest Configuration.setConfiguration(new ConfigFile()); ^ 2 errors Regards, Rajith
1.1 - Development Freeze begins - Time to test, test, test
All, We've reached the code freeze time for 1.1. In order to get a respectable release out soon we'll need to focus on bug fixes, testing, deploying and running the server. All changes should be checked in already. In my opinion, people are waiting for 1.1 and expecting a reliable, solid server. Solid from the perspective that it runs reliably and consistently. I expect the nice folks over at the other Open Source AppServer projects are waiting to see how we do. Let's show everyone that we're on a track for success. Here is the major tasks we need to focus on: 1. Testing Includes the all consolelinks, deployment from console, command line deployment, DayTrader in all modes of operation, performance, stress, etc. This is the most important aspect of getting 1.1 to be solid. 2. CTS Testing Certainly a limited number of folks can work on this but whoever has some extra capacity talk to Kevan and I'm sure he'll have stuff to do. 3. Documentation We've made several changes to the server in terms of the configIds. Let's make sure we accurately communicate the changes in the release notes for our users. 4. Focus Let's stay focused on 1.1. We've only got a few more weeks to go before our release goes live. 5. Package Upgrades As soon as we have a successful set of tests we'll upgrade the appropriate packages and cut releases of ActiveMQ, TranQL and OpenEJB. We're almost there guys. Matt
Re: Apache Geronimo Principles & Goals
Aaron, I agree with the general outline below. I mentioned in one of the 1.1 posts that in order to be competitive it would benefit the project to define some goals around the releases. I think the principles below help to provide the framework for prioritization of goals. I'd like to take your thoughts below along with representations of the scenarios we want to be effective. I have a set of charts I noodled on about a month or two ago that shows graphically how Geronimo can be deployed. I'll look to get those out on the website and get people's feedback on them. I think this will help as well. Aaron Mulder wrote: All, Here's a little something I've been assembling to help as we move past certification and look for what's next. I'd like to post this (or something like it) to the web site, ideally for the 1.1 release so it'll be there for people wondering (at a high level) where we're going from here. Thanks, Aaron Apache Geronimo Principles & Goals === Principles === * Be competitive with other application servers * Be flexible to include exactly what a user wants (lightweight, heavyweight, product integration, customized admin tools, etc.). Make it easy to get there from the initial download. * Be the IntelliJ of app servers (it thinks like you do, works like you expect, etc.) -- alternately, be the OS X of app servers (easy to use and even the hard stuff "just works") === Goals === Flexibility --- Geronimo should meet anyone's needs from very lightweight to very heavyweight. Generally, the distribution option should be: 1) Minimal -- kernel and command-line/script administration tools only 2) Web -- web container and web admin tools 3) J2EE -- certified J2EE stack with web admin tools The included tools must make it extremely easy to download and install additional features (e.g. plugins) to add on to the basic distribution. And, of course, anyone is free to create more comprehensive distributions by bundling plugins and distributing the resulting package. It should be possible to get an app running and then have "1-click" options to strip down the server to only what that application requires. It should also be possible to easily replicate a Geronimo installation to another machine (or to another existing Geronimo installation). It should also be possible to export an environment to run a J2EE application client in (ideally, export it as a dynamic Java Web Start configuration so you can just run it on your local PC by clicking a link in the console). Performance & Scalability - Performance must be comparable to other application servers in key areas. Geronimo should support clustering of web and EJB components for scalability and fail-over fault tolerance. Geronimo should work with common hardware load-balancers. Benchmarks should be made available with clear instructions for users to configure and run them on Geronimo as well as on other application servers. There should be clear performance tuning guidelines, and the performance tuning options should be extremely accessible (e.g. provide a dashboard- style page with all the settings to tune a web application in one place along with recommendations for the various settings). Application Portability --- It should be as easy as possible to port applications to Geronimo, meaning: - reduce the need for Geronimo-specific XML configuration files - simplify and minimize required settings in Geronimo-specific XML configuration files (e.g. eliminate nested namespaces, provide optimized file formats for common things like database pools, eliminate target names in references) - Isolate the application classpath from Server internals (Spring, logging) - Make common but non-standard code work (global JNDI lookups, etc.) - Support file layouts, config files, scripts, termininology from other popular application servers (or stay as similar as possible) - Provide conversion tools to import configurations from other app servers Some popular J2EE applications should be ported to Geronimo to confirm that the process is as painless as possible. Administration & Management --- Geronimo should provide command-line, Ant, Maven, and web versions of all key tools. This includes tools to: - get a list of available plugins - download and install plugins - deploy/redeploy applications - start and stop the server - export an application client wrapped in Java Web Start, even including auto-generated SSL keys/certs for mutual authentication. The web console should be at least as function as the BEA WebLogic web console. It should make it easy to both configure the server and gather runtime statistics. It should make it easy to run a second Geronimo instance on the same machine (using different network ports). It should be possible to rearrange the console content to suit the user's needs/style, or at least provi
[jira] Created: (GERONIMO-1902) Console does not allow editing of Tomcat Connector Attributes
Console does not allow editing of Tomcat Connector Attributes - Key: GERONIMO-1902 URL: http://issues.apache.org/jira/browse/GERONIMO-1902 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.0 Environment: All Reporter: Matt Hogstrom Assigned to: Aaron Mulder Fix For: 1.1 When attempting to edit the Tomcat Connectors the following messages are generated: 08:56:26,315 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,318 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,566 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,587 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,593 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager -- 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: Directory Update (Jeff?)
+1 Definitely the right direction. Aaron Mulder wrote: On 4/23/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Are we including ldap in the main distro, or shipping it as a plugin? If it is the latter, we can ship it late if needed. Great point! We can even post what we've got today as the 0.92 plugin and then post a new plugin version later. (In fact the 0.92 plugin is on the plugin site already, though we'll want to rebuild it against the final 1.1 G code when that comes out.) I guess this means we need to start moving things like directory out of our main tree so they can be versioned separately. Thanks, Aaron On Apr 23, 2006, at 7:15 PM, Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Matt Hogstrom wrote: Depends. Since we're focusing on getting the 1.1 release out I'm not sure we'll have time. Jeff would have to comment on his availability to test, etc. Alex Karasulu wrote: You guys have time for the latest RC2 release of Directory? We could push this release for G to get a bunch of fixes and performance enhancements in there. Alex Jeff Genender wrote: Yeah, I can take a look. Jeff Aaron Mulder wrote: All, While working on the plugins I found that our Directory is out of date (0.9.2 vs latest 0.9.3 on iBiblio). I also found that if we just "take the latest of everything Directory-related" it blows up (in particular, mina 0.9.0 doesn't work, but 0.8.2 appears to). Can someone test a good combination of all the Directory- related libs and update our etc/project.properties accordingly? Jeff, I think you did the original Directory integration, I'm not sure if you want to bite on this. It's not a huge deal if we ship G 1.1 a point release of Directory behind, but it would be nice if we could update. Thanks, Aaron
Re: Directory Update (Jeff?)
I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. Thanks, Aaron On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > Alex, > > Can you get the jars in ibiblio and I can get the integration going? I > am only seeing 0.9.2 in ibiblio at the moment. > > Thanks, > > Jeff > > Alex Karasulu wrote: > > Jeff Genender wrote: > >> If the changes are not huge, I can probably do it. Alex, are the > >> updates significant? > > Since 0.9.2 I'd say RC1 is a significant update. There are package name > > changes to comply with Directory's TLP domain name which are perhaps the > > most significant changes. There are changes to a couple dependencies. > > For the most part the code has been cleaned up and several *severe* bugs > > have been corrected and tested. RC1 is also an order of magnitude faster. > > > > We plan to get another 1.0 release candidate (RC2) out soon perhaps by > > the end of this week coming week or week there after. But looking at > > emails out there from Dain and Aaron it sounds to me like the update to > > G can take place any time after the 1.1 release. Let us know if you > > have any problems or need a hand while performing an upgrade either to > > RC1 or RC2 when it comes out. > > > > Regards, > > Alex > > >
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Well done Rick and Welcome on board! Gianny Kevan Miller wrote: Congratulations Rick! --kevan On Apr 21, 2006, at 2:59 PM, 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] Closed: (GERONIMO-1901) Add additional parameters to TomcatGBean to provide improved configuration of Tomcat Attributs
[ http://issues.apache.org/jira/browse/GERONIMO-1901?page=all ] Matt Hogstrom closed GERONIMO-1901: --- Resolution: Fixed Sendingtomcat/src/java/org/apache/geronimo/tomcat/ConnectorGBean.java Sending tomcat/src/java/org/apache/geronimo/tomcat/TomcatWebConnector.java Transmitting file data .. Committed revision 396533. Added the ability to manipulate the following parameters: maxKeepAliveRequests="100" maxKeepAliveRequests socketBuffer="9000" socketBuffer useBodyEncodingForURI="false"useBodyEncodingForURI To manipulate these attributes modify the config.xml 0.0.0.0 8080 8443 <-- These are the new attributes. (defaults shown) --> false 9000 100 > Add additional parameters to TomcatGBean to provide improved configuration of > Tomcat Attributs > -- > > Key: GERONIMO-1901 > URL: http://issues.apache.org/jira/browse/GERONIMO-1901 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: Tomcat > Versions: 1.0 > Environment: All > Reporter: Matt Hogstrom > Assignee: Matt Hogstrom > Priority: Minor > Fix For: 1.1 > > Added additional attributes in TomcatWebConnector and ConnectorGBean to allow > configuration for: > "maxKeepAliveRequests" > "socketBuffer" > "useBodyEncodingForURI" -- 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-1901) Add additional parameters to TomcatGBean to provide improved configuration of Tomcat Attributs
Add additional parameters to TomcatGBean to provide improved configuration of Tomcat Attributs -- Key: GERONIMO-1901 URL: http://issues.apache.org/jira/browse/GERONIMO-1901 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: Tomcat Versions: 1.0 Environment: All Reporter: Matt Hogstrom Assigned to: Matt Hogstrom Priority: Minor Fix For: 1.1 Added additional attributes in TomcatWebConnector and ConnectorGBean to allow configuration for: "maxKeepAliveRequests" "socketBuffer" "useBodyEncodingForURI" -- 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
Congrats!!! - sachin On Apr 21, 2006, at 2:59 PM, 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
Unassigned Patches: week of 04-24-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 3 2006 - GERONIMO-1414 - Console About page does not set the shortcut icon Jan 6 2006 - GERONIMO-1392 - update "additional samples" redirect in geronimo website Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 8 2006 - GERONIMO-1163 - improve jmx debug console Jan 14 2006 - GERONIMO-1453 - GBeanOverride throws NullPointerException when more than one reference element specified Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 25 2006 - GERONIMO-1037 - Clicking on "uninstall" link in Applications management pages deletes the configuration without any confirmation from user Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 13 2006 - GERONIMO-1623 - Preliminary port of the OpenWire C# into C++. Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1700 - Web Console prints a stack trace when attempting to deploy an application that is already deployed. Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Mar 23 2006 - GERONIMO-1762 - Create a derby network /embedded XA datasource via admin console fail Mar 24 2006 - GERONIMO-1764 - Daytrader createDB.sh script does not support cygwin users on Windows.
Re: Directory Update (Jeff?)
Feel free to help, it would be great. Jeff Alexei Zakharov wrote: Hi, Just want to add that the version 0.9.2 is the reason of the org.apache.geronimo.directory.RunningTest hang on BEA Jrockit. I've been playing with different versions of ApacheDS and Jrockit for the last couple of weeks - you may see GERONIMO-1805 and DIRSERVER-607 for details of my activity. In case big guys are currently busy with fixing other important issues I'd like to volunteer for this. I simply can continue my efforts and try to handle the porting to ApacheDS 1.0 RCx. Thanks, 2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>: Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex -- Alexei Zakharov, Intel Middleware Product Division
Re: Directory Update (Jeff?)
Alex, Can you get the jars in ibiblio and I can get the integration going? I am only seeing 0.9.2 in ibiblio at the moment. Thanks, Jeff Alex Karasulu wrote: Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex
Re: Final fields serialization mechanism in Geronimo Corba RMI IIOP implementation
Udovichenko, Nellya wrote: Hello! My JDK version is Sun JDK 1.5. When I use Geronimo Corba RMI IIOP implementation class org.apache.geronimo.interop.rmi.iiop.FinalFieldSetter throws RuntimeException because the implementation of FinalFieldSetter interface cannot be found if JDK version differs 1.4. I'm not sure what you're doing that uses this code, but the code in the org.apache.geronimo.interop package is obsolete and not even in use by Geronimo. In fact, we deleted this package this package from the current builds because the Yoko project is going to be filling the space that the interop code once attempted to fill. Rick I have found that there is a class org.apache.geronimo.interop.util.SystemUtil which chooses the adapter according to the current JDK version. This adapter is used for FinalFieldSetter. The bug is also reproducible on BEA JRockit 1.4.2_04/1.5.0. Therefore, some questions appear: 1) What do you think it needs to be done if JDK version differs from 1.4? 2) Why JDK version is obtained from ‘java.vm.version’ parameter rather than ‘java.specification.version’? Can we avoid using of the adapter? 3) Сlass sun.misc.Unsafe in FinalFieldSetterJDK1.4 is used for object recreation without invoking a constructor. Can we use default serialization mechanism instead? I have also found reference to the bug in Sun JDK http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6379948 Does anyone have any ideas? Thanks, Nellya Udovichenko, Intel Middleware Products Division
Re: Directory Update (Jeff?)
Hi, Just want to add that the version 0.9.2 is the reason of the org.apache.geronimo.directory.RunningTest hang on BEA Jrockit. I've been playing with different versions of ApacheDS and Jrockit for the last couple of weeks - you may see GERONIMO-1805 and DIRSERVER-607 for details of my activity. In case big guys are currently busy with fixing other important issues I'd like to volunteer for this. I simply can continue my efforts and try to handle the porting to ApacheDS 1.0 RCx. Thanks, 2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>: > Jeff Genender wrote: > > If the changes are not huge, I can probably do it. Alex, are the > > updates significant? > Since 0.9.2 I'd say RC1 is a significant update. There are package name > changes to comply with Directory's TLP domain name which are perhaps the > most significant changes. There are changes to a couple dependencies. > For the most part the code has been cleaned up and several *severe* bugs > have been corrected and tested. RC1 is also an order of magnitude faster. > > We plan to get another 1.0 release candidate (RC2) out soon perhaps by > the end of this week coming week or week there after. But looking at > emails out there from Dain and Aaron it sounds to me like the update to > G can take place any time after the 1.1 release. Let us know if you > have any problems or need a hand while performing an upgrade either to > RC1 or RC2 when it comes out. > > Regards, > Alex -- Alexei Zakharov, Intel Middleware Product Division
Re: Tomcat version in G1.1 for clustering
Jeff Genender wrote: Hi Matthew, Ultimately clustering should not be based on WADI directly, but for components that implement the session API interface. We want to make clustering components pluggable, so there is no hard coded clustering agent. With my WADI hat on: Agreed - this is the correct approach - however, for reasons stated in the related threads on this list, I believe that the proposed API has been positioned at the wrong level of abstraction. As such, I believe that it actually acts as a barrier to WADI's integration. I am unaware of WADI's status regarding its implementation of the session API. Jules or Greg would need to comment on this. I've given this a lot of consideration and come to the conclusion, that, whilst I have every intention of WADI and Geronimo being integrated, this integration is unlikely to occur via the proposed API in its current form. I think that WADI will continue to go down the route of integrating its front end directly with the tier in question, whilst exposing its backend to Geronimo management facilities. We (Geronimo) will have a session clustering component that will be offered as a part of Geronimo that will implement the session API interface shortly. Its been a side project for a couple of weeks ;-) With my Geronimo hat on: Sounds interesting. Is the design discussion going on in public somewhere or are you integrating an existing component? I am sure that there are many people on the list who would be interested in participating. Relative to the Tomcat clustering, yes this is an interim capability to allow for clustering the web tier. Although it will always be available, I believe we will have a more robust solution that works across all component in the near future. Stay tuned ;-) You bet :-) Jules Jeff Matthew Jording wrote: Jeff, Dave, I would like to implement a Geronimo Cluster Management Web Service and need some additional information on the advances of WADI integration. The current clustering examples seem to only be concerned with tomcat web tier clustering and doesn't seem to use WADI to facilitate the management of the sessions. Thanks Matt Jeff Genender wrote: Dave, Thanks for doing this. Jeff Dave Colasurdo wrote: I've validated that the Geronimo clustering example (http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example) still works for Geronimo 1.1 (with Tomcat 5.5.9). The application deployment plan (attached to email) required some changes. I'm now rebuilding G1.1 with Tomcat 5.5.15 to determine if the clustering Gbeans and plans still work.. -Dave- Jeff Genender wrote: IIRC, 5.5.15 went to backward compatibility... http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] Perhaps Filip can fill us in on this. If I remember right, the 5.5.9 clustering GBeans will work on forward versions. So I don't think there is a problem there. HEAD has been set to 5.5.15 for quite some time. Nevertheless, it doesn't hurt to try em out ;-) Jeff Dave Colasurdo wrote: Jeff (et al.), Will G1.1 definitely be upgraded to Tomcat 5.5.15? IIRC, the clustering deployment plans were quite different for 5.5.9 -vs- 5.5.12. If we upgrade to 5.5.15, we will likely need a new plan that accounts for both the webcontainer upgrade as well as the new G1.1 plan format.. Thanks -Dave- Jeff Genender wrote: Thanks Rainer. But I think 5.5.15 will be the one for 1.1. But possibly 5.5.17 for 1.2 ;-) Jeff Rainer Jung wrote: Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave- http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1";> http://geronimo.apache.org/xml/ns/deployment-1.1";> geronimo servlets-examples-tomcat-cluster 1.1-SNAPSHOT car /servlets-examples-cluster false geronimo-properties-realm TomcatCluster org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=false
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Congrats Rick. It was very well deserved. -dain On Apr 21, 2006, at 11:59 AM, 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
