[jira] Created: (GERONIMO-2022) New printed Book available - patch for documentation page attached
New printed Book available - patch for documentation page attached -- Key: GERONIMO-2022 URL: http://issues.apache.org/jira/browse/GERONIMO-2022 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: website Versions: 1.0 Reporter: Kristian Koehler Hi we wrote a Geronimo book which is now available. Could someone please add a link to the documentation page. ;-) Patch attached Kristian -- 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-2022) New printed Book available - patch for documentation page attached
[ http://issues.apache.org/jira/browse/GERONIMO-2022?page=all ] Hernan Cunico reassigned GERONIMO-2022: --- Assign To: Hernan Cunico New printed Book available - patch for documentation page attached -- Key: GERONIMO-2022 URL: http://issues.apache.org/jira/browse/GERONIMO-2022 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: website Versions: 1.0 Reporter: Kristian Koehler Assignee: Hernan Cunico Hi we wrote a Geronimo book which is now available. Could someone please add a link to the documentation page. ;-) Patch attached Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2022) New printed Book available - patch for documentation page attached
[ http://issues.apache.org/jira/browse/GERONIMO-2022?page=comments#action_12402215 ] Hernan Cunico commented on GERONIMO-2022: - Kristian, pls re-attach patch or provide details about the book. Cheers! Hernan New printed Book available - patch for documentation page attached -- Key: GERONIMO-2022 URL: http://issues.apache.org/jira/browse/GERONIMO-2022 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: website Versions: 1.0 Reporter: Kristian Koehler Assignee: Hernan Cunico Hi we wrote a Geronimo book which is now available. Could someone please add a link to the documentation page. ;-) Patch attached Kristian -- 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-2022) New printed Book available - patch for documentation page attached
[ http://issues.apache.org/jira/browse/GERONIMO-2022?page=all ] Kristian Koehler updated GERONIMO-2022: --- Attachment: book.patch sorry for the inconvenience here is the patch New printed Book available - patch for documentation page attached -- Key: GERONIMO-2022 URL: http://issues.apache.org/jira/browse/GERONIMO-2022 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: website Versions: 1.0 Reporter: Kristian Koehler Assignee: Hernan Cunico Attachments: book.patch Hi we wrote a Geronimo book which is now available. Could someone please add a link to the documentation page. ;-) Patch attached Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1900) Sample app links on welcome app are broken by default
[ http://issues.apache.org/jira/browse/GERONIMO-1900?page=comments#action_12402233 ] Aaron Mulder commented on GERONIMO-1900: OK, looking at patch 9... I still am not thrilled with this. In no particular order: - it seems too complex for what we're doing: multiple servlets, new images, changes to existing JSPs, new JSPs... - The JavaDoc is not up to date - There are string constants that do not seem to be up to date - Some variables are in camel case, others use underscores - The login page has a table with over 30 cells to hold username, password, and submit - The servlets aren't just mapped to the URLs where the sample apps will appear, making the whole thing more complex less transparent - I don't like servlets with tons of instance variables Let's back up and think about the best way to proceed here. Sample app links on welcome app are broken by default - Key: GERONIMO-1900 URL: http://issues.apache.org/jira/browse/GERONIMO-1900 Project: Geronimo Type: Bug Security: public(Regular issues) Components: usability, sample apps Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: logo_head_570x86.gif, welcome-10.patch, welcome-2.patch, welcome-3.patch, welcome-4.patch, welcome-6.patch, welcome-7.patch, welcome-8.patch, welcome-9.patch, welcome-images.jar, welcome-images.zip, welcome.patch It would be nice to take users to a page that would prompt them to install the sample if they click a link to it and it's not present. However, automating this would require us to be able to construct a link into a portlet, which does not seem easy. For now, the welcome app can include pages at the locations where the sample apps will be bound, with text to the effect of: This sample has not yet been installed. To install it, visit the (URL)console(/URL) and select the Plugins page, click the Search for Plugins button, and select the (NAME HERE) sample to install. Then visit this same URL again to view the (NAME HERE) example. -- 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-1822) Connector builder doesn't check consistency of transaction settings
[ http://issues.apache.org/jira/browse/GERONIMO-1822?page=all ] David Jencks closed GERONIMO-1822: -- Resolution: Fixed Since the plan is to merge the 1.2 changes back into 1.1, I think we can close this one now. Connector builder doesn't check consistency of transaction settings --- Key: GERONIMO-1822 URL: http://issues.apache.org/jira/browse/GERONIMO-1822 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector Versions: 1.0, 1.1, 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1, 1.2 GERONIMO-1800 has an example of deploying a local-tx connector with an xa-transaction plan that does not fail deployment and fails when the connection manager tries to get an XAResource from the managed connection. The connector builder should compare the tx specification of the connector and plan and make sure they are consistent. -- 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-2012) Reflect configuration - module change in config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2012?page=all ] Dain Sundstrom closed GERONIMO-2012: Resolution: Fixed Reflect configuration - module change in config.xml Key: GERONIMO-2012 URL: http://issues.apache.org/jira/browse/GERONIMO-2012 Project: Geronimo Type: Bug Security: public(Regular issues) Components: general Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: Dain Sundstrom Fix For: 1.1 Attachments: 2012.patch This JIRA is to capture an issue raised by John Sissino so that we have something to attach a patch created by Dain to while SVN is down. The problem was reported in John's note to the dev list: http://www.mail-archive.com/dev%40geronimo.apache.org/msg22260.html text from email: I noticed we still have a configuration element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the configuration element name to module to have consistent terminology considering the recent configId changes. * update cmd line help for --override option in Daemon to use module terminology. * update the wording in the var\config\README.txt to use the module terminology. * change the --long startup output to use the word Module instead of Configuration - also give us a bit more room on each line. Any objections? -- 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-2018) Change temporary system proerty flags to start with X
[ http://issues.apache.org/jira/browse/GERONIMO-2018?page=all ] Dain Sundstrom closed GERONIMO-2018: Resolution: Fixed Change temporary system proerty flags to start with X --- Key: GERONIMO-2018 URL: http://issues.apache.org/jira/browse/GERONIMO-2018 Project: Geronimo Type: Improvement Security: public(Regular issues) Reporter: Dain Sundstrom Assignee: Dain Sundstrom Priority: Blocker Fix For: 1.1 org.apache.geronimo.gbean.NoProxy in AbstractGBeanReference org.apache.geronimo.kernel.config.Marshaler in ConfigurationUtil -- 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: Please try out the upgrade jar
Hi David J., This is very helpful! So far it worked for the simple ejb, war, ear that I've tested. I'll let you know if I ran into problems deploying other modules. Dave Colasurdo, FYI, I tried upgrading my geronimo-web.xml and it was converted from: web-app xmlns=http://geronimo.apache.org/xml/ns/web; ... To: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; ... Maybe the upgrade tool is not expecting: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0; ... Not sure if this is a bug or that's the expected behavior. Chris --- Dave Colasurdo [EMAIL PROTECTED] wrote: Thanks David! It seems to run fine on the simple plans that I have tried though I do have a few quick comments and observations.. 1) Should the version in the schema name be updated (from 1.0 - 1.1) for both jetty and tomcat plans? For example, the following line is unchanged when the tool is run.. web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0; 2) When using a unicode file as input (on windows platform) the output file isn't created in unicode format. 3) On windows platform, it seems that CR (x'0D') is inserted on the end of every line.. This appears as a musical note in my editor :) -Dave- David Jencks wrote: I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar path to source plan [path to target plan] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Please try out the upgrade jar
Thanks for trying it out. I changed how it starts quite a bit today -- I hope it hasn't become too slow. I also think I fixed the schema issue Dave Colasurdo found. thanks david jencks On May 14, 2006, at 3:57 PM, Chris Cardona wrote: Hi David J., This is very helpful! So far it worked for the simple ejb, war, ear that I've tested. I'll let you know if I ran into problems deploying other modules. Dave Colasurdo, FYI, I tried upgrading my geronimo-web.xml and it was converted from: web-app xmlns=http://geronimo.apache.org/xml/ns/web; ... To: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; ... Maybe the upgrade tool is not expecting: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0; ... Not sure if this is a bug or that's the expected behavior. Chris --- Dave Colasurdo [EMAIL PROTECTED] wrote: Thanks David! It seems to run fine on the simple plans that I have tried though I do have a few quick comments and observations.. 1) Should the version in the schema name be updated (from 1.0 - 1.1) for both jetty and tomcat plans? For example, the following line is unchanged when the tool is run.. web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0; 2) When using a unicode file as input (on windows platform) the output file isn't created in unicode format. 3) On windows platform, it seems that CR (x'0D') is inserted on the end of every line.. This appears as a musical note in my editor :) -Dave- David Jencks wrote: I put the upgrade jar at http://people.apache.org/~djencks/geronimo-upgrade-1.1-SNAPSHOT.jar It would be very helpful to find out to what extent this works in real life. It's supposed to include all the classes it needs (that's why its so big) usage: java -jar geronimo-upgrade-1.1-SNAPSHOT.jar path to source plan [path to target plan] if you leave out the target, you'll get output in the same directory as the source. thanks david jencks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-2023) Improve sample app install process
Improve sample app install process -- Key: GERONIMO-2023 URL: http://issues.apache.org/jira/browse/GERONIMO-2023 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: sample apps Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 It could have a nicer download page, and should show some kind of feedback while downloading/installing (ideally AJAX, but at least printouts to stdout). -- 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-1900) Sample app links on welcome app are broken by default
[ http://issues.apache.org/jira/browse/GERONIMO-1900?page=all ] Aaron Mulder resolved GERONIMO-1900: Resolution: Fixed Put in a fairly straightforward welcome app installer. Remaining issues are described in the new linked issue. Prasad, if you have some time to look at that one, it would be great. Sample app links on welcome app are broken by default - Key: GERONIMO-1900 URL: http://issues.apache.org/jira/browse/GERONIMO-1900 Project: Geronimo Type: Bug Security: public(Regular issues) Components: usability, sample apps Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: logo_head_570x86.gif, welcome-10.patch, welcome-2.patch, welcome-3.patch, welcome-4.patch, welcome-6.patch, welcome-7.patch, welcome-8.patch, welcome-9.patch, welcome-images.jar, welcome-images.zip, welcome.patch It would be nice to take users to a page that would prompt them to install the sample if they click a link to it and it's not present. However, automating this would require us to be able to construct a link into a portlet, which does not seem easy. For now, the welcome app can include pages at the locations where the sample apps will be bound, with text to the effect of: This sample has not yet been installed. To install it, visit the (URL)console(/URL) and select the Plugins page, click the Search for Plugins button, and select the (NAME HERE) sample to install. Then visit this same URL again to view the (NAME HERE) example. -- 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-1756) Move from 1.1-dev version of commons-fileupload to version 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1756?page=all ] Aaron Mulder resolved GERONIMO-1756: Fix Version: (was: 1.2) Resolution: Fixed Move from 1.1-dev version of commons-fileupload to version 1.1 -- Key: GERONIMO-1756 URL: http://issues.apache.org/jira/browse/GERONIMO-1756 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Reporter: John Sisson Assignee: Matt Hogstrom Fix For: 1.1 Now that a formal release is available we should move it it as we are currently using a 1.1-dev build and I have no idea what revision that was built from, which makes it hard to debug! Version 1.1 of commons-fileupload was released on 22 Dec 2005 - http://jakarta.apache.org/commons/fileupload/ The dependency commons-io will also need to be upgraded to 1.1 according to the commons-fileupload release notes http://jakarta.apache.org/commons/fileupload/changes-report.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] Resolved: (GERONIMO-1212) Timeouts in commons-fileupload
[ http://issues.apache.org/jira/browse/GERONIMO-1212?page=all ] Aaron Mulder resolved GERONIMO-1212: Fix Version: 1.1 (was: 1.x) Resolution: Fixed Assign To: Aaron Mulder Timeouts in commons-fileupload -- Key: GERONIMO-1212 URL: http://issues.apache.org/jira/browse/GERONIMO-1212 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 We're using a dev build of commons-fileupload to get portlet file upload support. Fairly frequently (but not reproducably often), I get read timeouts from commons-fileupload when I upload to a portlet from Safari. I'm not sure if a newer commons-fileupload build would help (they still don't have a release newer than 2003). Going back and uploading the same file again usually works. It's weird. org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Read timed out at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:376) at org.apache.commons.fileupload.portlet.PortletFileUpload.parseRequest(PortletFileUpload.java:101) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processImportUpload(DatabasePoolPortlet.java:430) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:237) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:277) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
[jira] Commented: (GERONIMO-1981) Web Connector has GBean=(container name) in AbstractName
[ http://issues.apache.org/jira/browse/GERONIMO-1981?page=comments#action_12402249 ] Aaron Mulder commented on GERONIMO-1981: It looks like the GBean=JettyWebContainer part of the ObjectName is only added to the ObjectName of a web connector added at runtime. The code that generates this name is JettyManagerImpl:75 and TomcatManagerImpl:77 Web Connector has GBean=(container name) in AbstractName Key: GERONIMO-1981 URL: http://issues.apache.org/jira/browse/GERONIMO-1981 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 The GBean name for the default Jetty AJP connector appears to be (forgive the URL encoding but this came from the console): geronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%3FGBean%3DJettyWebContainer%2CServiceModule%3Dgeronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%2Cj2eeType%3DGBean%2Cname%3DJettyAJP13Connector The problem is the part of the connector name that appears to say GBean=JettyWebContainer I believe that was introduced in an attempt to have a standard JSR-77 component list its parent module with its parent module type, but that doesn't seem to make sense for parents of type GBean. Can we remove the ParentType=ParentName block for parents of type GBean? If not, then we have a bug that when creating a new web connector we don't add the ParentType=ParentName block. e.g., see JettyManagerImpl.addConnector, which runs this: AbstractName name = kernel.getNaming().createChildName(containerName, uniqueName, NameFactory.GERONIMO_SERVICE); And that gets a name without the GBean=JettyWebConnector, which means even if the name= component is the same as an existing connector, it comes out with a distinct AbstractName. -- 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-1981) Web Connector has GBean=(container name) in AbstractName
[ http://issues.apache.org/jira/browse/GERONIMO-1981?page=all ] David Jencks reassigned GERONIMO-1981: -- Assign To: Dain Sundstrom (was: Aaron Mulder) The problem here is to get a sibling name from an abstract name. We have the web container name, and want to create a sibling name for a new web connector. We don't know what kind of module these are in, so I don't see how to get the parent name for the web container. If we added a method public abstract AbstractName createSiblingName(AbstractName siblingAbstractName, String name, String type); that replaced the name and type in the source name, that would be ideal. What do you think of adding this method to Naming? Web Connector has GBean=(container name) in AbstractName Key: GERONIMO-1981 URL: http://issues.apache.org/jira/browse/GERONIMO-1981 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: Dain Sundstrom Priority: Blocker Fix For: 1.1 The GBean name for the default Jetty AJP connector appears to be (forgive the URL encoding but this came from the console): geronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%3FGBean%3DJettyWebContainer%2CServiceModule%3Dgeronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%2Cj2eeType%3DGBean%2Cname%3DJettyAJP13Connector The problem is the part of the connector name that appears to say GBean=JettyWebContainer I believe that was introduced in an attempt to have a standard JSR-77 component list its parent module with its parent module type, but that doesn't seem to make sense for parents of type GBean. Can we remove the ParentType=ParentName block for parents of type GBean? If not, then we have a bug that when creating a new web connector we don't add the ParentType=ParentName block. e.g., see JettyManagerImpl.addConnector, which runs this: AbstractName name = kernel.getNaming().createChildName(containerName, uniqueName, NameFactory.GERONIMO_SERVICE); And that gets a name without the GBean=JettyWebConnector, which means even if the name= component is the same as an existing connector, it comes out with a distinct AbstractName. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
[ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12402251 ] David Jencks commented on GERONIMO-1638: Backported revisions r378827, r379430, r382366 in rev 406493. We still need to tweak the scripts. Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: John Sisson Fix For: 1.2 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks -- 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-2020) Relative symlinks to the shell scripts were not handled correctly
[ http://issues.apache.org/jira/browse/GERONIMO-2020?page=all ] John Sisson reassigned GERONIMO-2020: - Assign To: John Sisson Relative symlinks to the shell scripts were not handled correctly - Key: GERONIMO-2020 URL: http://issues.apache.org/jira/browse/GERONIMO-2020 Project: Geronimo Type: Bug Security: public(Regular issues) Components: startup/shutdown Versions: 1.0 Environment: UNIX, Linux Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1 Attachments: relative-symlinks.patch Geronimo's shell scripts originated from Tomcat and recently Tomcat had this fix applied to fix issues with relative symlinks. http://mail-archives.apache.org/mod_mbox/tomcat-dev/200603.mbox/[EMAIL PROTECTED] Attaching patch for someone to test on a unix box. -- 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-1934) Incomplete dependency resolution assumes JAR as type
[ http://issues.apache.org/jira/browse/GERONIMO-1934?page=all ] Aaron Mulder resolved GERONIMO-1934: Resolution: Fixed Incomplete dependency resolution assumes JAR as type Key: GERONIMO-1934 URL: http://issues.apache.org/jira/browse/GERONIMO-1934 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core, kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Database pool created by the console: console.dbpool/LaptopStorePool/1.0/rar App that depends on this: sys:dependency sys:artifactIdLaptopStorePool/sys:artifactId /sys:dependency Deployment result: Error: Unable to distribute laptopstore-ear-1.0-SNAPSHOT.ear: Unable to create configuration for deployment load of demo/LaptopStore/1146190482029/car failed Unable to resolve dependency /LaptopStorePool//jar It should not assume that a missing type means JAR but should instead check everything -- 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-1569) improve packaging plugin control of logging.
[ http://issues.apache.org/jira/browse/GERONIMO-1569?page=all ] David Jencks updated GERONIMO-1569: --- Fix Version: 1.1 Backported fix to 1.1 in rev 406500 improve packaging plugin control of logging. Key: GERONIMO-1569 URL: http://issues.apache.org/jira/browse/GERONIMO-1569 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.2, 1.1 The packaging plugin should use GeronimoLogging to initialize and control the log4j system. -- 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-2024) namespace updates were turned off in 1.1
namespace updates were turned off in 1.1 Key: GERONIMO-2024 URL: http://issues.apache.org/jira/browse/GERONIMO-2024 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 apparently early in the 1.1 branch namespace conversions were turned off in org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil line 112. I'm going to turn them back on this is a notice to watch if anything bad happens. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2024) namespace updates were turned off in 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2024?page=comments#action_12402253 ] David Jencks commented on GERONIMO-2024: uncommented the line in rev 406502 lets check for bad effects for a day or two. namespace updates were turned off in 1.1 Key: GERONIMO-2024 URL: http://issues.apache.org/jira/browse/GERONIMO-2024 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 apparently early in the 1.1 branch namespace conversions were turned off in org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil line 112. I'm going to turn them back on this is a notice to watch if anything bad happens. -- 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-1936) WAR deployed with configId with no type isn't treated as WAR by deploy tool, is by console
[ http://issues.apache.org/jira/browse/GERONIMO-1936?page=all ] Aaron Mulder resolved GERONIMO-1936: Resolution: Cannot Reproduce Looks like this was fixed by one of the previous changes? WAR deployed with configId with no type isn't treated as WAR by deploy tool, is by console -- Key: GERONIMO-1936 URL: http://issues.apache.org/jira/browse/GERONIMO-1936 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 When a WAR is deployed with: environment configId groupIdfoo/groupId artifactIdbar/artifactId /configId /environment Then the deploy tool doesn't show URLs for the WAR in its list (e.g. JSR-88 doesn't think it's a WAR?). However, the console does list it in the list of deployed WARs. Need to see what's wrong with the logic in the deploy tool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1905) Confirm deploy/undeploy/redeploy for WARs with no configId
[ http://issues.apache.org/jira/browse/GERONIMO-1905?page=comments#action_12402256 ] Aaron Mulder commented on GERONIMO-1905: If you deploy a web app with no moduleId, you can redeploy it and the settings are migrated to the new version. However, the entry for the new version in config.xml is marked with load=false so it is not started on the next boot. 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 Assignee: 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] Created: (GERONIMO-2025) Undeploy and redeploy with no version leaves dangling entries in config.xml
Undeploy and redeploy with no version leaves dangling entries in config.xml --- Key: GERONIMO-2025 URL: http://issues.apache.org/jira/browse/GERONIMO-2025 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment, kernel Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2 If you deploy an application with no version and then undeploy it, we leave an entry for it (with a timestamp version number) in config.xml, just marked as load=false. If you later deploy the application again, you get a new timestamp version number and a new entry is written into config.xml. Do this (undeploy/deploy) a few times and config.xml gets kind of messy. It would be be good to delete entries from config.xml on undeploy if they have no actual settings. It would be good to detect that a previous version is in conifg.xml but not in the repository and delete the settings from config.xml if the artifact has no version number and a newer copy is deployed. This is not a huge priority since nothing breaks, it just makes config.xml kind of crufty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1905) Confirm deploy/undeploy/redeploy for WARs with no configId
[ http://issues.apache.org/jira/browse/GERONIMO-1905?page=comments#action_12402257 ] Aaron Mulder commented on GERONIMO-1905: Previous behavior fixed. Next problem: if you redeploy with a plan that has an environment with no module ID, the deploy tool calculates a module ID of /// and dies. 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 Assignee: 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
