Yup, I know... still need to figure that out actually. Keep in mind
I'm not done hacking up this stuff just yet, I hope to solve this
problem soon... but before I do that I'm going to re-enable all the
other previously disabled stuff (like whisper and remote support) and
make sure that works.
BTW, I'm glad you are looking at this stuff. I'm currently full steam
ahead working on getting spring enabled (and liking it much more than
plexus)... but if you have some time to keep reviewing or help out in
any other manner I'd really appreciate it!
--jason
On Sep 19, 2008, at 7:13 PM, Guillaume Nodet 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
