Doh, find the answer to my last question. The build was disable in idea project did not show whisper. My bad!
On Fri, Sep 19, 2008 at 2:13 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Just had a look at the current code, and I want to point a possible problem. > Bear with me if I misunderstood something. > When a command is created from spring, we have the following bean definition: > > <bean > class="org.apache.geronimo.gshell.wisdom.command.CommandImpl"> > <property name="id" value="gshell-optional:sleep"/> > > <property name="action"> > <bean > class="org.apache.geronimo.gshell.commands.optional.SleepCommand"/> > </property> > </bean> > > which means that the SleepCommand is bean created from spring as a singleton. > When the command is executed, the bean is populated with the arguments > from the command line and executed. > It seems to me that the design has a flaw in that it is not thread > safe: the same bean will be used to serve multiple commands. > Even more annoying, the bean is not reset to a clean state, meaning > that command arguments will be kept from one > execution to the other if they have not been overriden by the command line. > > I think a possible and simple workaround would be to create a new > instance of the bean each time it is executed. > That's what we've done in ServiceMix on the older version of gshell > using the OsgiCommandSupport. > The createCommand() is called and by default create a new instance of > the command to be populated and executed. > If a command has specific wiring or injections, it has to override > this method and populate the new bean after creation. > This is not really clean, but it was working at that time. > > Also, another unrelated point, where is the whipser stuff now ? I > could not find it or any replacement in the svn tree ... > > [1] > http://svn.apache.org/repos/asf/servicemix/smx4/kernel/trunk/gshell/gshell-core/src/main/java/org/apache/geronimo/gshell/support/OsgiCommandSupport.java > > On Thu, Sep 11, 2008 at 8:17 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: >> Finally got back to hacking on GShell... and have been working on replacing >> the Plexus container with a Spring container. Today I finally got it >> working correctly, using maven repository for dependencies. >> >> Still got some work left to do to clean up the layout muck and make the help >> command functional again, but its in progress. >> >> Anyways, just a tiny update that things are progressing.... >> >> I'm not sure what is gonna happen with the gshell-rapture/plexus >> integration... as I get more and more into the gshell-wisdom/spring >> integration I'm feeling more and more that I should just drop the plexus >> stuff. We are still using plexus though to load the ArtifactManager used to >> resolve the GShell applications classpath, though I have hopes that the new >> Maven Mercury API can be used and requires less Plexus muck to work, but >> I've not actually tried that yet. Also the current gshell-artifact >> integration requires most of the Maven 2.1.* artifacts to resolve poms, >> which I'm tempted to just replace with a wee bit of xstream model stuff to >> *simulate* the basics needed to resolve an artifacts transitive >> dependencies... but for now I just use Maven, which inflates the system like >> 2m... sucky, but it works. >> >> So, the main design issue we have right now is what to do with the layout >> muck... might rip it out, have a flat list of commands and then re-implement >> the hierarchy... hot sure yet. >> >> Anyways... making progress. >> >> --jason >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://open.iona.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://open.iona.com
