[jira] Commented: (GERONIMO-5243) /activemq-console does not require admin authentication
[ https://issues.apache.org/jira/browse/GERONIMO-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854820#action_12854820 ] Jack Cai commented on GERONIMO-5243: I cannot reproduce this problem with the 2.2.1 snapshot build of Apr. 7th. There is no application bounded to http://localhost:8080/activemq-console. What did I miss? /activemq-console does not require admin authentication --- Key: GERONIMO-5243 URL: https://issues.apache.org/jira/browse/GERONIMO-5243 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Kevan Miller Priority: Blocker Fix For: 2.2.1, 3.0 On branches/2.2 I'm able to access http://localhost:8080/activemq-console without authentication. Since I'm able to inspect Destinations, delete Destinations, etc. , this is not a good thing. We need to secure with geronimo-admin realm, just like the admin console. I haven't tested on trunk, but am guessing this is a problem, there also. activemq-console was not shipped in 2.1.0. So, it's not a problem there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5159) Add pause when startup.bat fails on Windows
Add pause when startup.bat fails on Windows Key: GERONIMO-5159 URL: https://issues.apache.org/jira/browse/GERONIMO-5159 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: commands Affects Versions: 2.2, 2.1.4 Environment: Windows Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5 When starting Geronimo in a separate command prompt (with startup.bat or geronimo.bat start), the new command prompt will close immediately after an error occurs, leaving no chance for the user to take a look at the console output. An improvement could be made to pause the prompt when an exception occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5159) Add pause when startup.bat fails on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838811#action_12838811 ] Jack Cai commented on GERONIMO-5159: Commit a fix for 2.1 branch at 916641 Add pause when startup.bat fails on Windows Key: GERONIMO-5159 URL: https://issues.apache.org/jira/browse/GERONIMO-5159 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4, 2.2 Environment: Windows Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5 When starting Geronimo in a separate command prompt (with startup.bat or geronimo.bat start), the new command prompt will close immediately after an error occurs, leaving no chance for the user to take a look at the console output. An improvement could be made to pause the prompt when an exception occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-5159) Add pause when startup.bat fails on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-5159. Resolution: Fixed Commit fix to 2.2 branch at Rev 916899 trunk at Rev 916901. Add pause when startup.bat fails on Windows Key: GERONIMO-5159 URL: https://issues.apache.org/jira/browse/GERONIMO-5159 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4, 2.2 Environment: Windows Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5 When starting Geronimo in a separate command prompt (with startup.bat or geronimo.bat start), the new command prompt will close immediately after an error occurs, leaving no chance for the user to take a look at the console output. An improvement could be made to pause the prompt when an exception occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5159) Add pause when startup.bat fails on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-5159. -- Add pause when startup.bat fails on Windows Key: GERONIMO-5159 URL: https://issues.apache.org/jira/browse/GERONIMO-5159 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4, 2.2 Environment: Windows Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5 When starting Geronimo in a separate command prompt (with startup.bat or geronimo.bat start), the new command prompt will close immediately after an error occurs, leaving no chance for the user to take a look at the console output. An improvement could be made to pause the prompt when an exception occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5142) runtime errors if JAVA_HOME or JRE_HOME is not specified
[ https://issues.apache.org/jira/browse/GERONIMO-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837063#action_12837063 ] Jack Cai commented on GERONIMO-5142: So maybe let's just remove the support for locating java from PATH, which is the current behavior on Windows platforms. runtime errors if JAVA_HOME or JRE_HOME is not specified Key: GERONIMO-5142 URL: https://issues.apache.org/jira/browse/GERONIMO-5142 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.4, 2.2 Reporter: Kevan Miller Fix For: 2.1.5, 2.2.1 setjavaenv.sh used to require JAVA_HOME or JRE_HOME to be specified. Looks like it was updated to look for a java runtime in the PATH, and use that, if the environment variables weren't specified. On Mac OS, at least, this doesn't work. JAVA_HOME/JRE_HOME are used to set other variables. Namely EXT_DIRS and ENDORSED_DIRS. They aren't set properly, if JAVA_HOME/JRE_HOME aren't set. This causes runtime errors: Module 19/70 org.apache.geronimo.configs/openejb/2.1.4/car 2010-02-11 09:48:23,404 ERROR [SimpleEncryption] Unable to decrypt java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES at javax.crypto.Cipher.getInstance(DashoA13*..) at org.apache.geronimo.crypto.AbstractEncryption.decrypt(AbstractEncryption.java:74) at org.apache.geronimo.crypto.EncryptionManager.decrypt(EncryptionManager.java:109) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5125) Enable connecting to a ldap server anonymously on console
[ https://issues.apache.org/jira/browse/GERONIMO-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837065#action_12837065 ] Jack Cai commented on GERONIMO-5125: It appears to me that no one would ever want to use anonymously LDAP access in production though. Enable connecting to a ldap server anonymously on console - Key: GERONIMO-5125 URL: https://issues.apache.org/jira/browse/GERONIMO-5125 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: OS:windows 7 Geronimo:2.1.5-SNAPSHOT Reporter: Lu Jiang After resorving GERONIMO-4997 ,https://issues.apache.org/jira/browse/GERONIMO-4997 ,Connecting to a ldap server anonymous is actually supported. But we can not generate a security realm file on console wizard if we try to connect the ldap server anonymously Steps to reproduce: 1. click Security-Security Realms-Add new security realm 2.Enter a unique name for the relam file and choose LDAP Realm,click next. 3.input all useful information like connectionURL,userBase,etc..according to your ldap server configuration.but Leave the input box for Connect Username and Connect password blank,then click next. An waring box will occur saying:option-ConnectionUsername must not be empty.And I cann't generate a realm file successfully if no user name and password is provided. I think since we can connect to it in an anonymous way.It's not a must to provide user name and password on console.It would be better to provide a way to enable this :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5040) PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12830825#action_12830825 ] Jack Cai commented on GERONIMO-5040: See http://www.mail-archive.com/d...@commons.apache.org/msg13327.html PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows --- Key: GERONIMO-5040 URL: https://issues.apache.org/jira/browse/GERONIMO-5040 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.4, 2.2 Reporter: Johannes Weberhofer Attachments: GERONIMO-5040-service_pr.bat.diff Geronimo should - in my optinion - be started in Java-Mode. In Java (and the currently used exe-Mode) it is necessary to add all important options directly into the startup-arguments fields before the -jar line, which should be noticed in the Wiki. The issue is related to DAEMON-119. At the shutdown page, it is necessary to explicitly select the Java-Mode and set a timeout (30 seconds or so); otherwise the geronimo server will simply be killed without any chance to terminate gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4694) Upgrade to Derby 10.5.3.0
[ https://issues.apache.org/jira/browse/GERONIMO-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-4694. Resolution: Fixed Fix Version/s: (was: Wish List) 3.0 2.2.1 2.1.5 Committed at Rev 906389 for 2.1, Rev 906391 for 2.2, and Rev 906392 for trunk Upgrade to Derby 10.5.3.0 - Key: GERONIMO-4694 URL: https://issues.apache.org/jira/browse/GERONIMO-4694 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.2 Reporter: Jack Cai Assignee: Jack Cai Fix For: 2.1.5, 2.2.1, 3.0 Derby has released a new version 10.5.1.1 last month. Let's upgrade to this version for 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4694) Upgrade to Derby 10.5.3.0
[ https://issues.apache.org/jira/browse/GERONIMO-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4694. -- Upgrade to Derby 10.5.3.0 - Key: GERONIMO-4694 URL: https://issues.apache.org/jira/browse/GERONIMO-4694 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.2 Reporter: Jack Cai Assignee: Jack Cai Fix For: 2.1.5, 2.2.1, 3.0 Derby has released a new version 10.5.1.1 last month. Let's upgrade to this version for 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4968) Problemastic OS check in Windows startup command
[ https://issues.apache.org/jira/browse/GERONIMO-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829566#action_12829566 ] Jack Cai commented on GERONIMO-4968: Clean up more OS check, and committed to 2.1 at Rev 906428, to 2.2 at Rev 906431, and to trunk at Rev 906426. Problemastic OS check in Windows startup command Key: GERONIMO-4968 URL: https://issues.apache.org/jira/browse/GERONIMO-4968 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5, 2.2.1, 3.0 Attachments: GERONIMO-4968.2.1.patch, GERONIMO-4968.2.2.patch, GERONIMO-4968.trunk.patch A user reported that the startup command failed due to OS check failue, even though he is running Windows XP - which is a supported OS. The problem is that the startup command does an exact match of the OS env var against Windows_NT, while in this user's case, the OS env var is WINNT 5.1. Maven has a similar problem: http://jira.codehaus.org/browse/MNG-3354 I'd suggest that we remove the OS check code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4694) Upgrade to Derby 10.5.3.0
[ https://issues.apache.org/jira/browse/GERONIMO-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4694: --- Assignee: Jack Cai Summary: Upgrade to Derby 10.5.3.0 (was: Upgrade to Derby 10.5.1.1) Upgrade to 10.5.3.0 instead. Upgrade to Derby 10.5.3.0 - Key: GERONIMO-4694 URL: https://issues.apache.org/jira/browse/GERONIMO-4694 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.2 Reporter: Jack Cai Assignee: Jack Cai Fix For: Wish List Derby has released a new version 10.5.1.1 last month. Let's upgrade to this version for 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5040) PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804545#action_12804545 ] Jack Cai commented on GERONIMO-5040: If I rememer correctly, the reason that I didn't use the java mode is because there is a defect in Apache Commons Daemon to detect the java.exe location in some cases. See https://issues.apache.org/jira/browse/DAEMON-112. So to minimize the code difference between the geronimo version and the commons version, I falled back to use the exe mode, which should work. You can add the parameters to set the permgenspace if you want. For the missing timeout setting, I didn't find that geronimo is killed before it stops gracefully. Maybe there are two few apps on my server. Anyway, we are expecting that Apache Commons Daemon would do a new release which shall include all the pending patches. So hopefully after that we can update the batch file to use the Java mode. PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows --- Key: GERONIMO-5040 URL: https://issues.apache.org/jira/browse/GERONIMO-5040 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.4, 2.2 Reporter: Johannes Weberhofer Attachments: GERONIMO-5040-service_pr.bat.diff Geronimo should - in my optinion - be started in Java-Mode. In Java (and the currently used exe-Mode) it is necessary to add all important options directly into the startup-arguments fields before the -jar line, which should be noticed in the Wiki. The issue is related to DAEMON-119. At the shutdown page, it is necessary to explicitly select the Java-Mode and set a timeout (30 seconds or so); otherwise the geronimo server will simply be killed without any chance to terminate gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-5032) Procrun issue: windows service is stoped when user log off console session
[ https://issues.apache.org/jira/browse/GERONIMO-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-5032. Resolution: Fixed Fix Version/s: 3.0 2.2.1 2.1.5 Committed to 2.1 at 899553, to 2.2 at 899555, to 3.0 at 899556. Thanks Forrest! Procrun issue: windows service is stoped when user log off console session -- Key: GERONIMO-5032 URL: https://issues.apache.org/jira/browse/GERONIMO-5032 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: JVM-compatibility Affects Versions: 2.2 Environment: sun jdk windows OS Reporter: Forrest Xia Assignee: Forrest Xia Priority: Minor Fix For: 2.1.5, 2.2.1, 3.0 Attachments: GERONIMO-5032.patch When using sun jdk to start geronimosrv service, if user log off, the service will stop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4968) Problemastic OS check in Windows startup command
[ https://issues.apache.org/jira/browse/GERONIMO-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-4968. Resolution: Fixed Fix Version/s: (was: 2.2) 2.2.1 2.1.5 Assignee: Jack Cai Committed the patch to 2.1 at Rev 899562, to 2.2 at Rev 899564, to trunk at Rev 899565 Problemastic OS check in Windows startup command Key: GERONIMO-4968 URL: https://issues.apache.org/jira/browse/GERONIMO-4968 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5, 2.2.1, 3.0 Attachments: GERONIMO-4968.2.1.patch, GERONIMO-4968.2.2.patch, GERONIMO-4968.trunk.patch A user reported that the startup command failed due to OS check failue, even though he is running Windows XP - which is a supported OS. The problem is that the startup command does an exact match of the OS env var against Windows_NT, while in this user's case, the OS env var is WINNT 5.1. Maven has a similar problem: http://jira.codehaus.org/browse/MNG-3354 I'd suggest that we remove the OS check code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4968) Problemastic OS check in Windows startup command
[ https://issues.apache.org/jira/browse/GERONIMO-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4968. -- Problemastic OS check in Windows startup command Key: GERONIMO-4968 URL: https://issues.apache.org/jira/browse/GERONIMO-4968 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jack Cai Assignee: Jack Cai Priority: Trivial Fix For: 2.1.5, 2.2.1, 3.0 Attachments: GERONIMO-4968.2.1.patch, GERONIMO-4968.2.2.patch, GERONIMO-4968.trunk.patch A user reported that the startup command failed due to OS check failue, even though he is running Windows XP - which is a supported OS. The problem is that the startup command does an exact match of the OS env var against Windows_NT, while in this user's case, the OS env var is WINNT 5.1. Maven has a similar problem: http://jira.codehaus.org/browse/MNG-3354 I'd suggest that we remove the OS check code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796974#action_12796974
]
Jack Cai commented on GERONIMO-3003:
Commited the encrypt command patch to 2.1 branch at Rev 896103 and 2.2 branch
at Rev 896316.
TODO:
1. Trunk update
2. GShell equivalent
3. Doc update
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.cmd.21.patch,
GERONIMO-3003.cmd.22.patch, GERONIMO-3003.patch, GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
---
Attachment: GERONIMO-3003.cmd.22.patch
GERONIMO-3003.cmd.21.patch
Attaching the patch to add a command to the deploy commandline to do an
encryption. Typical usage:
Use a running server to do the encryption so that the encryption setting of
that server will be used:
deploy(.sh|.bat) -h localhost -p 1099 encrypt sometext
Use the common simple encrption so that no running server is required
deploy(.sh|.bat) -o encrypt sometext
Tested with 2.2 branch.
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.cmd.21.patch,
GERONIMO-3003.cmd.22.patch, GERONIMO-3003.patch, GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
---
Attachment: (was: GERONIMO-3003.cmd.21.patch)
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.patch,
GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
---
Attachment: (was: GERONIMO-3003.cmd.22.patch)
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.patch,
GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
---
Attachment: GERONIMO-3003.cmd.22.patch
GERONIMO-3003.cmd.21.patch
Add a bit error check code and tested with 2.1 branch.
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.cmd.21.patch,
GERONIMO-3003.cmd.22.patch, GERONIMO-3003.patch, GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4987) Use ConcurrentHashMap instead of Collections.synchronizedMap(new HashMap())
Use ConcurrentHashMap instead of Collections.synchronizedMap(new HashMap()) --- Key: GERONIMO-4987 URL: https://issues.apache.org/jira/browse/GERONIMO-4987 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 2.1.4 Reporter: Jack Cai Priority: Trivial Fix For: 3.0 It might be better to use ConcurrentHashmap in below files. ./plugins/console/console-filter/src/main/java/org/apache/geronimo/console/filter/XSRFHandler.java: private MapString, String sessionMap = Collections.synchronizedMap(new HashMapString, String()); ./framework/modules/geronimo-crypto/src/main/java/org/apache/geronimo/crypto/EncryptionManager.java: private static final MapString, Encryption ENCRYPTORS = Collections.synchronizedMap(new HashMapString, Encryption()); ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java: asyncKeys = Collections.synchronizedMap(new HashMapObject, DownloadResults()); ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java: asyncKeys = Collections.synchronizedMap(new HashMapObject, DownloadResults()); ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java: asyncKeys = Collections.synchronizedMap(new HashMapObject, DownloadResults()); ./framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/Authenticator.java: private MapString, LoginContext contextMap = Collections.synchronizedMap(new HashMapString, LoginContext()); ./framework/modules/geronimo-security/src/main/java/org/apache/geronimo/security/ContextManager.java: private static MapSubjectId, Subject subjectIds = Collections.synchronizedMap(new HashMapSubjectId, Subject()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4987) Use ConcurrentHashMap instead of Collections.synchronizedMap(new HashMap())
[ https://issues.apache.org/jira/browse/GERONIMO-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4987: --- Attachment: GERONIMO-4987_trunk.patch A simple and safe fix. Use ConcurrentHashMap instead of Collections.synchronizedMap(new HashMap()) --- Key: GERONIMO-4987 URL: https://issues.apache.org/jira/browse/GERONIMO-4987 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1.4 Reporter: Jack Cai Priority: Trivial Fix For: 3.0 Attachments: GERONIMO-4987_trunk.patch It might be better to use ConcurrentHashmap in below files. ./plugins/console/console-filter/src/main/java/org/apache/geronimo/console/filter/XSRFHandler.java: private MapString, String sessionMap = Collections.synchronizedMap(new HashMapString, String()); ./framework/modules/geronimo-crypto/src/main/java/org/apache/geronimo/crypto/EncryptionManager.java: private static final MapString, Encryption ENCRYPTORS = Collections.synchronizedMap(new HashMapString, Encryption()); ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java: asyncKeys = Collections.synchronizedMap(new HashMapObject, DownloadResults()); ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java: asyncKeys = Collections.synchronizedMap(new HashMapObject, DownloadResults()); ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java: asyncKeys = Collections.synchronizedMap(new HashMapObject, DownloadResults()); ./framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/Authenticator.java: private MapString, LoginContext contextMap = Collections.synchronizedMap(new HashMapString, LoginContext()); ./framework/modules/geronimo-security/src/main/java/org/apache/geronimo/security/ContextManager.java: private static MapSubjectId, Subject subjectIds = Collections.synchronizedMap(new HashMapSubjectId, Subject()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4296) Start Derby NetworkServerControl with credentials to prevent unauthorized shutdowns
[ https://issues.apache.org/jira/browse/GERONIMO-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790060#action_12790060 ] Jack Cai commented on GERONIMO-4296: I think it makes sense to use the geronimo-admin realm, as the embedded Derby is not for production use of other purpose. Start Derby NetworkServerControl with credentials to prevent unauthorized shutdowns --- Key: GERONIMO-4296 URL: https://issues.apache.org/jira/browse/GERONIMO-4296 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.0.3, 2.1.3, 2.1.4, 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: Wish List Use the new NetworkServerControl support in Derby 10.4.1.3 and later to start our embedded Derby server with credentials, to prevent any other apps on localhost from stopping our Derby instance. The following Derby release note details the scenario and the new API - http://db.apache.org/derby/releases/release-10.4.1.3.html#Note+for+DERBY-3585 We could either use random uid/pwd values to start the Derby server, which would be the most secure, but would keep other apps from using our Derby server. The other option, would be to set uid/pwd GBean attributes and default the to the default system/manager values and leave it up to the user to change them. Note: This may also require some Samples, Testsuite and Portlet chagnes to handle the required DB auth. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790178#action_12790178
]
Jack Cai commented on GERONIMO-3003:
I believe Requirement (1) is already done in the previous patch. The TODO is to
provide a utility to generate encrypted strings. A simple way to do this is to
let the user optionally specify a key file and then generate the string, or use
the default key if no key file is provided. A more robust way is to call the
running server to do the encryption, e.g., extend the
org.apache.geronimo.system.util.ConfiguredEncryption GBean to provide such
operation. I'd prefer the latter solution. If no objection, I'll create a patch.
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.patch,
GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4968) Problemastic OS check in Windows startup command
[ https://issues.apache.org/jira/browse/GERONIMO-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4968: --- Attachment: GERONIMO-4968.trunk.patch GERONIMO-4968.2.2.patch GERONIMO-4968.2.1.patch Removing the OS check from the Windows commands. Please review. Thanks! Problemastic OS check in Windows startup command Key: GERONIMO-4968 URL: https://issues.apache.org/jira/browse/GERONIMO-4968 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jack Cai Priority: Trivial Fix For: 2.2, 3.0 Attachments: GERONIMO-4968.2.1.patch, GERONIMO-4968.2.2.patch, GERONIMO-4968.trunk.patch A user reported that the startup command failed due to OS check failue, even though he is running Windows XP - which is a supported OS. The problem is that the startup command does an exact match of the OS env var against Windows_NT, while in this user's case, the OS env var is WINNT 5.1. Maven has a similar problem: http://jira.codehaus.org/browse/MNG-3354 I'd suggest that we remove the OS check code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790012#action_12790012
]
Jack Cai commented on GERONIMO-3003:
In addition to what is already done for this requirement, guess the original
requirement raised in this JIRA is not resolved. However, instead of doing what
is proposed originally (rewrite the deployment plan to encrypt the password),
another way to achieve the security goal is to -
1) accept encrypted passwords in deployment plan, and
2) provide an encrypt utility so users could generate encrypted strings that
could then be pasted into the deployment plan
Comments?
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.patch,
GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4968) Problemastic OS check in Windows startup command
Problemastic OS check in Windows startup command Key: GERONIMO-4968 URL: https://issues.apache.org/jira/browse/GERONIMO-4968 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jack Cai Priority: Trivial Fix For: 2.2, 3.0 A user reported that the startup command failed due to OS check failue, even though he is running Windows XP - which is a supported OS. The problem is that the startup command does an exact match of the OS env var against Windows_NT, while in this user's case, the OS env var is WINNT 5.1. Maven has a similar problem: http://jira.codehaus.org/browse/MNG-3354 I'd suggest that we remove the OS check code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4694) Upgrade to Derby 10.5.1.1
[ https://issues.apache.org/jira/browse/GERONIMO-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12780472#action_12780472 ] Jack Cai commented on GERONIMO-4694: Derby 10.5 is on maven repo now: http://repo1.maven.org/maven2/org/apache/derby/derby/10.5.3.0_1/ Let's upgrade? Upgrade to Derby 10.5.1.1 - Key: GERONIMO-4694 URL: https://issues.apache.org/jira/browse/GERONIMO-4694 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.2 Reporter: Jack Cai Fix For: Wish List Derby has released a new version 10.5.1.1 last month. Let's upgrade to this version for 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4874) Improve the console filter performance
[ https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758572#action_12758572 ] Jack Cai commented on GERONIMO-4874: Thanks Ivan! And we can now remove the below two files: plugins/console/console-filter/src/main/java/org/apache/geronimo/console/filter/FilterResponseWrapper.java plugins/console/console-filter/src/main/java/org/apache/geronimo/console/filter/ResponseOutputStream.java Improve the console filter performance -- Key: GERONIMO-4874 URL: https://issues.apache.org/jira/browse/GERONIMO-4874 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: All Reporter: Jack Cai Priority: Minor Fix For: 2.1.5, 2.2, 3.0 Attachments: GERONIMO-4874.patch, GERONIMO-4874_0918.patch Current console filter for blocking XSRF attack does not scale well as it need to read all the output into a string and then do some text replacement. This will use a lot of memory in extreme cases. See the discussion [1]. [1] http://www.nabble.com/XSRFHandler-question-td24545409s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4222: --- Attachment: tranql-connector-mysql-local-1.3-SNAPSHOT.rar vendors.patch connector.patch I've completed the patch that will leverage the PooledConnection interface, so pasting it here for initial review. The connector.patch is for the tranql-connector trunk, and the vendors.patch contains updates to the mysql, derby and pg connectors (for convenience, I created the patch from the vendor root.) I'm uploading the built RAR packages so hopefully somebody can help to test the new connectors. To test them with an existing Geronimo build, need to rename the RAR package to match the version used in that Geronimo build. Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Jack Cai Fix For: Wish List Attachments: before and after wasce restart.txt, connector.patch, PGtrial.patch, stacktrace.txt, tranql-connector-mysql-local-1.3-SNAPSHOT.rar, tranql-connector-postgresql-common-1.1.jar, vendors.patch I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4222: --- Attachment: tranql-connector-postgresql-xa-1.2-SNAPSHOT.rar tranql-connector-postgresql-local-1.2-SNAPSHOT.rar tranql-connector-mysql-xa-1.3-SNAPSHOT.rar Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Jack Cai Fix For: Wish List Attachments: before and after wasce restart.txt, connector.patch, PGtrial.patch, stacktrace.txt, tranql-connector-mysql-local-1.3-SNAPSHOT.rar, tranql-connector-mysql-xa-1.3-SNAPSHOT.rar, tranql-connector-postgresql-common-1.1.jar, tranql-connector-postgresql-local-1.2-SNAPSHOT.rar, tranql-connector-postgresql-xa-1.2-SNAPSHOT.rar, vendors.patch I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4222: --- Attachment: tranql-connector-derby-embed-local-1.5-SNAPSHOT.rar tranql-connector-derby-embed-xa-1.5-SNAPSHOT.rar Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Jack Cai Fix For: Wish List Attachments: before and after wasce restart.txt, connector.patch, PGtrial.patch, stacktrace.txt, tranql-connector-derby-embed-local-1.5-SNAPSHOT.rar, tranql-connector-derby-embed-xa-1.5-SNAPSHOT.rar, tranql-connector-mysql-local-1.3-SNAPSHOT.rar, tranql-connector-mysql-xa-1.3-SNAPSHOT.rar, tranql-connector-postgresql-common-1.1.jar, tranql-connector-postgresql-local-1.2-SNAPSHOT.rar, tranql-connector-postgresql-xa-1.2-SNAPSHOT.rar, vendors.patch I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4833) javax.resource.ResourseException in too many graphs in one view after disable server
[ https://issues.apache.org/jira/browse/GERONIMO-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757865#action_12757865 ] Jack Cai commented on GERONIMO-4833: There are quite a few problems in the monitoring code in branch 2.1. Fortunately David has heavily refactored the code for 2.2. For now, I will be creating a fix just for this problem for 2.1. javax.resource.ResourseException in too many graphs in one view after disable server Key: GERONIMO-4833 URL: https://issues.apache.org/jira/browse/GERONIMO-4833 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.4 Environment: Windows XP sp2 Sun jdk 1.5 Reporter: Vanessa Wang 1 add a jmx server 2 add a view with more than 15 graphs 3 disable the jmx server 4 click the new view you just added error occur: SQL state: null SQL error: 0 java.sql.SQLException at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:6) at org.apache.geronimo.monitoring.console.util.DBManager.createConnectin(DBManager.java:53) at org.apache.geronimo.monitoring.console.util.DBManager.init(DBManagr.java:39) at org.apache.geronimo.monitoring.console.GraphsBuilder.buildOneDB(GrapsBuilder.java:48) at jsp.WEB_002dINF.view.monitoringPage_jsp._jspService(monitoringPage_jp.java:139) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(AppicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Applicationispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDipatcher.java:488) at org.apache.pluto.internal.impl.PortletRequestDispatcherImpl.include(ortletRequestDispatcherImpl.java:106) at org.apache.geronimo.monitoring.console.MonitoringPortlet.doView(MonioringPortlet.java:313) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.geronimo.console.BasePortlet.render(BasePortlet.java:141) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:20) 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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(AppicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Applicationispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDipatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPorletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPorletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainermpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:12) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dkin_jsp.java:102) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(AppicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Applicationispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDipatcher.java:488) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrar.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEac_005f0(default_002dtheme_jsp.java:238) at
[jira] Assigned: (GERONIMO-4833) javax.resource.ResourseException in too many graphs in one view after disable server
[ https://issues.apache.org/jira/browse/GERONIMO-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai reassigned GERONIMO-4833: -- Assignee: Jack Cai javax.resource.ResourseException in too many graphs in one view after disable server Key: GERONIMO-4833 URL: https://issues.apache.org/jira/browse/GERONIMO-4833 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.4 Environment: Windows XP sp2 Sun jdk 1.5 Reporter: Vanessa Wang Assignee: Jack Cai 1 add a jmx server 2 add a view with more than 15 graphs 3 disable the jmx server 4 click the new view you just added error occur: SQL state: null SQL error: 0 java.sql.SQLException at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:6) at org.apache.geronimo.monitoring.console.util.DBManager.createConnectin(DBManager.java:53) at org.apache.geronimo.monitoring.console.util.DBManager.init(DBManagr.java:39) at org.apache.geronimo.monitoring.console.GraphsBuilder.buildOneDB(GrapsBuilder.java:48) at jsp.WEB_002dINF.view.monitoringPage_jsp._jspService(monitoringPage_jp.java:139) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(AppicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Applicationispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDipatcher.java:488) at org.apache.pluto.internal.impl.PortletRequestDispatcherImpl.include(ortletRequestDispatcherImpl.java:106) at org.apache.geronimo.monitoring.console.MonitoringPortlet.doView(MonioringPortlet.java:313) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.geronimo.console.BasePortlet.render(BasePortlet.java:141) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:20) 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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(AppicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Applicationispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDipatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPorletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPorletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainermpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:12) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dkin_jsp.java:102) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(AppicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(Applicationispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDipatcher.java:488) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrar.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEac_005f0(default_002dtheme_jsp.java:238) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002theme_jsp.java:124) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at
[jira] Commented: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758103#action_12758103 ] Jack Cai commented on GERONIMO-4222: Thanks Forrest for trying out the patch! Guess the problem is because you still have some tranql-connector-1.4.jar in your repo which get loaded by the server (each vendor RAR contains a copy of this jar). Once we replace all the 1.4 jars with the updated jars, the problem shall go away. Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Jack Cai Fix For: Wish List Attachments: before and after wasce restart.txt, connector.patch, PGtrial.patch, stacktrace.txt, tranql-connector-derby-embed-local-1.5-SNAPSHOT.rar, tranql-connector-derby-embed-xa-1.5-SNAPSHOT.rar, tranql-connector-mysql-local-1.3-SNAPSHOT.rar, tranql-connector-mysql-xa-1.3-SNAPSHOT.rar, tranql-connector-postgresql-common-1.1.jar, tranql-connector-postgresql-local-1.2-SNAPSHOT.rar, tranql-connector-postgresql-xa-1.2-SNAPSHOT.rar, vendors.patch I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4874) Improve the console filter performance
[ https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757719#action_12757719 ] Jack Cai commented on GERONIMO-4874: Thanks for the comments! Currently there are two types of broken that need to be taken care of: 1. If the outputstream is used when writting out the page, need to take care of the case where the bytes of one charactor is written in multiple batches 2. Need to take care of the case where the keyword (i.e. lt;/bodygt;) is written in multiple batches, just as Jarek described Both cases are currently handled using NIO buffers. For 1, I will decode as much bytes as possible into characters and buffer the incomplete bytes for the next decoding/scanning operation. See the code of SubstituteResponseOutputStream.decodeBuffer(). For 2, I will push back the last 6 characters back to the buffer for the next scanning operation. See the code of SubstituteUtil.processSubstitute(). Hope this explains. Improve the console filter performance -- Key: GERONIMO-4874 URL: https://issues.apache.org/jira/browse/GERONIMO-4874 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: All Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4874.patch, GERONIMO-4874_0918.patch Current console filter for blocking XSRF attack does not scale well as it need to read all the output into a string and then do some text replacement. This will use a lot of memory in extreme cases. See the discussion [1]. [1] http://www.nabble.com/XSRFHandler-question-td24545409s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai reassigned GERONIMO-4222: -- Assignee: Jack Cai Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Assignee: Jack Cai Fix For: Wish List Attachments: before and after wasce restart.txt, PGtrial.patch, stacktrace.txt, tranql-connector-postgresql-common-1.1.jar I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4874) Improve the console filter performance
[ https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4874: --- Attachment: GERONIMO-4874_0918.patch I did build 2.1 branch with the patch. Everything passed, including the console test suite. I made a minor correction to the patch. Please help to review this new one. Improve the console filter performance -- Key: GERONIMO-4874 URL: https://issues.apache.org/jira/browse/GERONIMO-4874 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: All Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4874.patch, GERONIMO-4874_0918.patch Current console filter for blocking XSRF attack does not scale well as it need to read all the output into a string and then do some text replacement. This will use a lot of memory in extreme cases. See the discussion [1]. [1] http://www.nabble.com/XSRFHandler-question-td24545409s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4222: --- Attachment: tranql-connector-postgresql-common-1.1.jar As David pointed out, there's no stardard way to tell that an SQLException is fatal. So it might be hard to make the generic adapter detect dead connection. I went out writing an exception sorter that will regard the following SQL states as fatal for Postgresql. The list of fatal errors can be configured through the property file packaged in the attached jar. Does anybody want to test it with Geronimo (simply replace this jar with the one in Geronimo repo)? CONNECTION_UNABLE_TO_CONNECT: 08001 CONNECTION_DOES_NOT_EXIST: 08003 CONNECTION_REJECTED: 08004 CONNECTION_FAILURE: 08006 CONNECTION_FAILURE_DURING_TRANSACTION: 08007 PROTOCOL_VIOLATION: 08P01 COMMUNICATION_ERROR: 08S01 SYSTEM_ERROR: 6 Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Fix For: Wish List Attachments: before and after wasce restart.txt, stacktrace.txt, tranql-connector-postgresql-common-1.1.jar I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4222: --- Attachment: PGtrial.patch Attaching a modified trial patch that hard code the fatal error codes. Even though this might fix the problem with Postgresql, it's far from the final solution. I realize that tranql does not take advantange of the PooledDatasource/PooledConnection implemenations that are available in most existing DBMS JDBC drivers. The PooledConnection can notify a listener when a fatal error occured and the connection should be discarded. I'd suggest that we improve tranql to use PooledDatasource, instead of relying on a customized ExceptionSorter that we have to write by ourselves for every DBMS. What do others think? Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.2, 2.1.3, 2.1.4 Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm Fix For: Wish List Attachments: before and after wasce restart.txt, PGtrial.patch, stacktrace.txt, tranql-connector-postgresql-common-1.1.jar I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4874) Improve the console filter performance
[ https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4874: --- Attachment: GERONIMO-4874.patch I use the nio buffers and charset decoders to do the text scan and replacement in a stream-style. The performance is improved in two aspects - 1. Less memory consumption. The output is written out as it comes in. No need to hold a big chunk of data in memory. 2. Less charset decoding/encoding overhead. The original filter will encode text into byte array and then decode again. The patch will scan text directly. I tested the new filter with the admin console by clicking through most of the pages. Everything looks good. The patch can be applied to branch 2.1, branch 2.2 and trunk. Improve the console filter performance -- Key: GERONIMO-4874 URL: https://issues.apache.org/jira/browse/GERONIMO-4874 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: All Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4874.patch Current console filter for blocking XSRF attack does not scale well as it need to read all the output into a string and then do some text replacement. This will use a lot of memory in extreme cases. See the discussion [1]. [1] http://www.nabble.com/XSRFHandler-question-td24545409s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4874) Improve the console filter performance
[ https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755301#action_12755301 ] Jack Cai commented on GERONIMO-4874: Forgot to mention, the below two files can be removed if the attached patch is applied. plugins/console/console-filter/src/main/java/org/apache/geronimo/console/filter/FilterResponseWrapper.java plugins/console/console-filter/src/main/java/org/apache/geronimo/console/filter/ResponseOutputStream.java Improve the console filter performance -- Key: GERONIMO-4874 URL: https://issues.apache.org/jira/browse/GERONIMO-4874 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Environment: All Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4874.patch Current console filter for blocking XSRF attack does not scale well as it need to read all the output into a string and then do some text replacement. This will use a lot of memory in extreme cases. See the discussion [1]. [1] http://www.nabble.com/XSRFHandler-question-td24545409s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4690) On Windows, offline deployer throws IllegalArgumentException when not attached to a console
[ https://issues.apache.org/jira/browse/GERONIMO-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4690: --- Attachment: GERONIMO-4690.patch Solution 1 looks simple and quick to do. Created a patch according to this. Fixing JLine would be the best solution ultimately. On Windows, offline deployer throws IllegalArgumentException when not attached to a console --- Key: GERONIMO-4690 URL: https://issues.apache.org/jira/browse/GERONIMO-4690 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1.4 Environment: Windows Reporter: Sean McNealy Attachments: GERONIMO-4690.patch On Windows, offline deployer throws IllegalArgumentException when not attached to a console. The underlying JLine implementation for Windows has a bug where it will return a width of one (1) when there is no console. By not attached to a console, I mean the output is piped to a program, piped to a file, or the process running the deployer is forked from the main process. The exception is thrown from within geronimo-deploy-tool\src\main\java\org\apache\geronimo\deployment\cli\DeployUtils.java Note that both reformat and println methods are effected by this problem. Solutions include: Expecting width=1 and doing the same thing as width=0 that works for *nix systems. Having DeployUtils methods just output strings that aren't reformatted when width 10. Fixing JLine. I've already files bug 2807391 with their sourceforge project. If that bug is resolved including a new JLine would resolve this bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4773) logger not initialized in shutdown command
[
https://issues.apache.org/jira/browse/GERONIMO-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747324#action_12747324
]
Jack Cai commented on GERONIMO-4773:
Can we also remove the folder:
framework/modules/geronimo-kernel/src/main/resources/META-INF/services?
logger not initialized in shutdown command
--
Key: GERONIMO-4773
URL: https://issues.apache.org/jira/browse/GERONIMO-4773
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Reporter: Jack Cai
Priority: Minor
Fix For: 2.2
Attachments: GERONIMO-4773.patch
When issue the shutdown command, the following warning messages will be shown
every time.
{quote}
log4j:WARN No appenders could be found for logger
(org.apache.geronimo.kernel.basic.BasicKernel).
log4j:WARN Please initialize the log4j system properly.
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4810) Predefine a localhost server with some predefined graphs and views
Predefine a localhost server with some predefined graphs and views Key: GERONIMO-4810 URL: https://issues.apache.org/jira/browse/GERONIMO-4810 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor It will be useful if we can predefine a localhost server. Some frequent-used graphs/views can also be prodefined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_21_0812.patch GERONIMO-4769_trunk_command_0812.patch GERONIMO-4769_trunk_0812.patch Update the patch to adapt to the latest code. Also write commands for renaming resources . Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Assignee: Ivan Priority: Minor Attachments: GERONIMO-4769_21.patch, GERONIMO-4769_21_0804.patch, GERONIMO-4769_21_0812.patch, GERONIMO-4769_21_command_0812.patch, GERONIMO-4769_trunk.patch, GERONIMO-4769_trunk_0804.patch, GERONIMO-4769_trunk_0812.patch, GERONIMO-4769_trunk_command_0812.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_21_command_0812.patch Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Assignee: Ivan Priority: Minor Attachments: GERONIMO-4769_21.patch, GERONIMO-4769_21_0804.patch, GERONIMO-4769_21_0812.patch, GERONIMO-4769_21_command_0812.patch, GERONIMO-4769_trunk.patch, GERONIMO-4769_trunk_0804.patch, GERONIMO-4769_trunk_0812.patch, GERONIMO-4769_trunk_command_0812.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.
[
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742272#action_12742272
]
Jack Cai commented on GERONIMO-4763:
I guess the jms-resource-providers.properties in console-base-portlets and
activemq-portlets should remain in the resources folder instead of moving to
i18n-resources.
i18n properties files should be converted to ascii at build time.
--
Key: GERONIMO-4763
URL: https://issues.apache.org/jira/browse/GERONIMO-4763
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: usability
Affects Versions: 2.1.5, 2.2
Reporter: Shawn Jiang
Assignee: Ivan
Priority: Minor
Fix For: 2.2
Attachments: G4763_fix_IBM_SDK.patch, G4763_mv_i18n_trunk.bat,
G4763_trunk.patch
Current i18n properties files are stored in source code repo after they are
converted to ascii from native offline. It's very hard to contribute new
translations.
We should keep native characters in source code while convert them to ascii
at build time. maven plugin native2ascii-maven-plugin could be used here:
{code}
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdnative2ascii-maven-plugin/artifactId
version1.0-alpha-1/version
configuration
desttarget/classes/dest
srcsrc/main/resources/src
/configuration
executions
execution
idnative2ascii-utf8/id
goals
goalnative2ascii/goal
/goals
configuration
encodingUTF8/encoding
includes
ConsoleResources_jp.properties,
ConsoleResources_zh*.properties
/includes
/configuration
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.
[
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741218#action_12741218
]
Jack Cai commented on GERONIMO-4763:
A profile can also be activated bt determing the OS. This might be useful to
deal with Mac OS.
i18n properties files should be converted to ascii at build time.
--
Key: GERONIMO-4763
URL: https://issues.apache.org/jira/browse/GERONIMO-4763
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: usability
Affects Versions: 2.1.5, 2.2
Reporter: Shawn Jiang
Assignee: Ivan
Priority: Minor
Fix For: 2.2
Attachments: G4763_fix_IBM_SDK.patch, G4763_mv_i18n_trunk.bat,
G4763_trunk.patch
Current i18n properties files are stored in source code repo after they are
converted to ascii from native offline. It's very hard to contribute new
translations.
We should keep native characters in source code while convert them to ascii
at build time. maven plugin native2ascii-maven-plugin could be used here:
{code}
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdnative2ascii-maven-plugin/artifactId
version1.0-alpha-1/version
configuration
desttarget/classes/dest
srcsrc/main/resources/src
/configuration
executions
execution
idnative2ascii-utf8/id
goals
goalnative2ascii/goal
/goals
configuration
encodingUTF8/encoding
includes
ConsoleResources_jp.properties,
ConsoleResources_zh*.properties
/includes
/configuration
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4608) java.io.EOFException when reading ejb response
[ https://issues.apache.org/jira/browse/GERONIMO-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4608: --- Priority: Critical (was: Major) Affects Version/s: 2.2 2.1.5 After extensive testing and debugging, I believe it's a problem in JDK. The OpenEJB server has written the result properly to the outputstream every time, but occasionally the client failed to retrieve the complete result. The underlying socket or object streams must be doing something wrong. The failure actually happens quite frequently. I assume it is a common problem for all remote EJB access. On my Windows box the failure usually happens once out of 20 times. So I regard it as a serious reliability problem. To work around this problem, we can add a BufferedInputStream around the SocketInputStream in the EJB client's code. I created a JIRA against OpenEJB (see https://issues.apache.org/jira/browse/OPENEJB-1058) and provide a patch there. The patch works well. I ran the monitoring function for 500 times and didn't encounter the problem again. java.io.EOFException when reading ejb response --- Key: GERONIMO-4608 URL: https://issues.apache.org/jira/browse/GERONIMO-4608 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.4, 2.1.5, 2.2 Environment: Windows Reporter: Jack Cai Priority: Critical In the monitoring admin console page, define a server, enable query and then view its statistics. Keep refreshing the server view page, and soon there will be a server is offline message. Initial debugging reveals when the jsp access the server-side agent ejb, there is a java.io.EOFException thrown during the reading of ejb response. An old mail discussion also mentioned this problem, see [1]. This problem only occurs on Windows system. [1] http://www.nabble.com/error-on-running-tests-on-windows-tt16618112.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4762) Databinding exception issue with Axis
[ https://issues.apache.org/jira/browse/GERONIMO-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739872#action_12739872 ] Jack Cai commented on GERONIMO-4762: Geronimo 2.1.4 and 2.1.5-SNAPSHOT both use a modified version of AXIS2, 1.3-G20090310 and 1.3-G20090406 respectively. I believe the patch you mentioned is not included in these versions. Databinding exception issue with Axis - Key: GERONIMO-4762 URL: https://issues.apache.org/jira/browse/GERONIMO-4762 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.1.4 Environment: Linux x64 Reporter: Robert Palmer I'm having an issue with Axis from the version of Geronimo I downloaded last night (on July 21, 2009): geronimo-tomcat6-javaee5-2.1.4. The bug relates to this exact description of the problem I'm having that was fixed in April of 2007: https://issues.apache.org/jira/browse/AXIS2-2313 It's caused by a web service accessing the soap header from a handler when two web services are active (i.e., a web service calls another web service). The exact exception thrown is: javax.xml.ws.WebServiceException: An internal error occurred. The org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl block object is already consumed. Processing cannot continue. Run with the debug option to determine where the block was first consumed. Does anyone know if this fix was included in the version of Geronimo that I downloaded? Thanks, Robert -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4773) logger not initialized in shutdown command
[
https://issues.apache.org/jira/browse/GERONIMO-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-4773:
---
Patch Info: [Patch Available]
logger not initialized in shutdown command
--
Key: GERONIMO-4773
URL: https://issues.apache.org/jira/browse/GERONIMO-4773
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Reporter: Jack Cai
Priority: Minor
Attachments: GERONIMO-4773.patch
When issue the shutdown command, the following warning messages will be shown
every time.
{quote}
log4j:WARN No appenders could be found for logger
(org.apache.geronimo.kernel.basic.BasicKernel).
log4j:WARN Please initialize the log4j system properly.
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_21_0804.patch So this is another try based on the previous suggestions from Ivan and Shawn. I use the maven ant plugin to do the copies. For convenience I rename the base bundles to *_en.properties. The patch works well for me. Please review. Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4769_21.patch, GERONIMO-4769_21_0804.patch, GERONIMO-4769_trunk.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_trunk_0804.patch Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4769_21.patch, GERONIMO-4769_21_0804.patch, GERONIMO-4769_trunk.patch, GERONIMO-4769_trunk_0804.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4773) logger not initialized in shutdown command
[
https://issues.apache.org/jira/browse/GERONIMO-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-4773:
---
Attachment: GERONIMO-4773.patch
Turns out the root cause is because we moved to slf4j in 2.2 and removed the
log classes in kernel.
To eliminate the annoying warning message, one solution is to simply add a
log4j.properties config file to shutdown.jar.
Also, no reason now to keep the file
framework/modules/geronimo-kernel/src/main/resources/META-INF/services/org.apache.commons.logging.LogFactory,
as it points to a class that does not exist any more.
Please review the patch. Built and tested.
logger not initialized in shutdown command
--
Key: GERONIMO-4773
URL: https://issues.apache.org/jira/browse/GERONIMO-4773
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Reporter: Jack Cai
Priority: Minor
Attachments: GERONIMO-4773.patch
When issue the shutdown command, the following warning messages will be shown
every time.
{quote}
log4j:WARN No appenders could be found for logger
(org.apache.geronimo.kernel.basic.BasicKernel).
log4j:WARN Please initialize the log4j system properly.
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.
[
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738231#action_12738231
]
Jack Cai commented on GERONIMO-4763:
AFAIK, there is no Harmony equivalent yet. A few JDK tools haven't been
implemented in Harmony yet.
i18n properties files should be converted to ascii at build time.
--
Key: GERONIMO-4763
URL: https://issues.apache.org/jira/browse/GERONIMO-4763
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: usability
Affects Versions: 2.1.5, 2.2
Reporter: Shawn Jiang
Assignee: Ivan
Priority: Minor
Attachments: G4763_mv_i18n_trunk.bat, G4763_trunk.patch
Current i18n properties files are stored in source code repo after they are
converted to ascii from native offline. It's very hard to contribute new
translations.
We should keep native characters in source code while convert them to ascii
at build time. maven plugin native2ascii-maven-plugin could be used here:
{code}
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdnative2ascii-maven-plugin/artifactId
version1.0-alpha-1/version
configuration
desttarget/classes/dest
srcsrc/main/resources/src
/configuration
executions
execution
idnative2ascii-utf8/id
goals
goalnative2ascii/goal
/goals
configuration
encodingUTF8/encoding
includes
ConsoleResources_jp.properties,
ConsoleResources_zh*.properties
/includes
/configuration
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4774) EJB Server portlet a little messed up in admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4774. -- EJB Server portlet a little messed up in admin console -- Key: GERONIMO-4774 URL: https://issues.apache.org/jira/browse/GERONIMO-4774 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Jack Cai Attachments: FireFox.jpg, IE.jpg The EJB Server portlet is a little messed up in FireFox. See snapshots. Also, after clicking a container and view its properties, there is no button to go back to the previous page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4774) EJB Server portlet a little messed up in admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-4774. Resolution: Duplicate OK. So it's a duplicate of https://issues.apache.org/jira/browse/GERONIMO-4746. Closing it. EJB Server portlet a little messed up in admin console -- Key: GERONIMO-4774 URL: https://issues.apache.org/jira/browse/GERONIMO-4774 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Jack Cai Attachments: FireFox.jpg, IE.jpg The EJB Server portlet is a little messed up in FireFox. See snapshots. Also, after clicking a container and view its properties, there is no button to go back to the previous page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4773) logger not initialized in shutdown command
logger not initialized in shutdown command
--
Key: GERONIMO-4773
URL: https://issues.apache.org/jira/browse/GERONIMO-4773
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2
Reporter: Jack Cai
Priority: Minor
When issue the shutdown command, the following warning messages will be shown
every time.
{quote}
log4j:WARN No appenders could be found for logger
(org.apache.geronimo.kernel.basic.BasicKernel).
log4j:WARN Please initialize the log4j system properly.
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4774) EJB Server portlet a little messed up in admin console
EJB Server portlet a little messed up in admin console -- Key: GERONIMO-4774 URL: https://issues.apache.org/jira/browse/GERONIMO-4774 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Reporter: Jack Cai The EJB Server portlet is a little messed up in FireFox. See snapshots. Also, after clicking a container and view its properties, there is no button to go back to the previous page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4774) EJB Server portlet a little messed up in admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4774: --- Attachment: FireFox.jpg EJB Server portlet a little messed up in admin console -- Key: GERONIMO-4774 URL: https://issues.apache.org/jira/browse/GERONIMO-4774 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Jack Cai Attachments: FireFox.jpg, IE.jpg The EJB Server portlet is a little messed up in FireFox. See snapshots. Also, after clicking a container and view its properties, there is no button to go back to the previous page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4774) EJB Server portlet a little messed up in admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4774: --- Attachment: IE.jpg EJB Server portlet a little messed up in admin console -- Key: GERONIMO-4774 URL: https://issues.apache.org/jira/browse/GERONIMO-4774 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Jack Cai Attachments: FireFox.jpg, IE.jpg The EJB Server portlet is a little messed up in FireFox. See snapshots. Also, after clicking a container and view its properties, there is no button to go back to the previous page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4775) Need to convert static English images into translatable text in Admin console
Need to convert static English images into translatable text in Admin console - Key: GERONIMO-4775 URL: https://issues.apache.org/jira/browse/GERONIMO-4775 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Currently there are a few images in admin console, which has English text in it. For example, the Log Out image in the upper-right corner. There are a few more, all in the plugins/console/console-portal-driver/src/main/webapp/images. If we want to make the admin console fully globalized, we need to eliminate these images and replace them with translatable text. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4716) Upgrade HTTPComponent HTTPCore to released version 4.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4716: --- Attachment: GERONIMO-4716_21.patch This is a stupid simple patch to upgrade the version of httpcomponents. I have run the build with the new version and everything looks good. Upgrade HTTPComponent HTTPCore to released version 4.0.1 Key: GERONIMO-4716 URL: https://issues.apache.org/jira/browse/GERONIMO-4716 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4716_21.patch We using 4.0 alpha or beta versions of HTTPComponent's HTTPCore in 2.1 and 2.2 code. Might want to upgrade the latest release version which 4.0.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4716) Upgrade HTTPComponent HTTPCore to released version 4.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4716: --- Attachment: GERONIMO-4716_trunk.patch This one for the trunk. Builds well. Upgrade HTTPComponent HTTPCore to released version 4.0.1 Key: GERONIMO-4716 URL: https://issues.apache.org/jira/browse/GERONIMO-4716 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4716_21.patch, GERONIMO-4716_trunk.patch We using 4.0 alpha or beta versions of HTTPComponent's HTTPCore in 2.1 and 2.2 code. Might want to upgrade the latest release version which 4.0.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4769) Add English resource bundle for Admin console
Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_21.patch Simply duplicate the base bundles with the _en extension. Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4769_21.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_trunk.patch For trunk. Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4769_21.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: (was: GERONIMO-4769_trunk.patch) Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4769_21.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4769) Add English resource bundle for Admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4769: --- Attachment: GERONIMO-4769_trunk.patch Add English resource bundle for Admin console - Key: GERONIMO-4769 URL: https://issues.apache.org/jira/browse/GERONIMO-4769 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Reporter: Jack Cai Priority: Minor Attachments: GERONIMO-4769_21.patch, GERONIMO-4769_trunk.patch The resource bundle search logic will consider default locale before falling back to the base resource bundle. This means if Geronimo is running on a Chinese OS with locale zh_CN, when a user visits the admin console with en_US as the browser locale, the user will actually see the admin console in Chinese! To avoid this problem, we shall duplicate the base resource bundles with the name *en.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12736523#action_12736523
]
Jack Cai commented on GERONIMO-3003:
David, looks like you forgot to commit EncryptionSetting.java.
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.patch,
GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.
[
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12736570#action_12736570
]
Jack Cai commented on GERONIMO-4763:
I think it is sun.tools.native2ascii.*. Most JDKs should contain these
classes in their tools.jar.
i18n properties files should be converted to ascii at build time.
--
Key: GERONIMO-4763
URL: https://issues.apache.org/jira/browse/GERONIMO-4763
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: usability
Affects Versions: 2.1.5, 2.2
Reporter: Shawn Jiang
Assignee: Ivan
Priority: Minor
Attachments: G4763_mv_i18n_trunk.bat, G4763_trunk.patch
Current i18n properties files are stored in source code repo after they are
converted to ascii from native offline. It's very hard to contribute new
translations.
We should keep native characters in source code while convert them to ascii
at build time. maven plugin native2ascii-maven-plugin could be used here:
{code}
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdnative2ascii-maven-plugin/artifactId
version1.0-alpha-1/version
configuration
desttarget/classes/dest
srcsrc/main/resources/src
/configuration
executions
execution
idnative2ascii-utf8/id
goals
goalnative2ascii/goal
/goals
configuration
encodingUTF8/encoding
includes
ConsoleResources_jp.properties,
ConsoleResources_zh*.properties
/includes
/configuration
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12736422#action_12736422
]
Jack Cai commented on GERONIMO-3003:
Thanks Ivan, Kevan and David!
I think it makes good sense to simply store encrypted values in GBeanOverride.
I reviewed David's revised patch and suggest to add the below lines to the
patch so that GBeanOverride.applyOverride() will encrypt attribute values which
are not encrypted in config.xml but should be encrypted. This is to handle
scenarios in which users change a password in config.xml and want it get
encrypted when the server writes back to config.xml.
{code}
@@ -357,6 +402,19 @@
}
String valueString = entry.getValue();
Object value = getValue(attributeInfo, valueString, configName,
gbeanName, classLoader);
+/*
+ * Make sure encrypted attributes are encrypted even if they are in
+ * plain text originally.
+ */
+if (valueString != null
+ attributeInfo.getEncryptedSetting() ==
EncryptionSetting.ENCRYPTED) {
+String decryptedValue = (String) attributeInfo
+.getEncryptedSetting().decrypt(valueString);
+if (valueString.equals(decryptedValue)) {
+entry.setValue(attributeInfo.getEncryptedSetting().encrypt(
+valueString));
+}
+}
data.setAttribute(attributeName, value);
}
{code}
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003-2.2-2.patch, GERONIMO-3003.patch,
GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4758) The Server Console page displays messy codes when set zh as the prefered language in browser
[ https://issues.apache.org/jira/browse/GERONIMO-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12735943#action_12735943 ] Jack Cai commented on GERONIMO-4758: I'd suggest to use UTF-8 as it is smaller in size and is more popular. There are other places where UTF-8 is used, e.g., in XSSXSRFFilter. Also suggest to handle the exception nicely. The Server Console page displays messy codes when set zh as the prefered language in browser Key: GERONIMO-4758 URL: https://issues.apache.org/jira/browse/GERONIMO-4758 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.4, 2.2 Environment: Windows XP + IE6 / Chrome Reporter: Siqi Du Fix For: 2.2 Attachments: console-filter-branch-2.1.patch, console-filter-trunk.patch, screenshot-1.jpg 1, Set zh_cn the 1st place in the language preference list ( from Internet Options of Control Panel) 2, The login page works well and give out the right view. 3, After login, on the console page all the Chinese character is replaced with a ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4761) MBean not found exception: agent-car-jmx
[
https://issues.apache.org/jira/browse/GERONIMO-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734922#action_12734922
]
Jack Cai commented on GERONIMO-4761:
The JMX agent is not installed by default. Please install it first. See:
http://cwiki.apache.org/GMOxDOC22/monitoring-components-on-geronimo-server.html
MBean not found exception: agent-car-jmx
-
Key: GERONIMO-4761
URL: https://issues.apache.org/jira/browse/GERONIMO-4761
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.2
Environment: From console
Reporter: Chi Runhua
1. Log in to console and go to *Monitoring* portlet,
2. Click *Add a new server* and choose protocol as JMX
3. Fill in other fields as requested, then click *Add*
Exception thrown from command line:
{code}
java.lang.Exception: [ERROR] Required mbean not found: agent-car-jmx
at
org.apache.geronimo.monitoring.console.MRCConnector.init(MRCConnector.java:123)
at
org.apache.geronimo.monitoring.console.MRCConnector.init(MRCConnector.java:55)
at
jsp.WEB_002dINF.view.monitoringNormal_jsp._jspService(monitoringNormal_jsp.java:271)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at
org.apache.pluto.internal.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:106)
at
org.apache.geronimo.monitoring.console.MonitoringPortlet.normalView(MonitoringPortlet.java:455)
at
org.apache.geronimo.monitoring.console.MonitoringPortlet.doEdit(MonitoringPortlet.java:412)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:253)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at org.apache.geronimo.console.BasePortlet.render(BasePortlet.java:153)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at
org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
at
org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)
at
org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172)
at
org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152)
at
jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:102)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968)
at
jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:215)
at
jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:120)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at
[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
---
Attachment: GERONIMO-3003.patch
Creating a patch for the trunk. If it is accepted well, I'll create a patch for
2.1 branch too.
The current design is -
1. Developers can specify a String type attribute of a GBean as encrypted,
either through API or annotation. Encrypted attributes are encrypted when
marshalled, e.g., serialized to config.ser. It will also get encrypted when
saved into the server's config.xml.
2. By default, GBean attributes are not encrypted except those whose name
contains the string password (ignore case) and whose type is java.lang.String.
Since the patch is pretty big and affects quite a few files, please help to
review and commit it soon. I hope it will make into G2.2 release. Thanks!
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Assignee: Jack Cai
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
---
Attachment: GERONIMO-3003_21.patch
Created a patch for 2.1 branch.
I did both a few unit testing and manual testing, for both 2.2 and 2.1. All
looks good.
Please help to review and commit. Thanks!
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Assignee: Jack Cai
Priority: Minor
Fix For: Wish List
Attachments: GERONIMO-3003.patch, GERONIMO-3003_21.patch
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4755) Warning message when starting the server due to Tomcat class not found
Warning message when starting the server due to Tomcat class not found -- Key: GERONIMO-4755 URL: https://issues.apache.org/jira/browse/GERONIMO-4755 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.2 Reporter: Jack Cai Priority: Minor When starting the 2.2 server (tomcat assembly), the below warning message will always appear during the starting of the juddi server. WARN [NamingContextListener] Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory] Initial investigation shows that Tomcat uses the class org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory as the default datasource factory class, see org.apache.naming.factory.ResourceFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4755) Warning message when starting the server due to Tomcat class not found
[ https://issues.apache.org/jira/browse/GERONIMO-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-4755. Resolution: Duplicate Duplicate with GERONIMO-4713 Warning message when starting the server due to Tomcat class not found -- Key: GERONIMO-4755 URL: https://issues.apache.org/jira/browse/GERONIMO-4755 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.2 Reporter: Jack Cai Priority: Minor When starting the 2.2 server (tomcat assembly), the below warning message will always appear during the starting of the juddi server. WARN [NamingContextListener] Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory] Initial investigation shows that Tomcat uses the class org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory as the default datasource factory class, see org.apache.naming.factory.ResourceFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4754) Unnecessary attributes retrieval causes slow login in LDAPLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4754: --- Attachment: GERONIMO-4754.patch Attaching a patch. Unnecessary attributes retrieval causes slow login in LDAPLoginModule - Key: GERONIMO-4754 URL: https://issues.apache.org/jira/browse/GERONIMO-4754 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Jack Cai Fix For: 2.1.5, 2.2 Attachments: GERONIMO-4754.patch LDAP login is slow due to unnecessary attributes retrieval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4754) Unnecessary attributes retrieval causes slow login in LDAPLoginModule
Unnecessary attributes retrieval causes slow login in LDAPLoginModule - Key: GERONIMO-4754 URL: https://issues.apache.org/jira/browse/GERONIMO-4754 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Jack Cai Fix For: 2.1.5, 2.2 Attachments: GERONIMO-4754.patch LDAP login is slow due to unnecessary attributes retrieval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4694) Upgrade to Derby 10.5.1.1
Upgrade to Derby 10.5.1.1 - Key: GERONIMO-4694 URL: https://issues.apache.org/jira/browse/GERONIMO-4694 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: databases Affects Versions: 2.2 Reporter: Jack Cai Fix For: 2.2 Derby has released a new version 10.5.1.1 last month. Let's upgrade to this version for 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4650) changes not persisted to security realms
[ https://issues.apache.org/jira/browse/GERONIMO-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai resolved GERONIMO-4650. Resolution: Duplicate As Viola pointed out, it's a duplicate of https://issues.apache.org/jira/browse/GERONIMO-4635. So closing it. changes not persisted to security realms Key: GERONIMO-4650 URL: https://issues.apache.org/jira/browse/GERONIMO-4650 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.1.4 Environment: Windows XP, JRE 1.5.0_06 Reporter: Bobby Lawrence After creating an LDAP security realm and editing the options and/or login module class name, a subsequent restart of the server loses all changes made. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4634) PlanCreator does not work for some applications like Open BlueDragon
PlanCreator does not work for some applications like Open BlueDragon Key: GERONIMO-4634 URL: https://issues.apache.org/jira/browse/GERONIMO-4634 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.4, 2.1.5, 2.2 Reporter: Jack Cai Some applications can be deployed with the deploy command, but the plancreator is not generating correct deployment plans. Open BlueGragon is one example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3003) Encrypt password strings in deployment plans
[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai reassigned GERONIMO-3003:
--
Assignee: Jack Cai
Encrypt password strings in deployment plans
Key: GERONIMO-3003
URL: https://issues.apache.org/jira/browse/GERONIMO-3003
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: Wish List
Reporter: Aman Nanner
Assignee: Jack Cai
Priority: Minor
Fix For: Wish List
Geronimo currently has a feature where password strings in the config.xml get
encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
encryption is performed in the
{{org.apache.geronimo.system.configuration.GBeanOverride}} class.
It would be desirable to have the same encryption applied to the password
strings in deployment plans (e.g. datasource or JMS deployment plans within
an EAR). Even though the plans are only used during the deployment process,
and not at runtime, the plans are left with plaintext password strings
sitting in them. It would be nice if the deployment process could internally
encrypt the strings and then write back out the deployment plan to the file
system. Also, this means that the deployment process will require the
ability to decrypt strings that are already in encrypted format in the plan
(in the case of redeployment, for example).
More discussion of this feature can be found in the following mailing list
thread:
http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
I would suggest that an appropriate spot to perform the encryption is in the
{{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
the following code just before the file is written to a temporary file:
if (gerModule.isSetAltDd()) {
// the the url of the alt dd
try {
altVendorDDs.put(path,
DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
} catch (IOException e) {
throw new DeploymentException(Invalid alt vendor
dd url: + gerModule.getAltDd().getStringValue(), e);
}
However, somebody more familiar with the design might be able to suggest a
better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-122) Object cannot be removed from context in many circumstances
[ https://issues.apache.org/jira/browse/XBEAN-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed XBEAN-122. -- Resolution: Fixed Closing it. Object cannot be removed from context in many circumstances --- Key: XBEAN-122 URL: https://issues.apache.org/jira/browse/XBEAN-122 Project: XBean Issue Type: Bug Components: naming Affects Versions: 3.5 Reporter: Jack Cai Assignee: Ivan Attachments: Geronimo-4549_0307.patch See https://issues.apache.org/jira/browse/GERONIMO-4549 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4602) Unexpected tomcat session destroy in the server container while the client is stil alive
[ https://issues.apache.org/jira/browse/GERONIMO-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4602. -- Resolution: Cannot Reproduce Unable to reproduce the problem now. Close it. Unexpected tomcat session destroy in the server container while the client is stil alive Key: GERONIMO-4602 URL: https://issues.apache.org/jira/browse/GERONIMO-4602 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.5 Environment: Windows/Linux, FireFox/IE, IBM Java 5 Reporter: Jack Cai Assignee: Jack Cai Priority: Critical After logging in the admin console, and keep refreshing the welcome page, at some random point (usually less than 100 times of refreshing), the user is unexpectedly logged out and redirected to the login form. I can see that the original session is destoryed in the server container. This could be a problem in Tomcat. I need to look deeper into 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-4601) Removing all statistics for one server resulted in exception and the configuration is not saved
[
https://issues.apache.org/jira/browse/GERONIMO-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai closed GERONIMO-4601.
--
Resolution: Invalid
There must be something crazy going on with my machine last time. As I look
into the code of the method
org.apache.geronimo.monitoring.MasterRemoteControl.getSnapshotDuration(), it
seems impossible that such an Exception was thrown, see -
{code}
public Long getSnapshotDuration() {
// return what is stored in the snapshot-config.xml or default value
try {
String returnedDuration =
SnapshotConfigXMLBuilder.getAttributeValue( DURATION ); // How can an Exception
escape this try??
return Long.parseLong( returnedDuration );
} catch(Exception e) {
return DEFAULT_DURATION; // the default
}
}
{code}
Would really appreciate if someone knows some insight about this...
Anyway, I can't reproduce this exception any more. Cancelling this issue.
Removing all statistics for one server resulted in exception and the
configuration is not saved
---
Key: GERONIMO-4601
URL: https://issues.apache.org/jira/browse/GERONIMO-4601
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: monitoring
Affects Versions: 2.1.5
Reporter: Jack Cai
Assignee: Jack Cai
Priority: Minor
If all statistics are removed for one server, then there is the below
exception in the server log, and the configuratiion is not saved - after
refresh, you get the old statistics back.
2009-03-25 16:17:31,109 ERROR [SnapshotConfigXMLBuilder] 文件过早结束。
org.xml.sax.SAXParseException: 文件过早结束。
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
at
org.apache.geronimo.monitoring.snapshot.SnapshotConfigXMLBuilder.openDocument(SnapshotConfigXMLBuilder.java:286)
at
org.apache.geronimo.monitoring.snapshot.SnapshotConfigXMLBuilder.getAttributeValue(SnapshotConfigXMLBuilder.java:197)
at
org.apache.geronimo.monitoring.MasterRemoteControl.getSnapshotDuration(MasterRemoteControl.java:320)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at
org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at
org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at
org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:810)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4607) Useless META-INF dir in the JEE server assembly
Useless META-INF dir in the JEE server assembly --- Key: GERONIMO-4607 URL: https://issues.apache.org/jira/browse/GERONIMO-4607 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.1.4, 2.2 Reporter: Jack Cai Priority: Minor In the JEE server assembly, there is a useless META-INF dir in the root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4607) Useless META-INF dir in the JEE server assembly
[ https://issues.apache.org/jira/browse/GERONIMO-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai updated GERONIMO-4607: --- Attachment: Geronimo-4607.patch Providing a fix. Useless META-INF dir in the JEE server assembly --- Key: GERONIMO-4607 URL: https://issues.apache.org/jira/browse/GERONIMO-4607 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.4, 2.2 Reporter: Jack Cai Priority: Minor Attachments: Geronimo-4607.patch In the JEE server assembly, there is a useless META-INF dir in the root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4608) java.io.EOFException when reading ejb response
java.io.EOFException when reading ejb response --- Key: GERONIMO-4608 URL: https://issues.apache.org/jira/browse/GERONIMO-4608 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.1.4 Environment: Windows Reporter: Jack Cai In the monitoring admin console page, define a server, enable query and then view its statistics. Keep refreshing the server view page, and soon there will be a server is offline message. Initial debugging reveals when the jsp access the server-side agent ejb, there is a java.io.EOFException thrown during the reading of ejb response. An old mail discussion also mentioned this problem, see [1]. This problem only occurs on Windows system. [1] http://www.nabble.com/error-on-running-tests-on-windows-tt16618112.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4394) Run Geronimo as a Windows service out of box
[ https://issues.apache.org/jira/browse/GERONIMO-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4394. -- Run Geronimo as a Windows service out of box Key: GERONIMO-4394 URL: https://issues.apache.org/jira/browse/GERONIMO-4394 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: commands Environment: Windows platforms Reporter: Jack Cai Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: GERONIMO-4394_Jack_1219.patch, geronimosrv.exe, geronimosrvw.exe, osservice.zip, README Although there is already an option provided by the Java Service Wrapper, some users are more interested in seeing something similar to what is provided by Tomcat. Provided that we can easily take the technology from Tomcat (http://commons.apache.org/daemon/procrun.html), I'm keen to implement this same thing for Geronimo. The advantage of using Apache Commons procrun is that - 1. Out-of-box experience, no need to download and install a third party component; 2. Tray icon that further improves usability. Eventually we would think to provide this run as a service capability for Linux/Unix platforms, but Windows would be a good start. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4463) Display complete usage information in the geronimo command
[ https://issues.apache.org/jira/browse/GERONIMO-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4463. -- Thanks Jarek. Closing this issue. Display complete usage information in the geronimo command -- Key: GERONIMO-4463 URL: https://issues.apache.org/jira/browse/GERONIMO-4463 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3, 2.2 Environment: All OS Reporter: Jack Cai Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.4, 2.2 Attachments: GERONIMO-4463_Jack.patch The usage information of the geronimo command does not show the --host and --secure option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4462) Allow JAVA_HOME to point to a JRE in Windows OS
[ https://issues.apache.org/jira/browse/GERONIMO-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4462. -- Thanks Jarek. Closing this issue. Allow JAVA_HOME to point to a JRE in Windows OS --- Key: GERONIMO-4462 URL: https://issues.apache.org/jira/browse/GERONIMO-4462 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.3, 2.2 Environment: Windows OS Reporter: Jack Cai Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.4, 2.2 Attachments: GERONIMO-4462_Jack.patch Currently the setjavaenv.bat script will set JRE_HOME=JAVA_HOME if JRE_HOME is not set. This requires JAVA_HOME to point to a JDK installation. Otherwise the geronimo.bat script will fail to launch because JAVA_HOME\jre is not a valid dir. This is an unnecessary requirement. We should allow user to point JAVA_HOME to a JRE installation, as what we do in Linux script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4607) Useless META-INF dir in the JEE server assembly
[ https://issues.apache.org/jira/browse/GERONIMO-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4607. -- Oops, didn't notice that. Closing this issue then. Useless META-INF dir in the JEE server assembly --- Key: GERONIMO-4607 URL: https://issues.apache.org/jira/browse/GERONIMO-4607 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.4, 2.2 Reporter: Jack Cai Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.5, 2.2 Attachments: Geronimo-4607.patch In the JEE server assembly, there is a useless META-INF dir in the root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter
[ https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Cai closed GERONIMO-4549. -- Resolution: Fixed Closing this issue as it's a XBean issue. JMS resource jndi entries are not removed after uninstalling the JMS connect adapter Key: GERONIMO-4549 URL: https://issues.apache.org/jira/browse/GERONIMO-4549 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Reporter: Forrest Xia Assignee: Jack Cai Priority: Minor Fix For: 2.1.5, 2.2 Attachments: Geronimo-4549_0307.patch Steps to reproduce this problem: 1. login admin console 2. Create a ActiveMQ resource connector with the wizard 3. Deploy it and check it is in running state 4. Click J2EE connector to uninstall it 5. Check JNDI viewer, you will see the JNDI entry still there, even you've uninstalled it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-122) Object cannot be removed from context in many circumstances
[ https://issues.apache.org/jira/browse/XBEAN-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689857#action_12689857 ] Jack Cai commented on XBEAN-122: Thanks Ivan for helping! Committing to the trunk is OK. Object cannot be removed from context in many circumstances --- Key: XBEAN-122 URL: https://issues.apache.org/jira/browse/XBEAN-122 Project: XBean Issue Type: Bug Components: naming Affects Versions: 3.5 Reporter: Jack Cai Assignee: Ivan Attachments: Geronimo-4549_0307.patch See https://issues.apache.org/jira/browse/GERONIMO-4549 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4601) Removing all statistics for one server resulted in exception and the configuration is not saved
Removing all statistics for one server resulted in exception and the configuration is not saved --- Key: GERONIMO-4601 URL: https://issues.apache.org/jira/browse/GERONIMO-4601 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1.5 Reporter: Jack Cai Assignee: Jack Cai Priority: Minor If all statistics are removed for one server, then there is the below exception in the server log, and the configuratiion is not saved - after refresh, you get the old statistics back. 2009-03-25 16:17:31,109 ERROR [SnapshotConfigXMLBuilder] 文件过早结束。 org.xml.sax.SAXParseException: 文件过早结束。 at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) at org.apache.geronimo.monitoring.snapshot.SnapshotConfigXMLBuilder.openDocument(SnapshotConfigXMLBuilder.java:286) at org.apache.geronimo.monitoring.snapshot.SnapshotConfigXMLBuilder.getAttributeValue(SnapshotConfigXMLBuilder.java:197) at org.apache.geronimo.monitoring.MasterRemoteControl.getSnapshotDuration(MasterRemoteControl.java:320) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238) at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129) at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122) at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84) at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60) at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78) at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:810) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4602) Unexpected tomcat session destroy in the server container while the client is stil alive
Unexpected tomcat session destroy in the server container while the client is stil alive Key: GERONIMO-4602 URL: https://issues.apache.org/jira/browse/GERONIMO-4602 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1.5 Environment: Windows/Linux, FireFox/IE, IBM Java 5 Reporter: Jack Cai Assignee: Jack Cai Priority: Critical After logging in the admin console, and keep refreshing the welcome page, at some random point (usually less than 100 times of refreshing), the user is unexpectedly logged out and redirected to the login form. I can see that the original session is destoryed in the server container. This could be a problem in Tomcat. I need to look deeper into it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
