[jira] Closed: (GERONIMO-1909) Errors in JMS Server portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1909?page=all ] Vamsavardhana Reddy closed GERONIMO-1909. - > Errors in JMS Server portlet > > > Key: GERONIMO-1909 > URL: http://issues.apache.org/jira/browse/GERONIMO-1909 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1 > Environment: Win XP, Sun JDK 1.4.2_08 >Reporter: Vamsavardhana Reddy > Fix For: 1.1 > > > Editing JMS Newtork Listneres and adding new JMS Network Listeners is not > functional. The following exceptions are logged to the console window. > 15:31:50,887 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainerGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSServer,name=ActiveMQ > 15:31:50,897 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainer in provided ClassLoader for > geronimo/activemq-broker/1.1-SN > APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS > erver,name=ActiveMQ > 15:31:51,078 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainerGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSServer,name=ActiveMQ > 15:31:51,078 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainer in provided ClassLoader for > geronimo/activemq-broker/1.1-SN > APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS > erver,name=ActiveMQ > 15:31:51,088 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQConnectorGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSConnector,name=ActiveMQ.tcp.default > 15:31:51,088 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQConnectorGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSConnector,name=ActiveMQ.vm.localhost > 15:31:51,108 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainerGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSServer,name=ActiveMQ > 15:31:51,128 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainer in provided ClassLoader for > geronimo/activemq-broker/1.1-SN > APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS > erver,name=ActiveMQ -- 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-1909) Errors in JMS Server portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1909?page=all ] Vamsavardhana Reddy resolved GERONIMO-1909. --- Fix Version/s: 1.1 (was: 1.1.x) Resolution: Fixed Verified that the issue is resolved in G1.1. > Errors in JMS Server portlet > > > Key: GERONIMO-1909 > URL: http://issues.apache.org/jira/browse/GERONIMO-1909 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1 > Environment: Win XP, Sun JDK 1.4.2_08 >Reporter: Vamsavardhana Reddy > Fix For: 1.1 > > > Editing JMS Newtork Listneres and adding new JMS Network Listeners is not > functional. The following exceptions are logged to the console window. > 15:31:50,887 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainerGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSServer,name=ActiveMQ > 15:31:50,897 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainer in provided ClassLoader for > geronimo/activemq-broker/1.1-SN > APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS > erver,name=ActiveMQ > 15:31:51,078 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainerGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSServer,name=ActiveMQ > 15:31:51,078 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainer in provided ClassLoader for > geronimo/activemq-broker/1.1-SN > APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS > erver,name=ActiveMQ > 15:31:51,088 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQConnectorGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSConnector,name=ActiveMQ.tcp.default > 15:31:51,088 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQConnectorGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSConnector,name=ActiveMQ.vm.localhost > 15:31:51,108 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainerGBean in provided ClassLoader for > geronimo/activemq-broker/1 > .1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType > =JMSServer,name=ActiveMQ > 15:31:51,128 WARN [BasicProxyManager] Could not load interface > org.activemq.gbe > an.ActiveMQContainer in provided ClassLoader for > geronimo/activemq-broker/1.1-SN > APSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSS > erver,name=ActiveMQ -- 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-2246) Why resource-env-ref:admin-object-module?
[ http://issues.apache.org/jira/browse/GERONIMO-2246?page=all ] Aaron Mulder updated GERONIMO-2246: --- Description: When mapping resource-env-refs (or a message-destination), It doesn't seem like admin-object-module is necessary. It can be provided alongside admin-object-name in order to narrow the search down to a specific module within an EAR (the current EAR or any EAR in the dependency graph that has a module with that name). However, if you need to specify a module, you can just use: jms.rar foo Instead of using admin-object-module and admin-object-name. It doesn't seem like this redundancy gets us anything, so I'd rather remove admin-object-module and make admin-object-link work like any other resource/EJB link (name only -- use "pattern" for more complex stuff). If we proceed, I don't think we necessarily want to remove it in 1.1.x (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and remove message-destination-link at the same time. David J, could you comment? was: When mapping resource-env-refs, It doesn't seem like admin-object-module is necessary. It can be provided alongside admin-object-name in order to narrow the search down to a specific module within an EAR (the current EAR or any EAR in the dependency graph that has a module with that name). However, if you need to specify a module, you can just use: jms.rar foo Instead of using admin-object-module and admin-object-name. It doesn't seem like this redundancy gets us anything, so I'd rather remove admin-object-module and make admin-object-link work like any other resource/EJB link (name only -- use "pattern" for more complex stuff). If we proceed, I don't think we necessarily want to remove it in 1.1.x (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and remove message-destination-link at the same time. David J, could you comment? > Why resource-env-ref:admin-object-module? > - > > Key: GERONIMO-2246 > URL: http://issues.apache.org/jira/browse/GERONIMO-2246 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, connector >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: David Jencks > Fix For: 1.2 > > > When mapping resource-env-refs (or a message-destination), It doesn't seem > like admin-object-module is necessary. It can be provided alongside > admin-object-name in order to narrow the search down to a specific module > within an EAR (the current EAR or any EAR in the dependency graph that has a > module with that name). However, if you need to specify a module, you can > just use: > > jms.rar > foo > > Instead of using admin-object-module and admin-object-name. It doesn't seem > like this redundancy gets us anything, so I'd rather remove > admin-object-module and make admin-object-link work like any other > resource/EJB link (name only -- use "pattern" for more complex stuff). > If we proceed, I don't think we necessarily want to remove it in 1.1.x > (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and > remove message-destination-link at the same time. > David J, could you comment? -- 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-2246) Why resource-env-ref:admin-object-module?
Why resource-env-ref:admin-object-module? - Key: GERONIMO-2246 URL: http://issues.apache.org/jira/browse/GERONIMO-2246 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector, deployment Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: David Jencks Fix For: 1.2 When mapping resource-env-refs, It doesn't seem like admin-object-module is necessary. It can be provided alongside admin-object-name in order to narrow the search down to a specific module within an EAR (the current EAR or any EAR in the dependency graph that has a module with that name). However, if you need to specify a module, you can just use: jms.rar foo Instead of using admin-object-module and admin-object-name. It doesn't seem like this redundancy gets us anything, so I'd rather remove admin-object-module and make admin-object-link work like any other resource/EJB link (name only -- use "pattern" for more complex stuff). If we proceed, I don't think we necessarily want to remove it in 1.1.x (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and remove message-destination-link at the same time. David J, could you comment? -- 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: Should we allow more ejb-links than j2ee specifies?
Dain Sundstrom wrote: On Jul 27, 2006, at 7:29 PM, Matt Hogstrom wrote: Aaron Mulder wrote: On 7/27/06, John Sisson <[EMAIL PROTECTED]> wrote: I think this would simplify configuration for users. Could we log a warning (that can be enabled/disabled) at deploy time identifying extended features are being utilised? Putting myself in users shoes, I would like to use these extensions, but would like a way of identifying which apps are using them and what extended features are being used in case I need to migrate my apps to another server, but don't wan't to see warning messages day to day during normal operation. I'm not really in favor of the log messages -- we have too many extensions. I am in favor of keeping the feature as presently implemented. +1 +1 -dain It was just an idea.. I'm happy keeping the feature as is. John
[jira] Created: (GERONIMO-2245) Why corbaNameGroup:css-name?
Why corbaNameGroup:css-name? Key: GERONIMO-2245 URL: http://issues.apache.org/jira/browse/GERONIMO-2245 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment, OpenEJB Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x Between Geronimo 1.0 and Geronimo 1.1, we removed most of the elements that allow you to list a full ObjectName/AbstractName in a reference. There is no more "target-name" for resource references, EJB references, etc. However, the corbaNameGroup still includes css-name, which appears to take the text of an AbstractName or AbstractNameQuery to identify a CSS. That seems weird, since there's already the "css" element (type patternType) which lets you explicitly identify a CSS by its name components. I think we should remove css-name to be consistent (and avoid people trying to use the AbstractName or AbstractNameQuery String syntax), unless there's a strong reason to keep it. -- 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-2243) GBean references do not trim space from interface names (ref-type)
[ http://issues.apache.org/jira/browse/GERONIMO-2243?page=all ] Aaron Mulder updated GERONIMO-2243: --- Attachment: 2243-trim-interface.patch > GBean references do not trim space from interface names (ref-type) > -- > > Key: GERONIMO-2243 > URL: http://issues.apache.org/jira/browse/GERONIMO-2243 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Aaron Mulder > Fix For: 1.1.1 > > Attachments: 2243-trim-interface.patch > > > In ENCConfigBuilder.addGBeanRef the interface name is stuffed directly from > the XML into the target interface collection, and in > ENCConfigBuilder.buildAbstractNameQuery it is passed directly through to the > AbstractNameQuery (even while all the other values are trimmed). The > interface names should be trimmed too. -- 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-2244) Explicit reference fail when module type is not "car"
Explicit reference fail when module type is not "car" - Key: GERONIMO-2244 URL: http://issues.apache.org/jira/browse/GERONIMO-2244 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, deployment Affects Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Currently the used in the naming schema includes group, artifact, and version, but not type. In ENCConfigBuilder.buildAbstractNameQuery, the type is hardcoded to "car". This means that if you use a naming:pattern with an artifactId, it only works if the target module's type is actually "car". This is not true, for example, for several module types created by the admin console, as well as in general for user-defined modules. The naming:pattern element should include a "type" element, and ENCConfigBuilder (and any other necessary code) should respect it. -- 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-2243) GBean references do not trim space from interface names (ref-type)
GBean references do not trim space from interface names (ref-type) -- Key: GERONIMO-2243 URL: http://issues.apache.org/jira/browse/GERONIMO-2243 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.1 In ENCConfigBuilder.addGBeanRef the interface name is stuffed directly from the XML into the target interface collection, and in ENCConfigBuilder.buildAbstractNameQuery it is passed directly through to the AbstractNameQuery (even while all the other values are trimmed). The interface names should be trimmed too. -- 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: Re: Liferay Plugin for G
Paul, If you're going to update the liferay plugin soon with more extensive metadata and to add tomcat to the name, I'd rather wait to post it until I get the update -- so the page about it will be more complete, so the module ID won't be changing for the next release, and so we don't have a dilemma caused by a second release of the "version 4.0.0" plugin. If that's going to be a problem, let me know and I'll post the version I have now. I don't remember of you've done this already, but if not, you might also want to make sure that the plugin lists itself in the "obsoletes" section, so it will uninstall older versions when you install a newer version. Thanks, Aaron On 7/27/06, Paul McMahan <[EMAIL PROTECTED]> wrote: On 7/27/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > Paul, > > I haven't heard back about whether you want me to post the same > plugins that are on your site, so I'll assume yes unless I hear > otherwise. I see you updated the paths on your server though, which > is great. Aaron, I'm at a conference this week and have limited devlist time so thanks for your patience. I did update the repository paths as you suggested, thanks for the tip. Posting the plugin to your site sounds great. But for the longer term I would like to encourage Liferay to host the plugin instead. I'll offer my assistance in setting up their repository and also help fix GERONIMO-2076 so people can copy/paste alternate repository URLs into the admin console. > A few more notes about the liferay plugins: > > It looks like you have a plugin for Geronimo/Tomcat only (not > Geronimo/Jetty). Can you build a Jetty plugin too, or does the > integration only work with Tomcat? If there are going to be versions > for both, it would be best to put "tomcat" or "jetty" in the module ID > for the portal plugin -- liferay/liferay-portal-tomcat/4.0.0/car and > liferay/liferay-portal-jetty/4.0.0/car instead of just using > liferay/liferay-portal/4.0.0/car for the Tomcat version (and then what > for Jetty?). Agreed. Adding a Jetty version of the plugin is definitely near the top of the todo list. It should be straightfoward since Liferay already provides a Jetty version. I'll rename the plugin to include the servlet engine name as you suggest. Does the plugin system support either/or style dependencies so I could create a single plugin with a dependency against either tomcat or jetty? If not then does it sound like a reasonable enhancement request for the 1.2 timeframe (maybe I can work on this)? > You should use a human-readable for the plugin metadata, and > make the an actual description (it will be used as text > on the web page that describes the plugin). There is no real > description for the Liferay plugin (only for the Liferay database > plugin), which means the web page on the site for the plugin will be > pretty empty. They both use the module ID as the name, which isn't so > good. It would be great if you could update the metadata accordingly. I agree and will add some better info to the plugin's metadata in its next iteration. > Generally, I'm not sure it's wise to make the plugin version the same > as the Liferay product version. That means you can't release > enhancements to the plugin separately from new versions of the > product. However, if you're simply repackaging the default Liferay > install (so you think there's no reason to release a separate plugin > update), then it makes sense. Right now the procedure I use to generate the plugin is just to export the Liferay WAR as a CAR using the plugin UI. I made a few changes to the exported artifact so it could support Derby. Liferay has indicated they are willing to incorporate those changes back into their main release. So I think for now it makes sense to keep the version numbers in synch. I think its possible that the version numbers may need to diverge later, but hopefully not because IMHO it would cause too much confusion. > In the repository list, you should use > http://www.geronimoplugins.com/repository/geronimo-1.1/ instead of > http://geronimoplugins.com/repository/ OK, I'll fix that. BTW, that repository is really just for dev/test purposes, so you may see some disorganization in there from time to time. > If you want a site to maintain anything in relation to these plugins > (e.g. the geronimo-service.xml files for the plugins), I have a > plugins project on sourceforge I can add you to. That would make it > easier for me to help with some of the metadata maintenance if you > like. That sounds cool. I don't have any peripheral stuff right now but I bet there may be something later. I have also been looking into setting up a Geronimo plugin related site that I'd like to get everyone's feedback on. I'll start a separate thread on that. thanks, Paul > > Thanks, > Aaron > > On 7/25/06, Paul McMahan <[EMAIL PROTECTED]> wrote: > > Sorry I've left this thread sitting idle for the last few days. I'm > > just now re
[jira] Updated: (GERONIMO-693) Provide Java Service Wrapper scripts in bin directory
[ http://issues.apache.org/jira/browse/GERONIMO-693?page=all ] Aaron Mulder updated GERONIMO-693: -- Fix Version/s: 1.1.x (was: 1.x) Priority: Critical (was: Minor) > Provide Java Service Wrapper scripts in bin directory > - > > Key: GERONIMO-693 > URL: http://issues.apache.org/jira/browse/GERONIMO-693 > Project: Geronimo > Issue Type: New Feature > Components: usability, startup/shutdown >Affects Versions: 1.0-M4, 1.0, 1.1 > Environment: Windows, Linux, Mac OS X >Reporter: Erin Mulder > Assigned To: John Sisson >Priority: Critical > Fix For: 1.1.x > > Attachments: wrapper.tar.gz > > > It would be nice to have obvious startup.sh and startup.bat scripts in the > bin directory so that the user doesn't need to look at the README file to > figure out how to start the server. (java -jar bin/server.jar isn't hard -- > it's just not quite as brainless as a script called "startup"). -- 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-2134) Shutdown error in ConfigurationClassLoader on Java 5
[ http://issues.apache.org/jira/browse/GERONIMO-2134?page=all ] Aaron Mulder updated GERONIMO-2134: --- Description: When I shut down (Ctrl-C), I got this: Server shutdown begun 12:50:27,288 ERROR [ConfigurationClassLoader] Unable to clear SoftCache field subclassAudits in class class java.io.ObjectInputStream Server shutdown completed was: I had left Geronimo running for a couple days. When I shut down, I got this: Server shutdown begun 12:50:27,288 ERROR [ConfigurationClassLoader] Unable to clear SoftCache field subclassAudits in class class java.io.ObjectInputStream Server shutdown completed > Shutdown error in ConfigurationClassLoader on Java 5 > > > Key: GERONIMO-2134 > URL: http://issues.apache.org/jira/browse/GERONIMO-2134 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.1.1 > > > When I shut down (Ctrl-C), I got this: > Server shutdown begun > 12:50:27,288 ERROR [ConfigurationClassLoader] Unable to clear SoftCache field > subclassAudits in class class java.io.ObjectInputStream > Server shutdown completed -- 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-2134) Shutdown error in ConfigurationClassLoader on Java 5
[ http://issues.apache.org/jira/browse/GERONIMO-2134?page=all ] Aaron Mulder updated GERONIMO-2134: --- Summary: Shutdown error in ConfigurationClassLoader on Java 5 (was: Shutdown error in ConfigurationClassLoader) Fix Version/s: 1.1.1 (was: 1.1.x) It seems like this happens consistently when running Geronimo under Java 5, but not under Java 1.4. > Shutdown error in ConfigurationClassLoader on Java 5 > > > Key: GERONIMO-2134 > URL: http://issues.apache.org/jira/browse/GERONIMO-2134 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.1.1 > > > I had left Geronimo running for a couple days. When I shut down, I got this: > Server shutdown begun > 12:50:27,288 ERROR [ConfigurationClassLoader] Unable to clear SoftCache field > subclassAudits in class class java.io.ObjectInputStream > Server shutdown completed -- 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-2242) Better output for port conflicts during startup
Better output for port conflicts during startup --- Key: GERONIMO-2242 URL: http://issues.apache.org/jira/browse/GERONIMO-2242 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x Currently Geronimo produces about 230 lines worth of error messages if there's a conflict on the web ports during startup (e.g. as a result of Tomcat already running on the same machine). Annoyingly, the "Address in use" message is kind of concealed by the massive stack traces, and worse, it never actually says which ports are the problem. This will likely be the most common startup error. It would be great to detect it and suppress the stack trace and instead emit a message along the lines of: ERROR: Geronimo cannot start. Port 8080 is already in use. Please either shut down the product listening on port 8080 or search for 8080 in var/config/config.xml and replace it with another available port number. -- 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-2134) Shutdown error in ConfigurationClassLoader
[ http://issues.apache.org/jira/browse/GERONIMO-2134?page=all ] Aaron Mulder updated GERONIMO-2134: --- Fix Version/s: 1.1.x > Shutdown error in ConfigurationClassLoader > -- > > Key: GERONIMO-2134 > URL: http://issues.apache.org/jira/browse/GERONIMO-2134 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.1.x > > > I had left Geronimo running for a couple days. When I shut down, I got this: > Server shutdown begun > 12:50:27,288 ERROR [ConfigurationClassLoader] Unable to clear SoftCache field > subclassAudits in class class java.io.ObjectInputStream > Server shutdown completed -- 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: VMware on GBuild?
On 7/29/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I wasn't sure if Aaron had his systems in a colo which I think he alluded to earlier. No, they're in the office -- I'll pick up a cheap home router if we think it'll work. Which it sounds like we do. Thanks, Aaron Jason Dillon wrote: > IMO its easier to just using a NAT'ing router... instead of mucking with > a proxy. Routers w/NAT are relatively cheap or if you have a Linux box > w/2 NICs you can roll any sort of fancier router you want... at the cost > of a bit more admin foo. > > --jason > > > On Jul 28, 2006, at 5:47 PM, Matt Hogstrom wrote: > >> Just getting back to the multiple images behind a gateway system. I >> was thinking the other images could simply go through the gateway >> using a proxy rather than having to mees around with IP layer tricks. >> >> Jason Dillon wrote: >>> Not sure... does ActiveMQ support it? If so... then sure... if >>> not... well, then we'd have to write a transport (er something like >>> that). >>> Why? >>> --jason >>> On Jul 28, 2006, at 12:10 PM, Matt Hogstrom wrote: Could it be through a proxy? Jason Dillon wrote: > Agents make a TCP connection to the central AMQ router running on > stan.gbuild.org... and then ActiveMQ takes care of the rest. So, > its not push or pull... but the Agent must initiate the connection. > --jason > On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: >> On 7/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >>> I'm no expert on how the TCK runs, but I do not believe that you >>> need >>> a public IP. Though, with out a public IP, we can't use Cacti to >>> monitor the hosts, or ssh to them directly to admin them... but if >>> you dedicate one host as a gateway then we can get past that... and >>> might even be able to setup port forwarding for SNMP/Cacti >>> monitoring. >>> >>> If there is any other issue that requires a public IP I am not aware >>> of it... and we should remove the need for it if one exists. >> >> How does the GBuild master communicate with the GBuild slaves? Is it >> all pull from the slaves? >> >> Thanks, >> Aaron > > > >
Re: VMware on GBuild?
I wasn't sure if Aaron had his systems in a colo which I think he alluded to earlier. Jason Dillon wrote: IMO its easier to just using a NAT'ing router... instead of mucking with a proxy. Routers w/NAT are relatively cheap or if you have a Linux box w/2 NICs you can roll any sort of fancier router you want... at the cost of a bit more admin foo. --jason On Jul 28, 2006, at 5:47 PM, Matt Hogstrom wrote: Just getting back to the multiple images behind a gateway system. I was thinking the other images could simply go through the gateway using a proxy rather than having to mees around with IP layer tricks. Jason Dillon wrote: Not sure... does ActiveMQ support it? If so... then sure... if not... well, then we'd have to write a transport (er something like that). Why? --jason On Jul 28, 2006, at 12:10 PM, Matt Hogstrom wrote: Could it be through a proxy? Jason Dillon wrote: Agents make a TCP connection to the central AMQ router running on stan.gbuild.org... and then ActiveMQ takes care of the rest. So, its not push or pull... but the Agent must initiate the connection. --jason On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
Re: Long-awaited 2-week holidays - at last!
enjoy...don't take your notebook:) Jacek Laskowski wrote: Hi, Just to let you know that I'm on my way to Croatia for a long-awaited, 2-week holidays. I'm off wire for 2 weeks until 8/15. Whoooh! Jacek
Re: Personal SVN Commit Report?
I use svn log -r $BranchCutRev|HEAD | grep $yourUserId -dain On Jul 27, 2006, at 12:54 PM, Aaron Mulder wrote: I know I've put some changes in 1.1 that ought to go into trunk. Is there a way for me to generate a list of commits I've made (with version number and comment) in one or both branches over the last month or so? Otherwise, I guess I'll consult the mailing list archives. Thanks, Aaron
Re: Should we allow more ejb-links than j2ee specifies?
On Jul 27, 2006, at 7:29 PM, Matt Hogstrom wrote: Aaron Mulder wrote: On 7/27/06, John Sisson <[EMAIL PROTECTED]> wrote: I think this would simplify configuration for users. Could we log a warning (that can be enabled/disabled) at deploy time identifying extended features are being utilised? Putting myself in users shoes, I would like to use these extensions, but would like a way of identifying which apps are using them and what extended features are being used in case I need to migrate my apps to another server, but don't wan't to see warning messages day to day during normal operation. I'm not really in favor of the log messages -- we have too many extensions. I am in favor of keeping the feature as presently implemented. +1 +1 -dain
Long-awaited 2-week holidays - at last!
Hi, Just to let you know that I'm on my way to Croatia for a long-awaited, 2-week holidays. I'm off wire for 2 weeks until 8/15. Whoooh! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
