[jira] Commented: (GERONIMO-5243) /activemq-console does not require admin authentication

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Closed: (GERONIMO-5159) Add pause when startup.bat fails on Windows

[Jack Cai (JIRA)]

 [ 
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] Resolved: (GERONIMO-5159) Add pause when startup.bat fails on Windows

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-5159) Add pause when startup.bat fails on Windows

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Created: (GERONIMO-5159) Add pause when startup.bat fails on Windows

[Jack Cai (JIRA)]

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-5125) Enable connecting to a ldap server anonymously on console

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5142) runtime errors if JAVA_HOME or JRE_HOME is not specified

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5040) PermGenSpace Problems and shut-down issues when using the "Apache Commons Daemon" under Windows

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Commented: (GERONIMO-4968) Problemastic OS check in Windows startup command

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Closed: (GERONIMO-4694) Upgrade to Derby 10.5.3.0

[Jack Cai (JIRA)]

 [ 
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] Resolved: (GERONIMO-4694) Upgrade to Derby 10.5.3.0

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4694) Upgrade to Derby 10.5.3.0

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Closed: (GERONIMO-4968) Problemastic OS check in Windows startup command

[Jack Cai (JIRA)]

 [ 
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] Resolved: (GERONIMO-4968) Problemastic OS check in Windows startup command

[Jack Cai (JIRA)]

 [ 
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] Resolved: (GERONIMO-5032) Procrun issue: windows service is stoped when user log off console session

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

 [ 
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-4987) Use ConcurrentHashMap instead of Collections.synchronizedMap(new HashMap())

[Jack Cai (JIRA)]

 [ 
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 Map sessionMap = Collections.synchronizedMap(new 
> HashMap());
> ./framework/modules/geronimo-crypto/src/main/java/org/apache/geronimo/crypto/EncryptionManager.java:
> private static final Map ENCRYPTORS = 
> Collections.synchronizedMap(new HashMap());
> ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java:
> asyncKeys = Collections.synchronizedMap(new HashMap DownloadResults>());
> ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java:
> asyncKeys = Collections.synchronizedMap(new HashMap DownloadResults>());
> ./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java:
> asyncKeys = Collections.synchronizedMap(new HashMap DownloadResults>());
> ./framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/Authenticator.java:
> private Map contextMap = 
> Collections.synchronizedMap(new HashMap());
> ./framework/modules/geronimo-security/src/main/java/org/apache/geronimo/security/ContextManager.java:
> private static Map subjectIds =  
> Collections.synchronizedMap(new HashMap());

-- 
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())

[Jack Cai (JIRA)]

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 Map sessionMap = Collections.synchronizedMap(new 
HashMap());
./framework/modules/geronimo-crypto/src/main/java/org/apache/geronimo/crypto/EncryptionManager.java:
private static final Map ENCRYPTORS = 
Collections.synchronizedMap(new HashMap());
./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java:
asyncKeys = Collections.synchronizedMap(new HashMap());
./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java:
asyncKeys = Collections.synchronizedMap(new HashMap());
./framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java:
asyncKeys = Collections.synchronizedMap(new HashMap());
./framework/modules/geronimo-jmx-remoting/src/main/java/org/apache/geronimo/jmxremoting/Authenticator.java:
private Map contextMap = 
Collections.synchronizedMap(new HashMap());
./framework/modules/geronimo-security/src/main/java/org/apache/geronimo/security/ContextManager.java:
private static Map subjectIds =  
Collections.synchronizedMap(new HashMap());




-- 
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

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Commented: (GERONIMO-4296) Start Derby NetworkServerControl with credentials to prevent unauthorized shutdowns

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4833) javax.resource.ResourseException in too many graphs in one view after disable server

[Jack Cai (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jack Cai updated GERONIMO-4833:
---

Attachment: Geronimo-4833.patch

Submitting a patch. Verified on 2.1 branch.

> 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
> Attachments: Geronimo-4833.patch
>
>
> 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.(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

[jira] Commented: (GERONIMO-4222) Database pool unusable after database unavailable for awhile

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Assigned: (GERONIMO-4833) javax.resource.ResourseException in too many graphs in one view after disable server

[Jack Cai (JIRA)]

 [ 
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.(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

[jira] Commented: (GERONIMO-4833) javax.resource.ResourseException in too many graphs in one view after disable server

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(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_002dt

[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-4874) Improve the console filter performance

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. ) 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] Updated: (GERONIMO-4874) Improve the console filter performance

[Jack Cai (JIRA)]

 [ 
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] Assigned: (GERONIMO-4222) Database pool unusable after database unavailable for awhile

[Jack Cai (JIRA)]

 [ 
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-4222) Database pool unusable after database unavailable for awhile

[Jack Cai (JIRA)]

 [ 
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-4222) Database pool unusable after database unavailable for awhile

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-4874) Improve the console filter performance

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4874) Improve the console filter performance

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4874) Improve the console filter performance

[Jack Cai (JIRA)]

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


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-4785) "useCaches" property of JarFileUrlConnection doesn't work

[Jack Cai (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jack Cai updated GERONIMO-4785:
---

Attachment: GERONIMO-4785.patch

This patch applies to both 2.1 and 2.2. Built well. 

I intentionally set the default value of useCaches to false, so that all the 
URLConnection instances will not use a cache (including our 
JarFileUrlConnection). All the tests passed.


> "useCaches" property of JarFileUrlConnection doesn't work
> -
>
> Key: GERONIMO-4785
> URL: https://issues.apache.org/jira/browse/GERONIMO-4785
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 2.1.4
> Environment: Sun JDK 1.5.0.19
>Reporter: Masayoshi Yamashita
> Attachments: GERONIMO-4785.patch
>
>
> When executing the following code on Geronimo server,
> =
> ClassLoader loader = Thread.currentThread().getContextClassLoader();
> URL url = loader.getResource("javax/servlet/http/");
> JarURLConnection conn1 = (JarURLConnection) url.openConnection();
> conn1.setUseCaches(false);
> JarFile jarFile1 = conn1.getJarFile();
> JarURLConnection conn2 = (JarURLConnection) url.openConnection();
> conn2.setUseCaches(false);
> JarFile jarFile2 = conn2.getJarFile();
> System.out.println(jarFile1);
> System.out.println(jarFile2);
> =
> there is a problem that "jarFile1" and "jarFile2" are same instances.
> Also, it is described in the javadoc of "useCaches" field as follows.
> "If false, the protocol must always try to get a fresh copy of the object."
> "org.apache.geronimo.kernel.classloader.JarFileUrlConnection" must return a 
> different instance, when "useCaches" is false.

-- 
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

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

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] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
> 
> org.codehaus.mojo
> native2ascii-maven-plugin
> 1.0-alpha-1
> 
> target/classes
> src/main/resources
> 
> 
> 
> native2ascii-utf8
> 
> native2ascii
> 
> 
> UTF8
> 
> ConsoleResources_jp.properties,
> ConsoleResources_zh*.properties
> 
> 
> 
> 
> 
> {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-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
> 
> org.codehaus.mojo
> native2ascii-maven-plugin
> 1.0-alpha-1
> 
> target/classes
> src/main/resources
> 
> 
> 
> native2ascii-utf8
> 
> native2ascii
> 
> 
> UTF8
> 
> ConsoleResources_jp.properties,
> ConsoleResources_zh*.properties
> 
> 
> 
> 
> 
> {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

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4773) logger not initialized in shutdown command

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-4762) Databinding exception issue with Axis

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

 [ 
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-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
> 
> org.codehaus.mojo
> native2ascii-maven-plugin
> 1.0-alpha-1
> 
> target/classes
> src/main/resources
> 
> 
> 
> native2ascii-utf8
> 
> native2ascii
> 
> 
> UTF8
> 
> ConsoleResources_jp.properties,
> ConsoleResources_zh*.properties
> 
> 
> 
> 
> 
> {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-4773) logger not initialized in shutdown command

[Jack Cai (JIRA)]

 [ 
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] Resolved: (GERONIMO-4774) EJB Server portlet a little messed up in admin console

[Jack Cai (JIRA)]

 [ 
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] Closed: (GERONIMO-4774) EJB Server portlet a little messed up in admin console

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4775) Need to convert static English images into translatable text in Admin console

[Jack Cai (JIRA)]

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-4774) EJB Server portlet a little messed up in admin console

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4774) EJB Server portlet a little messed up in admin console

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4774) EJB Server portlet a little messed up in admin console

[Jack Cai (JIRA)]

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] Created: (GERONIMO-4773) logger not initialized in shutdown command

[Jack Cai (JIRA)]

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] Commented: (GERONIMO-4763) i18n properties files should be converted to ascii at build time.

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
> 
> org.codehaus.mojo
> native2ascii-maven-plugin
> 1.0-alpha-1
> 
> target/classes
> src/main/resources
> 
> 
> 
> native2ascii-utf8
> 
> native2ascii
> 
> 
> UTF8
> 
> ConsoleResources_jp.properties,
> ConsoleResources_zh*.properties
> 
> 
> 
> 
> 
> {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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Updated: (GERONIMO-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

 [ 
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

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4769) Add English resource bundle for Admin console

[Jack Cai (JIRA)]

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-4716) Upgrade HTTPComponent HTTPCore to released version 4.0.1

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-4716) Upgrade HTTPComponent HTTPCore to released version 4.0.1

[Jack Cai (JIRA)]

 [ 
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] Commented: (GERONIMO-3003) Encrypt password strings in deployment plans

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(MRCConnector.java:123)
>   at 
> org.apache.geronimo.monitoring.console.MRCConnector.(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

[jira] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans

[Jack Cai (JIRA)]

 [ 
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] Updated: (GERONIMO-3003) Encrypt password strings in deployment plans

[Jack Cai (JIRA)]

 [ 
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] Resolved: (GERONIMO-4755) Warning message when starting the server due to Tomcat class not found

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4755) Warning message when starting the server due to Tomcat class not found

[Jack Cai (JIRA)]

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] Created: (GERONIMO-4754) Unnecessary attributes retrieval causes slow login in LDAPLoginModule

[Jack Cai (JIRA)]

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] Updated: (GERONIMO-4754) Unnecessary attributes retrieval causes slow login in LDAPLoginModule

[Jack Cai (JIRA)]

 [ 
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-4716) Upgrade HTTPComponent HTTPCore to released version 4.0.1

[Jack Cai (JIRA)]

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


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] Resolved: (GERONIMO-4650) changes not persisted to security realms

[Jack Cai (JIRA)]

 [ 
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-4694) Upgrade to Derby 10.5.1.1

[Jack Cai (JIRA)]

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] Closed: (XBEAN-122) Object cannot be removed from context in many circumstances

[Jack Cai (JIRA)]

 [ 
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] Assigned: (GERONIMO-3003) Encrypt password strings in deployment plans

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4634) PlanCreator does not work for some applications like Open BlueDragon

[Jack Cai (JIRA)]

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] Closed: (GERONIMO-4602) Unexpected tomcat session destroy in the server container while the client is stil alive

[Jack Cai (JIRA)]

 [ 
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-4607) Useless META-INF dir in the JEE server assembly

[Jack Cai (JIRA)]

 [ 
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-4462) Allow JAVA_HOME to point to a JRE in Windows OS

[Jack Cai (JIRA)]

 [ 
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-4463) Display complete usage information in the geronimo command

[Jack Cai (JIRA)]

 [ 
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-4394) Run Geronimo as a Windows service out of box

[Jack Cai (JIRA)]

 [ 
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] Created: (GERONIMO-4608) java.io.EOFException when reading ejb response

[Jack Cai (JIRA)]

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] Updated: (GERONIMO-4607) Useless META-INF dir in the JEE server assembly

[Jack Cai (JIRA)]

 [ 
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-4607) Useless META-INF dir in the JEE server assembly

[Jack Cai (JIRA)]

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] Closed: (GERONIMO-4601) Removing all statistics for one server resulted in exception and the configuration is not saved

[Jack Cai (JIRA)]

 [ 
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.