Re: importing geronimo/server/trunk into eclipse
I usually do a create patch from TortoiseSvn to find out if there are any files/directories in the tree which are not in svn and delete those. ++Vamsi On Jan 27, 2008 9:53 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 27, 2008, at 2:29 AM, Vamsavardhana Reddy wrote: Kevan, I did an import just y'day. I have removed all the existing projects from my workspace and did an import. I did not run into the duplicate projects problem. It is surely because of the old directories, for I have got rid of all old directories before doing the import. Ya. Removing all .project files from my src tree and re-running mvn eclipse:eclipse fixed my problem... Is there some easy way to cleanup directories that no longer exist in svn? Other than check out a fresh tree from svn... --kevan
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563026#action_12563026 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- Completed: At revision: 615660 in trunk(2.1) o Allow selecting any keystore type supported by the JVM in Tomcat HTTPS Connector pages. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3757-2.0.patch, GERONIMO-3757-2.1.patch, Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Unable to shutdown G 2.1 server
I am unable to shutdown G 2.1 Tomcat server either from admin console or by pressing Ctrl+C in the command window on Windows XP. Has anyone else run into this situation? ++Vamsi
Re: Unable to shutdown G 2.1 server
The server build I had from Saturday (26th) was fine. I am now at rev 615612 and there seems to be a problem. What revision is your server built from? ++Vamsi On Jan 28, 2008 3:49 AM, Viet Nguyen [EMAIL PROTECTED] wrote: Vamsi, I just tried it and it shuts down fine for me. -Viet On Jan 27, 2008 5:02 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I am unable to shutdown G 2.1 Tomcat server either from admin console or by pressing Ctrl+C in the command window on Windows XP. Has anyone else run into this situation? ++Vamsi
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3757: -- Attachment: GERONIMO-3757-2.1.patch GERONIMO-3757-2.1.patch: o Patch for trunk o One other change I plan is to push CreateKeyStoreHandler.keystoreTypes and defaultType to a separate KeystoresUtil class or so, for the reason that I feel these may come in handy in other code too. o I have tried the same functionality as GERONIMO-3757-2.1.patch on branches\2.0 and ran 2.0.3-SNAPSHOT Tomcat server on Harmony 5.0M4 JRE. Functionality looks pretty much alright. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: GERONIMO-3757-2.1.patch, Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3757: -- Attachment: GERONIMO-3757-2.0.patch GERONIMO-3757-2.0.patch: Patch for branches\2.0 just in case someone wants to try it out on branches\2.0 KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: GERONIMO-3757-2.0.patch, GERONIMO-3757-2.1.patch, Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3757: -- Component/s: console Fix Version/s: 2.1 2.0.x Assignee: Vamsavardhana Reddy Not sure if we should consider this function for 2.0.x, but added it to Fix Versions for now. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3757-2.0.patch, GERONIMO-3757-2.1.patch, Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: importing geronimo/server/trunk into eclipse
Kevan, I did an import just y'day. I have removed all the existing projects from my workspace and did an import. I did not run into the duplicate projects problem. It is surely because of the old directories, for I have got rid of all old directories before doing the import. ++Vamsi On Jan 27, 2008 9:23 AM, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 26, 2008, at 8:48 PM, Kevan Miller wrote: Has anyone done an import of trunk into eclipse, lately? I ran mvn eclipse:eclipse and am importing, but running into a number of duplicate projects. Doh... I haven't verified, yet, but this must be caused by directories getting moved around. Some of the old directories must still contain some eclipse info... --kevan
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562786#action_12562786 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615417 in branches\2.0 and trunk (2.1) o NestedJarFile should close the baseJar only if it is created by itself. o This is sort of correcting the previous rev 615389 which may close the parent jar in one case (I doubt if we will be hitting that instance in Geronimo, but just to keep things straight...) DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch, GERONIMO-3764-deploymentutil.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562836#action_12562836 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- try to load with all available providers is the first option I tried. And the results from IBMJDK 1.5, SunJDK 1.5 and Harmony 5.0M4 are not at all satisfying. It is much worse when the keystore password is not known (which is the case when a new keystore file is dropped in the keystores directory). Harmony won't load anything without the password; IBMJDK chooses wrong keystoreType etc. So, I decided to go with the file extension (which will allow users to drop any type of keystore file into the keystores directory) or defaultType when there is no extension and the user will be able to access the keystore from admin console right away. I was under the impression that when a new keystore is dropped in keystores directory, it won't be recognized by KeystoreManager unless a KeystoreInstance GBean is added to config.xml. But then I was wrong and KeystoreManager is dynamically adding the required KeystoreInstance gbean. If we don't decide upon the type at the type of the keystore at the time KeystoreManager adds the gbean, Option1: the user will have to stop the server, edit config.xml to correct the keystoreType and start the server, Option 2: make the keystoreType attribute manageable and add keystorePortlet pages to let the user change the type through admin console etc (which will be used only for new keystores added directly to keystores directory). So, I took the easy way out as it also keeps things simple :) KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562832#action_12562832
]
Vamsavardhana Reddy commented on GERONIMO-3757:
---
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
The reason for the above piece of code is that defaultType and the
corresponding algorithm name got from the Service need not be of same case.
For e.g. defaultType is jks where as the one we get from available types is
JKS. Nothing more :). I did not want the keystoreTypes to show jks and
JKS at the sametime. I wanted the defaultType to have a value from
keystoreTypes so that the following line in createKeystore.jsp enables
selecting the defaultType:
select name=type
option c:if test=${defaultType eq
keystoreType}selected/c:if${keystoreType}/option
/select
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
Geronimo-3757.patch, GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
configuration option, keystoreType, that would allow to change the keystore
type through config.xml without recompilation, like this:
module name=org.apache.geronimo.configs/server-security-config/2.0.2/car
gbean name=geronimo-default
attribute name=keystoreTypePKCS12/attribute
attribute
name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute
/gbean
/module
This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562747#action_12562747 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615389 in branches\2.0 and trunk (2.1) o NestedJarFile should close the baseJar irrespective of whether it is packed or not. In case of inPlace deployment of an ear file, not closing baseJar is resulting in a lock on DUMMY_JAR_FILE. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch, GERONIMO-3764-deploymentutil.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562675#action_12562675 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- I also curious about CreateKeystoreHandler.defaultType variable... 1. As far as I understood from the code you want this variable to be null if KeyStore.getDefaultType() is not in the list of available keystore types. Is this possible? From the other hand null type treated as KeyStore.getDefaultType() later in the code. It is a bit confusing for me... 2. How will we handle situation if defaultType variable is not null but it is impossible to create empty store for this type and the type will be removed from the list on next step? Response: 1. defaultType can not be null. Ideally, KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any exceptions. 2. The keystoreTypes is the list of types that will be shown for selection while creating a keystore using Keystores portlet. It does not matter what the defaultType is. If defaultType is in keystoreTypes, it will be selected, otherwise the first one in the list will be selected. We are using these to prevent users from selecting a keystore type that can not have an empty keystore. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Offline Deployer leaving behind temporary files
I have changed DeploymentUtil.toTempFile(URL url) and
DeploymentUtil.readAll(URL
url) to use JarFile.getInputStream() instead of URL.openStream() when the
protocol is jar. But, the other code the uses URL.openStream() still
leaves locks on the jar files which prevent immediate deletion of temp
files. The idea that I have is to change DeploymentUtil.createJarURL() such
that when the URL is for a file inside a jar file, rewrite the content to a
temp file and return the URL to that file.
The code will look something like the following:
String urlString = jar: + new File(jarFile.getName()).toURL()
+ !/ + path;
if(jarUrlRewrite) {
// To prevent the lockout of archive, instead of returning a
jar url, write the content to a
// temp file and return the url of that file.
File tempFile = null;
try {
tempFile = toTempFile(new URL(urlString));
} catch (IOException e) {
// The JarEntry does not exist!
// Return url of a file that does not exist.
try {
tempFile = createTempFile();
tempFile.delete();
} catch (IOException ignored) {
}
}
return tempFile.toURL();
} else {
return new URL(urlString);
}
And the jarUrlRewrite value (false by default, which means no change from
current behavior) can be controlled by a system property
org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite which the
users can set either using GERONIMO_OPTS environment variable or by using
the SystemProperties GBean.
When jarUrlRewrite is true, more temporary files are created, but the
Deployer will be able to delete the temporary files immediately and it won't
be needing to use DeployerReaper. On the other hand, each temp file created
will also be calling deleteOnExit() which may be holding on to 1K of memory
until the JVM terminates (if I recall correctly). Since DeployerReaper is
doing a fairly good job in case of online deployement, I suggest we set
jarUrlRewrite system property to true for offline-deployer and let users
decide what it should be for online deployer.
Comments? Suggestions? Anything I am missing.
++Vamsi
On Jan 24, 2008 12:13 AM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I have found the culprit. It is the URLs that we use to read content from
an archive, for e.g., META-INF/application.xml from an ear file. The
deployer is creating a JarFile and closing the JarFile after the deployment
operation is completed. JarFile.close() closes all the InputStreams
obtained from the JarFile and releases any locks.
For e.g., in EARConfigBuilder.getEarPlan(), we have code like the
following:
URL applicationXmlUrl = DeploymentUtil.createJarURL(earFile,
META-INF/application.xml);
specDD = DeploymentUtil.readAll (applicationXmlUrl);
After this code is executed the earFile is locked until the JVM
terminates. If you replace the above with something similar to
InputStream inp = earFile.getInputStream(earFile.getJarEntry
(META-INF/application.xml));
BufferedReader br = new BufferedReader(new
InputStreamReader(inp));
String line;
while((line = br.readLine()) != null) {
specDD += line;
}
the earFile is no longer locked once earFile.close() is called and can be
deleted anytime. This is what is observed on Win XP.
++Vamsi
On Jan 23, 2008 8:52 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote:
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should
be reading this file. I guess it is the same with other builders as
well. The JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on
windows, since the jar URL handler included with the Sun JavaVM
* holds a read lock on the JarFile, and this lock is not released
when the jar url is dereferenced. To fix this a
* replacement for the jar url handler must be written.
BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
I wouldn't trust that comment. Dain's commit was addressing this very
problem (at least within the server runtime:
http://svn.apache.org/viewvc?view=revrevision=399522
You need to check to see what type of ClassLoader is being used. If
it's not JarFileClassLoader, then we understand the problem. If it is
JarFileClassLoader, then maybe we aren't calling destroy. If we doing
all of these things, then obviously I'm wrong again... ;-)
--kevan
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562500#action_12562500 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615225 in branches\2.0 and trunk (2.1) o When url.openStream() is used to read an individual file from an archive i.e. when protocol is jar, the archive file is locked even after the stream is closed and it prevents immediate deletion of temporary files created during the deployment process. This can be avoided by using JarFile.getInputStream() instead. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch, GERONIMO-3764-deploymentutil.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562651#action_12562651 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- I thought it would be possible to determine the keystore type by trying to load the keystore file with various keystore implementations available in the JVM. After experimenting with IBMJDK 1.5, Sun JDK 1.5 and Harmony 5.0 M4 JRE, it appears to me that either using default keystore type or type based on file extension is the best option. This is applicable to only keystore files added directly to var/security/keystores directory. The keystores created using Keystores portlet need not have any extension in the name and can be of any type. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562384#action_12562384 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615134 in branches\2.0 and trunk (2.1) NestedJarFile and UnpackedJarFile use DUMMY_JAR_FILE in their constructors with super(DUMMY_JAR_FILE) but the close method does not invoke super.close(). Because of this, the DUMMY_JAR_FILE is locked and so, it does not get deleted at JVM termination. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch, GERONIMO-3764-deploymentutil.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Offline Deployer leaving behind temporary files
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves a lock
on the module file *preventing rebuilds*
// to address this we use a gross hack and copy the file to a
temporary directory
// the lock on the file will prevent that being deleted properly
until the URLJarFile has
// been GC'ed.
boolean cleanup = true;
try {
tmpDir = File.createTempFile(geronimo-deployer,
.tmpdir);
tmpDir.delete();
tmpDir.mkdir();
tmpFile = new File(tmpDir, moduleFile.getName());
DeploymentUtil.copyFile(moduleFile, tmpFile);
moduleFile = tmpFile;
Can someone explain the preventing rebuilds part in the above? It is
followed by code that creates a temporary copy of the module archive that
should be cleaned up by DeployerReaper which does not delete these files in
case of offline deployment. In online deployment also, the files may be
left behind if the DeployerReaper does not get a chance to run after the
files are added to pendingDeletionIndex. Incase of offline deployment
DeployerReaper does not get a chance at all as the java process terminates
immediately. I have tried deleteOnExit() as well with offline deployment,
but the files won't just go away. I am wondering if the reason this is
introduced in the first place is applicable to 2.x. If not, we can get rid
of this code.
++Vamsi
Build error on branches\2.0 building Persistence Deployer config
Has anyone come across this build error Error installing artifact's
metadata: Error installing metadata: Error updating group repository
metadata. only whitespace content allowed before start tag and not \u0
(position: START_DOCUMENT seen \u0... @1:1)? Output from build window
given below.
C:\G\server\branches\2.0\configs\persistence-jpa10-deployermvn -o -e
+ Error stacktraces are turned on.
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in your
loca
l
repository will be inaccessible.
[INFO] Scanning for projects...
[INFO]
-
---
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\G\server\branches\2.0\configs\persistence-jpa10-deployer\ta
rget\plan\plan.xml
log4j:WARN No appenders could be found for logger (
org.codehaus.mojo.pluginsuppo
rt.logging.Logging).
log4j:WARN Please initialize the log4j system properly.
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\G\server\branches\2.0\configs\persiste
nce-jpa10-deployer\target\plan\plan.xml
[INFO] Building jar:
C:\G\server\branches\2.0\configs\persistence-jpa10-deployer
\target\persistence-jpa10-deployer-2.0.3-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in:
persistence-jpa10-deployer-2.0.3-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
C:\G\server\branches\2.0\configs\persistence-jpa10-deployer\ta
rget\persistence-jpa10-deployer-2.0.3-SNAPSHOT.car to
C:\M2REPO\org\apache\geron
imo\configs\persistence-jpa10-deployer\2.0.3-SNAPSHOT\persistence-jpa10-deployer
-2.0.3-SNAPSHOT.car
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error installing artifact's metadata: Error installing metadata:
Error up
dating group repository metadata
only whitespace content allowed before start tag and not \u0 (position:
START_DO
CUMENT seen \u0... @1:1)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
artifac
t's metadata: Error installing metadata: Error updating group repository
metadat
a
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLi
fecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing
arti
fact's metadata: Error installing metadata: Error updating group repository
meta
data
at org.apache.maven.plugin.install.InstallMojo.execute(
InstallMojo.java:
143)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:443)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:539)
... 16 more
Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
Er
ror installing artifact's metadata: Error installing metadata: Error
updating gr
oup repository metadata
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(
DefaultArtifactInstaller.java:91)
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561675#action_12561675 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Incase of offline deployment, using deleteOnExit also did not help. Even at jvm process termination the locks on the files are not released and so the files are left behind. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Offline Deployer leaving behind temporary files
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should be
reading this file. I guess it is the same with other builders as well. The
JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on windows,
since the jar URL handler included with the Sun JavaVM
* holds a read lock on the JarFile, and this lock is not released when the
jar url is dereferenced. To fix this a
* replacement for the jar url handler must be written.
BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
++Vamsi
On Jan 23, 2008 7:48 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves a
lock on the module file *preventing rebuilds*
// to address this we use a gross hack and copy the file to a
temporary directory
// the lock on the file will prevent that being deleted
properly until the URLJarFile has
// been GC'ed.
boolean cleanup = true;
try {
tmpDir = File.createTempFile(geronimo-deployer,
.tmpdir);
tmpDir.delete();
tmpDir.mkdir();
tmpFile = new File(tmpDir, moduleFile.getName());
DeploymentUtil.copyFile(moduleFile, tmpFile);
moduleFile = tmpFile;
Can someone explain the preventing rebuilds part in the above? It is
followed by code that creates a temporary copy of the module archive that
should be cleaned up by DeployerReaper which does not delete these files in
case of offline deployment. In online deployment also, the files may be
left behind if the DeployerReaper does not get a chance to run after the
files are added to pendingDeletionIndex. Incase of offline deployment
DeployerReaper does not get a chance at all as the java process terminates
immediately. I have tried deleteOnExit() as well with offline deployment,
but the files won't just go away. I am wondering if the reason this is
introduced in the first place is applicable to 2.x. If not, we can get
rid of this code.
Hi Vamsi,
Well, the fact that the files are locked indicates a problem, I think. Can
you tell who's reading the files? I thought we would be using
org.apache.geronimo.kernel.classloader.JarFileClassLoader and would thus
avoid the Windows file locking problem.
Hmm, perhaps we're not calling JarFileClassLoader.destroy()? This should
free up the file locks.
--kevan
Re: Build error on branches\2.0 building Persistence Deployer config
argh... My bad... I should have read the message more carefully :(. I thought it is failing to build the car. While building G 2.0 branch, my system crashed 3 times in a span of 2 hours and the metadata file must have got corrupted. Thanks Kevan. On Jan 23, 2008 8:02 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 23, 2008, at 8:32 AM, Vamsavardhana Reddy wrote: Has anyone come across this build error Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata. only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0... @1:1)? Output from build window given below. I don't recall ever seeing this. I'd cleanup your local repo -- looks like one of the xml files has some bad characters. I'd start by deleting the following directory: C:\M2REPO\org\apache\geronimo\configs\persistence-jpa10-deployer\ And see if that fixes your problem. --kevan
Re: Offline Deployer leaving behind temporary files
I have found the culprit. It is the URLs that we use to read content from
an archive, for e.g., META-INF/application.xml from an ear file. The
deployer is creating a JarFile and closing the JarFile after the deployment
operation is completed. JarFile.close() closes all the InputStreams
obtained from the JarFile and releases any locks.
For e.g., in EARConfigBuilder.getEarPlan(), we have code like the following:
URL applicationXmlUrl = DeploymentUtil.createJarURL(earFile,
META-INF/application.xml);
specDD = DeploymentUtil.readAll(applicationXmlUrl);
After this code is executed the earFile is locked until the JVM terminates.
If you replace the above with something similar to
InputStream inp = earFile.getInputStream(earFile.getJarEntry
(META-INF/application.xml));
BufferedReader br = new BufferedReader(new InputStreamReader(inp));
String line;
while((line = br.readLine()) != null) {
specDD += line;
}
the earFile is no longer locked once earFile.close() is called and can be
deleted anytime. This is what is observed on Win XP.
++Vamsi
On Jan 23, 2008 8:52 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote:
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should
be reading this file. I guess it is the same with other builders as
well. The JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on
windows, since the jar URL handler included with the Sun JavaVM
* holds a read lock on the JarFile, and this lock is not released
when the jar url is dereferenced. To fix this a
* replacement for the jar url handler must be written.
BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
I wouldn't trust that comment. Dain's commit was addressing this very
problem (at least within the server runtime:
http://svn.apache.org/viewvc?view=revrevision=399522
You need to check to see what type of ClassLoader is being used. If
it's not JarFileClassLoader, then we understand the problem. If it is
JarFileClassLoader, then maybe we aren't calling destroy. If we doing
all of these things, then obviously I'm wrong again... ;-)
--kevan
[jira] Updated: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3764: -- Attachment: GERONIMO-3764-deploymentutil.patch GERONIMO-3764-deploymentutil.patch: The reason for archive files getting locked is that some of the code uses URLs to extract content from the archive, for e.g., application.xml from an ear file. See http://marc.info/?l=geronimo-devm=120111383903434w=2 . We will need to update DeploymentUtil and the attached patch gives an idea on what should be done. The drawback is that we may end up with more temp files (but these will be deletable as soon as the deployment operation completes) and deleteOnExit may be called only if delete fails on these files. Comments? Suggestions? Help!!! DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch, GERONIMO-3764-deploymentutil.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to change KeyStore type?
Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. *IBMJDK does not allow storing an empty PKCS12 keystore to disk.* This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3757: -- Attachment: GERONIMO-3757.patch GERONIMO-3757.patch: Created against branches\2.0. o Provides a keystoreType attribute o Keystores portlet updated to support all possible keystoreTypes. This patch may not necessarily be merged into branches\2.0. Please try the patch and comment. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reopened GERONIMO-3764: --- Offline deployer does not get a chance to cleanup temporary files :( DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3764: -- Attachment: GERONIMO-3764-2.0.patch GERONIMO-3764-2.0.patch: How about DeployerReaper cleaning up temp directories left by any previous runs? Anyone has a better idea? DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561108#action_12561108 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- deleteOnExit() seems to be a better option. But then deleteOnExit() does not delete files if the JVM is terminated abnormally. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561239#action_12561239 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 614127 in branches\2.0 and trunk (2.1) o DeployerReaper in offline deployment does not get a chance to reap the temporary directories. Reap these directories in the next run. o If anyone has a better idea on how to handle this or sees something I am missing, please suggest/comment. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561249#action_12561249 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 614136 in branches\2.0 and trunk (2.1) o Cleanup even when creation of temp file for deployment fails DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3763) Deploy New portlet does not cleanup the temp files
Deploy New portlet does not cleanup the temp files -- Key: GERONIMO-3763 URL: https://issues.apache.org/jira/browse/GERONIMO-3763 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.0.2, 2.0.1, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.x, 2.1 Deploy New portlet creates temp files from the files uploaded from the Admin Console, but does not cleanup the files after the deployment operation is completed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.2, 2.0.1, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to 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-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3764. - Resolution: Fixed Completed: At revision: 613388 in branches\2.0 and trunk (2.1). o DepoymentReaper needs full path, not just the filename. o DeploymentUtil.recursiveDelete() returns true upon successful deletion. o Remove the dirName, not deleteDir from pendingDeletionIndex. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to 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-3763) Deploy New portlet does not cleanup the temp files
[ https://issues.apache.org/jira/browse/GERONIMO-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3763. - Resolution: Fixed Completed: At revision: 613391 in branches\2.0 and trunk (2.1) o Deletes temporary files. o Upon failure, calls deleteOnExit. Deploy New portlet does not cleanup the temp files -- Key: GERONIMO-3763 URL: https://issues.apache.org/jira/browse/GERONIMO-3763 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.x, 2.1 Deploy New portlet creates temp files from the files uploaded from the Admin Console, but does not cleanup the files after the deployment operation is completed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3767) deploy process never completed after a failed deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3767: -- Affects Version/s: 2.0.x Fix Version/s: 2.0.x I have noticed this while installing a plugin using deployer. I should have reported this earlier. 2.0.x is also affected by this issue. deploy process never completed after a failed deploy Key: GERONIMO-3767 URL: https://issues.apache.org/jira/browse/GERONIMO-3767 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.x, 2.1 Reporter: Kevan Miller Fix For: 2.0.x, 2.1 Attempting to deploy proximity on 2.1, the deploy failed. After the failure, however, the deploy process never completed. Here's the failure plus stack traces from kill -3 on the deploy process. Exception in thread Thread-7 java.lang.NoClassDefFoundError: org/apache/struts/taglib/html/FormTag at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:457) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:420) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180) at org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:493) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:646) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:246) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815
[jira] Commented: (GERONIMO-3756) Blank screen in Security Realms portlet if wrong file path is specified
[ https://issues.apache.org/jira/browse/GERONIMO-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559879#action_12559879 ] Vamsavardhana Reddy commented on GERONIMO-3756: --- The problem occurs when there is a '\' in the string value used with ActionResponse.setRenderParameter(). In this case, the error message has a '\' in the filename on Windows. Does any one know if there are any guidelines on passing parameters containing special characters between portlet pages? Blank screen in Security Realms portlet if wrong file path is specified --- Key: GERONIMO-3756 URL: https://issues.apache.org/jira/browse/GERONIMO-3756 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.2 Environment: All Reporter: Manu T George Fix For: 2.0.x When I try to create a property file realm from the security realms portlet and I give a wrong file path for the user and group files, I get a blank screen on clicking next. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo
Thanks Matt. And congratulations Kevan. ++Vamsi On Jan 17, 2008 1:40 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Recently I have had several things change personally and I have found it increasingly difficult to keep up with the Geronimo mailing lists on a daily basis. As a result, I did some soul searching and decided that my intentions to stay on top of Geronimo were good but my follow through wasn't This was specifically in regard to being able to respond to people on issues that I needed to do as PMC chair. I tendered my resignation to the Board earlier this week. There was some discussion on the PMC list about a replacement and the PMC unanimously approved Kevan Miller as my successor. The board just approved this request so Kevan now has the mantle for Geronimo as the PMC chair. It is with great pleasure that I announce that Kevan has accepted this responsibility of PMC chair. The beauty is that Kevan has already been doing most of the work of the PMC chair anyway and is the right person going forward. Please give it up for Kevan Miller, VP, Apache Geronimo! I'm still noodling with some performance work as time allows so I'm not gone. I'll prolly continue to nag in my own unique way. Matt
[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557675#action_12557675 ] Vamsavardhana Reddy commented on GERONIMO-2015: --- Sun's PKCS12 implementation does not allow storing trusted certificate entries in a keystore. This will be a problem if one wants to configure ClientAuth for HTTPS, etc. Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: https://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Reporter: Nikolay Chugunov Fix For: Wish List Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, jksToPKCS12.patch, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release geronimo-txmanager-2.1
+1 ++Vamsi On Jan 10, 2008 4:05 PM, David Blevins [EMAIL PROTECTED] wrote: Discuss thread (for reference): http://mail-archives.apache.org/mod_mbox/geronimo-dev/200711.mbox/[EMAIL PROTECTED] Changes since last release: r585608 | dain | 2007-10-17 10:56:54 -0700 (Wed, 17 Oct 2007) | 1 line Added generic types to all collections usage r585309 | dain | 2007-10-16 17:54:22 -0700 (Tue, 16 Oct 2007) | 1 line clear proxy reference after returning to caller so the proxy can be garbage collected r584554 | akulshreshtha | 2007-10-14 08:19:58 -0700 (Sun, 14 Oct 2007) | 1 line GERONIMO-3250 Adding counters to keep track of transaction activity, Patch by Viet H. Nguyen Binaries: http://people.apache.org/~dblevins/stage-txmanager/repo/org/apache/geronimo/components/http://people.apache.org/%7Edblevins/stage-txmanager/repo/org/apache/geronimo/components/ Branch: http://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/ Vote will be open for 72 hours and close on the 13th [ ] +1 - Yes, release it [ ] 0 - Hmm... [ ] -1 - No, because... Vote away! -David
[jira] Assigned: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned GERONIMO-2503: - Assignee: Vamsavardhana Reddy (was: Rick McGuire) Rev 465638 did not go into the web 2.5 builder code which was in sandbox then. Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: https://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Assignee: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-2503. - Resolution: Fixed Fix Version/s: 2.1 2.0.x Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: https://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Assignee: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0.x, 2.1 Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556542#action_12556542 ] Vamsavardhana Reddy commented on GERONIMO-2503: --- Completed: At revision: 609569 in branches\2.0 and trunk (2.1) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: https://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Assignee: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0.x, 2.1 Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unable to render portlet SecurityRealmPortlet
Before you do an svn up this time, you can check your current revision number you have so that we can examine which rev could have caused the problem. ++Vamsi On Dec 19, 2007 7:20 PM, Shiva Kumar H R [EMAIL PROTECTED] wrote: I haven't svn updated for quite a few weeks now. So don't know if there is some regression in the latest build. On Dec 19, 2007 7:11 PM, Hernan Cunico [EMAIL PROTECTED] wrote: This is from Monday's rev #605334 Cheers! Hernan Shiva Kumar H R wrote: In which version of G are you facing this? I am able to use it successfully in trunk-build. On Dec 19, 2007 3:38 AM, Hernan Cunico [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi folks, I remember reading about a Security Realm issue but can't find it now, either way I think it was a NPE. Is there anybody else getting this error? I get this by just clicking on the Security Realms link from the console. 16:49:41,687 ERROR [SecurityRealmPortlet] Unable to render portlet java.lang.ClassCastException : org.apache.geronimo.security.realm.GenericSecurityRealm at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.renderList (SecurityRealmPortlet.java:565) at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.doView (SecurityRealmPortlet.java:256) ... Cheers! Hernan -- Thanks, Shiva -- Thanks, Shiva
Re: svn commit: r603936 - /geronimo/server/branches/2.0/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java
Thanks Prasad. I didn't realize I broke the tests with G1711. ++Vamsi On Dec 13, 2007 8:48 PM, [EMAIL PROTECTED] wrote: Author: prasad Date: Thu Dec 13 07:18:05 2007 New Revision: 603936 URL: http://svn.apache.org/viewvc?rev=603936view=rev Log: * edit link is now the 3rd link Modified: geronimo/server/branches/2.0/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java Modified: geronimo/server/branches/2.0/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.0/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java?rev=603936r1=603935r2=603936view=diff == --- geronimo/server/branches/2.0/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java (original) +++ geronimo/server/branches/2.0/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java Thu Dec 13 07:18:05 2007 @@ -52,7 +52,7 @@ String connectorSelector = //tr[2]/td[2]/table//tr[td[1] = \ + name + \]; -selenium.click(connectorSelector + /td[5]/a[2]); +selenium.click(connectorSelector + /td[5]/a[3]); selenium.waitForPageToLoad(3); selenium.type(port, 8008); @@ -60,7 +60,7 @@ selenium.waitForPageToLoad(3); assertTrue(selenium.isTextPresent(8008)); -selenium.click(connectorSelector + /td[5]/a[2]); +selenium.click(connectorSelector + /td[5]/a[3]); selenium.waitForPageToLoad(3); selenium.type(port, 8009);
[jira] Updated: (GERONIMO-1711) WebServer Connectors portlet should provide a restart option for connectors
[ https://issues.apache.org/jira/browse/GERONIMO-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-1711: -- Affects Version/s: 2.1 2.0.x Fix Version/s: (was: Wish List) 2.1 2.0.x WebServer Connectors portlet should provide a restart option for connectors - Key: GERONIMO-1711 URL: https://issues.apache.org/jira/browse/GERONIMO-1711 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.x, 2.1 WebServer Connectors portlet currently provides start, stop, edit and delete options. It does not provide a restart option for connectors that is already running. If any properties are edited, the changes are not reflected until the connector is stopped and started again. If one has to depend on this stop and start options clicked in succession, the admin console may not be accessible as soon as the connector is stopped and there is no way of issuing a start from admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1711) WebServer Connectors portlet should provide a restart option for connectors
[ https://issues.apache.org/jira/browse/GERONIMO-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-1711. - Resolution: Fixed Completed: At revision: 603211 in branches\2.0 and trunk. o Added a restart action for connectors WebServer Connectors portlet should provide a restart option for connectors - Key: GERONIMO-1711 URL: https://issues.apache.org/jira/browse/GERONIMO-1711 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Minor Fix For: 2.0.x, 2.1 WebServer Connectors portlet currently provides start, stop, edit and delete options. It does not provide a restart option for connectors that is already running. If any properties are edited, the changes are not reflected until the connector is stopped and started again. If one has to depend on this stop and start options clicked in succession, the admin console may not be accessible as soon as the connector is stopped and there is no way of issuing a start from admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Genesis 1.3
+0 ++Vamsi On Dec 11, 2007 5:22 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: +1 On Dec 11, 2007 10:58 AM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, a small change to Genesis was made to support a custom legal resource bundle for the GShell release. I'd like to get this out so we can get GShell out too. +1 -Release it +0 -Eh, whatever -1 -Um, no no no no no... --jason -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Make Yoko core orb a Yoko subproject.
+1 ++Vamsi On Dec 6, 2007 8:13 PM, Rick McGuire [EMAIL PROTECTED] wrote: The discussion thread has been out there long enough for comment, and those who have responded appear positive about the prospect. I think it's time to put this to a vote. The full proposal from Matt Hogstrom is attached at the end, but the basic proposal we're voting on implementing in Geronimo is: 1) Accept the Yoko core modules (corba spec, corba core implemenation, rmi spec and rmi implementation) as a subproject of Geronimo. 2) The Yoko subproject will be maintained as a stand-alone component so it can be used by Harmony as well as Geronimo. 3) Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join the Geronimo project as commiters so that they may continue contributing to the Yoko ORB. This is a single vote on the entire proposal (accepting the code and inviting the commiters). [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above. [ ] 0 No opinion [ ] -1 Do not implement the Yoko subproject as proposed. Only PMC member's votes are binding, but we invite anybody in the community to speak up and vote on this. Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern time on Monday. Rick Matt's full proposal presented to the Yoko project: The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF.
[jira] Closed: (GERONIMO-3654) Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
[ https://issues.apache.org/jira/browse/GERONIMO-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3654. - Resolution: Fixed Completed: At revision: 602089 o Copied o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers.NamedUsernamePasswordCredentialLoginModule o Marked NamedUPCredentialLoginModule as deprecated o Changed all references from o.a.g.s.jaas.NamedUPCredentialLoginModule to o.a.g.s.realm.providers.NamedUsernamePasswordCredentialLoginModule Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers --- Key: GERONIMO-3654 URL: https://issues.apache.org/jira/browse/GERONIMO-3654 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule extend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not the move breaks compatibility, should we consider this move only in trunk and not in branches\2.0? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3625) Review WrappingLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3625. - Resolution: Fixed Review WrappingLoginModule -- Key: GERONIMO-3625 URL: https://issues.apache.org/jira/browse/GERONIMO-3625 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review WrappingLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3650) Review ConfiguredIdentityNamedUsernamePasswordLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3650. - Resolution: Fixed Review ConfiguredIdentityNamedUsernamePasswordLoginModule - Key: GERONIMO-3650 URL: https://issues.apache.org/jira/browse/GERONIMO-3650 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review ConfiguredIdentityNamedUsernamePasswordLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3626) Review NamedUPCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3626. - Resolution: Fixed Review NamedUPCredentialLoginModule --- Key: GERONIMO-3626 URL: https://issues.apache.org/jira/browse/GERONIMO-3626 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review NamedUPCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3652) Review CallerIdentityPasswordCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3652. - Resolution: Fixed Review CallerIdentityPasswordCredentialLoginModule -- Key: GERONIMO-3652 URL: https://issues.apache.org/jira/browse/GERONIMO-3652 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: connector Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review CallerIdentityPasswordCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3640) Eliminate UPCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3640. - Resolution: Fixed Eliminate UPCredentialLoginModule - Key: GERONIMO-3640 URL: https://issues.apache.org/jira/browse/GERONIMO-3640 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 UPCredentialLoginModule seems to serve the same purpose as GeronimoPasswordCredentialLoginModule. Searching the codebase for references to UPCredentialLoginModule yields no results. Also GeronimoPasswordCredentialLoginModule is the one used by Security realms portlet. It may be a good idea to eliminate UPCredentialLoginModule and related classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3629) Review GeronimoPropertiesFileMappedPasswordCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3629. - Resolution: Fixed Review GeronimoPropertiesFileMappedPasswordCredentialLoginModule Key: GERONIMO-3629 URL: https://issues.apache.org/jira/browse/GERONIMO-3629 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review GeronimoPropertiesFileMappedPasswordCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3628) Review GeronimoPasswordCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3628. - Resolution: Fixed Review GeronimoPasswordCredentialLoginModule Key: GERONIMO-3628 URL: https://issues.apache.org/jira/browse/GERONIMO-3628 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review GeronimoPasswordCredentialLoginModule for potential violations and security risks. o LoginModule should remove/destroy credentials from subject upon logout. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3654) Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
[ https://issues.apache.org/jira/browse/GERONIMO-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549353 ] Vamsavardhana Reddy commented on GERONIMO-3654: --- On the second thought, I am planning to skip step 2 from the above. I will mark org.apache.geronimo.jaas.NamedUPCredentialLoginModule as deprecated only. We can remove the class from the codebase after the next release. Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers --- Key: GERONIMO-3654 URL: https://issues.apache.org/jira/browse/GERONIMO-3654 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule extend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not the move breaks compatibility, should we consider this move only in trunk and not in branches\2.0? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to get memory statistics from a remote Geronimo runtime?
On Dec 7, 2007 9:38 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 5, 2007, at 4:29 AM, Vamsavardhana Reddy wrote: On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: It is not clear to me if this is part of the earlier code or a separate program. If it is part of the JMX code, then Runtime is from the local jvm not remote. The non heap Memory for this program in either case is negligible. You could start G with -Dcom.sun.management.jmxremote. Start jconsole and click on the Memory tab to get the whole picture. I have started G with the said option and hooked up jconsole. The HeapMemoryUsage is showing exactly what Runtime is returning. It is only the heap memory exhaustion that results in OOME. I guess I am ok for now as this is what I am interested in. One will get OOM Exceptions if there is insufficient native memory to satisfy a Java request. For instance, when creating a thread, the OS has to allocate some native memory to create the Java Object. If that native allocation fails you will get an OOM even though you have plenty of heap memory. You are right. Any ideas on how to figure if we are exhausting that native memory?
Re: How to get memory statistics from a remote Geronimo runtime?
On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
It is not clear to me if this is part of the earlier code or a
separate program. If it is part of the JMX code, then Runtime is from
the local jvm not remote. The non heap Memory for this program in
either case is negligible.
You could start G with -Dcom.sun.management.jmxremote. Start
jconsole and click on the Memory tab to get the whole picture.
I have started G with the said option and hooked up jconsole. The
HeapMemoryUsage is showing exactly what Runtime is returning.
It is only the heap memory exhaustion that results in OOME. I guess I am ok
for now as this is what I am interested in.
Hope this is helpful
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know why the non heap memory is missing in the equations.
The
equations I gave are based what I observed by running the following
code.
MemoryMXBean memmxbean =
ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory.
In
other words you need to add contribution from non heap Memory to
all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from
Runtime.
Here is
the relationship I see between the stats from Runtime and those
got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() ==
MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct
way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : +
port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: How to get memory statistics from a remote Geronimo runtime?
I don't know if it is necessary to add the statistics from Runtime. Here is
the relationship I see between the stats from Runtime and those got from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() - MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() == MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Re: Deploying to multiple instances of G
On Dec 4, 2007 7:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Currently when an app is deployed to an instance of G (say A), it show up as 'stopped' in other instances. IIRC the relevant config.xml had load=false for this config. There shouldn't be any entry for this app in config.xml in the other instances of the server. Atleast it does not get added at deployment time. Even if it gets added with load=false, it does not result in a server startup failure whether or not the app is uninstalled from the server instance it is originally installed. If the app is deleted from A and all the servers are shutdown. The other servers can not be started (NoSuchConfigException) because the config (app) has been removed from the repository. What should be the correct behavior? If the app is installed from instance A and uninstalled from instance B then instance A is in trouble. I raised this concern a while ago and David Jencks said it is expected. As long as the app is installed and uninstalled from the same server instance, it should not (and does not currently) affect other instances. Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: How to get memory statistics from a remote Geronimo runtime?
I don't know why the non heap memory is missing in the equations. The
equations I gave are based what I observed by running the following code.
MemoryMXBean memmxbean = ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory. In
other words you need to add contribution from non heap Memory to all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from Runtime.
Here is
the relationship I see between the stats from Runtime and those got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() == MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Re: Deploying to multiple instances of G
Yes, the application can not be installed from other instances as all the instances are sharing the same repository. But, nothing prevents you from starting the app in the other instances. Only thing is that before you to uninstall the application from one instance, it has to be stopped in the other instances or else those instances will end up with startup failure. I have not experimented with each instance using its own repository for applications and using common repository for core components. In this case, one may have to use command line deployer and use the target option to specify the repo to which app is to be deployed. ++Vamsi On Dec 4, 2007 9:29 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: yes, I uninstalled it from the wrong server despite being aware of the behavior... Another version of the same problem is that the same app can not be deployed in another instance. am I correct? Thanks Anita --- Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On Dec 4, 2007 7:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Currently when an app is deployed to an instance of G (say A), it show up as 'stopped' in other instances. IIRC the relevant config.xml had load=false for this config. There shouldn't be any entry for this app in config.xml in the other instances of the server. Atleast it does not get added at deployment time. Even if it gets added with load=false, it does not result in a server startup failure whether or not the app is uninstalled from the server instance it is originally installed. If the app is deleted from A and all the servers are shutdown. The other servers can not be started (NoSuchConfigException) because the config (app) has been removed from the repository. What should be the correct behavior? If the app is installed from instance A and uninstalled from instance B then instance A is in trouble. I raised this concern a while ago and David Jencks said it is expected. As long as the app is installed and uninstalled from the same server instance, it should not (and does not currently) affect other instances. Thanks Anita Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC
Congratulations Jay! ++Vamsi On Dec 5, 2007 9:56 AM, Kevan Miller [EMAIL PROTECTED] wrote: All, Please join us in congratulating Jay McHugh as the newest member of the Geronimo PMC. It's been great to have Jay working with us as a committer on Geronimo. Even better to have him join us in providing oversight of the Geronimo project. Way to go Jay!!! The Apache Geronimo PMC --kevan
Re: How to get memory statistics from a remote Geronimo runtime?
On Dec 4, 2007 11:23 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
It is not clear to me if this is part of the earlier code or a
separate program. If it is part of the JMX code, then Runtime is from
the local jvm not remote. The non heap Memory for this program in
either case is negligible.
I got the code to run in a jsp. So, the statistics it shows are indeed from
Geronimo's JVM.
You could start G with -Dcom.sun.management.jmxremote. Start
jconsole and click on the Memory tab to get the whole picture.
Will try this. Thank you.
Hope this is helpful
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know why the non heap memory is missing in the equations.
The
equations I gave are based what I observed by running the following
code.
MemoryMXBean memmxbean =
ManagementFactory.getMemoryMXBean();
Runtime rt = Runtime.getRuntime();
MemoryUsage memUsage = memmxbean.getHeapMemoryUsage();
System.err.println(init=+memUsage.getInit());
System.err.println(max=+memUsage.getMax());
System.err.println(used=+memUsage.getUsed());
System.err.println(committed=+memUsage.getCommitted());
System.err.println(free=+(memUsage.getCommitted()-
memUsage.getUsed()));
System.err.println(TotalMemory = +rt.totalMemory());
System.err.println(MaxMemory = +rt.maxMemory());
System.err.println(FreeMemory = +rt.freeMemory());
System.err.println(Used=+(rt.totalMemory()-rt.freeMemory()));
++Vamsi
On Dec 4, 2007 8:57 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
IIUC,
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
runtime values are sum of values from Heap and non heap memory.
In
other words you need to add contribution from non heap Memory to
all 4
equations.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I don't know if it is necessary to add the statistics from
Runtime.
Here is
the relationship I see between the stats from Runtime and those
got
from
MemoryMXBean.getHeapMemoryUsage()
Runtime.totalMemory() == MemoryUsage.getCommitted()
Runtime.maxMemory() == MemoryUsage.getMax()
Runtime.freeMemory() == MemoryUsage.getCommitted() -
MemoryUsage.getUsed()
Runtime.totalMemory() - Runtime.freeMemory() ==
MemoryUsage.getUsed()
++Vamsi
On Dec 4, 2007 6:51 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
If you are interested in usedMemory and maxMemory as given by
Runtime, we could add that again. The JVM Stats give a rough
estimate
of heap memory only.
Thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct
way
to
get
maxHeapSize and usedMemory from a remote Geronimo server.
import
org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : +
port
+
/JMXConnector);
JMXConnector jmxConnector =
JMXConnectorFactory.connect(address,
map);
mbServerConnection =
jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats)
mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
How to get memory statistics from a remote Geronimo runtime?
I am wondering if the following (which works) is the correct way to get
maxHeapSize and usedMemory from a remote Geronimo server.
import org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user, password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector = JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName = ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats) mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic = (BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Re: How to get memory statistics from a remote Geronimo runtime?
That worked too. Thanks.
++Vamsi
On Dec 4, 2007 12:29 AM, Viet Nguyen [EMAIL PROTECTED] wrote:
You can do it that way or do it the JSR-77 way.
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.RemoteInitialContextFactory);
props.setProperty(Context.PROVIDER_URL,
ejbd://localhost:4201);
props.setProperty(Context.SECURITY_PRINCIPAL, username);
props.setProperty(Context.SECURITY_CREDENTIALS, password);
props.setProperty(openejb.authentication.realmName,
geronimo-admin);
InitialContext ctx = new InitialContext(p);
ManagementHome mejbHome =
(ManagementHome)ctx.lookup(ejb/mgmt/MEJBRemoteHome);
mejb = mejbHome.create();
Stats stats = (Stats)mejb.getAttribute(new
ObjectName(mbean_name_here), stats);
Hope this helps,
Viet Nguyen
On Dec 3, 2007 1:52 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
I am wondering if the following (which works) is the correct way to get
maxHeapSize and usedMemory from a remote Geronimo server.
import org.apache.geronimo.management.stats.BoundedRangeStatisticImpl;
Map map = new HashMap();
map.put(jmx.remote.credentials, new String[] {user,
password});
JMXServiceURL address = new JMXServiceURL(
service:jmx:rmi:///jndi/rmi://+host+ : + port +
/JMXConnector);
JMXConnector jmxConnector = JMXConnectorFactory.connect(address,
map);
mbServerConnection = jmxConnector.getMBeanServerConnection();
objName =
ObjectName.getInstance
(geronimo:J2EEServer=geronimo,name=JVM,j2eeType=JVM);
Stats stats = (Stats) mbServerConnection.getAttribute(objName,
stats);
BoundedRangeStatisticImpl statistic =
(BoundedRangeStatisticImpl)
stats.getStatistic(HeapSize);
long maxMemory = statistic.getUpperBound();
long usedMemory = statistic.getCurrent();
Is this ok? Or, is there a better way?
++Vamsi
Re: Apache Geronimo Context
Not clear what you want to know. Can you be more specific? ++Vamsi On Dec 3, 2007 11:11 PM, nezha [EMAIL PROTECTED] wrote: Hi, I want to kown how Apache Geronimo communicate with the other Applications and Servers, what does it use for this communication? I mean the different media, protocols and Data format, that Geronimo uses for the exanchange of information with its extern environment. Thank you -- View this message in context: http://www.nabble.com/Apache-Geronimo-Context-tf4938237s134.html#a14134941 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: basic security review
I think I have touched upon everything in the code base that seems to be a LoginModule implementation. Only thing that remains w.r.t LoginModules is the moving of NamedUPCredentialLoginModule to o.a.g.s.realm.providers. (I have not bothered about changing UPCredentialLoginModule as I have marked it deprecated. Let us wait for one release before deleting the deprecated LoginModule). I will call it a completion of one phase in security review. Thanks to David Jencks for refactoring the tests, it made adding new testcases much simpler. This should definitely help avoid any unwanted surprises like the one that resulted in G 2.0.1 and the one that crept in in the due course. One more thing that remains is updating the Wiki page to reflect all the LoginModules that have been reviewed (argh... I am feeling lazy :( ) There is definitely a lot more to be done. Let us keep the ball rolling. ++Vamsi On Oct 31, 2007 1:14 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I think we should create JIRAs for each review activity that results in code changes and update the wiki with the JIRA number. This way we will be able to track the progress on each activity in one central place. Also, add important points from this discussion thread to the wiki too. ++Vamsi On 10/30/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I agree. Our strategy to make Geronimo secure should include an elaborate set of unit testcases, a rich set of tests in the security-testsuite in our testsuite framework, along with peer review of code in components that are potential security risks. We should aim to have imbricate or maybe even duplicate tests than have gaps. Towards this end, I created a security-testsuite in our testsuite framework. It contains one test now. I shall add some more soon. Please contribute to this testsuite with more and more tests that you can think of. Thanx Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: A few security problems were discovered in Geronimo in the last few months and weeks. Most of them were Geronimo-specific except one. Therefore, I think we should spend a little bit of our time to review our code and check for potential security problems. As the first step, I think we should identify components that make security decisions (e.g. LoginModules) or enable access to server management and control (e.g. MEJB) or any other components that might be important for sever security. Once we have a few components identified we can start the review. Besides finding and fixing the potential security problems during the review we must also ensure that we have decent tests for these components that cover a range of inputs. For each problem that we do discover, we must write a test case to make sure it never happens again. Basically, a problem is not fully addressed until we have a test for it. For now, I created the following page where we can keep track of the components and the review: http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review Feel free to update it in any way. Opinions? Ideas? Thoughts? Jarek
[jira] Closed: (GERONIMO-3658) Review RepeatedFailureLockoutLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3658. - Resolution: Fixed Completed: At revision: 599857 o Changes to bring RepeatedFailureLockoutLoginModule in line with http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html Review RepeatedFailureLockoutLoginModule Key: GERONIMO-3658 URL: https://issues.apache.org/jira/browse/GERONIMO-3658 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review RepeatedFailureLockoutLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3657) Review FileAuditLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3657. - Resolution: Fixed Completed: At revision: 599854 o Changes to bring FileAuditLoginModule in line with http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html Review FileAuditLoginModule --- Key: GERONIMO-3657 URL: https://issues.apache.org/jira/browse/GERONIMO-3657 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review FileAuditLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3640) Eliminate UPCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547111 ] Vamsavardhana Reddy commented on GERONIMO-3640: --- For now, I have marked UPCredentialLoginModule as deprecated. We will remove the class from the codebase after the next release. Completed: At revision: 599796 o Marked UPCredentialLoginModule as deprecated. o Replaced the only reference to UPCredentialLoginModule in ConfigurationEntryTest with GeronimoPasswordCredentialLoginModule. Eliminate UPCredentialLoginModule - Key: GERONIMO-3640 URL: https://issues.apache.org/jira/browse/GERONIMO-3640 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 UPCredentialLoginModule seems to serve the same purpose as GeronimoPasswordCredentialLoginModule. Searching the codebase for references to UPCredentialLoginModule yields no results. Also GeronimoPasswordCredentialLoginModule is the one used by Security realms portlet. It may be a good idea to eliminate UPCredentialLoginModule and related classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3657) Review FileAuditLoginModule
Review FileAuditLoginModule --- Key: GERONIMO-3657 URL: https://issues.apache.org/jira/browse/GERONIMO-3657 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review FileAuditLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3641: -- Affects Version/s: (was: 2.0.x) (was: 2.1) Fix Version/s: (was: 2.0.x) (was: 2.1) Looks like there is nothing to be addressed here. My bad, this should have been an e-mail to dev-list instead of a JIRA :( NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule -- Key: GERONIMO-3641 URL: https://issues.apache.org/jira/browse/GERONIMO-3641 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Reporter: Vamsavardhana Reddy I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and NamedUPCredentialLoginModule are added to geronimo codebase around the same time (rev 159325 and rev 159560). The difference between the two is that NamedUPCredentialLoginModule uses the user supplied username and password where as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the username and password from options supplied to the login module. NamedUPCredentialLoginModule is used by the Security realms portlet whereas there are no references to ConfiguredIdentityNamedUsernamePasswordLoginModule in the codebase. I guess one of them (most likely ConfiguredIdentityNamedUsernamePasswordLoginModule) is redundant and it should be eliminated. What am I missing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3641. - Resolution: Invalid NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule -- Key: GERONIMO-3641 URL: https://issues.apache.org/jira/browse/GERONIMO-3641 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Reporter: Vamsavardhana Reddy I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and NamedUPCredentialLoginModule are added to geronimo codebase around the same time (rev 159325 and rev 159560). The difference between the two is that NamedUPCredentialLoginModule uses the user supplied username and password where as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the username and password from options supplied to the login module. NamedUPCredentialLoginModule is used by the Security realms portlet whereas there are no references to ConfiguredIdentityNamedUsernamePasswordLoginModule in the codebase. I guess one of them (most likely ConfiguredIdentityNamedUsernamePasswordLoginModule) is redundant and it should be eliminated. What am I missing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3658) Review RepeatedFailureLockoutLoginModule
Review RepeatedFailureLockoutLoginModule Key: GERONIMO-3658 URL: https://issues.apache.org/jira/browse/GERONIMO-3658 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review RepeatedFailureLockoutLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3648) Keystores portlet should provide for changing keystore and key passwords
Keystores portlet should provide for changing keystore and key passwords Key: GERONIMO-3648 URL: https://issues.apache.org/jira/browse/GERONIMO-3648 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, management, security Affects Versions: 2.0.2, 2.0.1, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Currently it is not possible to change either a keystore password or a key password in Geronimo. Keystores portlet should provide a way to change these passwords. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Administering geronimo remotely
On Nov 29, 2007 2:24 PM, David Jencks [EMAIL PROTECTED] wrote: On Nov 28, 2007, at 5:50 PM, Anita Kulshreshtha wrote: I am trying to administer a geronimo instance remotely using admin console. I can install jars to remote g instance using Repository link, i.e. the jar files from local file system get installed in remote g repo as expected. I tried a car and was able to install it too! I'm not entirely clear what you are saying here did you use the plugins page install the car file or the add a jar to the repo page? If a car is added from Common Libs portlet, it should not show up as a configuration. But, this is a different problem. I wouldn't expect the plugin page to work without additional infrastructure running, see below. This car (a J2EE Connector) showed up in stopped state, so I started it (using 'start' link on remote console). This caused a lifecycle operation failed ... org.apache.geronimo.kernel.config.NoSuchConfigException: error. Is this the expected behavior? if I select the local .m2 repo as plugin repository in plugins portlet, should I expect the selected plugin to be installed at the remote instance using jars/cars from the local files system? In order for this to work you'd need to have the local .m2 repository available on a web server to the remote machine and I think the plugins would generally have to say they are available from this web server in the geronimo-plugin.xml file. hope this helps... david jencks Thanks Anita __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
[jira] Commented: (GERONIMO-3640) Eliminate UPCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546819 ] Vamsavardhana Reddy commented on GERONIMO-3640: --- I am afraid this JIRA is not about NamedUPCredentialLoginModule, but about UPCredentialLoginModule which has the exact same function as GeronimoPasswordCredentialLoginModule. Is there any need to retain UPCredentialLoginModule? Eliminate UPCredentialLoginModule - Key: GERONIMO-3640 URL: https://issues.apache.org/jira/browse/GERONIMO-3640 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 UPCredentialLoginModule seems to serve the same purpose as GeronimoPasswordCredentialLoginModule. Searching the codebase for references to UPCredentialLoginModule yields no results. Also GeronimoPasswordCredentialLoginModule is the one used by Security realms portlet. It may be a good idea to eliminate UPCredentialLoginModule and related classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3650) Review ConfiguredIdentityNamedUsernamePasswordLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546847 ] Vamsavardhana Reddy commented on GERONIMO-3650: --- Completed: At revision: 599552 o logout() should destroy credentials when the subject is read-only. o Changes to bring ConfiguredIdentityNamedUsernamePasswordLoginModule in line with http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html **: This commit can use a thorough revision. Review ConfiguredIdentityNamedUsernamePasswordLoginModule - Key: GERONIMO-3650 URL: https://issues.apache.org/jira/browse/GERONIMO-3650 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review ConfiguredIdentityNamedUsernamePasswordLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3650) Review ConfiguredIdentityNamedUsernamePasswordLoginModule
Review ConfiguredIdentityNamedUsernamePasswordLoginModule - Key: GERONIMO-3650 URL: https://issues.apache.org/jira/browse/GERONIMO-3650 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review ConfiguredIdentityNamedUsernamePasswordLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3652) Review CallerIdentityPasswordCredentialLoginModule
Review CallerIdentityPasswordCredentialLoginModule -- Key: GERONIMO-3652 URL: https://issues.apache.org/jira/browse/GERONIMO-3652 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: connector Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review CallerIdentityPasswordCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3652) Review CallerIdentityPasswordCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546862 ] Vamsavardhana Reddy commented on GERONIMO-3652: --- Completed: At revision: 599565 o logout() should remove principals and credentials when the subject is not read-only. o Changes to bring CallerIdentityPasswordCredentialLoginModule in line with http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html **: This commit can use a thorough review. Review CallerIdentityPasswordCredentialLoginModule -- Key: GERONIMO-3652 URL: https://issues.apache.org/jira/browse/GERONIMO-3652 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: connector Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review CallerIdentityPasswordCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleto org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleextend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not this move breaks compatibility, should we consider this move only in trunk and not in branches\2.0. ++Vamsi
[jira] Created: (GERONIMO-3654) Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers --- Key: GERONIMO-3654 URL: https://issues.apache.org/jira/browse/GERONIMO-3654 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule extend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not the move breaks compatibility, should we consider this move only in trunk and not in branches\2.0? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
Created a JIRA https://issues.apache.org/jira/browse/GERONIMO-3654 for this. ++Vamsi On Nov 30, 2007 12:41 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleto org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleextend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not this move breaks compatibility, should we consider this move only in trunk and not in branches\2.0. ++Vamsi
[jira] Created: (GERONIMO-3639) Review SubjectRegistrationLoginModule
Review SubjectRegistrationLoginModule - Key: GERONIMO-3639 URL: https://issues.apache.org/jira/browse/GERONIMO-3639 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review SubjectRegistrationLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3639) Review SubjectRegistrationLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3639: -- Priority: Trivial (was: Major) Affects Version/s: (was: 2.0.x) (was: 2.1) Fix Version/s: (was: 2.0.x) (was: 2.1) Invalid since SubjectRegistrationLoginModule is no more. See GERONIMO-3407. At Revision: 598938 o Deleted SubjectRegistrationLoginModule.java that should have been deleted from branches\2.0 in rev 565936. Review SubjectRegistrationLoginModule - Key: GERONIMO-3639 URL: https://issues.apache.org/jira/browse/GERONIMO-3639 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Trivial Review SubjectRegistrationLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3639) Review SubjectRegistrationLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3639. - Resolution: Invalid Review SubjectRegistrationLoginModule - Key: GERONIMO-3639 URL: https://issues.apache.org/jira/browse/GERONIMO-3639 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Priority: Trivial Review SubjectRegistrationLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3407) SubjectRegistrationLoginModule conceptually can't work.
[ https://issues.apache.org/jira/browse/GERONIMO-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546201 ] Vamsavardhana Reddy commented on GERONIMO-3407: --- At Revision: 598938 o Deleted SubjectRegistrationLoginModule.java that should have been deleted from branches\2.0 in rev 565936. SubjectRegistrationLoginModule conceptually can't work. --- Key: GERONIMO-3407 URL: https://issues.apache.org/jira/browse/GERONIMO-3407 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0, 2.0.x, 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.1, 2.1 The idea of SubjectRegistrationLoginModule while attractive just can't work. The idea behind subject registration is that we want to compute the AccessControlContext for a subject once and cache it. That can only be done once the subject is fully populated by all login modules, so if the ACC is determined by a login module it must be the last one. However, if any previous LM is marked REQUISITE no further modules will be processed. Therefore we have to register the subjects in some other way. Just maybe we could preregister the subject but determine the ACC lazily?? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3640) Eliminate UPCredentialLoginModule
Eliminate UPCredentialLoginModule - Key: GERONIMO-3640 URL: https://issues.apache.org/jira/browse/GERONIMO-3640 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 UPCredentialLoginModule seems to serve the same purpose as GeronimoPasswordCredentialLoginModule. Searching the codebase for references to UPCredentialLoginModule yields no results. Also GeronimoPasswordCredentialLoginModule is the one used by Security realms portlet. It may be a good idea to eliminate UPCredentialLoginModule and related classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule
NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule -- Key: GERONIMO-3641 URL: https://issues.apache.org/jira/browse/GERONIMO-3641 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and NamedUPCredentialLoginModule are added to geronimo codebase around the same time (rev 159325 and rev 159560). The difference between the two is that NamedUPCredentialLoginModule uses the user supplied username and password where as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the username and password from options supplied to the login module. NamedUPCredentialLoginModule is used by the Security realms portlet whereas there are no references to ConfiguredIdentityNamedUsernamePasswordLoginModule in the codebase. I guess one of them (most likely ConfiguredIdentityNamedUsernamePasswordLoginModule) is redundant and it should be eliminated. What am I missing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3644) Adding a second TomcatContainer is resulting in IllegalArgumentException
Adding a second TomcatContainer is resulting in IllegalArgumentException Key: GERONIMO-3644 URL: https://issues.apache.org/jira/browse/GERONIMO-3644 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.0.2, 2.0.1, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 I have added a second TomcatContainer gbean to config.xml using the following xml: gbean gbeanInfo=org.apache.geronimo.tomcat.TomcatContainer name=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer attribute name=catalinaHomevar/catalina/attribute reference name=EngineGBean patternnameTomcatEngine/name/pattern /reference reference name=ServerInfo patternnameServerInfo/name/pattern /reference reference name=WebManager patternnameTomcatWebManager/name/pattern /reference /gbean Upon starting the server, I am getting an IllegalArgumentException. Exception is occurring since no name is set for defaultContext created around line 221 in TomcatContainer.java it is using a name which is an empty string. StackTrace is given below. 21:51:11,359 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer java.lang.IllegalArgumentException: addChild: Child name '' is not unique at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.geronimo.tomcat.TomcatContainer.doStart(TomcatContainer.java:232) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration
[jira] Closed: (GERONIMO-3644) Adding a second TomcatContainer is resulting in IllegalArgumentException
[ https://issues.apache.org/jira/browse/GERONIMO-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3644. - Resolution: Fixed Completed: At revision: 599076 o Made the defaultContext use a name instead of ''. Adding a second TomcatContainer is resulting in IllegalArgumentException Key: GERONIMO-3644 URL: https://issues.apache.org/jira/browse/GERONIMO-3644 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 I have added a second TomcatContainer gbean to config.xml using the following xml: gbean gbeanInfo=org.apache.geronimo.tomcat.TomcatContainer name=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer attribute name=catalinaHomevar/catalina/attribute reference name=EngineGBean patternnameTomcatEngine/name/pattern /reference reference name=ServerInfo patternnameServerInfo/name/pattern /reference reference name=WebManager patternnameTomcatWebManager/name/pattern /reference /gbean Upon starting the server, I am getting an IllegalArgumentException. Exception is occurring since no name is set for defaultContext created around line 221 in TomcatContainer.java it is using a name which is an empty string. StackTrace is given below. 21:51:11,359 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer java.lang.IllegalArgumentException: addChild: Child name '' is not unique at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.geronimo.tomcat.TomcatContainer.doStart(TomcatContainer.java:232) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean
Re: [jira] Commented: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule
Thanks for the clarification David. ++Vamsi On Nov 29, 2007 2:05 AM, David Jencks (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546376] David Jencks commented on GERONIMO-3641: ConfiguredIdentityNamedUsernamePasswordLoginModule is pretty much essential for the TCK. You use it in case you want to supply credentials for the server when its calling another server, e.g. a remote web service and you are relying on the server credentials rather than the user credentials. You can get a similar effect with a run-as where the run-as subject has been set up with NamedUPCredentialLoginModule but using ConfiguredIdentityNamedUsernamePasswordLoginModule means you can avoid the run-as. NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule -- Key: GERONIMO-3641 URL: https://issues.apache.org/jira/browse/GERONIMO-3641 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and NamedUPCredentialLoginModule are added to geronimo codebase around the same time (rev 159325 and rev 159560). The difference between the two is that NamedUPCredentialLoginModule uses the user supplied username and password where as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the username and password from options supplied to the login module. NamedUPCredentialLoginModule is used by the Security realms portlet whereas there are no references to ConfiguredIdentityNamedUsernamePasswordLoginModule in the codebase. I guess one of them (most likely ConfiguredIdentityNamedUsernamePasswordLoginModule) is redundant and it should be eliminated. What am I missing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3625) Review WrappingLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545164 ] Vamsavardhana Reddy commented on GERONIMO-3625: --- Completed: At revision: 597830 http://svn.apache.org/viewvc?rev=597830view=rev o Moving principal wrapping tests to a different testcase. **: This commit can use a thorough review. Review WrappingLoginModule -- Key: GERONIMO-3625 URL: https://issues.apache.org/jira/browse/GERONIMO-3625 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review WrappingLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3626) Review NamedUPCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3626: -- Issue Type: Task (was: Bug) Review NamedUPCredentialLoginModule --- Key: GERONIMO-3626 URL: https://issues.apache.org/jira/browse/GERONIMO-3626 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review NamedUPCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3625) Review WrappingLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3625: -- Issue Type: Task (was: Bug) Review WrappingLoginModule -- Key: GERONIMO-3625 URL: https://issues.apache.org/jira/browse/GERONIMO-3625 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review WrappingLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3627) LoginModule.logout() method should handle read-only subjects properly
LoginModule.logout() method should handle read-only subjects properly - Key: GERONIMO-3627 URL: https://issues.apache.org/jira/browse/GERONIMO-3627 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 logout() method in LoginModule implementation should handle read-only subjects properly and also reverse the effect of commit() on the subject by removing principals, remove/destroy credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
