[jira] Resolved: (GERONIMO-1905) Confirm deploy/undeploy/redeploy for WARs with no configId
[ http://issues.apache.org/jira/browse/GERONIMO-1905?page=all ] Aaron Mulder resolved GERONIMO-1905: Resolution: Fixed > 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] 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
[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_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] 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: > > > foo > bar > > > 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-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] 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] 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] 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: > > LaptopStorePool > > 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] 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] 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-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-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] 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.j
[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-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] 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
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: http://geronimo.apache.org/xml/ns/web"; ... To: http://geronimo.apache.org/xml/ns/j2ee/web-1.1"; ... Maybe the upgrade tool is not expecting: 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.. 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 to source plan> [ 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
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: http://geronimo.apache.org/xml/ns/web"; ... To: http://geronimo.apache.org/xml/ns/j2ee/web-1.1"; ... Maybe the upgrade tool is not expecting: 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.. > 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 to source plan> [ > 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] 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
[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-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] 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] 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-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] 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] 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
