Re: svn commit: r594117 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/src/main/assembly/ assemblies/geronimo-jetty6-javaee5/src/main/resources/cluster-repository/ assemblies/ge
Hi Kevan, I just fixed the encryption problem when writing the password JavaBean property to config.xml. I am still contemplating the following ideas to restrict access to this GBean attribute as it contains sensitive information: * for JMX access, I believe we could wrap the MBeanServer used under the cover of our JMXConnectorServer with an MBeanServerForwarder restricting access to sensitive information based on the client subject and the targeted GBean types, names, attributes et cetera. This way administrators will be able to provide finer grained access to the GBeans within a Geronimo instance. * for in-server access, I am really not sure how to proceed. It seems to me that application developers could deploy malicious applications to Geronimo and obtain through them sensitive information. For instance, I could deploy an application searching for a ClusterInfo GBean or a specific connector GBean in order to gain access to JMX credentials and database credentials (I assume there is a connector GBean storing this information in-memory in order to create physical database connections) respectively. Any ideas on how to proceed? Thanks, Gianny On 15/11/2007, at 7:43 AM, Gianny Damour wrote: Hi Kevan, Sorry for my late reply and thanks for raising this security issue. I believe that the encryption of password attributes is not enough in this case as password in this case is an XML JavaBean attribute; based on a cursory review of GBeanOverride, it seems that this case is not yet handled. I will fix this problem tonight or in the next couple of days. Thanks, Gianny On 15/11/2007, at 6:54 AM, Kevan Miller wrote: On Nov 13, 2007 4:40 PM, Kevan Miller [EMAIL PROTECTED] wrote: Hi Gianny, I notice that this scheme is storing admin username and password in clear text. It will also make the username/password accessible via JMX. I think we need to avoid this. Would prefer to see this information handled in a manner more consistent with our handling of sensitive information in var/security. Would you agree? David Jencks reminded me that 'password' properties in config.xml will be encrypted. --kevan
[BUILD] 2.0: Failed for Revision: 596560
Geronimo Revision: 596560 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/build-0300.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071120 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 23 minutes 55 seconds [INFO] Finished at: Tue Nov 20 03:29:29 EST 2007 [INFO] Final Memory: 200M/1002M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/logs-0300/test.log [INFO] Running console-testsuite.basic-console [INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.428 sec FAILURE! [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec FAILURE! -- [INFO] Running corba-testsuite.corba-mytime [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec FAILURE! [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec FAILURE! [INFO] Running deployment-testsuite.jca-cms [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec FAILURE! [INFO] Running enterprise-testsuite.jms [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec FAILURE! [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec FAILURE! [INFO] Running web-testsuite.jsps [INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec FAILURE! [INFO] Running web-testsuite.myfaces [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec FAILURE! -- [INFO] Running web-testsuite.security [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec FAILURE! [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec FAILURE! [INFO] Running web-testsuite.servlets [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec FAILURE!
[jira] Created: (GERONIMO-3611) Deployer should provide an install-library option to upload jars to repository
Deployer should provide an install-library option to upload jars to repository Key: GERONIMO-3611 URL: https://issues.apache.org/jira/browse/GERONIMO-3611 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment, usability Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Currently the only way to upload a library jar into repo is by using Common Libs portlet in Admin Console. Adding an install-library option to deployer should be helpful in uploading dependency jars to server's repo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Distribution and start/stop of clustered deployments
On 17/11/2007, at 12:30 AM, Kevan Miller wrote: On Nov 13, 2007, at 9:36 PM, Gianny Damour wrote: Hi Joe, After some investigations, here is my understanding of problem 1: there are two deployments because by default, i.e. when no target is specified, the distribute command executes against all the configuration stores defined by a Geronimo instance. Note that this default behavior is also applied by other deployment components, such as the hot directory scanner or the installation portlet. To some extent, I believe this default behavior should be changed to deploy to only one configuration store. Indeed, I am not convinced that users distributing applications would expect their applications to be deployed as many times as the number of configuration stores defined by the targeted Geronimo server. Also, having the same configuration multiple times in a Geronimo instance does not make a lot of sense. A potentially better default behavior would be: only distribute to the first target returned by DeploymentManager.getTargets(). Internally, our implementation of getTargets returns as the first target the default configuration store. Problem 3) is caused by problem 1). What do you think? Hi Gianny, That seems like reasonable behavior. I haven't looked closely at this, yet. I'm curious about how list- modules would work. I'm also wondering about plugin installation, console support, etc. Have they been updated appropriately to reflect your multiple config store scheme? Hi Joe, I created a JIRA to track this change of behavior and will soon commit the change. Regarding the list-modules command, it lists all the configurations per target, i.e. configuration store. Thanks, Gianny --kevan
[jira] Created: (GERONIMO-3612) When no target configuration store is explicitly specified while installing a configuration, the configuration should be installed to a default configuration store
When no target configuration store is explicitly specified while installing a configuration, the configuration should be installed to a default configuration store --- Key: GERONIMO-3612 URL: https://issues.apache.org/jira/browse/GERONIMO-3612 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.0.x When a configuration is installed, either via the command line or via various portlets, and no configuration store is explicitly selected, it is installed to all the configuration stores defined by the server. A more reasonable behavior is to install this configuration to a single configuration store, which is explicitly configured as the default configuration store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 596660
Geronimo Revision: 596660 built with tests included See the full build-0900.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/build-0900.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071120 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 30 minutes 58 seconds [INFO] Finished at: Tue Nov 20 09:35:54 EST 2007 [INFO] Final Memory: 200M/1003M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/logs-0900/test.log [INFO] Running console-testsuite.basic-console [INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.445 sec FAILURE! [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.207 sec FAILURE! -- [INFO] Running corba-testsuite.corba-mytime [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec FAILURE! [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec FAILURE! [INFO] Running deployment-testsuite.jca-cms [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec FAILURE! [INFO] Running enterprise-testsuite.jms [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.043 sec FAILURE! [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec FAILURE! [INFO] Running web-testsuite.jsps [INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.087 sec FAILURE! [INFO] Running web-testsuite.myfaces [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec FAILURE! -- [INFO] Running web-testsuite.security [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec FAILURE! [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec FAILURE! [INFO] Running web-testsuite.servlets [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec FAILURE!
[jira] Assigned: (GSHELL-70) Boolean options should be able to take an optional argument to negate, ie. --foo=false
[
https://issues.apache.org/jira/browse/GSHELL-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-70:
--
Assignee: Jason Warner
Boolean options should be able to take an optional argument to negate, ie.
--foo=false
--
Key: GSHELL-70
URL: https://issues.apache.org/jira/browse/GSHELL-70
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Support - CLP
Reporter: Jason Dillon
Assignee: Jason Warner
Fix For: 1.0-alpha-2
Boolean options, like:
{code:java}
@Option(name=-f, aliases={--foo})
private boolean foo;
{code}
Should support negation with:
{noformat}
--foo=false
{noformat}
or:
{noformat}
-f=false
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r596542 - in /geronimo/server/trunk: framework/modules/geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ framework/modules/geronimo-service-builder/src/tes
This is a change to an existing and published schema. I think that needs its own new file and namespace. Jarek Modified: geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd?rev=596542r1=596541r2=596542view=diff == --- geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd (original) +++ geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd Mon Nov 19 21:25:27 2007 @@ -183,6 +183,19 @@ /xsd:documentation /xsd:annotation /xsd:attribute +xsd:attribute name=propertyEditor use=optional type=xsd:string +xsd:annotation +xsd:documentation +The propertyEditor attribute defines the property editor class +to be used to get the value of this attribute based on its +string representation. + +If no editor is specified, then the type of the attribute, as +declared by GBeanAttribute, is used to find a propertyEditor +through the standard JavaBean search strategy. +/xsd:documentation +/xsd:annotation +/xsd:attribute !--xsd:attribute name=value use=optional-- !--xsd:annotation-- !--xsd:documentation--
[ANNOUNCE] Erik Craig as Geronimo's most recent committer
Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats, Erik! On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
On Nov 20, 2007, at 11:45 AM, Matt Hogstrom wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Congrats Erik! --kevan
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congratulations and welcome! Jay Matt Hogstrom wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik! Welcome aboard. Regards, Alan On Nov 20, 2007, at 8:45 AM, Matt Hogstrom wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
[Discuss] Schema changes (Re: svn commit: r596542)
The 1.2 schema managed to sneak into the 2.0.x releases - but nothing is actually referencing it. Until you get to 2.1.x (trunk) all of the programs still refer to 1.1. So, we should probably figure out whether or not we need to jump up to 1.3 or if we can stay on 1.2. And, this would make a good opportunity to find out if anyone has any additional changes that they would like to make to the schema. Regardless of whether or not we need to change the schema version immediately - we should be releasing 2.1 soon, and it would be better to get as many changes as possible into the schema now rather than burning though lots of version numbers. So, does anyone else have a take on new elements that should be added to the schema and whether or not we need to freeze 1.2? Jay Jarek Gawor wrote: This is a change to an existing and published schema. I think that needs its own new file and namespace. Jarek Modified: geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd?rev=596542r1=596541r2=596542view=diff == --- geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd (original) +++ geronimo/server/trunk/framework/modules/geronimo-system/src/main/xsd/attributes-1.2.xsd Mon Nov 19 21:25:27 2007 @@ -183,6 +183,19 @@ /xsd:documentation /xsd:annotation /xsd:attribute +xsd:attribute name=propertyEditor use=optional type=xsd:string +xsd:annotation +xsd:documentation +The propertyEditor attribute defines the property editor class +to be used to get the value of this attribute based on its +string representation. + +If no editor is specified, then the type of the attribute, as +declared by GBeanAttribute, is used to find a propertyEditor +through the standard JavaBean search strategy. +/xsd:documentation +/xsd:annotation +/xsd:attribute !--xsd:attribute name=value use=optional-- !--xsd:annotation-- !--xsd:documentation--
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik!! ++Vamsi On Nov 20, 2007 10:15 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik!!! welcome aboard Cheers! Hernan Matt Hogstrom wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik! Jarek On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: svn: Can't move source to dest on Windows
yeah, the comma is also a problem. Cheers! Hernan Vamsavardhana Reddy wrote: There is also a comma in the filename!! Should that be got rid of too? ++Vamsi On Nov 20, 2007 1:27 AM, Jarek Gawor [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: SVN checkout on Windows is failing for me becuase recently a file was renamed to have : in the name. That's not supported on Windows. Can we change this back? Here's the change: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/ http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/ Here's the error I'm seeing: svn: In directory 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d' svn: Can't move source to dest svn: Can't move 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server, default.groovy.svn-base' to 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base': No such file or directory Jarek
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Way to go Erik! Congrats! Joe Jason Warner wrote: Congrats, Erik! On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Mr. Craig! Best wishes, Paul On Nov 20, 2007, at 11:45 AM, Matt Hogstrom wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt
Re: [Discuss] Schema changes (Re: svn commit: r596542)
On Nov 20, 2007, at 9:39 AM, Jay D. McHugh wrote: The 1.2 schema managed to sneak into the 2.0.x releases - but nothing is actually referencing it. Until you get to 2.1.x (trunk) all of the programs still refer to 1.1. So, we should probably figure out whether or not we need to jump up to 1.3 or if we can stay on 1.2. Although I may have lost track of my activities :-) I think I've been happily updating the 1.2 schema under the impression that it wasn't in use yet. So I'm fine with keeping the 1.2 version for g 2.1. And, this would make a good opportunity to find out if anyone has any additional changes that they would like to make to the schema. Regardless of whether or not we need to change the schema version immediately - we should be releasing 2.1 soon, and it would be better to get as many changes as possible into the schema now rather than burning though lots of version numbers. Even better would be a version-number-free way of dealing with these schemas and their evolution. I don't have any ideas. Does anyone else? So, does anyone else have a take on new elements that should be added to the schema and whether or not we need to freeze 1.2? I'll keep looking for new elements and think we can keep changing 1.2 until g. 2.1 is released. thanks david jencks Jay Jarek Gawor wrote: This is a change to an existing and published schema. I think that needs its own new file and namespace. Jarek Modified: geronimo/server/trunk/framework/modules/geronimo-system/ src/main/xsd/attributes-1.2.xsd URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/ modules/geronimo-system/src/main/xsd/attributes-1.2.xsd? rev=596542r1=596541r2=596542view=diff == --- geronimo/server/trunk/framework/modules/geronimo-system/src/ main/xsd/attributes-1.2.xsd (original) +++ geronimo/server/trunk/framework/modules/geronimo-system/src/ main/xsd/attributes-1.2.xsd Mon Nov 19 21:25:27 2007 @@ -183,6 +183,19 @@ /xsd:documentation /xsd:annotation /xsd:attribute +xsd:attribute name=propertyEditor use=optional type=xsd:string +xsd:annotation +xsd:documentation +The propertyEditor attribute defines the property editor class +to be used to get the value of this attribute based on its +string representation. + +If no editor is specified, then the type of the attribute, as +declared by GBeanAttribute, is used to find a propertyEditor +through the standard JavaBean search strategy. +/xsd:documentation +/xsd:annotation +/xsd:attribute !--xsd:attribute name=value use=optional-- !--xsd:annotation-- !--xsd:documentation--
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Very nice, congratulations Erik !! Jason Warner wrote: Congrats, Erik! On Nov 20, 2007 11:45 AM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt -- Thanks, Tim McConnell
[jira] Created: (GERONIMO-3613) setConnectionTimeout() does not change the connect timeout on the connector
setConnectionTimeout() does not change the connect timeout on the connector --- Key: GERONIMO-3613 URL: https://issues.apache.org/jira/browse/GERONIMO-3613 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee AsyncHttpClient.setConnectionTimeout() does not change the connect timeout on the connector. The SocketConnector object is instantiated in the AsyncHttpClient constructor, and the connectTimeout instance variable is applied to the configuration in the AsyncHttpClient constructor, and is never used subsequently. setConnectionTimeout() has no effect, and getConnectionTimeout() returns a misleading value as a result. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
On Nov 20, 2007 5:45 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Yay! It's been a while since we could welcome a new committer and hence my warm welcome doubled. Welcome Erik! Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Updated: (GERONIMO-3613) setConnectionTimeout() does not change the connect timeout on the connector
[ https://issues.apache.org/jira/browse/GERONIMO-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3613: -- Attachment: AsyncHttpClient.patch A suggested patch setConnectionTimeout() does not change the connect timeout on the connector --- Key: GERONIMO-3613 URL: https://issues.apache.org/jira/browse/GERONIMO-3613 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: AsyncHttpClient.patch AsyncHttpClient.setConnectionTimeout() does not change the connect timeout on the connector. The SocketConnector object is instantiated in the AsyncHttpClient constructor, and the connectTimeout instance variable is applied to the configuration in the AsyncHttpClient constructor, and is never used subsequently. setConnectionTimeout() has no effect, and getConnectionTimeout() returns a misleading value as a result. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3614) the executor in AsyncHttpClient is static, and may not be shut down properly
the executor in AsyncHttpClient is static, and may not be shut down properly Key: GERONIMO-3614 URL: https://issues.apache.org/jira/browse/GERONIMO-3614 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee The threadPool variable in AsyncHttpClient (that gets passed to Mina for I/O) is declared as static, and I believe it is a bug. If you instantiate more than one AsyncHttpClient objects, subsequent instantiations overwrite the value of threadPool. It appears it is the responsibility of AsyncHttpClient, not the caller of AsyncHttpClient, to shut down the thread pool. It means then, if you instantiated multiple AsyncHttpClient objects, and call destroyAll() on all of them, only the thread pool that is associated with the last AsyncHttpClient object will be properly shut down. All previous thread pools will linger. The fix should be to turn it into an instance variable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Distribution and start/stop of clustered deployments
Gianny Damour wrote: On 17/11/2007, at 12:30 AM, Kevan Miller wrote: On Nov 13, 2007, at 9:36 PM, Gianny Damour wrote: Hi Joe, After some investigations, here is my understanding of problem 1: there are two deployments because by default, i.e. when no target is specified, the distribute command executes against all the configuration stores defined by a Geronimo instance. Note that this default behavior is also applied by other deployment components, such as the hot directory scanner or the installation portlet. To some extent, I believe this default behavior should be changed to deploy to only one configuration store. Indeed, I am not convinced that users distributing applications would expect their applications to be deployed as many times as the number of configuration stores defined by the targeted Geronimo server. Also, having the same configuration multiple times in a Geronimo instance does not make a lot of sense. A potentially better default behavior would be: only distribute to the first target returned by DeploymentManager.getTargets(). Internally, our implementation of getTargets returns as the first target the default configuration store. Problem 3) is caused by problem 1). What do you think? Hi Gianny, That seems like reasonable behavior. I haven't looked closely at this, yet. I'm curious about how list-modules would work. I'm also wondering about plugin installation, console support, etc. Have they been updated appropriately to reflect your multiple config store scheme? Hi Joe, I created a JIRA to track this change of behavior and will soon commit the change. Hi Gianny, Sorry for the delay ... somehow I missed this response. Yes, I think that default configuration store approach makes sense. Thanks for opening the JIRA. I presume that a deploy would have to specify the configuration store if it were other than the default, correct? Regarding the list-modules command, it lists all the configurations per target, i.e. configuration store. As Kevan also pointed out, I think that we need to consider the multiple configuration stores in the console when more than one is present for display and deploy (including plugins) as well as the CLI. With your changes proposed above I would presume that they would always work with the default configuration store (the first one returned) until they can be updated to support multiple. Thanks, Gianny --kevan
[jira] Updated: (GERONIMO-3614) the executor in AsyncHttpClient is static, and may not be shut down properly
[ https://issues.apache.org/jira/browse/GERONIMO-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3614: -- Attachment: AsyncHttpClient.patch a suggested fix the executor in AsyncHttpClient is static, and may not be shut down properly Key: GERONIMO-3614 URL: https://issues.apache.org/jira/browse/GERONIMO-3614 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: AsyncHttpClient.patch The threadPool variable in AsyncHttpClient (that gets passed to Mina for I/O) is declared as static, and I believe it is a bug. If you instantiate more than one AsyncHttpClient objects, subsequent instantiations overwrite the value of threadPool. It appears it is the responsibility of AsyncHttpClient, not the caller of AsyncHttpClient, to shut down the thread pool. It means then, if you instantiated multiple AsyncHttpClient objects, and call destroyAll() on all of them, only the thread pool that is associated with the last AsyncHttpClient object will be properly shut down. All previous thread pools will linger. The fix should be to turn it into an instance variable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 596797
Geronimo Revision: 596797 built with tests included See the full build-1500.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/build-1500.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071120 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 30 minutes 1 second [INFO] Finished at: Tue Nov 20 15:39:06 EST 2007 [INFO] Final Memory: 200M/1002M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/logs-1500/test.log [INFO] Running console-testsuite.basic-console [INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.451 sec FAILURE! [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.237 sec FAILURE! -- [INFO] Running corba-testsuite.corba-mytime [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec FAILURE! [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec FAILURE! [INFO] Running deployment-testsuite.jca-cms [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec FAILURE! [INFO] Running enterprise-testsuite.jms [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec FAILURE! [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec FAILURE! [INFO] Running web-testsuite.jsps [INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.095 sec FAILURE! [INFO] Running web-testsuite.myfaces [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec FAILURE! -- [INFO] Running web-testsuite.security [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec FAILURE! [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.05 sec FAILURE! [INFO] Running web-testsuite.servlets [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec FAILURE!
[jira] Created: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future
AsyncHttpClient.sendRequest() should return a future Key: GERONIMO-3615 URL: https://issues.apache.org/jira/browse/GERONIMO-3615 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Currently the caller gets notified when the I/O is completed via AsyncHttpClientCallback. While this works for many use cases, there may be situations where sendRequest() returning a future would lead to a much more straightforward programming model. This will become much more powerful especially if one initiates requests to multiple URLs at once. I would request that sendRequest() return a future object on which one can query the status of the operation, and also obtain the result or an error case (exception or timeout) by calling methods on the future. It is desirable to have the return type implement java.util.concurrent.Future. Furthermore, the implementation class of the Future could retain the reference to the callback. Then one can have a consolidated and coherent mechanism of completion (callbacks firing as a result of future completion). In other words, the suggestion is to change the return type of sendRequest() from void to java.util.concurrent.FutureHttpResponseMessage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3616) AsyncHttpClient should support a batch invocation method
AsyncHttpClient should support a batch invocation method Key: GERONIMO-3616 URL: https://issues.apache.org/jira/browse/GERONIMO-3616 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee It is desirable to have a method on AsyncHttpClient that submits multiple URLs at once. For example, public void sendRequests(HttpRequestMessage[] requests); One would expect it to initiate all HTTP requests as soon as possible in a non-blocking manner and return. Furthermore, it would be even more powerful if it returned a list of futures or a completion queue of results. One idea would be to return something like a completion queue (blocking) so that results or futures are added as they are completed. In other words, public BlockingQueueHttpResponseMessage sendRequests(HttpRequestMessage[] requests); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures
AsyncHttpClient should support retries on connection failures - Key: GERONIMO-3617 URL: https://issues.apache.org/jira/browse/GERONIMO-3617 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee AsyncHttpClient should provide a way to support retries if initial connection attempts fail. There should be a configuration where connection retries are enabled and also the maximum number of attempts is specified. If these are set, connection attempts should be retried. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3618: -- Attachment: HttpIoHandler.patch a suggested fix when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: HttpIoHandler.patch If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3619) Allow context-param's to be overridden in geronimo-web.xml
Allow context-param's to be overridden in geronimo-web.xml -- Key: GERONIMO-3619 URL: https://issues.apache.org/jira/browse/GERONIMO-3619 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.x, 2.1 Reporter: Kevan Miller Priority: Minor Fix For: Wish List A user on our dev list requested the ability to override context-params specified in a web.xml deployment descriptor. Tomcat supports this capability. Allowing the params to be overridden allows users to deploy a war file without having to alter the contents of the war. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congratulations Erik! Welcome aboard Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
[BUILD] 2.0: Failed for Revision: 596898
Geronimo Revision: 596898 built with tests included See the full build-2100.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/build-2100.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071120 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 31 minutes 48 seconds [INFO] Finished at: Tue Nov 20 21:36:52 EST 2007 [INFO] Final Memory: 200M/1003M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071120/logs-2100/test.log [INFO] Running console-testsuite.basic-console [INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.428 sec FAILURE! [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.201 sec FAILURE! -- [INFO] Running corba-testsuite.corba-mytime [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec FAILURE! [INFO] Running deployment-testsuite.deployment [INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec FAILURE! [INFO] Running deployment-testsuite.jca-cms [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec FAILURE! [INFO] Running enterprise-testsuite.jms [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.043 sec FAILURE! [INFO] Running jpa-testsuite.jpa [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec FAILURE! [INFO] Running sec-testsuite.security [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec FAILURE! [INFO] Running web-testsuite.jsps [INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.076 sec FAILURE! [INFO] Running web-testsuite.myfaces [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec FAILURE! -- [INFO] Running web-testsuite.security [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec FAILURE! [INFO] Running web-testsuite.references [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec FAILURE! [INFO] Running web-testsuite.servlets [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec FAILURE!
Re: [ANNOUNCE] Erik Craig as Geronimo's most recent committer
Congrats Erik! On 11/20/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Please extend a welcome to Erik Craig who is the latest committer to be added to the Geronimo fold. Erik has had a sustained and continued track record in working on the J2G conversion tool as well as his recent work on monitoring with Anita. and others. Give it up for Mr Craig ! Matt -- Thanks, Shiva
