geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <jason.dil...@gmail.com>
Subject Re: GShell update
Date Fri, 19 Sep 2008 12:49:46 GMT
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  
> <jason.dillon@gmail.com> 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


Mime
View raw message