[jira] [Commented] (GERONIMO-5743) ServletContext.getRealPath() returns null
[ https://issues.apache.org/jira/browse/GERONIMO-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085915#comment-13085915 ] Jay D. McHugh commented on GERONIMO-5743: - Is this happening for Tomcat or Jetty (or both)? And, is it returning null when you do not send it a parameter - or when there is a parameter passed in too? ServletContext.getRealPath() returns null - Key: GERONIMO-5743 URL: https://issues.apache.org/jira/browse/GERONIMO-5743 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 3.0-M1 Reporter: Jarek Gawor Assignee: Ivan Fix For: 3.0 In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous versions of Geronimo a real path was returned. Returning null is ok from specification point of view but it breaks compatibility for applications. It also looks like there are a number of web applications that rely on the getRealPath() to return a non-null value. One such application is Nexus web app. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5743) ServletContext.getRealPath() returns null
[ https://issues.apache.org/jira/browse/GERONIMO-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-5743: Comment: was deleted (was: Is this happening for Tomcat or Jetty (or both)? And, is it returning null when you do not send it a parameter - or when there is a parameter passed in too?) ServletContext.getRealPath() returns null - Key: GERONIMO-5743 URL: https://issues.apache.org/jira/browse/GERONIMO-5743 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 3.0-M1 Reporter: Jarek Gawor Assignee: Ivan Fix For: 3.0 In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous versions of Geronimo a real path was returned. Returning null is ok from specification point of view but it breaks compatibility for applications. It also looks like there are a number of web applications that rely on the getRealPath() to return a non-null value. One such application is Nexus web app. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-4130) Unable to preserve comments from plan.xml into config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869772#action_12869772 ] Jay D. McHugh commented on GERONIMO-4130: - This ticket has two parts. The original issue was enabling and disabling services. The issue of comments came up because that used to be the way to accomplish enabling and disabling services. I think that the issue of enabling and disabling services is already handled by the 'load' attribute of the 'module' entities. If I am mistaken about using the load attribute to control whether a particular module starts or not then this ticket is valid. And we need to make sure that there is a simple and straight forward way to determine which modules are started (we also need to make sure that the title of this ticket is changed to reflect the actual problem). If the load attribute does control which modules actually start, then the use of comments in the config.xml file is a completely separate issue. And, it should get it's own (new) ticket. Here is a discussion of how comments are being handled in the config.xml and why. If anyone thinks that it would be worthwhile to handle 'true XML comments' then we should open a new ticket to track that. There is a problem with using 'real' comments. And that problem is that the tools that are being used to parse the XML files completely ignore them. So, whenever one of these files are parsed and then recreated - the comment would be lost. That is why the comment tag was used in the first place. Comments are normally 'for human consumption' only. We needed to put them into the actual XML data in order to tell the parser that they really are a part of the data and not just fluff for people to read. The config.xml file is read in during server start up and recreated from scratch during shutdown. Real XML style comments (and their location within the file) do not appear to be maintained by the parser/builder. We would need to make our own XML parser that internally converted the comments into XML data and a new XML builder that would re-convert that special comment data back into actual comments. Sorry that it took so long for me to realize that I was answering a different problem than the real issue. Lin, Have I finally seen the problem that you were trying to bring up (modifying which services start)? Do you still think that there is a problem with how comments are being handled? Jay Unable to preserve comments from plan.xml into config.xml - Key: GERONIMO-4130 URL: https://issues.apache.org/jira/browse/GERONIMO-4130 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: car-maven-plugin Affects Versions: 2.1.x, 2.2 Reporter: Lin Sun Fix For: 2.2.1, Wish List I got a user asking me how to turn off tomcat access log. It was easy in previous releases, as we could provide comment in config.xml and tell the users to To disable accesslogging uncomment the following section However, with our new config.xml, we don't preserve any comments, which makes hard for users to config things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5216) CLONE -getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851427#action_12851427 ] Jay D. McHugh commented on GERONIMO-5216: - Hey Matthias, It looks like this must be a problem with how the tag library is processing the c:url tag. I will try to take a look as soon as I have some time. Jay CLONE -getContextRoot() returns forward slash rather than empty string for apps deployed to root context Key: GERONIMO-5216 URL: https://issues.apache.org/jira/browse/GERONIMO-5216 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.2 Reporter: Matthias Koch Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3832) Timers created using the Timer Services are not dropeed when the associated ejb module is stopped or undeployed.
[ https://issues.apache.org/jira/browse/GERONIMO-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761715#action_12761715 ] Jay D. McHugh commented on GERONIMO-3832: - Antonio - Could you please double check that this is still a problem on either 2.1.4 or trunk (or both)? I would suspect that it was quietly fixed without updating this ticket. Timers created using the Timer Services are not dropeed when the associated ejb module is stopped or undeployed. Key: GERONIMO-3832 URL: https://issues.apache.org/jira/browse/GERONIMO-3832 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.2, 2.1.1 Environment: windows 2000, jdk 1.5.0 Reporter: Antonio Muñoz Priority: Minor When a periodic timer is scheduled using the geronimo timer service, the ejbtimeout method is called properly every time the period is reached. The problems comes when our ejb module is stopped or undeployed because the ejbtimeout is tried to be called again and again every time the period is reached even when the ejb module is already stopped. The logical solution should be stopping every timer associated to the ejb module is being stopped or undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4901) Shutting down Geronimo destroys pending Timers
Shutting down Geronimo destroys pending Timers -- Key: GERONIMO-4901 URL: https://issues.apache.org/jira/browse/GERONIMO-4901 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: Geronimo 2.1.4 Reporter: Jay D. McHugh Here is what SEEMS to be happening: Shutting down and bringing Geronimo back up seems to be effectively undeploying everything, then redeploying it. So, pending Timers are being destroyed. This may not be the actual cause of this - Based upon the log entries during shutdown and restart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4901) Shutting down Geronimo destroys pending Timers
[ https://issues.apache.org/jira/browse/GERONIMO-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761772#action_12761772 ] Jay D. McHugh commented on GERONIMO-4901: - Here is a portion of the geronimo.log file that seems to show my app being disassembled during shutdown and reconstituted during startup: (Using current 2.1.5 snapshot as of 10/02/2009) During shutdown: 2009-10-02 18:01:56,810 INFO [startup] Undeploying app: /opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil4824243862298920212.jar 2009-10-02 18:01:56,835 INFO [startup] Undeploying app: /opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil1436047464632244742.jar 2009-10-02 18:02:02,120 INFO [startup] Undeploying app: /usr/src/mavenRepository/org/apache/geronimo/plugins/geronimo-mejb/2.1.5-SNAPSHOT/geronimo-mejb-2.1.5-SNAPSHOT.jar 2009-10-02 18:02:02,163 INFO [remote] Received stop signal While coming back up - after starting all of the Geronimo services: 2009-10-02 18:10:54,602 INFO [startup] Assembling app: /opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil4824243862298920212.jar 2009-10-02 18:10:58,546 INFO [startup] Jndi(name=ComponentClassBeanLocal) -- Ejb(deployment-id=palmBeans.jar/ComponentClassBean) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=VClean7Local) -- Ejb(deployment-id=palmBeans.jar/VClean7) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=GenericComponentBeanLocal) -- Ejb(deployment-id=palmBeans.jar/GenericComponentBean) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=VClean2Local) -- Ejb(deployment-id=palmBeans.jar/VClean2) 2009-10-02 18:10:58,547 INFO [startup] Jndi(name=ESDBeanLocal) -- Ejb(deployment-id=palmBeans.jar/ESDBean) .. Shutting down Geronimo destroys pending Timers -- Key: GERONIMO-4901 URL: https://issues.apache.org/jira/browse/GERONIMO-4901 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: Geronimo 2.1.4 Reporter: Jay D. McHugh Here is what SEEMS to be happening: Shutting down and bringing Geronimo back up seems to be effectively undeploying everything, then redeploying it. So, pending Timers are being destroyed. This may not be the actual cause of this - Based upon the log entries during shutdown and restart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4723) Replace our dojo repackaging with the released dojo-war
[ https://issues.apache.org/jira/browse/GERONIMO-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12730511#action_12730511 ] Jay D. McHugh commented on GERONIMO-4723: - (I accidentally put the wrong Jira number in the commit comment) Sendingplugins/dojo/dojo-jetty/pom.xml Sendingplugins/dojo/dojo-jetty/src/main/history/dependencies.xml Sendingplugins/dojo/dojo-tomcat/pom.xml Sendingplugins/dojo/dojo-tomcat/src/main/history/dependencies.xml Sendingplugins/dojo/pom.xml Transmitting file data . Committed revision 793687. Replace our dojo repackaging with the released dojo-war --- Key: GERONIMO-4723 URL: https://issues.apache.org/jira/browse/GERONIMO-4723 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: web Affects Versions: 2.2 Reporter: David Jencks Attachments: GERONIMO-2723.patch dojo has a dojo-war that looks pretty similar to our repacked dojo war. I can't quite tell if it works. Maybe someone who understands what dojo does could try it? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4130) Unable to preserve comments from plan.xml into config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715948#action_12715948 ] Jay D. McHugh commented on GERONIMO-4130: - I just checked 2.1.5 to see if the comment function was still working. And it is. Is it not working in 2.2? The way to put in comments is to wrap them in a comment element. example commentThis will be preserved/comment You should be able to add a comment element at any level of the config. Unable to preserve comments from plan.xml into config.xml - Key: GERONIMO-4130 URL: https://issues.apache.org/jira/browse/GERONIMO-4130 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: car-maven-plugin Affects Versions: 2.1.x, 2.2 Reporter: Lin Sun Fix For: Wish List I got a user asking me how to turn off tomcat access log. It was easy in previous releases, as we could provide comment in config.xml and tell the users to To disable accesslogging uncomment the following section However, with our new config.xml, we don't preserve any comments, which makes hard for users to config things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4527: Attachment: geronimo-4527.diff Put all of the changes here so that there would be an easily reviewable set of changes if anyone cared to see what was changed to fix the build. Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-4527. - Resolution: Fixed Fix Version/s: 2.0.3 Changes committed to branches/2.0 Sending modules/geronimo-client/src/main/java/org/apache/geronimo/client/AppClientContainer.java Sending modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java Sending modules/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbRefBuilder.java Sendingpom.xml Transmitting file data Committed revision 740608. Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3 Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670246#action_12670246 ] Jay D. McHugh commented on GERONIMO-4527: - I have been trying to get 2.0 ready for release - including removing dependencies on beta versions. When I moved it to point it at OpenEJB 3.0 (rather than 3.0-beta-1), the build stopped working. If you switch away from the beta version, does the build still work for you? Geronimo 2.0.x branch does not build with tests --- Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3 Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0)
[ https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4527: Description: Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 3.0, the build stopped working. Due to changes in the group/artifact names of the artifacts for XBeans - OpenEJB 3.0 no longer builds. There is now a new snapshot version of OpenEJB (3.0.1-SNAPSHOT). These changes include the new snapshot version of OpenEJB rather than the unbuildable 3.0 version. was:Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. Summary: Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0) (was: Geronimo 2.0.x branch does not build with tests) Sorry for any confusion. This issue sprung up as a result of removing the dependency to the beta version of OpenEJB locally. Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0) - Key: GERONIMO-4527 URL: https://issues.apache.org/jira/browse/GERONIMO-4527 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, kernel, OpenEJB Affects Versions: 2.0.3 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3 Attachments: geronimo-4527.diff Because of a number of changes that have occurred in dependencies of Geronimo it will no longer build. In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 3.0, the build stopped working. Due to changes in the group/artifact names of the artifacts for XBeans - OpenEJB 3.0 no longer builds. There is now a new snapshot version of OpenEJB (3.0.1-SNAPSHOT). These changes include the new snapshot version of OpenEJB rather than the unbuildable 3.0 version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed
[ https://issues.apache.org/jira/browse/GERONIMO-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-1907. - Resolution: Won't Fix Assignee: Jay D. McHugh (was: Rakesh Midha) When an app is undeployed (as part of a redeploy) any other apps that depend on it are stopped. Trying to track down all apps that depend on the current app so that they can be automatically restarted is too much effort to expend in the 2.0.x branch. If there is sufficient interest - a new JIRA should be opened in a more current/active branch. Deploy command should redeploy if the app is already deployed - Key: GERONIMO-1907 URL: https://issues.apache.org/jira/browse/GERONIMO-1907 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, usability Affects Versions: 1.1 Reporter: Aaron Mulder Assignee: Jay D. McHugh Priority: Critical Fix For: 2.0.3 Attachments: redeploy.patch Attached patch, and changing fix version to 1.2. Also unassigning so that committers can review and update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1354) The var/config.xml file is always re-written even if no attribute changes are made by the user
[ https://issues.apache.org/jira/browse/GERONIMO-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-1354. --- The var/config.xml file is always re-written even if no attribute changes are made by the user -- Key: GERONIMO-1354 URL: https://issues.apache.org/jira/browse/GERONIMO-1354 Project: Geronimo Issue Type: Wish Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0 Reporter: John Sisson Assignee: Jay D. McHugh Fix For: 2.0.3 This means the user can never edit the config.xml file while Geronimo is running. The user has to shut down Geronimo and then make their changes and therefore the amount of time to implement a change is longer than needed. For 1.0 I will add some extra text to the warning in the top of the config.xml file ( see org.apache.geronimo.system.configuration.ServerOverride) that tells the user not to edit the file whilst Geronimo is running. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2128) Allow user to specify the Isolation Level for a CMP bean's SQL access
[ https://issues.apache.org/jira/browse/GERONIMO-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2128: Fix Version/s: (was: 2.0.3) (was: 1.x) 2.0.4 Allow user to specify the Isolation Level for a CMP bean's SQL access - Key: GERONIMO-2128 URL: https://issues.apache.org/jira/browse/GERONIMO-2128 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Matt Hogstrom Fix For: 2.0.4 Currently CMP beans all execute in the default isolation level of the datasource. This means that in many situations higher level locks are required for the database access than are required. This improvement will allow the user to specify a new attribute on a CMP entity bean isolation-level that will be the isolation level used for database access on this entity bean. This will require updates to OpenEJB and TranQL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly
[ https://issues.apache.org/jira/browse/GERONIMO-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2288: Fix Version/s: (was: 2.0.3) 2.0.4 Abstract/Maven repositories install modules incorrectly --- Key: GERONIMO-2288 URL: https://issues.apache.org/jira/browse/GERONIMO-2288 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel, Plugins Affects Versions: 1.1, 1.1.1, 1.2, 2.0-M6 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 2.0.4 The repository unpacks a JAR when it installs it only if the Artifact type is car. That is incorrect -- it should unpack any module with META-INF/config.ser (which is the logic that we use in other places, such as RepositoryConfigurationStore). This breaks plugins that don't have the type car (such as copying a database pool from server to server). The currently handling attempts to be generic by associating a behavior with each file type, though in practice this is only used for type=car. In the 1.1 branch, I am going to put in a workaround to look up the car handler any time we find a META-INF/config.ser (a pretty minimal workaround). In trunk, I think we should remove the behavior/type association and instead have a boolean for whether configurations should be unpacked, or an ArtifactTypeHandler property specifically for configurations and another one for non-configurations. I don't see any reason to distinguish based on module type. Input would be appreciated for the 1.2 resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2045) Plugin prerequisites: for DB pools, support DB type/version and table validation
[ https://issues.apache.org/jira/browse/GERONIMO-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2045: Fix Version/s: (was: 2.0.3) (was: 1.x) 2.0.4 Plugin prerequisites: for DB pools, support DB type/version and table validation Key: GERONIMO-2045 URL: https://issues.apache.org/jira/browse/GERONIMO-2045 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 2.0.4 More robust database pool prerequisites for plugins: - check that one of a specific set of RDBMS name/version combinations is set for a connection pool prerequisite - check the schema somehow -- e.g. that some table exists, or some query returns an expected value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1842) Dynamically load jars from the WEB-INF/lib directory
[ https://issues.apache.org/jira/browse/GERONIMO-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-1842: Fix Version/s: (was: 2.0.3) (was: 1.x) 2.0.4 Dynamically load jars from the WEB-INF/lib directory Key: GERONIMO-1842 URL: https://issues.apache.org/jira/browse/GERONIMO-1842 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Reporter: Prasad Kashyap Fix For: 2.0.4 Currently the server has a hardcoded list of what it expects in the WEB-INF/lib dir. This means that additions/deletion of jars in that directory will not be picked up without actually redeploying that app. This seems like a major irritant. The best thing of course would be to dynamically pick up or drop jars from the lib directory as they are added/deleted. But we can, for now, settle for loading/unloading them at an app restart. This should be the bare minimum requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException
[ https://issues.apache.org/jira/browse/GERONIMO-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3815: Fix Version/s: (was: 2.0.3) 2.0.4 ContextManager.getCurrentContext() throws NullPointerException -- Key: GERONIMO-3815 URL: https://issues.apache.org/jira/browse/GERONIMO-3815 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.4, 2.1.4, 2.2 Attachments: GERONIMO-3815-2.debug.patch, GERONIMO-3815-3.debug.patch, GERONIMO-3815.debug.patch ContextManager.getCurrentContext() is throwing a NullPointerException. This is observed only when there is heavy load on the application. Most likely it is a threading issue where one thread is unregistering the subject while another is executing getCurrentContext(). Excerpt from stacktrace given below. Caused by: java.lang.NullPointerException at org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:197) at org.apache.geronimo.openejb.GeronimoSecurityService.isCallerAuthorized(GeronimoSecurityService.java:101) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:142) at org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267) at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy16.create(Unknown Source) ... 53 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4124) Tomcat jacc usage is messed up
[ https://issues.apache.org/jira/browse/GERONIMO-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4124: Fix Version/s: (was: 2.0.3) 2.0.4 Tomcat jacc usage is messed up -- Key: GERONIMO-4124 URL: https://issues.apache.org/jira/browse/GERONIMO-4124 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.4, 2.1.4, 2.2 Several problems: 1. UserDataPermissions are not getting evaluated by jacc due to the check for Subject in handler data. 2. Subject is never set into handler data (also a problem in jetty, dunno about openejb). 3. TomcatGeronimoRealm is calling ContextManager.setCallers before permission checks. This is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4222: Fix Version/s: (was: 2.0.3) 2.0.4 Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1, 2.1.1, 2.1.2, 2.1.4, 2.2 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Donald Woods Fix For: 2.0.4, 2.1.4, 2.2 Attachments: before and after wasce restart.txt, stacktrace.txt I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1807) Remove uses of ObjectName from core server
[ https://issues.apache.org/jira/browse/GERONIMO-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-1807: Fix Version/s: (was: 2.0.3) 2.0.4 Remove uses of ObjectName from core server -- Key: GERONIMO-1807 URL: https://issues.apache.org/jira/browse/GERONIMO-1807 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Reporter: Dain Sundstrom Fix For: 2.0.4 Using the ObjectName class in the core server causes a dependency on the jmx classes. We are also in the process of moving away from these, but there are still many places that use this class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4295) Upgrade to Derby 10.4.2.0
[ https://issues.apache.org/jira/browse/GERONIMO-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-4295: Fix Version/s: (was: 2.0.3) 2.0.4 Upgrade to Derby 10.4.2.0 - Key: GERONIMO-4295 URL: https://issues.apache.org/jira/browse/GERONIMO-4295 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.0.3, 2.1.3, 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 2.0.4, 2.1.4, 2.2 Upgrade to Derby 10.4.2.0, which was released on Sept. 5, 2008. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4368) OpenJPA can't find org.postgresql.Driver
[ https://issues.apache.org/jira/browse/GERONIMO-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641431#action_12641431 ] Jay D. McHugh commented on GERONIMO-4368: - I believe that what Donald meant when he said to copy the newer OpenJPA files over top the old ones was to replace them - change the new file names so that they overwrite the old ones. Not to remove the 1.0.3 version and install a 1.2.0 version. There are other areas within Geronimo that will still be looking for the old version. OpenJPA can't find org.postgresql.Driver Key: GERONIMO-4368 URL: https://issues.apache.org/jira/browse/GERONIMO-4368 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1.3 Environment: Linux gentoo, JDK IBM 1.6, Reporter: Michał Kudła Priority: Blocker Tutorial from http://www.jaceklaskowski.pl/wiki/Aplikacja_Java_EE_5_z_MDB_z_JPA_w_trybie_JTA_i_PostgreSQL_w_Apache_Geronimo_2 http://www.jaceklaskowski.pl/aplikacje/mdb-jpa-jta-postgresql-geronimo.zip works fine under geronimo 2.1 but not work under 2.1.3. [EMAIL PROTECTED] ~/Programy/geronimo-tomcat6-javaee5-2.1.3/bin $ ./geronimo.sh run -vv Using GERONIMO_BASE: /home/m1k0/Programy/geronimo-tomcat6-javaee5-2.1.3 Using GERONIMO_HOME: /home/m1k0/Programy/geronimo-tomcat6-javaee5-2.1.3 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/opt/ibm-jdk-bin-1.6.0.2/jre 13:24:43,096 DEBUG [BasicKernel] Starting boot cut/ 13:30:06,159 INFO [DirectoryHotDeployer] Deploying TicketServiceEAR.ear 13:30:06,687 INFO [config] Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) 13:30:06,688 INFO [config] Configuring Service(id=Default Stateful Container, type=Container, provider-id=Default Stateful Container) 13:30:06,691 INFO [config] Configuring Service(id=Default BMP Container, type=Container, provider-id=Default BMP Container) 13:30:06,691 INFO [config] Configuring Service(id=Default CMP Container, type=Container, provider-id=Default CMP Container) 13:30:06,692 INFO [config] Configuring app: pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear 13:30:06,778 INFO [OpenEJB] Auto-deploying ejb TicketServiceBean: EjbDeployment(deployment-id=TicketServiceMDB.jar/TicketServiceBean) 13:30:06,783 INFO [config] Loaded Module: pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear 13:30:08,259 INFO [config] Configuring Service(id=jms-resources.jms-resources-javax.jms.MessageListener, type=Container, provider-id=Default MDB Container) 13:30:08,260 INFO [service] Creating Container(id=jms-resources.jms-resources-javax.jms.MessageListener) 13:30:08,312 INFO [KernelContextGBean] bound gbean pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear?J2EEApplication=pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear,JCAConnectionFactory=TicketConnectionFactory,JCAResource=jms-resources,ResourceAdapter=jms-resources,ResourceAdapterModule=jms-resources,j2eeType=JCAManagedConnectionFactory,name=TicketConnectionFactory at name pl.jaceklaskowski.ticketservice/TicketServiceEAR/JCAManagedConnectionFactory/TicketConnectionFactory 13:30:08,317 INFO [KernelContextGBean] bound gbean pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear?J2EEApplication=pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear,JCAResource=jms-resources,ResourceAdapter=jms-resources,ResourceAdapterModule=jms-resources,j2eeType=JCAAdminObject,name=TicketQueue at name pl.jaceklaskowski.ticketservice/TicketServiceEAR/JCAAdminObject/TicketQueue 13:30:08,414 INFO [KernelContextGBean] bound gbean pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear?J2EEApplication=pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear,JCAConnectionFactory=jdbc/postgres,JCAResource=postgresql,ResourceAdapter=postgresql,ResourceAdapterModule=postgresql,j2eeType=JCAManagedConnectionFactory,name=jdbc/postgres at name pl.jaceklaskowski.ticketservice/TicketServiceEAR/JCAManagedConnectionFactory/jdbc/postgres 13:30:08,416 INFO [startup] Assembling app: /home/m1k0/Programy/geronimo-tomcat6-javaee5-2.1.3/var/temp/geronimo-deploymentUtil17068.jar
[jira] Closed: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3921. --- Jetty was not an issue. They did not have the same check for apps deployed to the root context. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.3, 2.1.1, 2.2 An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4150) Tutorials - Developing a JAX-WS POJO Web Service
[ https://issues.apache.org/jira/browse/GERONIMO-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609972#action_12609972 ] Jay D. McHugh commented on GERONIMO-4150: - I went through the tutorial (up through the web client) and everything went fine. The one problem I saw was that the screen shots showed different conversion methods than the ones discussed in the tutorial (the screenshots showed temperature conversions). Otherwise, an easy to follow working tutorial. Thanks for putting it together. Tutorials - Developing a JAX-WS POJO Web Service Key: GERONIMO-4150 URL: https://issues.apache.org/jira/browse/GERONIMO-4150 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: documentation Affects Versions: 2.1, 2.1.1 Reporter: Sainath Chowdary Assignee: Shiva Kumar H R Geronimo v2.1 documentation, Tutorials section. Develop a tutorial for Building a JAX-WS POJO Web Service addressing the following common topics (use this list as the initial guideline). This document should also match the styling used in the existing tutorials. * Setting up Eclipse for Application development * Sample application overview identify the different components * Prerequisites external resources (i.e. databases, connection pools, JMS queues, etc) * Sample app creation breakdown into multiple bullets * Deploy and Test the application See http://cwiki.apache.org/GMOxDOC21/tutorials.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4108) Upgrade Dojo to version 1.1.1
[ https://issues.apache.org/jira/browse/GERONIMO-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-4108. - Resolution: Fixed Fix Version/s: 2.2 Only changed over in trunk. Geronimo 2.1.x is still using Dojo 1.0.2 - Is there anyone who thinks we need to upgrade it as well? Upgrade Dojo to version 1.1.1 - Key: GERONIMO-4108 URL: https://issues.apache.org/jira/browse/GERONIMO-4108 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.2 Dojo version 1.1.1 has been released. It is completely backwards compatible with the current 1.1.0 version Geronimo is currently using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4108) Upgrade Dojo to version 1.1.1
Upgrade Dojo to version 1.1.1 - Key: GERONIMO-4108 URL: https://issues.apache.org/jira/browse/GERONIMO-4108 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo version 1.1.1 has been released. It is completely backwards compatible with the current 1.1.0 version Geronimo is currently using. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3931. - Resolution: Fixed Fix Version/s: 2.2 2.1.x 2.1.2 No one updated the JIRA with any new information. This appears to have already been fixed. Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain Assignee: Jay D. McHugh Fix For: 2.1.2, 2.1.x, 2.2 While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3931. --- Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain Assignee: Jay D. McHugh Fix For: 2.1.2, 2.1.x, 2.2 While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3460) EAR will not display properly at the / context root (tomcat only)
[ https://issues.apache.org/jira/browse/GERONIMO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3460: --- Assignee: Jay D. McHugh EAR will not display properly at the / context root (tomcat only) --- Key: GERONIMO-3460 URL: https://issues.apache.org/jira/browse/GERONIMO-3460 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Tomcat Affects Versions: 2.0.1 Environment: G v 2.0.1 (tomcat), windows xp Reporter: Viet Hung Nguyen Assignee: Jay D. McHugh Priority: Critical Fix For: 2.0.x Attachments: college_fest.ear When an EAR is deployed at the / context root (using tomcat) there are problems viewing the webapp. These problems exists under these conditions: 1. EAR never works on the initial deploy 2. EAR never works on server startup The only way I have gotten these EARs to work is to: 1. change the context-root to something not / (but I shouldn't have to do this) 2. redeploy the EAR 3. restart the EAR 4. undeploy, then deploy the EAR To reproduce the problem, use the attached EAR, uninstall any WAR that is using / as its context-root, deploy the EAR and visit http://localhost:8080/ Note: When the WAR inside the EAR is deployed, everything works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3460) EAR will not display properly at the / context root (tomcat only)
[ https://issues.apache.org/jira/browse/GERONIMO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3460. --- EAR will not display properly at the / context root (tomcat only) --- Key: GERONIMO-3460 URL: https://issues.apache.org/jira/browse/GERONIMO-3460 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Tomcat Affects Versions: 2.0.1 Environment: G v 2.0.1 (tomcat), windows xp Reporter: Viet Hung Nguyen Assignee: Jay D. McHugh Priority: Critical Fix For: 2.0.x Attachments: college_fest.ear When an EAR is deployed at the / context root (using tomcat) there are problems viewing the webapp. These problems exists under these conditions: 1. EAR never works on the initial deploy 2. EAR never works on server startup The only way I have gotten these EARs to work is to: 1. change the context-root to something not / (but I shouldn't have to do this) 2. redeploy the EAR 3. restart the EAR 4. undeploy, then deploy the EAR To reproduce the problem, use the attached EAR, uninstall any WAR that is using / as its context-root, deploy the EAR and visit http://localhost:8080/ Note: When the WAR inside the EAR is deployed, everything works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3460) EAR will not display properly at the / context root (tomcat only)
[ https://issues.apache.org/jira/browse/GERONIMO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3460. - Resolution: Duplicate Duplicate of Geronimo-3921. I missed this JIRA when I created the other one. EAR will not display properly at the / context root (tomcat only) --- Key: GERONIMO-3460 URL: https://issues.apache.org/jira/browse/GERONIMO-3460 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Tomcat Affects Versions: 2.0.1 Environment: G v 2.0.1 (tomcat), windows xp Reporter: Viet Hung Nguyen Assignee: Jay D. McHugh Priority: Critical Fix For: 2.0.x Attachments: college_fest.ear When an EAR is deployed at the / context root (using tomcat) there are problems viewing the webapp. These problems exists under these conditions: 1. EAR never works on the initial deploy 2. EAR never works on server startup The only way I have gotten these EARs to work is to: 1. change the context-root to something not / (but I shouldn't have to do this) 2. redeploy the EAR 3. restart the EAR 4. undeploy, then deploy the EAR To reproduce the problem, use the attached EAR, uninstall any WAR that is using / as its context-root, deploy the EAR and visit http://localhost:8080/ Note: When the WAR inside the EAR is deployed, everything works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602734#action_12602734 ] Jay D. McHugh commented on GERONIMO-3921: - Has anyone checked to confirm that this works in Jetty? If not, I'll check in the next few days and close this issue. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1.1, 2.2 An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590587#action_12590587 ] Jay D. McHugh commented on GERONIMO-3931: - It also works in branches/2.1 (2.1.2-Snapshot) which probably means that it works in 2.1.1 I will check branches/2.1.1 just to make sure. Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3931: --- Assignee: Jay D. McHugh Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain Assignee: Jay D. McHugh While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590612#action_12590612 ] Jay D. McHugh commented on GERONIMO-3931: - Also working in branches/2.1.1. If someone can show that this is a problem, please update the JIRA. Otherwise, I'll close it on 4/21 at about 5:00 PM CDT. Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590274#action_12590274 ] Jay D. McHugh commented on GERONIMO-3931: - This appears to be fixed in trunk. I will check to see if it is corrected in 2.1.1 tomorrow (or possibly later tonight). Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579991#action_12579991 ] Jay D. McHugh commented on GERONIMO-3921: - Jarek, I just checked the Jetty 'wrapper' around the getContext method and it does not have the same check for the first character not being a '/'. So it _should_ be functioning correctly. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1, 2.0.2, 2.0.1, 2.0, 2.0.x, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578906#action_12578906 ] Jay D. McHugh commented on GERONIMO-3921: - Fix committed to branches/2.1 Sending plugins/tomcat/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java Transmitting file data . Committed revision 637227. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578907#action_12578907 ] Jay D. McHugh commented on GERONIMO-3921: - Fixed it too fast. Forgot the parens on the length function to the fix on trunk (branches/2.1 was correct). Sending plugins/tomcat/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java Transmitting file data . Committed revision 637232. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context
[ https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578903#action_12578903 ] Jay D. McHugh commented on GERONIMO-3921: - Fix committed to trunk. Sending plugins/tomcat/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java Transmitting file data . Committed revision 637223. getContextRoot() returns forward slash rather than empty string for apps deployed to root context - Key: GERONIMO-3921 URL: https://issues.apache.org/jira/browse/GERONIMO-3921 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Jay D. McHugh Assignee: Jay D. McHugh An app deployed to the root context should have returned by getContextRoot() - On Tomcat, we are returning /. dcherk wrote: I am deploying my war file into the root context with the following deployment plan: -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.2; ... context-root/context-root ... /web-app -- The application starts up properly, and responds on http://localhost, as expected. However, when I examine request.getContextPath(), I get a forward slash: /. This is incorrect, as far as I can tell. According to the API (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()): -- For servlets in the default (root) context, this method [HttpServletRequest.html.getContextPath()] returns . -- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3855) PortletSecurityException in Plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3855: --- Assignee: Jay D. McHugh PortletSecurityException in Plugins portlet --- Key: GERONIMO-3855 URL: https://issues.apache.org/jira/browse/GERONIMO-3855 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Jay D. McHugh Cannot take any actions in the Plugins portlet. Recreate: Go to the Plugins portlet in the admin console Click any action-- Update Repository List or Add Repository or Export a Plugin or Assemble a Server Note the exception: javax.servlet.ServletException: javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3855) PortletSecurityException in Plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570527#action_12570527 ] Jay D. McHugh commented on GERONIMO-3855: - It appears that Pluto is not currently performing any special handling of multipage portlets over https. So, based on some posts on the Pluto mailing lists these changes simply block the exception that was being thrown in the setSecure() method. Sendingpom.xml Deleting repository/org/apache/pluto/1.2.0-G601060.README.TXT Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT Adding repository/org/apache/pluto/geronimo-3855.patch Deleting repository/org/apache/pluto/pluto-container/1.2.0-G601060 Deleting repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061/pluto-portal-driver-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-taglib/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar Transmitting file data Committed revision 629300. PortletSecurityException in Plugins portlet --- Key: GERONIMO-3855 URL: https://issues.apache.org/jira/browse/GERONIMO-3855 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Jay D. McHugh Cannot take any actions in the Plugins portlet. Recreate: Go to the Plugins portlet in the admin console Click any action-- Update Repository List or Add Repository or Export a Plugin or Assemble a Server Note the exception: javax.servlet.ServletException: javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3855) PortletSecurityException in Plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570527#action_12570527 ] jaydm edited comment on GERONIMO-3855 at 2/19/08 5:24 PM: -- It appears that Pluto is not currently performing any special handling of multipage portlets over https. So, based on some posts on the Pluto mailing lists these changes simply block the exception that was being thrown in the setSecure() method. Committed on trunk: Sendingpom.xml Deleting repository/org/apache/pluto/1.2.0-G601060.README.TXT Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT Adding repository/org/apache/pluto/geronimo-3855.patch Deleting repository/org/apache/pluto/pluto-container/1.2.0-G601060 Deleting repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061/pluto-portal-driver-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-taglib/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar Transmitting file data Committed revision 629300. was (Author: jaydm): It appears that Pluto is not currently performing any special handling of multipage portlets over https. So, based on some posts on the Pluto mailing lists these changes simply block the exception that was being thrown in the setSecure() method. Sendingpom.xml Deleting repository/org/apache/pluto/1.2.0-G601060.README.TXT Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT Adding repository/org/apache/pluto/geronimo-3855.patch Deleting repository/org/apache/pluto/pluto-container/1.2.0-G601060 Deleting repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061/pluto-portal-driver-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-taglib/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar Transmitting file data Committed revision 629300. PortletSecurityException in Plugins portlet --- Key: GERONIMO-3855 URL: https://issues.apache.org/jira/browse/GERONIMO-3855 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Jay D. McHugh Cannot take any actions in the Plugins portlet. Recreate: Go to the Plugins portlet in the admin console Click any action-- Update Repository List or Add Repository or Export a Plugin or Assemble a Server Note the exception: javax.servlet.ServletException:
[jira] Commented: (GERONIMO-3855) PortletSecurityException in Plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570540#action_12570540 ] Jay D. McHugh commented on GERONIMO-3855: - Committed to branches/2.1 Sendingpom.xml Deleting repository/org/apache/pluto/1.2.0-G601060.README.TXT Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT Adding repository/org/apache/pluto/geronimo-3855.patch Deleting repository/org/apache/pluto/pluto-container/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-container/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-container/1.2.0-G601061/pluto-container-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar Deleting repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060 Deleting repository/org/apache/pluto/pluto-taglib/1.2.0-G601060 Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061 Adding (bin) repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar Transmitting file data Committed revision 629312. PortletSecurityException in Plugins portlet --- Key: GERONIMO-3855 URL: https://issues.apache.org/jira/browse/GERONIMO-3855 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Jay D. McHugh Cannot take any actions in the Plugins portlet. Recreate: Go to the Plugins portlet in the admin console Click any action-- Update Repository List or Add Repository or Export a Plugin or Assemble a Server Note the exception: javax.servlet.ServletException: javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3855) PortletSecurityException in Plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3855. --- Resolution: Fixed Fix Version/s: 2.2 2.1.1 2.1 Committed to both branches/2.1 and trunk (2.0 still uses Pluto 1.0). Everywhere that I checked has worked, but please take a second to test. PortletSecurityException in Plugins portlet --- Key: GERONIMO-3855 URL: https://issues.apache.org/jira/browse/GERONIMO-3855 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Paul McMahan Assignee: Jay D. McHugh Fix For: 2.1, 2.1.1, 2.2 Cannot take any actions in the Plugins portlet. Recreate: Go to the Plugins portlet in the admin console Click any action-- Update Repository List or Add Repository or Export a Plugin or Assemble a Server Note the exception: javax.servlet.ServletException: javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) root cause javax.portlet.PortletSecurityException: No Supported org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3596) Unintuitive workings of the MySQL DBPool deployment wizard
[ https://issues.apache.org/jira/browse/GERONIMO-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562347#action_12562347 ] Jay D. McHugh commented on GERONIMO-3596: - Committed a version change for the tranql wrappers in 2.0.3+. Sendingpom.xml Transmitting file data . Committed revision 615101. Tested the creation of a mysql database pool - the 'url' prompt is gone now. Unintuitive workings of the MySQL DBPool deployment wizard -- Key: GERONIMO-3596 URL: https://issues.apache.org/jira/browse/GERONIMO-3596 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector, databases, deployment Affects Versions: 2.0.2 Environment: ogre% uname -a FreeBSD ogre 7.0-BETA2 FreeBSD 7.0-BETA2 #4: Sat Nov 10 15:29:36 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OGRE amd64 ogre% java -version java version 1.6.0_02-p2 Java(TM) SE Runtime Environment (build 1.6.0_02-p2-root_04_nov_2007_14_03-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_02-p2-root_04_nov_2007_14_03-b00, mixed mode) Nothing else. I don't think it matters at all for this bug report anyway. Reporter: Jesper Louis Andersen Assignee: David Jencks Fix For: 2.1 Attachments: tranql-connector-mysql-local-1.2-SNAPSHOT.rar There is an unintuitive gotcha hidden in the DBPool wizard for the MySQL (and probably also the MySQL-XA) driver. It manifests itself with a NullPointerException when trying to connect to a database. See for instance the following mail: http://spteam-lists.blogspot.com/2007/11/re-apache-geronimo-202-and-mysql-data.html The reason is that if you DON'T fill out the URL field, you get the following deployment plan: ?xml version=1.0 encoding=UTF-8? connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector-1.2; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; dep:moduleId dep:groupIdconsole.dbpool/dep:groupId dep:artifactIdcxnet/dep:artifactId dep:version1.0/dep:version dep:typerar/dep:type /dep:moduleId dep:dependencies dep:dependency dep:groupIdmysql/dep:groupId dep:artifactIdmysql-connector-java/dep:artifactId dep:version5.1.5/dep:version dep:typejar/dep:type /dep:dependency /dep:dependencies /dep:environment resourceadapter outbound-resourceadapter connection-definition connectionfactory-interfacejavax.sql.DataSource/connectionfactory-interface connectiondefinition-instance namecxnet/name config-property-setting name=DatabaseNamefoo/config-property-setting config-property-setting name=Passwordfoo/config-property-setting config-property-setting name=UserNamefoo/config-property-setting config-property-setting name=URL/ connectionmanager no-transaction/ single-pool max-size10/max-size min-size0/min-size match-one/ /single-pool /connectionmanager /connectiondefinition-instance /connection-definition /outbound-resourceadapter /resourceadapter /connector + Notice the Empty URL parameter. Quick workaround: Supply the URL parameter or use the 'show plan' feature and add the URL in the plan. Steps to reproduce: 1. Add a mysql-connector-java JAR to the library section. I used 5.1.5 as a version, but it also fails with 5.0.8 and 3.1.14. 2. Click Database Pools - Wizard - choose 'foo' and MySQL as driver 3. Enter the fields: pool name, database driver, port number, user name, server name, database name, password and confirm password take care NOT to enter the URL. 4. Now click 'show plan'. It this point it should be obvious that we are trying to deploy a plan without an URL. The idea for a fix: 1. Gather fields from input. 2. If URL is empty, stitch together one from the other parameters. 3. Use the constructed URL. And do take care to report this back to the guy in the linked mail above ;) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3451: --- Assignee: Jay D. McHugh Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561891#action_12561891 ] Jay D. McHugh commented on GERONIMO-3451: - Resolved this issue on trunk with a new version of tomcat private snapshot including the latest security patch and djencks patch for the restricted listener fix. Sendingpom.xml Adding repository/org/apache/tomcat/6.0.14-G614585.README.TXT Adding repository/org/apache/tomcat/catalina/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar Adding repository/org/apache/tomcat/jasper/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar Transmitting file data Committed revision 614754. Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3451. - Resolution: Fixed Fix Version/s: 2.1 Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1 During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561895#action_12561895 ] Jay D. McHugh commented on GERONIMO-3451: - Checked into branches/2.0 also: Sendingpom.xml Adding repository/org/apache/tomcat/catalina/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar Adding repository/org/apache/tomcat/jasper/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar Transmitting file data ... Committed revision 614758. Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1 During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3451. --- Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1 During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet
[
https://issues.apache.org/jira/browse/GERONIMO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh reassigned GERONIMO-3549:
---
Assignee: Jay D. McHugh
Potential vulnerability in Apache Tomcat Webdav servlet
---
Key: GERONIMO-3549
URL: https://issues.apache.org/jira/browse/GERONIMO-3549
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Donald Woods
Assignee: Jay D. McHugh
Fix For: 2.0.x, 2.1
Subject: [SECURITY] Potential vulnerability in Apache Tomcat Webdav
servlet
Date: Thu, 18 Oct 2007 13:40:24 -0400
From: Kevan Miller [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: Geronimo Dev dev@geronimo.apache.org
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav servlet,
you may be affected by this vulnerability. If you do not configure the
Webdav servlet or configure read-only Webdav servlets, you are not
impacted by this vulnerability. Jetty configurations of Geronimo are not
affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL
PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However, it
is possible for the Webdav Servlet to be configured or referenced by a
user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
http://web.xml/ deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet, for
example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem has
been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo (2.0.3
and/or 2.1).
--kevan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet
[
https://issues.apache.org/jira/browse/GERONIMO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh resolved GERONIMO-3549.
-
Resolution: Fixed
Commits for Geronimo-3451 ('restricted listeners') also include necessary
security fixes for this issue.
Potential vulnerability in Apache Tomcat Webdav servlet
---
Key: GERONIMO-3549
URL: https://issues.apache.org/jira/browse/GERONIMO-3549
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Donald Woods
Assignee: Jay D. McHugh
Fix For: 2.0.x, 2.1
Subject: [SECURITY] Potential vulnerability in Apache Tomcat Webdav
servlet
Date: Thu, 18 Oct 2007 13:40:24 -0400
From: Kevan Miller [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: Geronimo Dev dev@geronimo.apache.org
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav servlet,
you may be affected by this vulnerability. If you do not configure the
Webdav servlet or configure read-only Webdav servlets, you are not
impacted by this vulnerability. Jetty configurations of Geronimo are not
affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL
PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However, it
is possible for the Webdav Servlet to be configured or referenced by a
user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
http://web.xml/ deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet, for
example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem has
been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo (2.0.3
and/or 2.1).
--kevan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet
[
https://issues.apache.org/jira/browse/GERONIMO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh closed GERONIMO-3549.
---
Potential vulnerability in Apache Tomcat Webdav servlet
---
Key: GERONIMO-3549
URL: https://issues.apache.org/jira/browse/GERONIMO-3549
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Donald Woods
Assignee: Jay D. McHugh
Fix For: 2.0.x, 2.1
Subject: [SECURITY] Potential vulnerability in Apache Tomcat Webdav
servlet
Date: Thu, 18 Oct 2007 13:40:24 -0400
From: Kevan Miller [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: Geronimo Dev dev@geronimo.apache.org
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav servlet,
you may be affected by this vulnerability. If you do not configure the
Webdav servlet or configure read-only Webdav servlets, you are not
impacted by this vulnerability. Jetty configurations of Geronimo are not
affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL
PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However, it
is possible for the Webdav Servlet to be configured or referenced by a
user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
http://web.xml/ deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet, for
example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem has
been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo (2.0.3
and/or 2.1).
--kevan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3450. - Resolution: Invalid See Ramesh's comment. Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 2.0.x, 2.1 Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3450. --- Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 2.0.x, 2.1 Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-1265. --- Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Fix For: 2.1 Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-1265. - Resolution: Fixed Fix Version/s: 2.1 No one has commented that they wanted the additional functionality that I had been holding this issue open for. So I am closing it. We can create a new JIRA or reopen this one later if anyone decides that we want that (or some other) comment functionality later. Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Fix For: 2.1 Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3069. - Resolution: Fixed Fix Version/s: 2.0.2 2.1 Either Dojo or Safari (or both) made changes that resolved the display problems. Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.1, 2.0.2 Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3069. --- Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.0.2, 2.1 Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559171#action_12559171 ] Jay D. McHugh commented on GERONIMO-3069: - Would someone on a Mac test this issue please. I haven't changed anything, but the Windows version of Safari seems to be rendering correctly on both 2.0.2 and trunk. Thanks Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559176#action_12559176 ] Jay D. McHugh commented on GERONIMO-1265: - After considering this some more - I don't think it is necessary for us to be able to do either of the 'todo' items above (especially not #1). Comments are retained for each level of the config.xml file. And if they are added to the pom.xml's in source (in the 'config-xml-content' section) then they are carried into the generated config.xml for the server. Is there anyone who specifically wants to be able to do either of the 'todo' items above? If not, then I am going to go ahead and close this issue. Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553197 ] Jay D. McHugh commented on GERONIMO-3300: - Erik, If you can get it working that would be great. I am in the middle of rebuilding my computer and right now I can't build anything. Jay Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553199 ] Jay D. McHugh commented on GERONIMO-3300: - By the way Erik, Dojo 1.0.2 just came out Sunday - So 1.0.1 is already out of date. If it would be easier for you - you could just nuke what I had out there. Jay Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551151 ] Jay D. McHugh commented on GERONIMO-3300: - I have tried to create a plugin for dojo-1.0.1 under /plugins. But, it does not work the way I expected it to. So, any help on getting that to act like a real plugin would be great. Jay Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3596) Unintuitive workings of the MySQL DBPool deployment wizard
[ https://issues.apache.org/jira/browse/GERONIMO-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547169 ] Jay D. McHugh commented on GERONIMO-3596: - The new adapters are still working for me, but has anyone else had a chance to try these? It would be nice to be able to stop manually copying these into my server each time I rebuild. Unintuitive workings of the MySQL DBPool deployment wizard -- Key: GERONIMO-3596 URL: https://issues.apache.org/jira/browse/GERONIMO-3596 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector, databases, deployment Affects Versions: 2.0.2 Environment: ogre% uname -a FreeBSD ogre 7.0-BETA2 FreeBSD 7.0-BETA2 #4: Sat Nov 10 15:29:36 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OGRE amd64 ogre% java -version java version 1.6.0_02-p2 Java(TM) SE Runtime Environment (build 1.6.0_02-p2-root_04_nov_2007_14_03-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_02-p2-root_04_nov_2007_14_03-b00, mixed mode) Nothing else. I don't think it matters at all for this bug report anyway. Reporter: Jesper Louis Andersen Attachments: tranql-connector-mysql-local-1.2-SNAPSHOT.rar There is an unintuitive gotcha hidden in the DBPool wizard for the MySQL (and probably also the MySQL-XA) driver. It manifests itself with a NullPointerException when trying to connect to a database. See for instance the following mail: http://spteam-lists.blogspot.com/2007/11/re-apache-geronimo-202-and-mysql-data.html The reason is that if you DON'T fill out the URL field, you get the following deployment plan: ?xml version=1.0 encoding=UTF-8? connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector-1.2; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; dep:moduleId dep:groupIdconsole.dbpool/dep:groupId dep:artifactIdcxnet/dep:artifactId dep:version1.0/dep:version dep:typerar/dep:type /dep:moduleId dep:dependencies dep:dependency dep:groupIdmysql/dep:groupId dep:artifactIdmysql-connector-java/dep:artifactId dep:version5.1.5/dep:version dep:typejar/dep:type /dep:dependency /dep:dependencies /dep:environment resourceadapter outbound-resourceadapter connection-definition connectionfactory-interfacejavax.sql.DataSource/connectionfactory-interface connectiondefinition-instance namecxnet/name config-property-setting name=DatabaseNamefoo/config-property-setting config-property-setting name=Passwordfoo/config-property-setting config-property-setting name=UserNamefoo/config-property-setting config-property-setting name=URL/ connectionmanager no-transaction/ single-pool max-size10/max-size min-size0/min-size match-one/ /single-pool /connectionmanager /connectiondefinition-instance /connection-definition /outbound-resourceadapter /resourceadapter /connector + Notice the Empty URL parameter. Quick workaround: Supply the URL parameter or use the 'show plan' feature and add the URL in the plan. Steps to reproduce: 1. Add a mysql-connector-java JAR to the library section. I used 5.1.5 as a version, but it also fails with 5.0.8 and 3.1.14. 2. Click Database Pools - Wizard - choose 'foo' and MySQL as driver 3. Enter the fields: pool name, database driver, port number, user name, server name, database name, password and confirm password take care NOT to enter the URL. 4. Now click 'show plan'. It this point it should be obvious that we are trying to deploy a plan without an URL. The idea for a fix: 1. Gather fields from input. 2. If URL is empty, stitch together one from the other parameters. 3. Use the constructed URL. And do take care to report this back to the guy in the linked mail above ;) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3122) Unable to create a (MySQL) database pool
[ https://issues.apache.org/jira/browse/GERONIMO-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3122. - Resolution: Duplicate Accidental clone of 2368 Unable to create a (MySQL) database pool Key: GERONIMO-3122 URL: https://issues.apache.org/jira/browse/GERONIMO-3122 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0-M3 Environment: mysql/mysql-connector-java/3.1.12/jar MySQL 5.0.27 Win-Xp Java 1.6 Reporter: nrkkalyan I tried to create new database pool using 1. Database Pool Wizard 2. Importing from Jboss 4. That time I got the following exception. EXCEPTION WHILE CREATING DATABASE POOL USING THE GERONIMO DATABASE POOL WIZARD /// Geronimo Application Server started 22:44:35,401 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) 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:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) 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:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:619) EXCEPTION WHILE CREATING
[jira] Closed: (GERONIMO-3122) Unable to create a (MySQL) database pool
[ https://issues.apache.org/jira/browse/GERONIMO-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3122. --- Unable to create a (MySQL) database pool Key: GERONIMO-3122 URL: https://issues.apache.org/jira/browse/GERONIMO-3122 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0-M3 Environment: mysql/mysql-connector-java/3.1.12/jar MySQL 5.0.27 Win-Xp Java 1.6 Reporter: nrkkalyan I tried to create new database pool using 1. Database Pool Wizard 2. Importing from Jboss 4. That time I got the following exception. EXCEPTION WHILE CREATING DATABASE POOL USING THE GERONIMO DATABASE POOL WIZARD /// Geronimo Application Server started 22:44:35,401 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) 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:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) 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:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:619) EXCEPTION WHILE CREATING DATABASE POOL USING IMPORT FROM JBOSS 4 ///
[jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3300: Description: Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. was: The new Dojo 0.9 Beta was just released. It will reduce the footprint of the main dojo.js to under 50k - But will require that some of the console screens to be reworked because the widget system was completely redesigned and is incompatible. Affects Version/s: (was: 2.0-M7) 2.1 Summary: Upgrade Dojo to 1.0 (was: Upgrade Dojo to 0.9) Upgrade Dojo to 1.0 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Dojo 1.0 is now available. But, to upgrade we will either need to rewrite all of the plugins that use Dojo widgets to use the new (backward incompatible) versions -or- include both the 0.4.3 and 1.0.0 versions of Dojo. Having both versions would make it possible to transition over to the newer version of Dojo in a more leisurely fashion but would introduce a fairly significant amount of bloat. I would prefer that we would just replace the old version and rewrite whatever needs to be rewritten but that would depend on how soon we are trying to get G2.1 out the door. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546372 ] Jay D. McHugh commented on GERONIMO-3638: - Content can be in any character set, but I am pretty sure that you are only allowed to use a portion of the 8859 character set in URLs. snippet from RFC1738 Thus, only alphanumerics, the special characters $-_.+!*'(),, and reserved characters used for their reserved purposes may be used unencoded within a URL. /snippet Since this is an HTTP client, shouldn't it be limited to the characters allowed by the URL spec? should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default
[ https://issues.apache.org/jira/browse/GERONIMO-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546454 ] Jay D. McHugh commented on GERONIMO-3638: - RFC 2396 seems to say the same character set (a portion of latin with numerics and some special characters). As far as whether we should be using the Charset.defaultCharset() - You may be right. Maybe we should be either using US-ASCII or ISO-8859-1 explicitly rather than letting the JVM pick which one we use. Anyone else have a comment or suggestion? should allow URL encoding with custom encoding charset other than the default - Key: GERONIMO-3638 URL: https://issues.apache.org/jira/browse/GERONIMO-3638 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: patch.zip Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the query string. However, applications may want to use a different encoding than the machine default charset; e.g. UTF-8. It needs to provide a way to specify an encoding that AHC should use to encode the query string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543651 ] Jay D. McHugh commented on GERONIMO-1265: - Committed revision 596403. Here is a new set of changes that should hopefully finish fleshing out comment support in config.xml. 1) If there is no 'top level' comment in config.xml then a default warning comment will be inserted. Once there is a comment, it will be retained. 2) If you include a comment element in the pom.xml file of a module at the GBean level, it will be carried over into the config.xml. 3) A comment added to config.xml at the module level will be retained. Todo: 1) Figure out how a comment for the entire config.xml file can be placed into the source and make sure that it makes it to the final config.xml. 2) Figure out how a comment for a full module (within) config.xml can be placed into the source and make sure it makes it to the final config.xml). Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3266. - Resolution: Fixed Fix Version/s: 2.1 I believe that the attributes-1.2.xsd is sufficient to provide comments at all levels of the config.xml. If there is some other information that someone needs/wants to store in config.xml - speak up. Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0, 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.1 Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3271. - Resolution: Fixed Fix Version/s: 2.1 All programs that were referencing attributes-1.1.xsd have been changed over to use attributes-1.2.xsd. Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: 2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect
[
https://issues.apache.org/jira/browse/GERONIMO-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525554
]
jaydm edited comment on GERONIMO-2567 at 9/6/07 4:19 PM:
-
Fixed in Revision: 568302/568304
Linux notes:
The hostname of the server needs to appear in the /etc/hosts file (on the
server) with its external ip address.
And the geronimo-home/var/config/config.xml file needs to have the
gbean-deployer module
updated to point to the external address (of the server).
ie:
module
name=org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car
gbean name=Deployer
attribute name=remoteDeployAddresshttp://172.16.1.2:${HTTPPortPrimary +
PortOffset}/attribute
/gbean
/module
was (Author: jaydm):
Fixed in Revision: 568302
Linux notes:
The hostname of the server needs to appear in the /etc/hosts file (on the
server) with its external ip address.
And the geronimo-home/var/config/config.xml file needs to have the
gbean-deployer module
updated to point to the external address (of the server).
ie:
module
name=org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car
gbean name=Deployer
attribute name=remoteDeployAddresshttp://172.16.1.2:${HTTPPortPrimary +
PortOffset}/attribute
/gbean
/module
Remote admin of server using deployer.jar fails to connect
--
Key: GERONIMO-2567
URL: https://issues.apache.org/jira/browse/GERONIMO-2567
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.2, 2.0, 2.0.x
Environment: Linux
Java 1.5
Reporter: Jay D. McHugh
Assignee: Kevan Miller
Fix For: 2.0.x, 2.1
Trying to remote deploy a WAR file resulted in a failed connection.
This happened regardless of whether the port was specified.
$ java -jar deployer.jar --user system --password manager --host 172.16.1.41
redeploy ~/PaLM.war
Error: Unable to connect to server at
deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect
[
https://issues.apache.org/jira/browse/GERONIMO-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh closed GERONIMO-2567.
---
Fixed in Revision: 568302
Linux notes:
The hostname of the server needs to appear in the /etc/hosts file (on the
server) with its external ip address.
And the geronimo-home/var/config/config.xml file needs to have the
gbean-deployer module
updated to point to the external address (of the server).
ie:
module
name=org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car
gbean name=Deployer
attribute name=remoteDeployAddresshttp://172.16.1.2:${HTTPPortPrimary +
PortOffset}/attribute
/gbean
/module
Remote admin of server using deployer.jar fails to connect
--
Key: GERONIMO-2567
URL: https://issues.apache.org/jira/browse/GERONIMO-2567
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.2, 2.0, 2.0.x
Environment: Linux
Java 1.5
Reporter: Jay D. McHugh
Assignee: Kevan Miller
Fix For: 2.0.x, 2.1
Trying to remote deploy a WAR file resulted in a failed connection.
This happened regardless of whether the port was specified.
$ java -jar deployer.jar --user system --password manager --host 172.16.1.41
redeploy ~/PaLM.war
Error: Unable to connect to server at
deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect
[ https://issues.apache.org/jira/browse/GERONIMO-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-2567. - Resolution: Invalid Assignee: Jay D. McHugh Kevan, You are correct - It was an IPv6 issue (I hadn't realized that I had IPv6 enabled locally). So, taking that into account (specifying the remote server address using the IPv4 version surrounded by [ ]) and setting the remoteDeployAddress in the server's config.xml (server address in IPv4 surrounded by [ ] with the port set to ) allowed me to connect and list my modules. Rather than a bug, this looks like it would be better addressed in the documentation. Remote admin of server using deployer.jar fails to connect -- Key: GERONIMO-2567 URL: https://issues.apache.org/jira/browse/GERONIMO-2567 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2, 2.0, 2.0.x Environment: Linux Java 1.5 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Fix For: Verification Required Trying to remote deploy a WAR file resulted in a failed connection. This happened regardless of whether the port was specified. $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 redeploy ~/PaLM.war Error: Unable to connect to server at deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect
[ https://issues.apache.org/jira/browse/GERONIMO-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521149 ] Jay D. McHugh commented on GERONIMO-2567: - I'll see if I can figure out why I can't get a connection. I need two questions answered to make sure that I am at least set up properly: 1) Do I need to have a server running locally to administer a remote server (I would tend to think not) 2) Which address should remoteDeployAddress point to? The remote server's external address or the local system's address? Other than those, I'll try to eliminate all other variables by statically addressing everything. I won't be able to look at this until either this evening or tomorrow though. Remote admin of server using deployer.jar fails to connect -- Key: GERONIMO-2567 URL: https://issues.apache.org/jira/browse/GERONIMO-2567 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2, 2.0, 2.0.x Environment: Linux Java 1.5 Reporter: Jay D. McHugh Fix For: Verification Required Trying to remote deploy a WAR file resulted in a failed connection. This happened regardless of whether the port was specified. $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 redeploy ~/PaLM.war Error: Unable to connect to server at deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect
[ https://issues.apache.org/jira/browse/GERONIMO-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-2567: Affects Version/s: 2.0.x 2.0 Summary: Remote admin of server using deployer.jar fails to connect (was: Remote deploy of apps fails) I am still having a problem. Perhaps the problem is that I am trying to use the deployer incorrectly (I usually just use the web console to administer remote servers). Please let me know if I am trying to use the tool incorrectly (It would be nice to be able to script my redeploys). Configuration: Local system - Linux with Sun JDK 1.5.0_12 Remote system - Linux with Sun JDK 1.5.0_8 (IP Address 172.16.1.41) No running firewall on either system and the web admin console works. When I try to list the modules running on a remote server here is the command I use and the resulting output: (with a server running locally also) java -jar deployer.jar --user system --password manager --host 172.16.1.41 list-modules Error: Unable to connect to server at deployer:geronimo:jmx://172.16.1.41 -- no such object in table javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no such object in table at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:167) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:131) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:181) at org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConnection.java:93) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:159) ... 8 more (without a server running locally) java -jar deployer.jar --user system --password manager --host 172.16.1.41 list-modules Error: Unable to connect to server at deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:167) at org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:131) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111) at org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:181) at org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConnection.java:93) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185) at
[jira] Commented: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517095 ] Jay D. McHugh commented on GERONIMO-3266: - Committed second attempt on schema file revision 561971 GERONIMO-3266 - Second revision of schema - Corrected the attributes level comment - Corrected the gbean level comment Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3271: Affects Version/s: (was: 2.0-M7) 2.1 Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517115 ] Jay D. McHugh commented on GERONIMO-3271: - Committed - Revision 561988 Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517117 ] Jay D. McHugh commented on GERONIMO-1265: - Committed revision 561989 - Added new schema (see 3266) - Added support for module level comments Changes inspired by Don Hill's patch - Thanks Don! Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3266: Affects Version/s: (was: 2.0-M7) 2.1 2.0 Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0, 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1265) Preserve comments added by users in the config.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-1265: Assignee: Jay D. McHugh Affects Version/s: (was: 1.2) (was: 2.0-M7) 2.1 Preserve comments added by users in the config.xml file --- Key: GERONIMO-1265 URL: https://issues.apache.org/jira/browse/GERONIMO-1265 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0-M5, 1.0, 1.1, 2.1 Reporter: John Sisson Assignee: Jay D. McHugh Attachments: geronimo-1265.patch Currently if a user adds comments to the config.xml file, they will be lost when Geronimo re-generates the file if a configuration change is made (e.g. through the web console). As a temporary measure, the code that re-generates the XML will place a warning at the top of the file warning users not to place comments in it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517095 ] Jay D. McHugh edited comment on GERONIMO-3266 at 8/1/07 4:37 PM: - Committed second attempt on schema file revision 561971 (trunk) revision 561990 (branches/2.0) Second revision of schema - Corrected the attributes level comment - Corrected the gbean level comment was: Committed second attempt on schema file revision 561971 Second revision of schema - Corrected the attributes level comment - Corrected the gbean level comment Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0, 2.1 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516742 ] Jay D. McHugh commented on GERONIMO-3266: - I believe that this will allow for comments at just about every level of config.xml. Is there any other type of information that we need/want to be able to store? I would rather get all foreseeable changes in now, so that we don't end coming out with attributes-1.3, 1.4, ... If no one has any suggestions of other information that should (could) be stored in config.xml then I'll mark this as finished in about a week (Aug 6, 2007) Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3271: --- Assignee: Jay D. McHugh Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3300) Upgrade Dojo to 0.9
Upgrade Dojo to 0.9 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh The new Dojo 0.9 Beta was just released. It will reduce the footprint of the main dojo.js to under 50k - But will require that some of the console screens to be reworked because the widget system was completely redesigned and is incompatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3069) Rework AJAX style console screens to work on Safari
[ https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3069: Issue Type: Sub-task (was: Bug) Parent: GERONIMO-3300 Rework AJAX style console screens to work on Safari --- Key: GERONIMO-3069 URL: https://issues.apache.org/jira/browse/GERONIMO-3069 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Attachments: geronimo-3069-jmx-1.patch Some of the newer console screens do not work properly in Safari. Try to rewrite the javascript code so that it works on safari. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3050) Create a JPA persistence unit view for the console
[ https://issues.apache.org/jira/browse/GERONIMO-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3050: Issue Type: Sub-task (was: Improvement) Parent: GERONIMO-3300 Create a JPA persistence unit view for the console -- Key: GERONIMO-3050 URL: https://issues.apache.org/jira/browse/GERONIMO-3050 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create one or more JPA views that show: - View of loaded persistence units (tree format with persistable classes under each unit) - View of loaded persistence units detailing their properties (back-end database, transaction mode, ...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3300) Upgrade Dojo to 0.9
[ https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510038 ] Jay D. McHugh commented on GERONIMO-3300: - It will be a while before I have completed the changes to allow a switch to 0.9. If I manage to finish before the final release comes out - Then I'll wait until it does. I just wanted to organize the subtasks under the larger task of upgrading so that I wouldn't be doing the work twice (once under 0.4.3 and then again under 0.9). This will probably end up being for 2.0.1. Upgrade Dojo to 0.9 --- Key: GERONIMO-3300 URL: https://issues.apache.org/jira/browse/GERONIMO-3300 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh The new Dojo 0.9 Beta was just released. It will reduce the footprint of the main dojo.js to under 50k - But will require that some of the console screens to be reworked because the widget system was completely redesigned and is incompatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)
[ https://issues.apache.org/jira/browse/GERONIMO-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508908 ] Jay D. McHugh commented on GERONIMO-3266: - Committed first attempt at a new schema file (attributes-1.2.xsd). revision 551660 Enhance attributes schema (relates to config.xml) - Key: GERONIMO-3266 URL: https://issues.apache.org/jira/browse/GERONIMO-3266 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 2.0-M7 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Create a version 1.2 of the attributes.xsd to allow for comments anywhere in the file. Are there any other enhancements that anyone would be interested in for config.xml? If we can figure out what future changes would be desired, maybe we can 'future-proof' the schema so we won't need to mess with it again (at least for a while). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3271) Update all users of the attributes schema to use new version
Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3271) Update all users of the attributes schema to use new version
[ https://issues.apache.org/jira/browse/GERONIMO-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3271: Component/s: startup/shutdown Affects Version/s: 2.0-M7 Update all users of the attributes schema to use new version Key: GERONIMO-3271 URL: https://issues.apache.org/jira/browse/GERONIMO-3271 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0-M7 Reporter: Jay D. McHugh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
