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
