The problem is that the customer want to "script" some actions using sh and so the console can't be used.
More over, the console is not always installed on a "production" environment and I think that the console can't create a SU from a xbean.xml. I can extend the console feature and use the same "classes" in the "script" tool. Regards JB On Friday 20 February 2009 - 09:19, Lars Heinemann wrote: > Hi JB, > > what would be the benefit of this? Most of the listed things can be > achieved by using the JConsole. > > Regards, > Lars > > > 2009/2/20 <[email protected]>: > > Hi guys, > > > > I'm coming back from three days with a customer where I have installed SMX > > 3.3 on AIX6/Power6/JVM IBM 1.5. > > I have deployed a set of services using CXF-SE using EJBs in WebSphere > > 6.1.0.17. > > > > Basicly, the customer has asked how to view the SU/SA deployed (without the > > console, directly in command line) and > > if it's a tool is provided to add a SU BC in front of an existing SE. > > > > Resulting with this dealing, I propose to add a tool in SMX 3.3 which is a > > kind of mix between SMX4 gshell and SMX3 console. > > > > I have wrote a kind of feature scope in the plane yesterday evening and I > > propose : > > - to add a script bin/smx-shell (like we have bin/servicemix) > > - the smx-shell can : list the SAs, list the SUs, stop/start SA/SU, create > > a SU zip using a xbean.xml and a set of jar (like the maven plugin does but > > without any requirement to have maven already installed, the purpose is to > > be able to add for example a JMS SU that target a SE), test a SA (providing > > a typed normalized message content) > > > > What do you think of that ? > > Could I create smx3-shell project in the tooling svn directory ? > > > > Thanks, > > Regards > > JB > > > > > > -- > http://lhein.blogspot.com
