[jira] Closed: (GERONIMO-941) Change console-standard to portlets-for-console or something
[ https://issues.apache.org/jira/browse/GERONIMO-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-941. - Resolution: Fixed Fix Version/s: (was: 1.x) 2.1 it's called console-base now and if you try to go there you are redirected to the console login screen. Change console-standard to portlets-for-console or something Key: GERONIMO-941 URL: https://issues.apache.org/jira/browse/GERONIMO-941 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, usability Affects Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 2.1 At least, change the context path (I don't care as much about the module directory name). When you look and see: http://localhost:8080/console http://localhost:8080/console-standard It's not at all clear what the difference is or which one you want. It would probably also be a good idea to have an index.jsp in the renamed module that redirects to ../console in case someone tries out the wrong one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1921) Console should display context root for the installed web apps
[ https://issues.apache.org/jira/browse/GERONIMO-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-1921. -- Resolution: Fixed Actually installed web apps have their console-root displayed. I don't think its desirable for the plugin installer to fish around inside stuff it's looking at to try to figure out what it is and if there is extra info it should fish out. If you disagree please open a new issue for this specific functionality. Console should display context root for the installed web apps -- Key: GERONIMO-1921 URL: https://issues.apache.org/jira/browse/GERONIMO-1921 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Environment: all Reporter: Anita Kulshreshtha Priority: Minor Fix For: 1.1.x Console should display context root for the web apps in these two places - 1. Web App Wars -- Installed Web Apps 2. plugins -- .-- Import/Export configuraitons - if has web apps Currently user has no way of determining context root for the sample apps supplied with geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2712) LDAP editing capability from Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558964#action_12558964 ] David Jencks commented on GERONIMO-2712: I'm not sure how much effort we want to put into duplicating functionality of apache directory's excellent eclipse-based ldap studio. LDAP editing capability from Admin Console -- Key: GERONIMO-2712 URL: https://issues.apache.org/jira/browse/GERONIMO-2712 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0-M1, 2.0-M2, 2.0-M3, 2.0-M4, 2.0-M5 Reporter: Hernan Cunico Fix For: Wish List Currently from the console we are able to just view the content of the LDAP server but rely on external applications to actually import data to this DB. As a new feature and as an improvement from the usability perspective it would be great if we can provide a method to load the *.ldif* files directly form the console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2614) LDAP Viewer portlet should warn you is the LDAP support plugin is not installed and/or started
[ https://issues.apache.org/jira/browse/GERONIMO-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558963#action_12558963 ] David Jencks commented on GERONIMO-2614: I'm not sure I understand why... you can connect to an independent ldap server not running in geronimo and poke around to your hearts content. We don't really have a way to find out if there's an accessible ldap server on the network. LDAP Viewer portlet should warn you is the LDAP support plugin is not installed and/or started -- Key: GERONIMO-2614 URL: https://issues.apache.org/jira/browse/GERONIMO-2614 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Environment: this is for revision r480769 Reporter: Hernan Cunico LDAP support is available only via plugins now. The LDAP Viewer portlet shown an error pop-up window stating there is a connection error. The portlet should either know the plugin is not installed or the portlet itself should be provided as part of the LDAP support plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2187) Ability to set scope of Connection Pool created from console
[ https://issues.apache.org/jira/browse/GERONIMO-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2187. -- Resolution: Invalid I've never understood the idea behind calling some pools server-wide and some application specific, but IIUC an application specific pool is deployed as part of another application. As such the db pool wizard cannot possibly deploy an application specific pool. The plan creator might be able to, but not the pool wizard. Ability to set scope of Connection Pool created from console Key: GERONIMO-2187 URL: https://issues.apache.org/jira/browse/GERONIMO-2187 Project: Geronimo Issue Type: Wish Security Level: public(Regular issues) Components: console Affects Versions: Wish List Reporter: Krishnakumar B Priority: Minor Improves usability if user can also set scope of Pool from Console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2244) Explicit reference fail when module type is not car
[ https://issues.apache.org/jira/browse/GERONIMO-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2244. -- Resolution: Fixed The actual problem appears to have been fixed long ago Explicit reference fail when module type is not car - Key: GERONIMO-2244 URL: https://issues.apache.org/jira/browse/GERONIMO-2244 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, deployment Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x Currently the pattern used in the naming schema includes group, artifact, and version, but not type. In ENCConfigBuilder.buildAbstractNameQuery, the type is hardcoded to car. This means that if you use a naming:pattern with an artifactId, it only works if the target module's type is actually car. This is not true, for example, for several module types created by the admin console, as well as in general for user-defined modules. The naming:pattern element should include a type element, and ENCConfigBuilder (and any other necessary code) should respect it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2205) SecurityRealms portlet does not list stopped security realms
[ https://issues.apache.org/jira/browse/GERONIMO-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2205. -- Resolution: Fixed This is the expected behavior and I removed the state column some time ago. SecurityRealms portlet does not list stopped security realms Key: GERONIMO-2205 URL: https://issues.apache.org/jira/browse/GERONIMO-2205 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1 Environment: WinXP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: Wish List Security Realms portlet does not list stopped security realms. It lists only those realms running currently. If indeed this is the expected behaviour, there is no need for State column in the listing since it will show runnng for all entries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1980) Move Plugin Installer from rmi-naming to j2ee-system
[ https://issues.apache.org/jira/browse/GERONIMO-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-1980. -- Resolution: Fixed Assignee: David Jencks Plugin stuff is now in its own module and it can't use much less stuff. Its included in the framework assembly I dont think we can subtract anything else. Move Plugin Installer from rmi-naming to j2ee-system Key: GERONIMO-1980 URL: https://issues.apache.org/jira/browse/GERONIMO-1980 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem, Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 2.1 Ideally, the plugin installer will be as high in the food chain as possible, so it can replace as much as possible without shutting itself down. Currently it is in rmi-naming. I tried moving it to j2ee-system, which requires the following new dependencies for j2ee-system: - geronimo-core - geronimo-management - geronimo-util - geronimo-j2ee-management_1.0_spec - concurrent Somehow, the net result of this was that the OpenEJB config could not load javax.ejb.EJBObject, so there's something funky going on with the class loaders when the above changes are made. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-1922) Plugin Export should check for shared libs
[ https://issues.apache.org/jira/browse/GERONIMO-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558967#action_12558967 ] David Jencks commented on GERONIMO-1922: I thiink this is babysitting the users too much. If they want to shoot themselves in the foot by using shared-lib in the first place, who are we to try to keep them from shooting everyone else in the foot too by exporting their app? After all, they might have included instructions in their geronimo-plugin.xml about the extra jars needed in shared-lib. Plugin Export should check for shared libs -- Key: GERONIMO-1922 URL: https://issues.apache.org/jira/browse/GERONIMO-1922 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, Plugins Affects Versions: 1.1, 1.1.1 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List The export process should check configation.findGBeans(new AbstractNameQuery(SharedLib.class.getName()) The MavenAsGeronimoServlet should not list any plugins that use the shared lib GBean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3607) export a server including a set of plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558984#action_12558984 ] David Jencks commented on GERONIMO-3607: Rev 612052. Clean up some of the portal plugin import code, mostly to allow importing multiple plugins at once. Also eliminate a redundant page. Fix a car-export problem. Prepares me to try to understand how to write an assemble server portlet. export a server including a set of plugins -- Key: GERONIMO-3607 URL: https://issues.apache.org/jira/browse/GERONIMO-3607 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Provide the ablility to package a server that includes a set of plugins, accessible through the console and through gshell. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3698) Installation of Admin Console fails with missing dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3698. -- Resolution: Fixed Rev 612053 eliminates the abuse of plugin prerequisites to make installing dependencies unduly difficult. Installation of Admin Console fails with missing dependency --- Key: GERONIMO-3698 URL: https://issues.apache.org/jira/browse/GERONIMO-3698 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1 Reporter: Kevan Miller Assignee: David Jencks Fix For: 2.1 Installation of the Jetty admin console fails with a missing dependency. Starting with a framework assembly, I installed the Jetty Admin Console: 6: Geronimo Plugins :: Administration Console - Jetty (2.1-SNAPSHOT) The installation fails with a missing dependency for: org.apache.geronimo.configs/jetty6/2.1-SNAPSHOT/car The installation works if I first install the jetty6 plugin. Here's the full failure info: Install Services [enter a comma separated list of numbers or 'q' to quit]: 6 Checking for status every 1000ms: Downloading org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car Copying commons-collections/commons-collections/3.1/jar to the repository (100%) Downloading org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Downloading org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar 320 kB of org.apache.tomcat/jasper-jdt/6.0.13/jar Starting org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car Installation Complete! Used existing: org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-core/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-common/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-management/2.1-SNAPSHOT/jar Used existing: asm/asm/2.2.3/jar Used existing: asm/asm-commons/2.2.3/jar Used existing: org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-transformer/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.plugins/pluto-support/2.1-SNAPSHOT/car Installed new: org.apache.pluto/pluto-portal-driver/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-portal-driver-impl/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-container/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-api/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-impl/1.2.0-G601060/jar Installed new: commons-logging/commons-logging-api/1.0.4/jar Installed new: commons-beanutils/commons-beanutils/1.6.1/jar Installed new: commons-collections/commons-collections/3.1/jar Installed new: javax.portlet/portlet-api/1.0/jar Installed new: org.apache.geronimo.configs/spring/2.1-SNAPSHOT/car Installed new: org.springframework/spring-core/2.0.5/jar Installed new: org.springframework/spring-beans/2.0.5/jar Installed new: org.springframework/spring-context/2.0.5/jar Installed new: org.springframework/spring-web/2.0.5/jar Installed new: org.codehaus.castor/castor/1.0.5/jar Installed new: org.apache.geronimo.plugins/geronimo-pluto/2.1-SNAPSHOT/jar Installed new: org.apache.pluto/pluto-taglib/1.2.0-G601060/jar Installed new: commons-digester/commons-digester/1.8/jar Installed new: org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee-schema/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.schema/geronimo-schema-jee_5/1.1/jar Installed new: org.apache.geronimo.schema/geronimo-schema-j2ee_1.4/1.2/jar Installed new: org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-webservices/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-reflect/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-test-ddbean/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-naming-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-security-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-j2ee-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-finder/3.2/jar Installed new:
[jira] Assigned: (GERONIMO-3698) Installation of Admin Console fails with missing dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3698: -- Assignee: David Jencks (was: Jarek Gawor) Installation of Admin Console fails with missing dependency --- Key: GERONIMO-3698 URL: https://issues.apache.org/jira/browse/GERONIMO-3698 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1 Reporter: Kevan Miller Assignee: David Jencks Fix For: 2.1 Installation of the Jetty admin console fails with a missing dependency. Starting with a framework assembly, I installed the Jetty Admin Console: 6: Geronimo Plugins :: Administration Console - Jetty (2.1-SNAPSHOT) The installation fails with a missing dependency for: org.apache.geronimo.configs/jetty6/2.1-SNAPSHOT/car The installation works if I first install the jetty6 plugin. Here's the full failure info: Install Services [enter a comma separated list of numbers or 'q' to quit]: 6 Checking for status every 1000ms: Downloading org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car Copying commons-collections/commons-collections/3.1/jar to the repository (100%) Downloading org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Downloading org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar 320 kB of org.apache.tomcat/jasper-jdt/6.0.13/jar Starting org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car Installation Complete! Used existing: org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-core/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-common/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.modules/geronimo-management/2.1-SNAPSHOT/jar Used existing: asm/asm/2.2.3/jar Used existing: asm/asm-commons/2.2.3/jar Used existing: org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar Used existing: org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car Used existing: org.apache.geronimo.modules/geronimo-transformer/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.plugins/pluto-support/2.1-SNAPSHOT/car Installed new: org.apache.pluto/pluto-portal-driver/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-portal-driver-impl/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-container/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-api/1.2.0-G601060/jar Installed new: org.apache.pluto/pluto-descriptor-impl/1.2.0-G601060/jar Installed new: commons-logging/commons-logging-api/1.0.4/jar Installed new: commons-beanutils/commons-beanutils/1.6.1/jar Installed new: commons-collections/commons-collections/3.1/jar Installed new: javax.portlet/portlet-api/1.0/jar Installed new: org.apache.geronimo.configs/spring/2.1-SNAPSHOT/car Installed new: org.springframework/spring-core/2.0.5/jar Installed new: org.springframework/spring-beans/2.0.5/jar Installed new: org.springframework/spring-context/2.0.5/jar Installed new: org.springframework/spring-web/2.0.5/jar Installed new: org.codehaus.castor/castor/1.0.5/jar Installed new: org.apache.geronimo.plugins/geronimo-pluto/2.1-SNAPSHOT/jar Installed new: org.apache.pluto/pluto-taglib/1.2.0-G601060/jar Installed new: commons-digester/commons-digester/1.8/jar Installed new: org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee-schema/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.schema/geronimo-schema-jee_5/1.1/jar Installed new: org.apache.geronimo.schema/geronimo-schema-j2ee_1.4/1.2/jar Installed new: org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car Installed new: org.apache.geronimo.modules/geronimo-j2ee/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-webservices/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-reflect/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-test-ddbean/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-naming-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-security-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-j2ee-builder/2.1-SNAPSHOT/jar Installed new: org.apache.geronimo.modules/geronimo-client/2.1-SNAPSHOT/jar Installed new: org.apache.xbean/xbean-finder/3.2/jar Installed new: org.apache.geronimo.modules/geronimo-web-2.5-builder/2.1-SNAPSHOT/jar Installed
[jira] Commented: (GERONIMO-2311) Exporting plug-in configurations
[ https://issues.apache.org/jira/browse/GERONIMO-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558980#action_12558980 ] David Jencks commented on GERONIMO-2311: When I export all the files are named car-export. Anyone know how to set the download file name in the CARExportServlet? Exporting plug-in configurations Key: GERONIMO-2311 URL: https://issues.apache.org/jira/browse/GERONIMO-2311 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1.2 Reporter: Krishnakumar B Priority: Minor When i export a configuration from geronimo to plugin and save it to disk the file names are not legible for e.g) I exported a DataSource Saved as rar.0%2Frar I exported a War . Saved as war.0%2Fwar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Console issues
I spent some time working on the admin console plugin installer so you can install more than one plugin at once. It works but there are still some problems I don't know how to fix: if someone who has a bit of jsp/servlet knowledge could take a look that would be great, and having someone with a sense of style review the changes would also be great. -- GERONIMO-3746 (Joseph Leong may be looking at this). The progress bar sometimes updates and sometimes doesn't and the page never looks to be done or moves on. Also the message at the top of the page doesn't work any more I can't figure out how to get a list of the plugins we are installing into the message. -- the car-export servlet seems to always name the file car- export (GERONIMO-2311) In general I think the console could use a pretty thorough review to make sure everything still works. The testsuite is great but not all- inclusive. Also, I seem to recall a nice background in the console before it turned into plugins. Anyone know what happened? thanks david jencks
Please look through jiras for 2.1
I think a lot of people would like to get 2.1 out pronto. One way we can all help is to look through the open jiras and see if they are still relevant, susceptible to an easy fix, already fixed, or postponable. I looked through the console jiras tonight and was not too happy to see the number of jiras that appear to be gathering irrelevance. Jira will be more useful the fewer bad issues we have in it. thanks david jencks
Re: Is there a problem with AsyncHttpClient connection reuse?
Sangjin Lee wrote: Yes, if you used a different configuration for the SSL, then it would be another issue. The questions are: - Do we want to even allow an option for using a shared connection cache? The benefit of a shared connection cache is ... just that; connection reuse will be maximized for the given process. However, the drawback is that you may run into unexpected socket configuration/SSL configuration behavior when you hand the connections to a different client instance. - If we do allow it, what should be the default? I think *not* sharing the connection cache might be a better default behavior. Perhaps we should handle this the same way as the thread pools. Externalize the session cache and if you wish to share connections, provide the appropriate session cache to the AsyncHttpClient instance when it's instantiated. If no cache is provided, then connection reuse is disabled for that client instance. Rick Thanks, Sangjin On 1/14/08, *Jarek Gawor* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 1/14/08, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's a good point... Currently the session cache is global, and all AsyncHttpClient instances are forced to share it. The main thing that concerns me is that as a result the connections will retain all the socket properties that came from the AsyncHttpClient instance that opened the connection. This might not be intuitive to say the least. For example, one AsyncHttpClient instance opens a connection with TCP delay disabled, and then another instance (this time with TCP delay enabled) comes along and picks up this connection for reuse. Contrary to what it expects, it would get a connection with TCP delay disabled. Right and this might be a bigger issue for SSL connections where you might need to distinguish between cached connections based on the client certs, CA certs, or enabled cipher suites (but I'm not sure if these options can be set on the AsyncHttpClient). Jarek
Re: Is there a problem with AsyncHttpClient connection reuse?
I opened a Jira on this issue: https://issues.apache.org/jira/browse/GERONIMO-3749 And attached a patch that I worked up to address this. This is implemented by plugging a SessionCache instance into the AsyncHttpClient instance. A couple notes about this: 1. I chose to use a set method instead of the a constructor argument because the number of permutations of the constructors is already a bit high. It might be better as a constructor argument, but I don't think we want to try to add a permutations for all of the possibilities. 2. The reuseConnection attribute became redundant when this was added. The cache is now used to trigger the reuse behavior. Please comment on the patch. I'll not commit anything until it appears we have consensus. Rick Sangjin Lee wrote: Yes, if you used a different configuration for the SSL, then it would be another issue. The questions are: - Do we want to even allow an option for using a shared connection cache? The benefit of a shared connection cache is ... just that; connection reuse will be maximized for the given process. However, the drawback is that you may run into unexpected socket configuration/SSL configuration behavior when you hand the connections to a different client instance. - If we do allow it, what should be the default? I think *not* sharing the connection cache might be a better default behavior. Thanks, Sangjin On 1/14/08, *Jarek Gawor* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 1/14/08, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's a good point... Currently the session cache is global, and all AsyncHttpClient instances are forced to share it. The main thing that concerns me is that as a result the connections will retain all the socket properties that came from the AsyncHttpClient instance that opened the connection. This might not be intuitive to say the least. For example, one AsyncHttpClient instance opens a connection with TCP delay disabled, and then another instance (this time with TCP delay enabled) comes along and picks up this connection for reuse. Contrary to what it expects, it would get a connection with TCP delay disabled. Right and this might be a bigger issue for SSL connections where you might need to distinguish between cached connections based on the client certs, CA certs, or enabled cipher suites (but I'm not sure if these options can be set on the AsyncHttpClient). Jarek
[jira] Created: (GERONIMO-3749) Global session cache can cause multiple client instances to reuse incorrectly configured connections.
Global session cache can cause multiple client instances to reuse incorrectly configured connections. - Key: GERONIMO-3749 URL: https://issues.apache.org/jira/browse/GERONIMO-3749 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: AsyncHttpClient Reporter: Rick McGuire Priority: Minor The current connection reuse mechanism relies on a single global session class per process (or really, per class loader that loads the ahc code) to store all of the i/o sessions indexed by host/port. Since the selection is made based totally on host and port, it is possible that one ahc client could end up reusing a connection created by a client with a completely different connection configuration. Caching should be implemented using a instance-based cache rather than a single global session cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3749) Global session cache can cause multiple client instances to reuse incorrectly configured connections.
[ https://issues.apache.org/jira/browse/GERONIMO-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire updated GERONIMO-3749: --- Attachment: 3749.patch Potential fix to this problem. Global session cache can cause multiple client instances to reuse incorrectly configured connections. - Key: GERONIMO-3749 URL: https://issues.apache.org/jira/browse/GERONIMO-3749 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Reporter: Rick McGuire Priority: Minor Attachments: 3749.patch The current connection reuse mechanism relies on a single global session class per process (or really, per class loader that loads the ahc code) to store all of the i/o sessions indexed by host/port. Since the selection is made based totally on host and port, it is possible that one ahc client could end up reusing a connection created by a client with a completely different connection configuration. Caching should be implemented using a instance-based cache rather than a single global session cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3645) Monitoring plugins build fails
[ https://issues.apache.org/jira/browse/GERONIMO-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha closed GERONIMO-3645. Resolution: Fixed Fix Version/s: 2.1 Monitoring plugins build fails -- Key: GERONIMO-3645 URL: https://issues.apache.org/jira/browse/GERONIMO-3645 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Anita Kulshreshtha Fix For: 2.1 Monitoring plugins build fails when there is a clean (empty) local maven repository due to lack of the artifacts org.apache.geronimo.modules:modules and org.apache.geronimo.configs:configs Need to sift through poms and clean up to prevent this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3712) Remove redundent statisitcs from JettyConnectorStats and JettyWebConnectorStats
[ https://issues.apache.org/jira/browse/GERONIMO-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha closed GERONIMO-3712. Resolution: Fixed Remove redundent statisitcs from JettyConnectorStats and JettyWebConnectorStats --- Key: GERONIMO-3712 URL: https://issues.apache.org/jira/browse/GERONIMO-3712 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, Jetty, management Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 2.1 Jetty WebConnector has a ConnectionsCount statistics which should be included in TimeStatistics named ConnectionsDuration. JettyWebContainer has a RequestCount statistics which should be included in TimeStatistics named RequestDuration. Currently the average value is stored in TimeStatistics.count. which is incorrect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3441) Server monitoring and management
[ https://issues.apache.org/jira/browse/GERONIMO-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha closed GERONIMO-3441. Resolution: Fixed Fix Version/s: 2.1 rev. 580468 - Initial check in to sandbox Server monitoring and management Key: GERONIMO-3441 URL: https://issues.apache.org/jira/browse/GERONIMO-3441 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Environment: All Reporter: Erik B. Craig Assignee: Anita Kulshreshtha Fix For: 2.1 Attachments: mrc-client.zip, mrc-server.zip, mrc.zip, screenshot1.jpg, screenshot2.jpg, stats.patch Currently, there is not a good way of surfacing Geronimo's server information so that an administrator can monitor the server's status. The architecture of using MBeans is established, but not fully exploited. This enhancement will take advantage of what Geronimo currently offers and extend it so that a server can tap into a cluster of servers and extract information from specific Geronimo servers or even aggregates of Geronimo servers. The goal is to have one machine be able to reach out to all Geronimo servers in order to fetch data or even alter their state. This will be especially useful in the case of someone having to monitor a large number of Geronimo servers. Viet Nguyen and myself have completed a bit of framework towards this goal, to be attached to this jira In-depth information can be found in the confluence wiki here http://cwiki.apache.org/confluence/display/GMOxDEV/Monitoring+and+Management+Service -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1775) Internationalization of the Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YunFeng Ma updated GERONIMO-1775: - Attachment: GERONIMO-1775-2.patch The patch GERONIMO-1775-2 enable the i18n support for Console Navigation and Portlet header. The design is that each console extension provides its own properties files to support i18n, but the Console Navigation and Portlet header are rendered in console-portal-driver. So each console extension has to register its properties files to a central registery when it starts, console-portal-driver can load the properties files in the registery to support i18n. Please review the implementation and any suggestion is welcome. Thanks a lot. Internationalization of the Admin Console - Key: GERONIMO-1775 URL: https://issues.apache.org/jira/browse/GERONIMO-1775 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Reporter: Yeray Cabrera Santana Assignee: Donald Woods Priority: Minor Fix For: 2.1 Attachments: chinese_console.JPG, GERONIMO-1775-1.patch, GERONIMO-1775-2.patch, GERONIMO-1775.patch Provide the internationalization of the administration console so it can be translated to different languages. This is a feature I would like to contribute with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
NoClassDefFoundError when stop a module in admin console
Hi David, I noticed that you commentted out the dependency geronimo-gbean-deployer in geronimo\plugins\console\console-jetty\pom.xml in rev 611338. Maybe this caused the NoClassDefFoundError when stop a module in admin console. The dependency geronimo-gbean-deployer still exists in geronimo\plugins\console\console-tomcat\pom.xml. Such as stop org.apache.geronimo.plugins/sysdb-console-jetty/2.1-SNAPSHOT/car in admin console, got the exception: HTTP ERROR: 500 org.apache.geronimo.deployment.plugin.TargetModuleIDImpl RequestURI=/console/portal//Applications/Web%20App%20WARs/__ac0x3console-base0x2WARModules!874780194|0 Caused by: java.lang.NoClassDefFoundError: org.apache.geronimo.deployment.plugin.TargetModuleIDImpl at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.printResults(ConfigManagerPortlet.java:166) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:210) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at
[jira] Updated: (GERONIMO-1775) Internationalization of the Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YunFeng Ma updated GERONIMO-1775: - Attachment: screen1.GIF A screen shot of the i18n support for Console Navigation and Portlet header. Internationalization of the Admin Console - Key: GERONIMO-1775 URL: https://issues.apache.org/jira/browse/GERONIMO-1775 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Reporter: Yeray Cabrera Santana Assignee: Donald Woods Priority: Minor Fix For: 2.1 Attachments: chinese_console.JPG, GERONIMO-1775-1.patch, GERONIMO-1775-2.patch, GERONIMO-1775.patch, screen1.GIF Provide the internationalization of the administration console so it can be translated to different languages. This is a feature I would like to contribute with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Console issues
Hi David, I'm glad you brought this up. I have been working on this GERONIMO-3746, while I'm at it is there anything else you or anyone else think i can add into the process? So the items I'm working on, just as you said, the progress bar has a few kinks and a 'completion' page (to give the user some assurance the process is done). Furthermore, I can't say that i have been gifted the 'sense of style' to redesign the pages... but anyone who has any ideas for the UI of the plugin installer i'll try my best to capture it. Thanks The best, Joseph Leong On Jan 15, 2008 4:23 AM, David Jencks [EMAIL PROTECTED] wrote: I spent some time working on the admin console plugin installer so you can install more than one plugin at once. It works but there are still some problems I don't know how to fix: if someone who has a bit of jsp/servlet knowledge could take a look that would be great, and having someone with a sense of style review the changes would also be great. -- GERONIMO-3746 (Joseph Leong may be looking at this). The progress bar sometimes updates and sometimes doesn't and the page never looks to be done or moves on. Also the message at the top of the page doesn't work any more I can't figure out how to get a list of the plugins we are installing into the message. -- the car-export servlet seems to always name the file car- export (GERONIMO-2311) In general I think the console could use a pretty thorough review to make sure everything still works. The testsuite is great but not all- inclusive. Also, I seem to recall a nice background in the console before it turned into plugins. Anyone know what happened? thanks david jencks
Re: [YOKO]
Hi Lars, Just a note about JDK versions. Since Geronimo 2.x is targeted at JEE5, 1.5 is actually a requirement now. By the way - Welcome to Geronimo. Jay Lars Kühne wrote: On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed +1 Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency to 1.5 since yoko entered the incubator? We shouldn't change the required JDK in a point release, so this seems like a good time to revisit this decision. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. That was me. My concern wasn't so much about user docs but developer level documentation, see the Answer this question... yoko issues in jira. Those questions mostly about being able to attract new developers. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Yes, the code could use some cleanup but it does pass certification and we can always improve things later, in another release. This of course assumes that we don't have to pay too much attention to backward compatibility. Does each follow-up version have to be a drop-in replacement of the first 1.0 release? Or is it OK to change ORB properties and such, as long as the changes are documented in the release notes (which is what I hope, but I don't know the requirements of Geronimo and Harmony)? Regards, Lars
Re: [YOKO]
The Yoko ORB code still generates 1.4 compatible code. Since the ORB doesn't have any direct dependencies on Geronimo, it probably can be maintained as just being dependent on 1.4. On the other hand, there are many times I wished I could use some of the stuff in 1.5 (such as the concurrency classes). Harmony is a 1.5 JDK, so 1.4 compatibility is not an issue for them. Yoko is used in the never released 1.2 Geronimo version too. I suspect that's going to remain in its never released state so I don't think Geronimo is an issue either. I can go either way on the JDK issue depending on what the consensus is. Rick Jay D. McHugh wrote: Hi Lars, Just a note about JDK versions. Since Geronimo 2.x is targeted at JEE5, 1.5 is actually a requirement now. By the way - Welcome to Geronimo. Jay Lars Kühne wrote: On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed +1 Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency to 1.5 since yoko entered the incubator? We shouldn't change the required JDK in a point release, so this seems like a good time to revisit this decision. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. That was me. My concern wasn't so much about user docs but developer level documentation, see the Answer this question... yoko issues in jira. Those questions mostly about being able to attract new developers. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Yes, the code could use some cleanup but it does pass certification and we can always improve things later, in another release. This of course assumes that we don't have to pay too much attention to backward compatibility. Does each follow-up version have to be a drop-in replacement of the first 1.0 release? Or is it OK to change ORB properties and such, as long as the changes are documented in the release notes (which is what I hope, but I don't know the requirements of Geronimo and Harmony)? Regards, Lars
Re: [YOKO]
Lars Kühne wrote: On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed +1 Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency to 1.5 since yoko entered the incubator? We shouldn't change the required JDK in a point release, so this seems like a good time to revisit this decision. I think this might be a good time to revisit this, though I'd be reluctant to put out a release without running it through the TCK first. Since the only TCK we have is the full Geronimo TCK this sort of needs to be coordinated with a Geronimo release. For the current Geronimo release that's in the works, we've checked a specific revision build into the Geronimo repository, so that's what it is running with. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. That was me. My concern wasn't so much about user docs but developer level documentation, see the Answer this question... yoko issues in jira. Those questions mostly about being able to attract new developers. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Yes, the code could use some cleanup but it does pass certification and we can always improve things later, in another release. This of course assumes that we don't have to pay too much attention to backward compatibility. Does each follow-up version have to be a drop-in replacement of the first 1.0 release? Or is it OK to change ORB properties and such, as long as the changes are documented in the release notes (which is what I hope, but I don't know the requirements of Geronimo and Harmony)? Generally, since Geronimo gets built and shipped with a specific release dependency, it's ok to break compatibility if there is a good reason for doing so. Of course, since Yoko is now part of Geronimo, the person breaking the compatibility also needs to be responsible for any Geronimo build breakages that occur. I think Harmony tends to adhere closer to the OMG standards in terms of its usage, so it's less of an issue. Geronimo uses a couple of hooks that were put in place to allow it to integrate CSIv2 and RMI support into Geronimo. These can be changed as long as the Geronimo code is fixed in parallel. Rick Regards, Lars
How to change KeyStore type?
Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
Re: [BUILD] 2.1: Failed for Revision: 611733
Btw, I updated the automatic build scripts to publish the unit test
reports (*.txt) if the build fails. So, next time if a unit test
fails, the email notification message sent will contain a link to the
unit test reports.
Jarek
On Jan 14, 2008 11:46 AM, Jarek Gawor [EMAIL PROTECTED] wrote:
David,
No, not right now with the unit tests. But I will try to figure
something out to provide that info.
Please keep in mind that this 3am trunk test is with IBM JDK. The
weird thing is that I'm unable to replicate the problem with the same
JDK on another machine. But my guess is that this test is failing
becuase it compares two xml documents as strings and not as DOM
objects.
Jarek
On 1/14/08, David Jencks [EMAIL PROTECTED] wrote:
Is there any chance of seeing the test failure output? This test is
passing when I run it which makes it a bit hard to diagnose.
thanks
david jencks
On Jan 14, 2008, at 12:16 AM, [EMAIL PROTECTED] wrote:
OpenEJB trunk at 61
Geronimo Revision: 611733 built with tests included
See the full build-0300.log file at http://people.apache.org/
~prasad/binaries/trunk/20080114/build-0300.log
Running
org.apache.geronimo.system.configuration.condition.JexlConditionParser
Test
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.046 sec
Running
org.apache.geronimo.system.configuration.InPlaceConfigurationUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.028 sec
Running org.apache.geronimo.system.logging.log4j.XLevelTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.005 sec
Running
org.apache.geronimo.system.configuration.ConfigurationStoreUtilTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.319 sec
Running
org.apache.geronimo.system.configuration.LocalAttributeManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.058 sec
Running org.apache.geronimo.system.configuration.GBeanOverrideTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.02 sec
Running org.apache.geronimo.system.configuration.ServerOverrideTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.048 sec
Running
org.apache.geronimo.system.configuration.condition.JexlExpressionParse
rTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.007 sec
Results :
Tests run: 58, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar: /home/prasad/geronimo/trunk/framework/modules/
geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-system-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/framework/modules/
geronimo-system/target/geronimo-system-2.1-SNAPSHOT.jar to /home/
prasad/.m2/repository/org/apache/geronimo/modules/geronimo-system/
2.1-SNAPSHOT/geronimo-system-2.1-SNAPSHOT.jar
[INFO]
--
--
[INFO] Building geronimo-plugin
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/framework/modules/
geronimo-plugin/target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/framework/
modules/geronimo-plugin/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 21 source files to /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/test-classes
[INFO] [surefire:test]
[WARNING] Component returned which is not the same manager.
Ignored.
[EMAIL PROTECTED]
282428
[INFO] Surefire report directory: /home/prasad/geronimo/trunk/
framework/modules/geronimo-plugin/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.system.plugin.ArchiverGBeanTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
0.143 sec
Running org.apache.geronimo.system.plugin.CopyConfigTest
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
1.348 sec FAILURE!
Running org.apache.geronimo.system.plugin.CopyFileTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0,
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
Peter, I also see the same problem on XP on second start up. But I was able to work around it by removing 'propertyEditor=org.apache.xbean.propertyeditor.LinkedListEditor' attribute from attribute/ element of DownloadedPluginRepos gbean. Hope this helps, Jarek On Jan 14, 2008 7:21 PM, Peter Petersson [EMAIL PROTECTED] wrote: In the men time I resorted to the assembly I pulled together yesterday and just doing a ./startup.sh; ./shutdown.sh; ./startup.sh fails on the second startup with the error indicated bellow. Its getting late here so I will look in to this again tomorrow hopefully with a fresh build. regards Peter Petersson Peter Petersson wrote: Things seems to be in a flux right now as I get a parse exception on 'geronimo-plugin-list' so I guess I have to wait with testing out plugins on a fresh build. I get back to you when this is out of the way. regards Peter P 23:44:02,710 INFO [PluginInstallerGBean] Attempting to download file:/home/ppe/.m2/repository/geronimo-plugins.xml 23:44:02,860 ERROR [PluginInstallerGBean] Unable to load repository configuration data org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'geronimo-plugin-list'. at org.apache.geronimo.system.plugin.PluginInstallerGBean$3.error(PluginInstallerGBean.java:1440) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) Peter Petersson wrote: David Jencks wrote: I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os Nice :) hmmm well I am on Linux and Hernan got this on a Windows XP box and maybe osx is spared but there is clearly something wrong with my environment or else the server is getting into a faulty state due to the plugin modules I install (roller-tomcat, roller-themes) although I doubt the later is the case ;), I will try investigate this a bit more, will post my findings (if any) here but If you or anyone else have some suggestions or hints on what may cause this let me know. I will do a svn update; mvn clean install; and go make some coffee and try out the new build with different setups. regards Peter P thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version] = 49.0 09:05:33,871 INFO [Log4jService] System property [locale] = sv_SE 09:05:33,871 INFO [Log4jService] System property [unicode.encoding]= UnicodeLittle 09:05:33,871 INFO [Log4jService] System property [file.encoding] = UTF-8 09:05:33,871 INFO [Log4jService] System property [java.vm.name]= Java HotSpot(TM) Server VM 09:05:33,871 INFO [Log4jService] System property [java.vm.vendor] = Sun Microsystems Inc. 09:05:33,871 INFO [Log4jService] System property [java.vm.version] = 1.5.0_13-b05 09:05:33,871 INFO [Log4jService] System property [java.vm.info]= mixed
[jira] Created: (GERONIMO-3750) WSDL generation fails for some web services
WSDL generation fails for some web services --- Key: GERONIMO-3750 URL: https://issues.apache.org/jira/browse/GERONIMO-3750 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.0.2, 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor It looks like wsgen process (with Axis2 web services) can fail if the web service is using JPA API. The exception looks something like: 11:19:15,796 ERROR [EjbModuleBuilder] JAXWSEJBModuleBuilderExtension.addGBeans() failed: Unable to find the service wsdl file org.apache.geronimo.common.DeploymentException: Unable to find the service wsdl file at org.apache.geronimo.jaxws.builder.WsdlGenerator.generateWsdl(WsdlGenerator.java:293) at org.apache.geronimo.axis2.builder.Axis2Builder.initialize(Axis2Builder.java:222) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.configureEJB(JAXWSServiceBuilder.java:215) at org.apache.geronimo.jaxws.builder.JAXWSEJBModuleBuilderExtension.addGBeans(JAXWSEJBModuleBuilderExtension.java:167) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:818) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:646) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:246) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
[ https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-98: --- Attachment: GShell-98.patch The issue ended up being that the find function in GroupNode was not able to handle nested GroupNodes. I enhanced it to provide a recursive search that should work for any amount of nesting that you so desire. NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2 Attachments: GShell-98.patch The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3750) WSDL generation fails for some web services
[ https://issues.apache.org/jira/browse/GERONIMO-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559120#action_12559120 ] Jarek Gawor commented on GERONIMO-3750: --- Added a few spec jars to the classpath of the wsgen tool. That seems to help. Fixes committed to trunk (revision 612156). WSDL generation fails for some web services --- Key: GERONIMO-3750 URL: https://issues.apache.org/jira/browse/GERONIMO-3750 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor It looks like wsgen process (with Axis2 web services) can fail if the web service is using JPA API. The exception looks something like: 11:19:15,796 ERROR [EjbModuleBuilder] JAXWSEJBModuleBuilderExtension.addGBeans() failed: Unable to find the service wsdl file org.apache.geronimo.common.DeploymentException: Unable to find the service wsdl file at org.apache.geronimo.jaxws.builder.WsdlGenerator.generateWsdl(WsdlGenerator.java:293) at org.apache.geronimo.axis2.builder.Axis2Builder.initialize(Axis2Builder.java:222) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.configureEJB(JAXWSServiceBuilder.java:215) at org.apache.geronimo.jaxws.builder.JAXWSEJBModuleBuilderExtension.addGBeans(JAXWSEJBModuleBuilderExtension.java:167) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:818) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:646) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:246) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO]
On Jan 15, 2008, at 7:03 AM, Rick McGuire wrote: The Yoko ORB code still generates 1.4 compatible code. Since the ORB doesn't have any direct dependencies on Geronimo, it probably can be maintained as just being dependent on 1.4. On the other hand, there are many times I wished I could use some of the stuff in 1.5 (such as the concurrency classes). Harmony is a 1.5 JDK, so 1.4 compatibility is not an issue for them. Yoko is used in the never released 1.2 Geronimo version too. I suspect that's going to remain in its never released state so I don't think Geronimo is an issue either. I can go either way on the JDK issue depending on what the consensus is. I would LOVE to use JDK1.5. Maybe Yoko 2.0? There are plenty of backport paths so it's not like we would be abandoning JDK1.4. Regards, Alan
[jira] Resolved: (GERONIMO-3750) WSDL generation fails for some web services
[ https://issues.apache.org/jira/browse/GERONIMO-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3750. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Committed the fixes to branches/2.0 (revision 612176). WSDL generation fails for some web services --- Key: GERONIMO-3750 URL: https://issues.apache.org/jira/browse/GERONIMO-3750 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 It looks like wsgen process (with Axis2 web services) can fail if the web service is using JPA API. The exception looks something like: 11:19:15,796 ERROR [EjbModuleBuilder] JAXWSEJBModuleBuilderExtension.addGBeans() failed: Unable to find the service wsdl file org.apache.geronimo.common.DeploymentException: Unable to find the service wsdl file at org.apache.geronimo.jaxws.builder.WsdlGenerator.generateWsdl(WsdlGenerator.java:293) at org.apache.geronimo.axis2.builder.Axis2Builder.initialize(Axis2Builder.java:222) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.configureEJB(JAXWSServiceBuilder.java:215) at org.apache.geronimo.jaxws.builder.JAXWSEJBModuleBuilderExtension.addGBeans(JAXWSEJBModuleBuilderExtension.java:167) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:818) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:646) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:246) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) -- 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.
Re: Is there a problem with AsyncHttpClient connection reuse?
It looks good to me. A couple of minor things. - AsyncHttpClient.getCachedConnection() takes a SessionCache as an argument. I don't think this is necessary as the SessionCache is an instance variable of AsyncHttpClient? - We will need to reflect this API change to the Geronimo sample code that we have... Thanks, Sangjin On 1/15/08, Rick McGuire [EMAIL PROTECTED] wrote: I opened a Jira on this issue: https://issues.apache.org/jira/browse/GERONIMO-3749 And attached a patch that I worked up to address this. This is implemented by plugging a SessionCache instance into the AsyncHttpClient instance. A couple notes about this: 1. I chose to use a set method instead of the a constructor argument because the number of permutations of the constructors is already a bit high. It might be better as a constructor argument, but I don't think we want to try to add a permutations for all of the possibilities. 2. The reuseConnection attribute became redundant when this was added. The cache is now used to trigger the reuse behavior. Please comment on the patch. I'll not commit anything until it appears we have consensus. Rick Sangjin Lee wrote: Yes, if you used a different configuration for the SSL, then it would be another issue. The questions are: - Do we want to even allow an option for using a shared connection cache? The benefit of a shared connection cache is ... just that; connection reuse will be maximized for the given process. However, the drawback is that you may run into unexpected socket configuration/SSL configuration behavior when you hand the connections to a different client instance. - If we do allow it, what should be the default? I think *not* sharing the connection cache might be a better default behavior. Thanks, Sangjin On 1/14/08, *Jarek Gawor* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 1/14/08, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's a good point... Currently the session cache is global, and all AsyncHttpClient instances are forced to share it. The main thing that concerns me is that as a result the connections will retain all the socket properties that came from the AsyncHttpClient instance that opened the connection. This might not be intuitive to say the least. For example, one AsyncHttpClient instance opens a connection with TCP delay disabled, and then another instance (this time with TCP delay enabled) comes along and picks up this connection for reuse. Contrary to what it expects, it would get a connection with TCP delay disabled. Right and this might be a bigger issue for SSL connections where you might need to distinguish between cached connections based on the client certs, CA certs, or enabled cipher suites (but I'm not sure if these options can be set on the AsyncHttpClient). Jarek
[jira] Commented: (GERONIMO-3749) Global session cache can cause multiple client instances to reuse incorrectly configured connections.
[
https://issues.apache.org/jira/browse/GERONIMO-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559196#action_12559196
]
Sangjin Lee commented on GERONIMO-3749:
---
It looks good to me. A couple of minor things.
- AsyncHttpClient.getCachedConnection() takes a SessionCache as an argument. I
don't think this is necessary as the SessionCache is an instance variable of
AsyncHttpClient? So I might suggest something like
+private ConnectFuture getCachedConnection(HttpRequestMessage message) {
+IoSession cached = sessionCache.getActiveSession(message);
if (cached == null) {
return null;
}
- We will need to reflect this API change to the Geronimo sample code that we
have...
Global session cache can cause multiple client instances to reuse incorrectly
configured connections.
-
Key: GERONIMO-3749
URL: https://issues.apache.org/jira/browse/GERONIMO-3749
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: AsyncHttpClient
Reporter: Rick McGuire
Priority: Minor
Attachments: 3749.patch
The current connection reuse mechanism relies on a single global session
class per process (or really, per class loader that loads the ahc code) to
store all of the i/o sessions indexed by host/port. Since the selection is
made based totally on host and port, it is possible that one ahc client could
end up reusing a connection created by a client with a completely different
connection configuration. Caching should be implemented using a
instance-based cache rather than a single global session cache.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[AsyncHttpClient] order of Future completion and callback invocation
Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. What do you think? I'll open a JIRA issue if you guys agree this is a bug. Thanks, Sangjin
[jira] Commented: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
[ https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559214#action_12559214 ] Jason Dillon commented on GSHELL-98: Cool! I will look at this later today. Still a little jet lagged though... NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2 Attachments: GShell-98.patch The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
[ https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GSHELL-98: -- Assignee: Jason Dillon (was: Jason Warner) NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Dillon Fix For: 1.0-alpha-2 Attachments: GShell-98.patch The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3751) callbacks may not be completed when caller uses future.get() too to complete request handling
[ https://issues.apache.org/jira/browse/GERONIMO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3751: -- Attachment: GERONIMO-3751.patch a suggested fix callbacks may not be completed when caller uses future.get() too to complete request handling - Key: GERONIMO-3751 URL: https://issues.apache.org/jira/browse/GERONIMO-3751 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Minor Attachments: GERONIMO-3751.patch Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncHttpClient] order of Future completion and callback invocation
I have opened a JIRA issue (GERONIMO-3751), and attached a suggested patch. Please let me know what you think... Thanks, Sangjin On Jan 15, 2008 11:49 AM, Sangjin Lee [EMAIL PROTECTED] wrote: Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. What do you think? I'll open a JIRA issue if you guys agree this is a bug. Thanks, Sangjin
Re: Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
Yes thank you Jarek! As mentioned by Jarek the second attribute below is the offending one. It is added to the config by adding a repository. The question is where is my org.apache.xbean.propertyeditor.LinkedListEditor :) maybe it is fixed in newer builds I haven't got around checking it yet. thanks Peter P config.xml : module name=org.apache.geronimo.configs/plugin/2.1-SNAPSHOT/car gbean name=DownloadedPluginRepos attribute name=repositoryListhttp://geronimo.apache.org/plugins/plugin-repository-list-2.1.txt/attribute attribute propertyEditor=org.apache.xbean.propertyeditor.LinkedListEditor name=userRepositories[~/.m2/repository,file:/home/ppe/.m2/repository/]/attribute /gbean /module Jarek Gawor wrote: Peter, I also see the same problem on XP on second start up. But I was able to work around it by removing 'propertyEditor=org.apache.xbean.propertyeditor.LinkedListEditor' attribute from attribute/ element of DownloadedPluginRepos gbean. Hope this helps, Jarek On Jan 14, 2008 7:21 PM, Peter Petersson [EMAIL PROTECTED] wrote: In the men time I resorted to the assembly I pulled together yesterday and just doing a ./startup.sh; ./shutdown.sh; ./startup.sh fails on the second startup with the error indicated bellow. Its getting late here so I will look in to this again tomorrow hopefully with a fresh build. regards Peter Petersson Peter Petersson wrote: Things seems to be in a flux right now as I get a parse exception on 'geronimo-plugin-list' so I guess I have to wait with testing out plugins on a fresh build. I get back to you when this is out of the way. regards Peter P 23:44:02,710 INFO [PluginInstallerGBean] Attempting to download file:/home/ppe/.m2/repository/geronimo-plugins.xml 23:44:02,860 ERROR [PluginInstallerGBean] Unable to load repository configuration data org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'geronimo-plugin-list'. at org.apache.geronimo.system.plugin.PluginInstallerGBean$3.error(PluginInstallerGBean.java:1440) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) Peter Petersson wrote: David Jencks wrote: I finally got around to applying your roller plugin patch but I can't reproduce this either on jetty or tomcat. I'm on osx I wonder if its due to the different os Nice :) hmmm well I am on Linux and Hernan got this on a Windows XP box and maybe osx is spared but there is clearly something wrong with my environment or else the server is getting into a faulty state due to the plugin modules I install (roller-tomcat, roller-themes) although I doubt the later is the case ;), I will try investigate this a bit more, will post my findings (if any) here but If you or anyone else have some suggestions or hints on what may cause this let me know. I will do a svn update; mvn clean install; and go make some coffee and try out the new build with different setups. regards Peter P thanks david jencks On Jan 14, 2008, at 2:28 AM, Peter Petersson wrote: Anyone still getting this? On the first startup the server starts fine but every following startup after a shutdown (or even reboot of comp) fails. I have had this problem for some time now (2 weeks I think) and to get around it I keep reinstalling the server but that's getting a bit boring :). This is happening for me on new builds of 2.1. The only thing I have done in between is installing the roller plugin. I have also tried startup with load=false in config.xml on the roller modules before startup (just in case the plugin would be causing the startup problem) but it dose not help. Any clues on what may causing this ? thanks Peter P 09:05:33,865 INFO [Log4jService] -- 09:05:33,865 INFO [Log4jService] Started Logging Service 09:05:33,865 INFO [Log4jService] Runtime Information: 09:05:33,865 INFO [Log4jService] Install Directory = /usr/local/geronimo-tomcat6-javaee5-2.1-SNAPSHOT 09:05:33,865 INFO [Log4jService] JVM in use = Sun Microsystems Inc. Java 1.5.0_13 09:05:33,865 INFO [Log4jService] Java Information: 09:05:33,865 INFO [Log4jService] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 09:05:33,865 INFO [Log4jService] System property [java.runtime.version] = 1.5.0_13-b05 09:05:33,865 INFO [Log4jService] System property [os.name] = Linux 09:05:33,865 INFO [Log4jService] System property [os.version] = 2.6.22-14-generic 09:05:33,871 INFO [Log4jService] System property [sun.os.patch.level] = unknown 09:05:33,871 INFO [Log4jService] System property [os.arch] = i386 09:05:33,871 INFO [Log4jService] System property [java.class.version]
[jira] Commented: (GERONIMO-3732) Separate plugin management into new jar, car, and management plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559270#action_12559270 ] David Jencks commented on GERONIMO-3732: Rev 612279. remove some bad dependencies on jsr88 stuff in the base console. Clean up the code and dependencies a little bit. Separate plugin management into new jar, car, and management plugins Key: GERONIMO-3732 URL: https://issues.apache.org/jira/browse/GERONIMO-3732 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 1. Move the plugin management code into a new jar 2. Move the gbeans into a new car, with some of the server-side jsr88 dependencies 3. Move the admin console plugin support into a new admin console plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-257) Errors when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP
Errors when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP -- Key: GERONIMODEVTOOLS-257 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-257 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 As reported by Tomasz Manaz, the following error occurs when publishing to the Geronimo 2.1 server using the 2.1 version of the GEP http://www.nabble.com/file/p14730930/gep-deploy-error.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NoClassDefFoundError when stop a module in admin console
Thanks for finding this, I rewrote the code to not use the offending class. Rev 612279, GERONIMO-3732. It looks like there could be more I18n work here with the status messages, but I don't have much of an idea how to do that. david jencks On Jan 15, 2008, at 5:08 AM, YunFeng Ma wrote: Hi David, I noticed that you commentted out the dependency geronimo-gbean-deployer in geronimo\plugins\console\console-jetty\pom.xml in rev 611338. Maybe this caused the NoClassDefFoundError when stop a module in admin console. The dependency geronimo-gbean-deployer still exists in geronimo\plugins\console\console-tomcat\pom.xml. Such as stop org.apache.geronimo.plugins/sysdb-console-jetty/2.1-SNAPSHOT/car in admin console, got the exception: HTTP ERROR: 500 org.apache.geronimo.deployment.plugin.TargetModuleIDImpl RequestURI=/console/portal//Applications/Web%20App%20WARs/ __ac0x3console-base0x2WARModules!874780194|0 Caused by: java.lang.NoClassDefFoundError: org.apache.geronimo.deployment.plugin.TargetModuleIDImpl at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.printRe sults(ConfigManagerPortlet.java:166) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.process Action(ConfigManagerPortlet.java:210) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle (InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 362) at org.mortbay.jetty.security.SecurityHandler.handle (SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle (JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101 (TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext $TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle (ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle (InstanceContextHandler.java:67) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle (UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle (ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle (TwistyWebAppContext.java:59) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) at org.apache.pluto.core.DefaultPortletInvokerService.invoke (DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action (DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction (PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet (PortalDriverServlet.java:112) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle (InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 362) at org.mortbay.jetty.security.SecurityHandler.handle (SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle (JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101 (TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext $TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle (ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle (InstanceContextHandler.java:58) at
[jira] Resolved: (GERONIMO-3684) Upgrade Monitoring Client to use Dojo 1.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3684. - Patch Committed revision 612294. Upgrade Monitoring Client to use Dojo 1.0.1 --- Key: GERONIMO-3684 URL: https://issues.apache.org/jira/browse/GERONIMO-3684 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Reporter: Erik B. Craig Assignee: Erik B. Craig Currently the Monitoring client us using Dojo 0.4.x and should be upgraded to utilize Dojo 1.0.1 which offers far superior charting abilities and browser compatibility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-258) GEP by default can no longer deploy to all targets returned from the deployment manager
GEP by default can no longer deploy to all targets returned from the deployment manager --- Key: GERONIMODEVTOOLS-258 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-258 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 Now that the Geronimo 2.1 server supports clustering multiple targets will likely be returned from any getTargets() method invoked on the deployment manager. The GEP should use only the first target, which is the default configuration store and which is explicitly configured by users. Otherwise, the artifacts will get deployed to the master-repository, the cluster-repository, and the local repository which is obviously incorrect and will result in deployment errors. Thanks to Gianny for this very useful bit of information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-48) Add file/URL support to the script command
[
https://issues.apache.org/jira/browse/GSHELL-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GSHELL-48:
---
Attachment: GShell-48.patch
This includes the functionality of both GShell-48 and it's subtask, GShell-49.
Add file/URL support to the script command
--
Key: GSHELL-48
URL: https://issues.apache.org/jira/browse/GSHELL-48
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Attachments: GShell-48.patch
Should be able to give the BSF {{script}} command a file or URL to execute.
--
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: (GSHELL-48) Add file/URL support to the script command
[
https://issues.apache.org/jira/browse/GSHELL-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559296#action_12559296
]
jawarner edited comment on GSHELL-48 at 1/15/08 4:10 PM:
-
This includes the functionality of both GShell-48 and the subtask, GShell-49.
was (Author: jawarner):
This includes the functionality of both GShell-48 and it's subtask,
GShell-49.
Add file/URL support to the script command
--
Key: GSHELL-48
URL: https://issues.apache.org/jira/browse/GSHELL-48
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Attachments: GShell-48.patch
Should be able to give the BSF {{script}} command a file or URL to execute.
--
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=12559337#action_12559337 ] Kevan Miller commented on GERONIMO-3069: Hi Jay, On both versions, the screens look fine on a Mac. --kevan 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-2311) Exporting plug-in configurations
[ https://issues.apache.org/jira/browse/GERONIMO-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YunFeng Ma updated GERONIMO-2311: - Attachment: GERONIMO-2311.patch The exported plugin name would be ArtifactName + - + ArtifactVersion + . + ArtifactType. This patch also fixed a problem that CARExportForward and PlanExportForward forward to the wrong context. Exporting plug-in configurations Key: GERONIMO-2311 URL: https://issues.apache.org/jira/browse/GERONIMO-2311 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1.2 Reporter: Krishnakumar B Priority: Minor Attachments: GERONIMO-2311.patch When i export a configuration from geronimo to plugin and save it to disk the file names are not legible for e.g) I exported a DataSource Saved as rar.0%2Frar I exported a War . Saved as war.0%2Fwar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NoClassDefFoundError when stop a module in admin console
Thanks a lot, David, you've given me a big help. Could any other console experts review this improvement? (https://issues.apache.org/jira/browse/GERONIMO-1775) Thanks - Yun Feng David Jencks wrote: Thanks for finding this, I rewrote the code to not use the offending class. Rev 612279, GERONIMO-3732. It looks like there could be more I18n work here with the status messages, but I don't have much of an idea how to do that. david jencks On Jan 15, 2008, at 5:08 AM, YunFeng Ma wrote: Hi David, I noticed that you commentted out the dependency geronimo-gbean-deployer in geronimo\plugins\console\console-jetty\pom.xml in rev 611338. Maybe this caused the NoClassDefFoundError when stop a module in admin console. The dependency geronimo-gbean-deployer still exists in geronimo\plugins\console\console-tomcat\pom.xml. Such as stop org.apache.geronimo.plugins/sysdb-console-jetty/2.1-SNAPSHOT/car in admin console, got the exception: HTTP ERROR: 500 org.apache.geronimo.deployment.plugin.TargetModuleIDImpl RequestURI=/console/portal//Applications/Web%20App%20WARs/__ac0x3console-base0x2WARModules!874780194|0 Caused by: java.lang.NoClassDefFoundError: org.apache.geronimo.deployment.plugin.TargetModuleIDImpl at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.printResults(ConfigManagerPortlet.java:166) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:210) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at
