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 14:39:46 GMT
FYI, I've just started to update the gshell-remote-* and gshell- 
whisper stuff to integrate with wisdom/spring... so might take a few  
days before the remote shell commands will work again.

It compiles now, but I've yet to actually get a rsh/rsh-server  
connection working.

The plan is to make it work asis with as little changes as possible...  
then if needed (and probably) refactor to make use of the spring  
container to allow richer configuration.

--jason


On Sep 19, 2008, at 7:17 PM, Guillaume Nodet wrote:

> 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 <gnodet@gmail.com>  
> 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
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://open.iona.com


Mime
View raw message