[BUILD] 2.1: Failed for Revision: 604123
OpenEJB trunk at 604115 Geronimo Revision: 604123 built with tests included See the full build-0300.log file at http://people.apache.org/~prasad/binaries/trunk/20071214/build-0300.log [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-20071214.081732-33.pom 2K downloaded [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-javaagent/3.0.0-SNAPSHOT/openejb-javaagent-3.0.0-20071214.081732-33.pom 2K downloaded [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-ejbd/3.0.0-SNAPSHOT/openejb-ejbd-3.0.0-20071214.081732-30.pom 4K downloaded [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-server/3.0.0-SNAPSHOT/openejb-server-3.0.0-20071214.081732-30.pom 2K downloaded [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-loader/3.0.0-SNAPSHOT/openejb-loader-3.0.0-20071214.081732-33.pom 1K downloaded [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-client/3.0.0-SNAPSHOT/openejb-client-3.0.0-20071214.081732-30.pom 3K downloaded [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. [EMAIL PROTECTED] [INFO] [compiler:compile] [INFO] Compiling 21 source files to /home/prasad/geronimo/trunk/plugins/openejb/geronimo-openejb/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/prasad/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[358,21] cannot find symbol symbol : method createEjbJar(org.apache.openejb.assembler.classic.EjbJarInfo,org.apache.openejb.assembler.classic.LinkResolverjavax.persistence.EntityManagerFactory,java.lang.ClassLoader) location: class org.apache.openejb.assembler.classic.Assembler /home/prasad/geronimo/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[358,21] cannot find symbol symbol : method createEjbJar(org.apache.openejb.assembler.classic.EjbJarInfo,org.apache.openejb.assembler.classic.LinkResolverjavax.persistence.EntityManagerFactory,java.lang.ClassLoader) location: class
Re: structure of GShell commands
The structure is just for namespace, you can arrange commands however
you like... one of the benefits of GShell.
I just setup the structure, cause I'm anal and I organize
everything... er except my bedroom, which is a huge cluster*uck.
* * *
My _recommendation_ is to have some sort of organization... though it
doesn't need to be geronimo/*...
Assuming that the configuration of GShell is specific to Geronimo,
then lets consider what someone using the interface might want/expect/
need? But also keep in mind that they are free to drop in other
commands, like the BSF scripting bits (the 'script' command) or the
VFS commands (currently only 'copy') or remote support ('remote-
shell', 'rsh', 'remote-shell-server', 'rshd').
I'm not sure what the right organization is really... cause we are
just getting things rolling in this direction.
So I say we take a stab at what we *think* folks want, then do it...
and make changes later as needed. IMO there is no reason not to
change something if we are making it easier/better.
--jason
On Dec 13, 2007, at 5:22 AM, Matt Hogstrom wrote:
If GShell would be targeted at more servers than G then I think
these commands should be under geronimo. If not, then I think a
flat structure makes sense.
On Dec 11, 2007, at 10:04 AM, Kevan Miller wrote:
We currently have the following structure for Geronimo GShell
commands:
geronimo/
start-server
stop-server
start-client
deploy/
install-library
disconnect
deploy
...
This doesn't make much sense to me. Let's either assume GShell is
used for Geronimo server or assume that GShell can be used for
multiple target environments, but not both...
I think the current deploy/ commands should be under the geronimo
tree. What do others think? I think applying a bit more structure,
now, will minimize entropy over time...
Anybody want to have a shot at proposing a command structure?
--kevan
[jira] Closed: (GSHELL-74) Update/include license/notice and other legal muck
[ https://issues.apache.org/jira/browse/GSHELL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-74. -- Resolution: Fixed Update/include license/notice and other legal muck -- Key: GSHELL-74 URL: https://issues.apache.org/jira/browse/GSHELL-74 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Blocker Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
GShell legal muck
Hey Kevan, I *think*... nay, *hope* the GShell legal files are now all in order. I've added the NOTICE and LICENSE for gshell-embeddable, gshell-diet-log4j has some custom bits and the rest are all using the legal-bundle from Genesis via the m-r-r-p. I'm going to deploy a new set of artifacts. Can you please review? I've committed a few other minor changes, might add a few more, but I think we are 95% (or more) ready for release. So if you can review the legal files and give me the nod, then I will spin up a vote. :-) --jason PS. I've been up all night hacking on stuff, so I'll probs not be around until later tonight.
[jira] Closed: (GSHELL-86) command groups in help screen
[ https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-86. -- Resolution: Fixed Okay, I've stripped of the leading /... but really this command needs a healthy looking at and a swift kick in the rear. I think with the next release the path stuff (or sub-shell) whatever it be, should be better sorted out and we can fix this command then. command groups in help screen - Key: GSHELL-86 URL: https://issues.apache.org/jira/browse/GSHELL-86 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Reporter: Jarek Gawor Fix For: 1.0-alpha-1 The help screen shows the following: ... /deploy list-plugins Install plugins into a geronimo server connect Connect to a Geronimo server disconnectDisconnect from a Geronimo server .. which I would interpret that I need to type /deploy/connect to execute the command. But that does not work but deploy/connect works. So I would propose updating the help screen to show the slash at the end of the group name instead of the front. e.g.: ... deploy/ list-plugins Install plugins into a geronimo server connect Connect to a Geronimo server disconnectDisconnect from a Geronimo server .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-86) command groups in help screen
[
https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551837
]
Guillaume Nodet commented on GSHELL-86:
---
{quote}
My point is though that I've been working insolation with-out input for a while
on this stuff, so some of the ways GShell works are just based on my own
preferences and whatever. I do want to make GShell as easy to use a possible
and make it be able to do just about anything that someone wants in a cli app.
{quote}
Well, that's the reason why I explained what we did in ServiceMix, though I
don't want to destabilize gshell at the moment, so we did whatever we needed in
ServiceMix (just very small changes in gshell where absolutely needed).
The main problem we have is that we are working in an OSGi environment where
commands are dynamically discovered, so the idea of having a layout described
by an xml file just does not work for us. What we came up with is having a
single class implementing the CommandRegistry and the LayoutManager. The
layout is updated dynamically when commands are registered.
command groups in help screen
-
Key: GSHELL-86
URL: https://issues.apache.org/jira/browse/GSHELL-86
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Reporter: Jarek Gawor
Fix For: 1.0-alpha-1
The help screen shows the following:
...
/deploy
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
which I would interpret that I need to type /deploy/connect to execute the
command. But that does not work but deploy/connect works. So I would
propose updating the help screen to show the slash at the end of the group
name instead of the front. e.g.:
...
deploy/
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-86) command groups in help screen
[
https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551830
]
Jason Dillon commented on GSHELL-86:
Sooo... the only significant difference, is that instead of:
{noformat}
obr info
{noformat}
You would:
{noformat}
obr/info
{noformat}
Or if you like:
{noformat}
obr
info
{noformat}
But... please *do* keep the thoughts and ideas coming in!!! GShell ASIS is
basically what I had been dreaming about since the JBucks 3.x days w/Twiddle
(and what I really wanted to have in G 1.0, but eh...).
My point is though that I've been working insolation with-out input for a while
on this stuff, so some of the ways GShell works are just based on my own
preferences and whatever. I do want to make GShell as *easy* to use a possible
and make it be able to do *just about anything* that someone wants in a cli app.
So... lets see if we can make it work for everyone :-)
command groups in help screen
-
Key: GSHELL-86
URL: https://issues.apache.org/jira/browse/GSHELL-86
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Reporter: Jarek Gawor
Fix For: 1.0-alpha-1
The help screen shows the following:
...
/deploy
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
which I would interpret that I need to type /deploy/connect to execute the
command. But that does not work but deploy/connect works. So I would
propose updating the help screen to show the slash at the end of the group
name instead of the front. e.g.:
...
deploy/
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-97) License and Notice info for gshell-embeddable
[ https://issues.apache.org/jira/browse/GSHELL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-97. -- Resolution: Fixed Using some groovy muck and static LICENSE and NOTICE files for this... maybe one day we can make the templates do our bidding, but for now... a wee bit of build magic and the problem is solved. License and Notice info for gshell-embeddable - Key: GSHELL-97 URL: https://issues.apache.org/jira/browse/GSHELL-97 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Build Affects Versions: 1.0-alpha-1 Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.0-alpha-1 Attachments: embeddableLicense.txt, embeddableNotice.txt gshell-embeddable needs to License and Notice files to be included in the jar file. I'm not sure how to add these when using the shade plugin. Hoping Jason D can lend a hand. Will attach the license and notice files to this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-86) command groups in help screen
[
https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551828
]
Jason Dillon commented on GSHELL-86:
So the point of the path and tree muck in GShell is to facilitate this
_sub-shell_ idea, so that a _sub-shell_ is simply a namespace for commands.
And when you enter the name of a path (which exists) then the current path is
set to that path, changing the name-space and effectively entering that
sub-shell.
BTW, you are free to re-implement the {{help}} command and bind in your own
version that behaves better for your application in the layout :-)
command groups in help screen
-
Key: GSHELL-86
URL: https://issues.apache.org/jira/browse/GSHELL-86
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Reporter: Jarek Gawor
Fix For: 1.0-alpha-1
The help screen shows the following:
...
/deploy
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
which I would interpret that I need to type /deploy/connect to execute the
command. But that does not work but deploy/connect works. So I would
propose updating the help screen to show the slash at the end of the group
name instead of the front. e.g.:
...
deploy/
list-plugins Install plugins into a geronimo server
connect Connect to a Geronimo server
disconnectDisconnect from a Geronimo server
..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Greetings from Japan Apache Geronimo User Group
I think it would be a good idea to some pointers to groups like this on our web site. What do others think? Any other user groups/translation sights that are out there? --kevan On Nov 26, 2007, at 7:57 PM, 石田 剛 wrote: Hello, everyone. This is the Greetings from Japan Apache Geronimo User Group. http://geronimo-jp.sourceforge.jp/ We, Japan Apache Geronimo User Group , are virtual community of the Geronimo-lovers. We have more than 50 members as of today, and the communiy is managed on a volunteer basis. We really appreciate and thank you for your great work, and efforts. Just to let you know, some of the members in our group would like to start translating the Geronimo Tech Docs into Japanese. We're in a preparation phase, and it may take some time, but our goal is publishing the translated docs to Geronimo Wiki. ( Another goal is , of cource, having fun ! as we're all volunteers and having fun in the community ) You can reach us at [EMAIL PROTECTED](to all members) or [EMAIL PROTECTED] (to translation members) I just wanted to say hello and thank you , and make a formal greetings. Lastly, please keep on the good works like it has been ! Regards. New Design Yahoo! JAPAN 2008/01/01
[jira] Commented: (GSHELL-86) command groups in help screen
[ https://issues.apache.org/jira/browse/GSHELL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551839 ] Jason Dillon commented on GSHELL-86: Understood... and thank you :-) So for alpha-1 we are basically sorted only the smallest changes are going in. Hopefully will release in a day or so... er I mean start a vote in a day or so. * * * I will start to write up some roadmap documentation, kinda like a brain-dump for what I'm thinking, maybe some crude UML or sketches too... so that we can have some discussion around whats going to change for alpha-2... and how it will keep working for your needs, Geronimos needs... and still make me feel happy that GShell will dominate the universe in due time :-) command groups in help screen - Key: GSHELL-86 URL: https://issues.apache.org/jira/browse/GSHELL-86 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Reporter: Jarek Gawor Fix For: 1.0-alpha-1 The help screen shows the following: ... /deploy list-plugins Install plugins into a geronimo server connect Connect to a Geronimo server disconnectDisconnect from a Geronimo server .. which I would interpret that I need to type /deploy/connect to execute the command. But that does not work but deploy/connect works. So I would propose updating the help screen to show the slash at the end of the group name instead of the front. e.g.: ... deploy/ list-plugins Install plugins into a geronimo server connect Connect to a Geronimo server disconnectDisconnect from a Geronimo server .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3706) support for proxy
support for proxy - Key: GERONIMO-3706 URL: https://issues.apache.org/jira/browse/GERONIMO-3706 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Proxy support is a critical feature for HTTP clients. I'd like to have AsyncHttpClient support proxy. The following would be considered as the basic features: - Enabling connecting through proxies for http and https targets - Exclusion (domains that should not go through proxies) - Allowing proxy related configuration on AsyncHttpClient - Support for proxy authentication, at least for Basic authentication (and perhaps Digest too?) There are things like SOCKS support, etc., but the above will be a good start. Thoughts? -- 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
This is probably my fault. 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:1021) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInsta llerGBean.java:675) at org.apache.geronimo.mavenplugins.car.InstallModulesMojo.doExecute (InstallM odulesMojo.java:163) at org.codehaus.mojo.pluginsupport.MojoSupport.execute (MojoSupport.java:122) ... 18 more [INFO] -- -- [INFO] Total time: 29 seconds [INFO] Finished at: Fri Dec 14 10:45:06 EST 2007 [INFO] Final Memory: 50M/254M [INFO] -- -- __ __ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http:// mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Building with c:\Documents and Setting as .m2 repo
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.downloadArtifact(Pl uginInstallerGBean.java:1021) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInsta llerGBean.java:675) at org.apache.geronimo.mavenplugins.car.InstallModulesMojo.doExecute(InstallM odulesMojo.java:163) at org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:122) ... 18 more [INFO] [INFO] Total time: 29 seconds [INFO] Finished at: Fri Dec 14 10:45:06 EST 2007 [INFO] Final Memory: 50M/254M [INFO] Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[jira] Commented: (GERONIMO-3706) support for proxy
[ https://issues.apache.org/jira/browse/GERONIMO-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551890 ] Sangjin Lee commented on GERONIMO-3706: --- I suspect the most challenging aspect would be connecting to https targets via proxy. This requires SSL tunneling by layering sockets, and I'm not sure how accommodating Mina will be in this regard... HTTP proxy should be quite straightforward in contrast. support for proxy - Key: GERONIMO-3706 URL: https://issues.apache.org/jira/browse/GERONIMO-3706 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Proxy support is a critical feature for HTTP clients. I'd like to have AsyncHttpClient support proxy. The following would be considered as the basic features: - Enabling connecting through proxies for http and https targets - Exclusion (domains that should not go through proxies) - Allowing proxy related configuration on AsyncHttpClient - Support for proxy authentication, at least for Basic authentication (and perhaps Digest too?) There are things like SOCKS support, etc., but the above will be a good start. Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
GShell 1.0-alpha-1 release update
Folks, the majority of the issues (mostly legal muck) and a few small bugs/improvements have been cleaned up for the 1.0-alpha-1 release of GShell. There is one issue which has been pointed out regarding the 'help' command, which ATM is less than ideal, but does show the information. The idea of the 'help' command is to be sort of a combination of 'ls' and 'man', so that running it with no argument shows the commands available in the current context, and running with an argument, the argument is assumed to be a command path, which is resolved and the help docs for the command are displayed. To make this work is a little bit more than a minor change, and I've planned to get it fixed up for the next version (hopefully in a few months)... and really, this is a moderately complex command which is well suited for someone wanting to learn more about how GShell works to tackle (which another reason why I didn't make it all super-uber- sexy). BUT... I think we really need to get 1.0-alpha-1 released, so it can be consumed by G 2.1 (as well as other projects which are starting to use GShell). And IMO, the 'help' commands ugliness is not a big enough priority to delay the release. IMO, GShell is still a work in progress, while quite functional for many purposes, its still a little rough around the edges and will take some more love to sift through the issues, flesh out the features and iron those pesky buggers out. My recommendation is that for G 2.1 that we don't advertise GShell as a _feature_, but just let it be ASIS, handling the CLI bits for G and average users won't really know the difference. Advanced folks might want to play with it, which is fine (good even to get more feedback), but I don't think that G 2.1 is the release where we want to unleash this on to the world. I would rather let GShell cook... and then simmer for a while longer, pull in more feedback (as now more folks are starting to be aware of the framework and are implementing tools with it *yay*), fix up the architecture, fill in some major holes, write some *real* documentation, and then hand it to the masses... perhaps in G 2.2. Though keep in mind, GShell isn't really Geronimo-specific... its intended to be a light(ish) framework for building rich command-line applications. It just so happens that Geronimo needs such a system to handle its growing cli needs. And GShell's remote login feature makes it ideal for administrators to use that cli to perform installs, maintenance, scripts ala BSF or whatever. Geronimo is definitely, well... IMO, an ideal candidate for GShell integration and I really believe that there is a *huge* value add here. But... before we go telling the world how dope the GShell integration in Geronimo is... I'd really like to fix some of its warts and create some documentation. * * * Anyways, the point of this email is really to ask you folks... can we live with how GShell works right now for the 1.0-alpha-1 release? Or are their any blocking issues which *must* be resolved? I'd really like to spin up a vote today or tomorrow... so if anyone has any input... now is the time. --jason PS. Thanks for those of you who have taken time to play with GShell and provided feedback. Your input is invaluable and IMO critical to the growth and success of GShell. So thanks again!
Re: GShell 1.0-alpha-1 release update
I'd like to release GShell asap. Having more frequent release is imho a good idea (though it's usually easier to say than to do...). GShell is already useful, even if there is still lots of things to do. On Dec 14, 2007 8:35 PM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, the majority of the issues (mostly legal muck) and a few small bugs/improvements have been cleaned up for the 1.0-alpha-1 release of GShell. There is one issue which has been pointed out regarding the 'help' command, which ATM is less than ideal, but does show the information. The idea of the 'help' command is to be sort of a combination of 'ls' and 'man', so that running it with no argument shows the commands available in the current context, and running with an argument, the argument is assumed to be a command path, which is resolved and the help docs for the command are displayed. To make this work is a little bit more than a minor change, and I've planned to get it fixed up for the next version (hopefully in a few months)... and really, this is a moderately complex command which is well suited for someone wanting to learn more about how GShell works to tackle (which another reason why I didn't make it all super-uber- sexy). BUT... I think we really need to get 1.0-alpha-1 released, so it can be consumed by G 2.1 (as well as other projects which are starting to use GShell). And IMO, the 'help' commands ugliness is not a big enough priority to delay the release. IMO, GShell is still a work in progress, while quite functional for many purposes, its still a little rough around the edges and will take some more love to sift through the issues, flesh out the features and iron those pesky buggers out. My recommendation is that for G 2.1 that we don't advertise GShell as a _feature_, but just let it be ASIS, handling the CLI bits for G and average users won't really know the difference. Advanced folks might want to play with it, which is fine (good even to get more feedback), but I don't think that G 2.1 is the release where we want to unleash this on to the world. I would rather let GShell cook... and then simmer for a while longer, pull in more feedback (as now more folks are starting to be aware of the framework and are implementing tools with it *yay*), fix up the architecture, fill in some major holes, write some *real* documentation, and then hand it to the masses... perhaps in G 2.2. Though keep in mind, GShell isn't really Geronimo-specific... its intended to be a light(ish) framework for building rich command-line applications. It just so happens that Geronimo needs such a system to handle its growing cli needs. And GShell's remote login feature makes it ideal for administrators to use that cli to perform installs, maintenance, scripts ala BSF or whatever. Geronimo is definitely, well... IMO, an ideal candidate for GShell integration and I really believe that there is a *huge* value add here. But... before we go telling the world how dope the GShell integration in Geronimo is... I'd really like to fix some of its warts and create some documentation. * * * Anyways, the point of this email is really to ask you folks... can we live with how GShell works right now for the 1.0-alpha-1 release? Or are their any blocking issues which *must* be resolved? I'd really like to spin up a vote today or tomorrow... so if anyone has any input... now is the time. --jason PS. Thanks for those of you who have taken time to play with GShell and provided feedback. Your input is invaluable and IMO critical to the growth and success of GShell. So thanks again! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release Genesis 1.3
Ooops, I always forget to vote... +1 --jason On Dec 11, 2007 1: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
[VOTE RESULT] Release Genesis 1.3
Looks like this vote passed: +1 12 +0 2 -1 0 (Sorry, I'm too lazy to list all the names, peep at the nabble archive if you wanna know aighty?) * * * And with no naysayers... I herby decree that Genesis 1.3 shall be released... which I'll do later tonight or tomorrow pending on the mood of the universe. --jason On Dec 11, 2007, at 1:58 AM, Jason Dillon 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
Re: GShell 1.0-alpha-1 release update
I *completely* agree!! I'm going to give it the rest of the day for feedback on my email and if there is no decent, then I will start the vote. --jason On Dec 14, 2007, at 11:51 AM, Guillaume Nodet wrote: I'd like to release GShell asap. Having more frequent release is imho a good idea (though it's usually easier to say than to do...). GShell is already useful, even if there is still lots of things to do. On Dec 14, 2007 8:35 PM, Jason Dillon [EMAIL PROTECTED] wrote: Folks, the majority of the issues (mostly legal muck) and a few small bugs/improvements have been cleaned up for the 1.0-alpha-1 release of GShell. There is one issue which has been pointed out regarding the 'help' command, which ATM is less than ideal, but does show the information. The idea of the 'help' command is to be sort of a combination of 'ls' and 'man', so that running it with no argument shows the commands available in the current context, and running with an argument, the argument is assumed to be a command path, which is resolved and the help docs for the command are displayed. To make this work is a little bit more than a minor change, and I've planned to get it fixed up for the next version (hopefully in a few months)... and really, this is a moderately complex command which is well suited for someone wanting to learn more about how GShell works to tackle (which another reason why I didn't make it all super-uber- sexy). BUT... I think we really need to get 1.0-alpha-1 released, so it can be consumed by G 2.1 (as well as other projects which are starting to use GShell). And IMO, the 'help' commands ugliness is not a big enough priority to delay the release. IMO, GShell is still a work in progress, while quite functional for many purposes, its still a little rough around the edges and will take some more love to sift through the issues, flesh out the features and iron those pesky buggers out. My recommendation is that for G 2.1 that we don't advertise GShell as a _feature_, but just let it be ASIS, handling the CLI bits for G and average users won't really know the difference. Advanced folks might want to play with it, which is fine (good even to get more feedback), but I don't think that G 2.1 is the release where we want to unleash this on to the world. I would rather let GShell cook... and then simmer for a while longer, pull in more feedback (as now more folks are starting to be aware of the framework and are implementing tools with it *yay*), fix up the architecture, fill in some major holes, write some *real* documentation, and then hand it to the masses... perhaps in G 2.2. Though keep in mind, GShell isn't really Geronimo-specific... its intended to be a light(ish) framework for building rich command-line applications. It just so happens that Geronimo needs such a system to handle its growing cli needs. And GShell's remote login feature makes it ideal for administrators to use that cli to perform installs, maintenance, scripts ala BSF or whatever. Geronimo is definitely, well... IMO, an ideal candidate for GShell integration and I really believe that there is a *huge* value add here. But... before we go telling the world how dope the GShell integration in Geronimo is... I'd really like to fix some of its warts and create some documentation. * * * Anyways, the point of this email is really to ask you folks... can we live with how GShell works right now for the 1.0-alpha-1 release? Or are their any blocking issues which *must* be resolved? I'd really like to spin up a vote today or tomorrow... so if anyone has any input... now is the time. --jason PS. Thanks for those of you who have taken time to play with GShell and provided feedback. Your input is invaluable and IMO critical to the growth and success of GShell. So thanks again! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release Genesis 1.3
+1 Cheers Prasad On Dec 11, 2007 4: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
Re: Tomcat webdav issue and Geronimo 2.1
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
[jira] Created: (GERONIMO-3707) use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient
use Executor rather than ExecutorService for thread pools that are passed into AsyncHttpClient -- Key: GERONIMO-3707 URL: https://issues.apache.org/jira/browse/GERONIMO-3707 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Minor Currently AsyncHttpClient takes an ExecutorService as an argument for the thread pool that gets passed into the SocketConnector constructor. Also, it uses ExecutorService as the type for the event thread pool which is passed to the ExecutorFilter. In both cases, Mina APIs actually take simply Executor. Therefore, it is possible to simply pass in Executor rather than ExecutorService. This is very helpful because the caller may need to retrofit existing thread pool implementations. Implementing Executor is considerably easier than ExecutorService. One implication of this change is that AsyncHttpClient will no longer own and manage the thread pool that gets passed in. I believe that is also OK as the caller can (and perhaps should) handle the lifecycle of a thread pool that it created. -- 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
It worked before Nov 28th. The default user home on windows is c:\Documents and Settings\uesr and maven uses it for default .m2 repo. Thanks for looking into this.. Anita --- David Jencks [EMAIL PROTECTED] wrote: This is probably my fault. 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:1021) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInsta llerGBean.java:675) at org.apache.geronimo.mavenplugins.car.InstallModulesMojo.doExecute (InstallM odulesMojo.java:163) at org.codehaus.mojo.pluginsupport.MojoSupport.execute (MojoSupport.java:122) ... 18 more [INFO] -- -- [INFO] Total time: 29 seconds [INFO] Finished at: Fri Dec 14 10:45:06 EST 2007 [INFO] Final Memory: 50M/254M [INFO] -- -- __ __ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http:// mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Building with c:\Documents and Setting as .m2 repo
I hearby decree that the operating system know as windows is officially the crappiest of the most possible crap that anyone in the entire universe has ever crapped before. Ya and that does include crazy alien crap too. --jason -Original Message- From: Anita Kulshreshtha [EMAIL PROTECTED] Date: Fri, 14 Dec 2007 16:08:00 To:dev@geronimo.apache.org Subject: Re: Building with c:\Documents and Setting as .m2 repo It worked before Nov 28th. The default user home on windows is c:\Documents and Settings\uesr and maven uses it for default .m2 repo. Thanks for looking into this.. Anita --- David Jencks [EMAIL PROTECTED] wrote: This is probably my fault. 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:1021) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInsta llerGBean.java:675) at org.apache.geronimo.mavenplugins.car.InstallModulesMojo.doExecute (InstallM odulesMojo.java:163) at org.codehaus.mojo.pluginsupport.MojoSupport.execute (MojoSupport.java:122) ... 18 more [INFO] -- -- [INFO] Total time: 29 seconds [INFO] Finished at: Fri Dec 14 10:45:06 EST 2007 [INFO] Final Memory: 50M/254M [INFO] -- -- __ __ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http:// mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Building with c:\Documents and Setting as .m2 repo
I hearby decree that the operating system know as windows is officially the crappiest of the most possible crap that anyone in the entire universe has ever crapped before. Ya and that does include crazy alien crap too. --jason --Original Message-- From: Anita Kulshreshtha To: dev@geronimo.apache.org ReplyTo: dev@geronimo.apache.org Sent: Dec 14, 2007 4:08 PM Subject: Re: Building with c:\Documents and Setting as .m2 repo It worked before Nov 28th. The default user home on windows is c:\Documents and Settings\uesr and maven uses it for default .m2 repo. Thanks for looking into this.. Anita --- David Jencks [EMAIL PROTECTED] wrote: This is probably my fault. 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
Re: [VOTE RESULT] Release Genesis 1.3
Release is done, pending sync to Central... hopefully in an hour or so... and then things should be sorted. --jason On Dec 14, 2007, at 12:17 PM, Jason Dillon wrote: Looks like this vote passed: +1 12 +0 2 -1 0 (Sorry, I'm too lazy to list all the names, peep at the nabble archive if you wanna know aighty?) * * * And with no naysayers... I herby decree that Genesis 1.3 shall be released... which I'll do later tonight or tomorrow pending on the mood of the universe. --jason On Dec 11, 2007, at 1:58 AM, Jason Dillon 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
[VOTE] Release GShell 1.0-alpha-1
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 * * * Oh, and I forgot to mention... that I'd really like to thank David Jencks for taking the time to fiddle with things, provide feedback and really I'd even go as far as advocating using GShell. Jeff Genender too, who has been pimping GShell to the Terracotta folks (who I've heard really dig GShell). Guillaume Nodet too for his help in gentrification of GShell to allow the codebase to work with Plexus and OSGI environments. And those of you who have committed patches (ie. Jason #2... their can be only one... hehe). Ha, its like I'm accepting an Oscar or something... /me hears the music start to play Anyways... thanks to everyone. And I really do look forward to any and all input/comments/suggestions/whatever you have to say (not that I'll like it mind you), but I value all input... aighty? Cheers, --jason On Dec 14, 2007 6:02 PM, 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
Re: Monitoring console deadlock
Anita,
Thanks for testing the monitoring plugin, because we could definitely
use more of that. Have you been able to reproduce this problem lately?
I remember experiencing the same problem because the connections
weren't be closed at the right time, so I'm wondering if I didn't
catch all of the closes that should have been there.
Thanks,
Viet
On Dec 13, 2007 9:25 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
I was running monitoring console on G(portoffset=10) and the agent
on default G instance. I saw this trace on the screen at a later time.
So I can not describe what exactly I was doing.. This can probably be
fixed by ordering the sql operations correctly.
Thanks
Anita
14:48:27,968 ERROR [SnapshotDBHelper] A lock could not be obtained due
to a dead
lock, cycle of locks and waiters is:
Lock : ROW, SYSCOLUMNS, (4,17)
Waiting XID : {691, S} , MONITOR, INSERT INTO Statistics
(snapshot_time, stats
ValueList, mbeanId) VALUES
(119747609,'23209078,30091640,34628360,32094576',
5)
Granted XID : {693, X}
Lock : ROW, STATISTICS, (4,7)
Waiting XID : {693, S} , MONITOR, SELECT DISTINCT snapshot_time FROM
Statistic
s WHERE snapshot_time 1194896887609
Granted XID : {691, X}
. The selected victim is XID : 691.
ERROR 40001: A lock could not be obtained due to a deadlock, cycle of
locks and
waiters is:
Lock : ROW, SYSCOLUMNS, (4,17)
Waiting XID : {691, S} , MONITOR, INSERT INTO Statistics
(snapshot_time, stats
ValueList, mbeanId) VALUES
(119747609,'23209078,30091640,34628360,32094576',
5)
Granted XID : {693, X}
Lock : ROW, STATISTICS, (4,7)
Waiting XID : {693, S} , MONITOR, SELECT DISTINCT snapshot_time FROM
Statistic
s WHERE snapshot_time 1194896887609
Granted XID : {691, X}
. The selected victim is XID : 691.
at
org.apache.derby.iapi.error.StandardException.newException(Unknown So
urce)
at
org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown
Source)
at
org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Sourc
e)
at
org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown
Source)
at
org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown So
urce)
at
org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(Un
known Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknow
n Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknow
n Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRow
OnPage(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockSc
anRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockSc
anRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(U
nknown Source)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.TabInfoImpl.getRowInternal(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.TabInfoImpl.getRowLocation(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.computeRowLocati
on(Unknown Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.computeAutoincRo
wLocations(Unknown Source)
at org.apache.derby.impl.sql.compile.InsertNode.bind(Unknown
Source)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
Source)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepa
reInternalStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Sourc
e)
at
org.tranql.connector.jdbc.StatementHandle.executeUpdate(StatementHand
le.java:166)
at
org.apache.geronimo.monitor.snapshot.SnapshotDBHelper.addSnapshotToDB
(SnapshotDBHelper.java:229)
at
org.apache.geronimo.monitor.snapshot.SnapshotProcessor.takeSnapshot(S
napshotProcessor.java:79)
at
org.apache.geronimo.monitor.MasterRemoteControl.handleTimeout(MasterR
emoteControl.java:205)
at sun.reflect.GeneratedMethodAccessor385.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invoc
ation.invoke(ReflectionInvocationContext.java:146)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proce
ed(ReflectionInvocationContext.java:129)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(Intercept
orStack.java:67)
Re: GShell 1.0-alpha-1 release update
On Dec 14, 2007, at 3:12 PM, Jason Dillon wrote: I *completely* agree!! I'm going to give it the rest of the day for feedback on my email and if there is no decent, then I will start the vote. At the moment, some Geronimo commands are/will be(?) available *only* through gshell (e.g. assemble). So, I'm interested in insuring that gshell does have meets-min capabilities. You could argue that we should have console/java cli support for these functions (or I'm just wrong... ;-), but that's the way things are ATM... I'm not advocating for a more robust 'help' command. However, I would like to be sure it's readable and instructive. Personally, I'd like to take a little time to kick the tires and make sure we don't have any glaring problems... --kevan
Re: GShell 1.0-alpha-1 release update
No worries take a whack at it. Though IMO its too bad the apache way slows down releasing binaries so much. Like I want to push out alpha-1 um like a week ago. I know there are holes, which well filla nd then roll out another alpha. Its certainly not going to be perfect that's for sure. Which is why I tend to follow the release often strategy. Push out something that is functional, fix it up and then push it out again. Seems to me like we have a 2-3 week minumum for each release, almost regaurdless of what it is... Though the javaee server and its tck muck certainly adds on more weeks. It seems like if nothing at all changed ina subproject it will still take the better part of a month to make a release :-( Well take a look... Let's try to get this finished in the next week na... I'm goinig to be out of the country for 3 weeks startin on the 22nd And I'd reallly, really like to have the release done by then But more so I think we need to rethink our stratagy. on releases It should be easy and quick. IMO the 3 day vote period is long enough :-P Well ping me if you need something changed. I'm at your disposal next week if it helps move things along...aight? :-) --jason -Original Message- From: Kevan Miller [EMAIL PROTECTED] Date: Fri, 14 Dec 2007 20:07:07 To:dev@geronimo.apache.org Subject: Re: GShell 1.0-alpha-1 release update On Dec 14, 2007, at 3:12 PM, Jason Dillon wrote: I *completely* agree!! I'm going to give it the rest of the day for feedback on my email and if there is no decent, then I will start the vote. At the moment, some Geronimo commands are/will be(?) available *only* through gshell (e.g. assemble). So, I'm interested in insuring that gshell does have meets-min capabilities. You could argue that we should have console/java cli support for these functions (or I'm just wrong... ;-), but that's the way things are ATM... I'm not advocating for a more robust 'help' command. However, I would like to be sure it's readable and instructive. Personally, I'd like to take a little time to kick the tires and make sure we don't have any glaring problems... --kevan
Re: [VOTE] Release GShell 1.0-alpha-1
+1 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
