geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: GShell update
Date Fri, 19 Sep 2008 12:17:55 GMT
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 <> 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]
> On Thu, Sep 11, 2008 at 8:17 PM, Jason Dillon <> 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:
> ------------------------
> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message