[jira] Created: (GERONIMO-3710) Need to fully convert to generics to avoid CCE -- a dumb example
Need to fully convert to generics to avoid CCE -- a dumb example Key: GERONIMO-3710 URL: https://issues.apache.org/jira/browse/GERONIMO-3710 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 A user found a way to discover we were stashing both strings and files in a collection of stuff that can't be deleted. Caused by: java.lang.ClassCastException: java.io.File at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.cleanupConfigurationDir(EARConfigBuilder.java:694) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.cleanupContext(EARConfigBuilder.java:681) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3710) Need to fully convert to generics to avoid CCE -- a dumb example
[ https://issues.apache.org/jira/browse/GERONIMO-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3710. -- Resolution: Fixed This specific problem fixed in trunk rev 604800. There's plenty more non-generic code and no doubt plenty of similar errors. Need to fully convert to generics to avoid CCE -- a dumb example Key: GERONIMO-3710 URL: https://issues.apache.org/jira/browse/GERONIMO-3710 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 A user found a way to discover we were stashing both strings and files in a collection of stuff that can't be deleted. Caused by: java.lang.ClassCastException: java.io.File at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.cleanupConfigurationDir(EARConfigBuilder.java:694) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.cleanupContext(EARConfigBuilder.java:681) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Building with c:\Documents and Setting as .m2 repo
MY build is happy again.. Thanks Anita --- David Jencks [EMAIL PROTECTED] wrote: Do you know when the last time it worked was? Is this the normal m2 repo location on xp? I have a lot of local changes around this area that I'm hoping to get working and committed today: hopefully this will get fixed as part of those changes. thanks david jencks On Dec 14, 2007, at 8:35 AM, Anita Kulshreshtha wrote: I get following stack trace while building using c:\Documents and Setting as .m2 repo. This used to work.. Thanks Anita Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Missing artifact in repositories: [file:/C:/Documents%20and%20Settings//.m2/repository/] Missing dependency: org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/c ar at org.apache.geronimo.system.plugin.PluginInstallerGBean.findArtifact (Plugin InstallerGBean.java:1624) at org.apache.geronimo.system.plugin.PluginInstallerGBean.openStream (PluginIn stallerGBean.java:1424) at org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifac t(Pl uginInstallerGBean.java:10 Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [VOTE] Release GShell 1.0-alpha-1
+1 -Donald Jason Dillon wrote: Oh ya... the time is now, all you party people get out on the floor and shake what your mother gave ya... This is the *first* _official_ release of GShell... and I invite all of you to go an have a quick look over the only docs we got at the moment: http://cwiki.apache.org/GSHELL More docs are on there way I can assure you... as well as more features, functionality and fun with your command-line... aight! * * * GShell has been a dream of mine for... er um what seems like years now... oh wait it has been years. And well, the universe has finally aligned and things are falling into place quite nicely I'd say. Some external groups are already consuming these goodies, others have asked me about it, and there might even been some commercial apps wanting a simple/easy/kick-ass command-line (remote scriptable) interface to their application on the horizon too. If any of you remember the JBucks days, when I whittled Twiddle out of thin air as a pluggable command-line framework (only realized to invoke lame JMX muck)... well, GShell is here to carve out its own notch... or well, I hope it can get sharp enough to cut something. I think it will... just believe, imagine and well we make dreams reality her in the land of source which is open... na... aighty. Keep in mind this is an *alpha-1* release, and is a little rough (or in some cases more than a little) around the corners. I hope, with the help, guidance and suggestions of the community, that we can sort though all of the significant issues and polish GShell off enough to make it generally mass-consumable by applications (like ServiceMix, ActiveMQ, and other sister server-orient projects which need a sophisticated command-line interface for administration, configuration, whatever). This version of GShell was inspired a little (okay... a lot) by the work I've done on the Groovy projects 'groovysh' command-line tool ( http://groovy.codehaus.org/Groovy+Shell ). Actually working on 'groovysh' really helped me to figure out many things w/GShell... and maybe one day Groovy's 'groovysh' will actually use GShell as a framework, though there is a bit of work left in the core to make that a reality. For folks that haven't use my new 'groovysh', you can easily have a look by using the 'groovy-maven-plugin', as in: mvn groovy:shell You'll notice a lot of similarities between 'groovysh' and 'gsh' I'm sure. * * * While working on this release I've come to realize that GShell and Maven2 are very similar creatures... which I'll elaborate on more in the future... but because of that significant functionality which is already implemented in Maven2 is 90% (or sometimes more) compatible with the direction GShell is headed towards. For example, one feature alpha-2 will have is to allow command plugins to define 'dependencies' just as a Maven project does now. And GShell can be configured (a bit more flexibly than Maven ATM) for how to find those dependencies (in a local repo, in a remote repo, in some uber-jar, etc). This will all leverage the maturing Maven2 codebase. So in some ways GShell will grow with Maven2 as they both become more and more functional, stable, reliable... and well ass-kicking no doubt. Um... crap, I'm e-babbling again; sorry. So, lets vote and push this puppy out already... ?! +1Oh ya, come on baby... you know you want it +0Um... I don't know what is wrong with batch personally, can't we just use that? -1I like cheese, cheese makes me happy... but damn it cheese won't let me remotely administer my application... wtf, no way... WAIT So, its Friday evening, 6ish PST... so lets say _sometime_ on Tuesday the 25th I'll call the vote. That is a little more than 72 hours... so get your #2 pencils out and shake what your mother gave ya... --jason smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat webdav issue and Geronimo 2.1
I have a 6.0.13 + Geronimo patches + WebDAV fix that is ready to build
and upload to the repo if you want it
-Donald
Joe Bohn wrote:
G It looks like the updated tomcat image does not work. Some
TCK tests are failing. I might have to revert this change.
I know that I ran the servlet tests locally prior to the checkin but I
must have been using a different tomcat instance than the one I built. I
just looked at the merge conflicts again from Tomcat and noticed one
small thing that didn't look right. I fixed that but the tests are
still failing.
David Jencks - I might need your expert advice looking into the tomcat
changes and the TCK errors (see the tck list). I'll check in my latest
updated Tomcat patch.
Joe
Joe Bohn wrote:
I just checked in this upgrade in
http://svn.apache.org/viewvc?rev=603398view=rev
I hope it works (some quick testing looks promising).
After digging into this now for tomcat 6.0.14 I can safely say that we
really need to come up with a better way. IMO we need to get Tomcat
to integrate these annotation changes soon or revert back to using the
native Tomcat mechanisms to support annotations. At the moment Tomcat
still has the annotation changes sitting in their sandbox and the code
in their new trunk is drifting.
Here are steps that I followed to create the patch to save the manual
changes that were necessary so that we can recreate the tomcat image.
I checked these directions in as
repository/org/apache/tomcat/6.0.14-G602188.README.TXT
Private Build of Tomcat for
Geronimo. How to build Tomcat
6_0_14 with modifications for Geronimo:
Checkout tomcat 6.0.14
svn co
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14
tomcat_6_0_14
Apply the custom patch for Geronimo Annotation changes, Webdav fix,
and build fix.
cd tomcat_6_0_14
patch -p0 -u tomcat_6_0_14-G602188.patch (checked in as a peer
to this file)
- Respond y to the 3 prompts Reversed (or previously applied)
patch detected! Assume -R? [n]
svn delete java/org/apache/jasper/runtime/AnnotationHelper.java --force
svn delete java/org/apache/AnnotationProcessor.java --force
svn delete
java/org/apache/catalina/util/DefaultAnnotationProcessor.java --force
Build tomcat
cd tomcat_6_0_14
Per tomcat build instructions install ant-1.6.5 or later and set
ANT_HOME as well as add ant/bin to PATH
You must run as the super user for the first build that downloads
more ant eclipse artifacts
ant download - to setup build for tomcat
Exit super user
ant - to build tomcat artifacts
Copy to appropriate jars and rename into geronimo/repository
cd tomcat_6_0_14
cp /build/lib/catalina.jar
geronimo-root/repository/org/apache/tomcat/catalina/6.0.14-G602188/catalina-6.0.14-G602188.jar
cp /build/lib/jasper.jar
geronimo-root/repository/org/apache/tomcat/jasper/6.0.14-G602188/jasper-6.0.14-G602188.jar
How the patch was created:
Checkout tomcat 6.0.14
svn co
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14
tomcat_6_0_14
Apply annotation changes from old tomcat trunk
cd tomcat_6_0_14
svn merge -r 542188:542189
https://svn.apache.org/repos/asf/tomcat/sandbox/gdev6x/ .
manually correct merge conflicts
Apply the Webdav security fix from the new tomcat trunk
svn merge -r 587081:587082
https://svn.apache.org/repos/asf/tomcat/trunk/ .
manually correct merge conflicts
Fix the tomcat build properties before attempting ant download
- Before you can build tomcat you need to make some manual changes
to build.properties.default
- replace jdt.jar=${jdt.lib}/org.eclipse.jdt.core_3.2.3.v_686_R32x.jar
with jdt.jar=${jdt.lib}/org.eclipse.jdt.core_3.3.1.v_780_R33x.jar
and
- replace
jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.2.2-200702121330/eclipse-JDT-3.2.2.zip
with
jdt.loc=http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
The merge earlier keeps a history on added parts. As a result, the
added parts will not appear on patch created from this image. To correct
this we must revert the addition changes and manually add the parts
back. Perform the following commands:
svn revert java/org/apache/InstanceManager.java
svn addjava/org/apache/InstanceManager.java
svn revert java/org/apache/jasper/runtime/InstanceManagerFactory.java
snv addjava/org/apache/jasper/runtime/InstanceManagerFactory.java
svn revert java/org/apache/catalina/deploy/InjectionTarget.java
snv addjava/org/apache/catalina/deploy/InjectionTarget.java
Create the patch:
svn diff TOMCAT_6_0_14-G602188.patch
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Agree. We need a minimal runtime that doesn't include all of the cloning and gshell support, but which can have it added via plugins if someone wants it. -Donald Kevan Miller wrote: On Dec 3, 2007, at 8:04 PM, Gianny Damour wrote: On 04/12/2007, at 11:45 AM, Jason Dillon wrote: On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote: A bit harder to apples-to-apples compare the longer term growth. lib/gshell accounts for a 5 meg growth (unpacked). So, that would help account for most of the growth in the minimal assembly... I wonder if we should consider allowing gshell to be optional... I'd recommend *not*, though if we aren't happy with the additional bloat from the current impl, we can re-implement in pure-java and remove the dependency on Groovy. Its possible, though not very elegant IMO, as the AntBuilder syntax is ideal for launching new processes. Hi, I am actually quite a fan of Groovy commands and really would like Groovy to stick around. Beside the fact that the AntBuilder syntax is neat, Groovy commands could provide a very neat and simple way to dynamically introduce new commands w/o going through a compile cycle. I believe many Geronimo users are Java savvy enough, and hence also Groovy savvy enough to directly implement their commands in Groovy. It is in my understanding that gshell provides a gsh-bsf command (not tried, just read the code) and this is a first way to launch Groovy scripts; however, it would be great to directly map commands to groovy scripts out-of-the-box. Understood. Playing a bit of the devil's advocate here... A high percentage of Geronimo users will never create a custom Geronimo command, nor create or use GShell scripting capabilities. They'll want to start/stop Geronimo and deploy/undeploy applications. For these capabilities, geronimo-boilerplate-minimal-2.1.jar has grown by nearly 200% (3.0 meg - 8.3 meg). Also, most users will never generate new server assemblies. Yet, for this capability, we're increasing the minimal server size by 8.3 megs (essentially including the boilerplate-minimal jar twice). At the moment, minimal assembly has grown from 16 megs to 31 megs. IMO one of Geronimo's major advantages is that it's lightweight and flexible. We're still flexible, but we seem to have put on a few holiday pounds... I'd like to think about how we can slim things back down... --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat webdav issue and Geronimo 2.1
Thanks Donald. I have one as well (just haven't tested it yet). I
think I will check it in after I've verified the tests. At least we'll
have a fix for the webdav issue then even if we can't move up to a newer
tomcat for now.
Joe
Donald Woods wrote:
I have a 6.0.13 + Geronimo patches + WebDAV fix that is ready to build
and upload to the repo if you want it
-Donald
Joe Bohn wrote:
G It looks like the updated tomcat image does not work. Some
TCK tests are failing. I might have to revert this change.
I know that I ran the servlet tests locally prior to the checkin but I
must have been using a different tomcat instance than the one I built.
I just looked at the merge conflicts again from Tomcat and noticed one
small thing that didn't look right. I fixed that but the tests are
still failing.
David Jencks - I might need your expert advice looking into the tomcat
changes and the TCK errors (see the tck list). I'll check in my
latest updated Tomcat patch.
Joe
Joe Bohn wrote:
I just checked in this upgrade in
http://svn.apache.org/viewvc?rev=603398view=rev
I hope it works (some quick testing looks promising).
After digging into this now for tomcat 6.0.14 I can safely say that
we really need to come up with a better way. IMO we need to get
Tomcat to integrate these annotation changes soon or revert back to
using the native Tomcat mechanisms to support annotations. At the
moment Tomcat still has the annotation changes sitting in their
sandbox and the code in their new trunk is drifting.
Here are steps that I followed to create the patch to save the manual
changes that were necessary so that we can recreate the tomcat
image. I checked these directions in as
repository/org/apache/tomcat/6.0.14-G602188.README.TXT
Private Build of Tomcat for
Geronimo. How to build Tomcat
6_0_14 with modifications for Geronimo:
Checkout tomcat 6.0.14
svn co
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14
tomcat_6_0_14
Apply the custom patch for Geronimo Annotation changes, Webdav fix,
and build fix.
cd tomcat_6_0_14
patch -p0 -u tomcat_6_0_14-G602188.patch (checked in as a peer
to this file)
- Respond y to the 3 prompts Reversed (or previously applied)
patch detected! Assume -R? [n]
svn delete java/org/apache/jasper/runtime/AnnotationHelper.java
--force
svn delete java/org/apache/AnnotationProcessor.java --force
svn delete
java/org/apache/catalina/util/DefaultAnnotationProcessor.java --force
Build tomcat
cd tomcat_6_0_14
Per tomcat build instructions install ant-1.6.5 or later and set
ANT_HOME as well as add ant/bin to PATH
You must run as the super user for the first build that downloads
more ant eclipse artifacts
ant download - to setup build for tomcat
Exit super user
ant - to build tomcat artifacts
Copy to appropriate jars and rename into geronimo/repository
cd tomcat_6_0_14
cp /build/lib/catalina.jar
geronimo-root/repository/org/apache/tomcat/catalina/6.0.14-G602188/catalina-6.0.14-G602188.jar
cp /build/lib/jasper.jar
geronimo-root/repository/org/apache/tomcat/jasper/6.0.14-G602188/jasper-6.0.14-G602188.jar
How the patch was created:
Checkout tomcat 6.0.14
svn co
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14
tomcat_6_0_14
Apply annotation changes from old tomcat trunk
cd tomcat_6_0_14
svn merge -r 542188:542189
https://svn.apache.org/repos/asf/tomcat/sandbox/gdev6x/ .
manually correct merge conflicts
Apply the Webdav security fix from the new tomcat trunk
svn merge -r 587081:587082
https://svn.apache.org/repos/asf/tomcat/trunk/ .
manually correct merge conflicts
Fix the tomcat build properties before attempting ant download
- Before you can build tomcat you need to make some manual changes
to build.properties.default
- replace jdt.jar=${jdt.lib}/org.eclipse.jdt.core_3.2.3.v_686_R32x.jar
with jdt.jar=${jdt.lib}/org.eclipse.jdt.core_3.3.1.v_780_R33x.jar
and
- replace
jdt.loc=http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.2.2-200702121330/eclipse-JDT-3.2.2.zip
with
jdt.loc=http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
The merge earlier keeps a history on added parts. As a result, the
added parts will not appear on patch created from this image. To
correct
this we must revert the addition changes and manually add the parts
back. Perform the following commands:
svn revert java/org/apache/InstanceManager.java
svn addjava/org/apache/InstanceManager.java
svn revert java/org/apache/jasper/runtime/InstanceManagerFactory.java
snv addjava/org/apache/jasper/runtime/InstanceManagerFactory.java
svn revert java/org/apache/catalina/deploy/InjectionTarget.java
snv addjava/org/apache/catalina/deploy/InjectionTarget.java
Create the patch:
svn diff
[jira] Commented: (GERONIMO-3678) Monitoring console should accept a port no for server to be monitored
[ https://issues.apache.org/jira/browse/GERONIMO-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552454 ] Anita Kulshreshtha commented on GERONIMO-3678: -- It would be nice to have all server addresses displayed as IPaddr:portno in all the portlets. Monitoring console should accept a port no for server to be monitored - Key: GERONIMO-3678 URL: https://issues.apache.org/jira/browse/GERONIMO-3678 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Viet Hung Nguyen Fix For: 2.1 Attachments: geronimo-3678.patch Currently the Monitoring Console accepts an IP address for the server to be monitored. This works for default geronimo instances. For non default installations we need to be able to specify the EJB port.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release GShell 1.0-alpha-1
+1 Jacek On Dec 15, 2007 3:02 AM, Jason Dillon [EMAIL PROTECTED] wrote: Oh ya... the time is now, all you party people get out on the floor and shake what your mother gave ya... This is the *first* _official_ release of GShell... and I invite all of you to go an have a quick look over the only docs we got at the moment: http://cwiki.apache.org/GSHELL More docs are on there way I can assure you... as well as more features, functionality and fun with your command-line... aight! * * * GShell has been a dream of mine for... er um what seems like years now... oh wait it has been years. And well, the universe has finally aligned and things are falling into place quite nicely I'd say. Some external groups are already consuming these goodies, others have asked me about it, and there might even been some commercial apps wanting a simple/easy/kick-ass command-line (remote scriptable) interface to their application on the horizon too. If any of you remember the JBucks days, when I whittled Twiddle out of thin air as a pluggable command-line framework (only realized to invoke lame JMX muck)... well, GShell is here to carve out its own notch... or well, I hope it can get sharp enough to cut something. I think it will... just believe, imagine and well we make dreams reality her in the land of source which is open... na... aighty. Keep in mind this is an *alpha-1* release, and is a little rough (or in some cases more than a little) around the corners. I hope, with the help, guidance and suggestions of the community, that we can sort though all of the significant issues and polish GShell off enough to make it generally mass-consumable by applications (like ServiceMix, ActiveMQ, and other sister server-orient projects which need a sophisticated command-line interface for administration, configuration, whatever). This version of GShell was inspired a little (okay... a lot) by the work I've done on the Groovy projects 'groovysh' command-line tool ( http://groovy.codehaus.org/Groovy+Shell ). Actually working on 'groovysh' really helped me to figure out many things w/GShell... and maybe one day Groovy's 'groovysh' will actually use GShell as a framework, though there is a bit of work left in the core to make that a reality. For folks that haven't use my new 'groovysh', you can easily have a look by using the 'groovy-maven- plugin', as in: mvn groovy:shell You'll notice a lot of similarities between 'groovysh' and 'gsh' I'm sure. * * * While working on this release I've come to realize that GShell and Maven2 are very similar creatures... which I'll elaborate on more in the future... but because of that significant functionality which is already implemented in Maven2 is 90% (or sometimes more) compatible with the direction GShell is headed towards. For example, one feature alpha-2 will have is to allow command plugins to define 'dependencies' just as a Maven project does now. And GShell can be configured (a bit more flexibly than Maven ATM) for how to find those dependencies (in a local repo, in a remote repo, in some uber-jar, etc). This will all leverage the maturing Maven2 codebase. So in some ways GShell will grow with Maven2 as they both become more and more functional, stable, reliable... and well ass-kicking no doubt. Um... crap, I'm e-babbling again; sorry. So, lets vote and push this puppy out already... ?! +1 Oh ya, come on baby... you know you want it +0 Um... I don't know what is wrong with batch personally, can't we just use that? -1 I like cheese, cheese makes me happy... but damn it cheese won't let me remotely administer my application... wtf, no way... WAIT So, its Friday evening, 6ish PST... so lets say _sometime_ on Tuesday the 25th I'll call the vote. That is a little more than 72 hours... so get your #2 pencils out and shake what your mother gave ya... --jason -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [VOTE] Release GShell 1.0-alpha-1
+1 Source and binaries look good. Help command and error cases could be handled better. I'll raise alpha-2 jira's. --kevan On Dec 14, 2007, at 9:02 PM, Jason Dillon wrote: Oh ya... the time is now, all you party people get out on the floor and shake what your mother gave ya... This is the *first* _official_ release of GShell... and I invite all of you to go an have a quick look over the only docs we got at the moment: http://cwiki.apache.org/GSHELL More docs are on there way I can assure you... as well as more features, functionality and fun with your command-line... aight! * * * GShell has been a dream of mine for... er um what seems like years now... oh wait it has been years. And well, the universe has finally aligned and things are falling into place quite nicely I'd say. Some external groups are already consuming these goodies, others have asked me about it, and there might even been some commercial apps wanting a simple/easy/kick-ass command-line (remote scriptable) interface to their application on the horizon too. If any of you remember the JBucks days, when I whittled Twiddle out of thin air as a pluggable command-line framework (only realized to invoke lame JMX muck)... well, GShell is here to carve out its own notch... or well, I hope it can get sharp enough to cut something. I think it will... just believe, imagine and well we make dreams reality her in the land of source which is open... na... aighty. Keep in mind this is an *alpha-1* release, and is a little rough (or in some cases more than a little) around the corners. I hope, with the help, guidance and suggestions of the community, that we can sort though all of the significant issues and polish GShell off enough to make it generally mass-consumable by applications (like ServiceMix, ActiveMQ, and other sister server-orient projects which need a sophisticated command-line interface for administration, configuration, whatever). This version of GShell was inspired a little (okay... a lot) by the work I've done on the Groovy projects 'groovysh' command-line tool ( http://groovy.codehaus.org/Groovy+Shell ). Actually working on 'groovysh' really helped me to figure out many things w/GShell... and maybe one day Groovy's 'groovysh' will actually use GShell as a framework, though there is a bit of work left in the core to make that a reality. For folks that haven't use my new 'groovysh', you can easily have a look by using the 'groovy- maven-plugin', as in: mvn groovy:shell You'll notice a lot of similarities between 'groovysh' and 'gsh' I'm sure. * * * While working on this release I've come to realize that GShell and Maven2 are very similar creatures... which I'll elaborate on more in the future... but because of that significant functionality which is already implemented in Maven2 is 90% (or sometimes more) compatible with the direction GShell is headed towards. For example, one feature alpha-2 will have is to allow command plugins to define 'dependencies' just as a Maven project does now. And GShell can be configured (a bit more flexibly than Maven ATM) for how to find those dependencies (in a local repo, in a remote repo, in some uber- jar, etc). This will all leverage the maturing Maven2 codebase. So in some ways GShell will grow with Maven2 as they both become more and more functional, stable, reliable... and well ass-kicking no doubt. Um... crap, I'm e-babbling again; sorry. So, lets vote and push this puppy out already... ?! +1 Oh ya, come on baby... you know you want it +0 Um... I don't know what is wrong with batch personally, can't we just use that? -1 I like cheese, cheese makes me happy... but damn it cheese won't let me remotely administer my application... wtf, no way... WAIT So, its Friday evening, 6ish PST... so lets say _sometime_ on Tuesday the 25th I'll call the vote. That is a little more than 72 hours... so get your #2 pencils out and shake what your mother gave ya... --jason
[jira] Commented: (GERONIMO-3617) AsyncHttpClient should support retries on connection failures
[ https://issues.apache.org/jira/browse/GERONIMO-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552561 ] Sangjin Lee commented on GERONIMO-3617: --- The number of retries would probably be a parameter on the AsyncHttpClient instance itself, as it pertains more to the client app than individual requests. The default should be 0 (no retries). The natural place where this would be attempted I think is AsyncHttpClient.FutureListener. FutureListener is the listener on the connect future. There one can deal with successful connections as well as failures. One could maintain the retry count on the FutureListener, and call connect() until the retry count is exhausted. The FutureListener object could (and probably should) be reused for subsequent retry attempts to keep track of the count. 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-3711) NPE if connection fails and callback is not provided
NPE if connection fails and callback is not provided Key: GERONIMO-3711 URL: https://issues.apache.org/jira/browse/GERONIMO-3711 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Minor Callbacks are now optional as it is no longer the only way to handle the result from asynchronous requests. In the implementation, the callbacks are now included as part of completing the ResponseFuture. Thus, as the operations complete, the callbacks should be invoked (if set) inside ResponseFuture. If connection fails, the connect future object gets invoked, but the current connect future (AsyncHttpClient.FutureListener) contains direct calls to AsyncHttpClientCallback.onException(). There are two problems with this: (1) callbacks may be null, so this may result in NPE, and (2) future will not be completed if connection fails. The solution is to properly set the exception on the ResponseFuture, and that will take care of the callback invocation as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3711) NPE if connection fails and callback is not provided
[ https://issues.apache.org/jira/browse/GERONIMO-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3711: -- Attachment: 3711.patch a suggested patch NPE if connection fails and callback is not provided Key: GERONIMO-3711 URL: https://issues.apache.org/jira/browse/GERONIMO-3711 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Minor Attachments: 3711.patch Callbacks are now optional as it is no longer the only way to handle the result from asynchronous requests. In the implementation, the callbacks are now included as part of completing the ResponseFuture. Thus, as the operations complete, the callbacks should be invoked (if set) inside ResponseFuture. If connection fails, the connect future object gets invoked, but the current connect future (AsyncHttpClient.FutureListener) contains direct calls to AsyncHttpClientCallback.onException(). There are two problems with this: (1) callbacks may be null, so this may result in NPE, and (2) future will not be completed if connection fails. The solution is to properly set the exception on the ResponseFuture, and that will take care of the callback invocation as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release GShell 1.0-alpha-1
+1 david jencks On Dec 14, 2007, at 6:02 PM, Jason Dillon wrote: Oh ya... the time is now, all you party people get out on the floor and shake what your mother gave ya... This is the *first* _official_ release of GShell... and I invite all of you to go an have a quick look over the only docs we got at the moment: http://cwiki.apache.org/GSHELL More docs are on there way I can assure you... as well as more features, functionality and fun with your command-line... aight! * * * GShell has been a dream of mine for... er um what seems like years now... oh wait it has been years. And well, the universe has finally aligned and things are falling into place quite nicely I'd say. Some external groups are already consuming these goodies, others have asked me about it, and there might even been some commercial apps wanting a simple/easy/kick-ass command-line (remote scriptable) interface to their application on the horizon too. If any of you remember the JBucks days, when I whittled Twiddle out of thin air as a pluggable command-line framework (only realized to invoke lame JMX muck)... well, GShell is here to carve out its own notch... or well, I hope it can get sharp enough to cut something. I think it will... just believe, imagine and well we make dreams reality her in the land of source which is open... na... aighty. Keep in mind this is an *alpha-1* release, and is a little rough (or in some cases more than a little) around the corners. I hope, with the help, guidance and suggestions of the community, that we can sort though all of the significant issues and polish GShell off enough to make it generally mass-consumable by applications (like ServiceMix, ActiveMQ, and other sister server-orient projects which need a sophisticated command-line interface for administration, configuration, whatever). This version of GShell was inspired a little (okay... a lot) by the work I've done on the Groovy projects 'groovysh' command-line tool ( http://groovy.codehaus.org/Groovy+Shell ). Actually working on 'groovysh' really helped me to figure out many things w/GShell... and maybe one day Groovy's 'groovysh' will actually use GShell as a framework, though there is a bit of work left in the core to make that a reality. For folks that haven't use my new 'groovysh', you can easily have a look by using the 'groovy-maven-plugin', as in: mvn groovy:shell You'll notice a lot of similarities between 'groovysh' and 'gsh' I'm sure. * * * While working on this release I've come to realize that GShell and Maven2 are very similar creatures... which I'll elaborate on more in the future... but because of that significant functionality which is already implemented in Maven2 is 90% (or sometimes more) compatible with the direction GShell is headed towards. For example, one feature alpha-2 will have is to allow command plugins to define 'dependencies' just as a Maven project does now. And GShell can be configured (a bit more flexibly than Maven ATM) for how to find those dependencies (in a local repo, in a remote repo, in some uber-jar, etc). This will all leverage the maturing Maven2 codebase. So in some ways GShell will grow with Maven2 as they both become more and more functional, stable, reliable... and well ass-kicking no doubt. Um... crap, I'm e-babbling again; sorry. So, lets vote and push this puppy out already... ?! +1 Oh ya, come on baby... you know you want it +0 Um... I don't know what is wrong with batch personally, can't we just use that? -1 I like cheese, cheese makes me happy... but damn it cheese won't let me remotely administer my application... wtf, no way... WAIT So, its Friday evening, 6ish PST... so lets say _sometime_ on Tuesday the 25th I'll call the vote. That is a little more than 72 hours... so get your #2 pencils out and shake what your mother gave ya... --jason
Re: [VOTE] Release GShell 1.0-alpha-1
+1 Joe Jason Dillon wrote: Oh ya... the time is now, all you party people get out on the floor and shake what your mother gave ya... This is the *first* _official_ release of GShell... and I invite all of you to go an have a quick look over the only docs we got at the moment: http://cwiki.apache.org/GSHELL More docs are on there way I can assure you... as well as more features, functionality and fun with your command-line... aight! * * * GShell has been a dream of mine for... er um what seems like years now... oh wait it has been years. And well, the universe has finally aligned and things are falling into place quite nicely I'd say. Some external groups are already consuming these goodies, others have asked me about it, and there might even been some commercial apps wanting a simple/easy/kick-ass command-line (remote scriptable) interface to their application on the horizon too. If any of you remember the JBucks days, when I whittled Twiddle out of thin air as a pluggable command-line framework (only realized to invoke lame JMX muck)... well, GShell is here to carve out its own notch... or well, I hope it can get sharp enough to cut something. I think it will... just believe, imagine and well we make dreams reality her in the land of source which is open... na... aighty. Keep in mind this is an *alpha-1* release, and is a little rough (or in some cases more than a little) around the corners. I hope, with the help, guidance and suggestions of the community, that we can sort though all of the significant issues and polish GShell off enough to make it generally mass-consumable by applications (like ServiceMix, ActiveMQ, and other sister server-orient projects which need a sophisticated command-line interface for administration, configuration, whatever). This version of GShell was inspired a little (okay... a lot) by the work I've done on the Groovy projects 'groovysh' command-line tool ( http://groovy.codehaus.org/Groovy+Shell ). Actually working on 'groovysh' really helped me to figure out many things w/GShell... and maybe one day Groovy's 'groovysh' will actually use GShell as a framework, though there is a bit of work left in the core to make that a reality. For folks that haven't use my new 'groovysh', you can easily have a look by using the 'groovy-maven-plugin', as in: mvn groovy:shell You'll notice a lot of similarities between 'groovysh' and 'gsh' I'm sure. * * * While working on this release I've come to realize that GShell and Maven2 are very similar creatures... which I'll elaborate on more in the future... but because of that significant functionality which is already implemented in Maven2 is 90% (or sometimes more) compatible with the direction GShell is headed towards. For example, one feature alpha-2 will have is to allow command plugins to define 'dependencies' just as a Maven project does now. And GShell can be configured (a bit more flexibly than Maven ATM) for how to find those dependencies (in a local repo, in a remote repo, in some uber-jar, etc). This will all leverage the maturing Maven2 codebase. So in some ways GShell will grow with Maven2 as they both become more and more functional, stable, reliable... and well ass-kicking no doubt. Um... crap, I'm e-babbling again; sorry. So, lets vote and push this puppy out already... ?! +1Oh ya, come on baby... you know you want it +0Um... I don't know what is wrong with batch personally, can't we just use that? -1I like cheese, cheese makes me happy... but damn it cheese won't let me remotely administer my application... wtf, no way... WAIT So, its Friday evening, 6ish PST... so lets say _sometime_ on Tuesday the 25th I'll call the vote. That is a little more than 72 hours... so get your #2 pencils out and shake what your mother gave ya... --jason
Re: [VOTE] Release GShell 1.0-alpha-1
I want to test building it. This must be trunk? Regards, Alan On Dec 14, 2007, at 6:02 PM, Jason Dillon wrote: Oh ya... the time is now, all you party people get out on the floor and shake what your mother gave ya... This is the *first* _official_ release of GShell... and I invite all of you to go an have a quick look over the only docs we got at the moment: http://cwiki.apache.org/GSHELL More docs are on there way I can assure you... as well as more features, functionality and fun with your command-line... aight! * * * GShell has been a dream of mine for... er um what seems like years now... oh wait it has been years. And well, the universe has finally aligned and things are falling into place quite nicely I'd say. Some external groups are already consuming these goodies, others have asked me about it, and there might even been some commercial apps wanting a simple/easy/kick-ass command-line (remote scriptable) interface to their application on the horizon too. If any of you remember the JBucks days, when I whittled Twiddle out of thin air as a pluggable command-line framework (only realized to invoke lame JMX muck)... well, GShell is here to carve out its own notch... or well, I hope it can get sharp enough to cut something. I think it will... just believe, imagine and well we make dreams reality her in the land of source which is open... na... aighty. Keep in mind this is an *alpha-1* release, and is a little rough (or in some cases more than a little) around the corners. I hope, with the help, guidance and suggestions of the community, that we can sort though all of the significant issues and polish GShell off enough to make it generally mass-consumable by applications (like ServiceMix, ActiveMQ, and other sister server-orient projects which need a sophisticated command-line interface for administration, configuration, whatever). This version of GShell was inspired a little (okay... a lot) by the work I've done on the Groovy projects 'groovysh' command-line tool ( http://groovy.codehaus.org/Groovy+Shell ). Actually working on 'groovysh' really helped me to figure out many things w/GShell... and maybe one day Groovy's 'groovysh' will actually use GShell as a framework, though there is a bit of work left in the core to make that a reality. For folks that haven't use my new 'groovysh', you can easily have a look by using the 'groovy- maven-plugin', as in: mvn groovy:shell You'll notice a lot of similarities between 'groovysh' and 'gsh' I'm sure. * * * While working on this release I've come to realize that GShell and Maven2 are very similar creatures... which I'll elaborate on more in the future... but because of that significant functionality which is already implemented in Maven2 is 90% (or sometimes more) compatible with the direction GShell is headed towards. For example, one feature alpha-2 will have is to allow command plugins to define 'dependencies' just as a Maven project does now. And GShell can be configured (a bit more flexibly than Maven ATM) for how to find those dependencies (in a local repo, in a remote repo, in some uber- jar, etc). This will all leverage the maturing Maven2 codebase. So in some ways GShell will grow with Maven2 as they both become more and more functional, stable, reliable... and well ass-kicking no doubt. Um... crap, I'm e-babbling again; sorry. So, lets vote and push this puppy out already... ?! +1 Oh ya, come on baby... you know you want it +0 Um... I don't know what is wrong with batch personally, can't we just use that? -1 I like cheese, cheese makes me happy... but damn it cheese won't let me remotely administer my application... wtf, no way... WAIT So, its Friday evening, 6ish PST... so lets say _sometime_ on Tuesday the 25th I'll call the vote. That is a little more than 72 hours... so get your #2 pencils out and shake what your mother gave ya... --jason
