Re: Classloading command [was Re: [virgo-dev] Classloading & Inner frame

[Glyn Normington <gnormington@xxxxxxxxxx>]

Hi Hristo

Yes, that makes good sense.

Glyn
On 28 Jul 2010, at 15:09, Iliev, Hristo wrote:

> Hi,
> 
> I had a look at the code and found out that vsh command is actually registered by org.eclipse.virgo.kernel.osgicommand bundle while org.eclipse.virgo.kernel.shell contains the code for the subcommands.
> 
> At least to me it makes more sense to put the new commands in osgicommands bundle for several reasons:
> 	* imports - no additional imports will be introduced to kernel.shell bundle and some of the needed packages are already imported in osgicommand
> 	* activator - registering the commands via activator in the kernel.shell bundle seems to break the current model. The shell bundle provides to osgicommand a service that is used to register the vsh command. If an activator is introduced then we would have 2 activators - one in the kernel.shell bundle that registers the classloading commands and one in osgicommand bundle that registers vsh command, while one activator can do both
> 	* direction - if the target is improvement of the Equinox console then perhaps it makes more sense to have the commands in the osgicommand bundle and to drop the kernel shell when possible. The osgicommand bundle can also be modified to run without the kernel.shell dependencies/imports
> 
> Do you think that separating the new "equinox" commands from kernel.shell makes sense?
> 
> Regards,
> Hristo Iliev
> 
> -----Original Message-----
> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
> Sent: Monday, July 12, 2010 12:24 PM
> To: Virgo Project
> Subject: Re: Classloading command [was Re: [virgo-dev] Classloading & Inner frameworks supportability commands]
> 
> Hi Hristo
> 
> I think it is reasonable to add your commands to the Equinox console at the same level as the vsh command rather than as subcommands of vsh. Let me explain why.
> 
> There is quite a bit of infrastructure, mostly in the kernel shell bundle, supporting the vsh Equinox command and the old kernel shell commands as subcommands of vsh. The advantage of turning your commands into subcommands of vsh would be that if we were ever to resurrect the kernel shell, then your commands would immediately be available there. However it is not clear that the kernel shell will ever be resurrected in anything like its original form. The current direction is to improve the Equinox console so we don't need to resurrect the kernel shell.
> 
> However it would still be worth structuring your commands as a UI piece providing the Equinox console command and a JMX interface providing the actual function. Then the actual function could be used from other user interfaces such as the admin console and any 3rd party management tools which might come along.
> 
> Looking in jconsole, it seems you have already started to do that with the FrameworkInfoCommand and com.sap.core.supportability.tools mbeans and so all you need to do is make sure all the function of your commands is available via your mbeans.
> 
> Is that clear? We can discuss this on tomorrow's Virgo community call if you like.
> 
> Glyn
> On 8 Jul 2010, at 07:37, Iliev, Hristo wrote:
> 
>> Hi,
>> 
>> If the nested frameworks stuff we send could execute arbitrary shell line then the classloading commands you tried can really be used to debug also the kernel space as well as other nested frameworks. Kernel developers deserve some help too I guess.
>> 
>> Btw we had a discussion in SAP about the JMX interfaces last week, so I think it is now a must-have since everyone agrees on this point :) Can you send an example so we can start preparing the commands for Virgo?
>> 
>> Regards,
>> Hristo Iliev
>> 
>> 
>> -----Original Message-----
>> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
>> Sent: Wednesday, July 07, 2010 3:38 PM
>> To: Virgo Project
>> Subject: Classloading command [was Re: [virgo-dev] Classloading & Inner frameworks supportability commands]
>> 
>> Hi Hristo
>> 
>> Much better progress on this one! The classloading commands are available in the Equinox console and seem to work fine for bundles in the user region. For example:
>> 
>> osgi> clhas org.eclipse.virgo.web.core.WebApplicationRegistry
>> 
>> Bundles containing [org.eclipse.virgo.web.core.WebApplicationRegistry]:
>> 37 org.eclipse.virgo.web.core
>> 
>> osgi> clload org.eclipse.virgo.web.core.WebApplicationRegistry
>> 
>> Successfully loaded [org.eclipse.virgo.web.core.WebApplicationRegistry] from:
>> 37 org.eclipse.virgo.web.core
>> 36 org.eclipse.gemini.web.tomcat
>>  [exported by 37 org.eclipse.virgo.web.core]
>> 
>> osgi> clexport org.eclipse.virgo.web.core.WebApplicationRegistry
>> 
>> Bundles exporting [org.eclipse.virgo.web.core.WebApplicationRegistry]:
>> 37 org.eclipse.virgo.web.core
>> 
>> (I observe that this command only processes bundles in the user region. For example, it can't find the org.eclipse.virgo.kernel.deployer.Deployer class which resides in the org.eclipse.virgo.kernel.deployer bundle in the kernel region. This doesn't matter since application developers should only be interested in bundles in the user region.)
>> 
>> So this is a really useful piece of function for users and I'd like to explore integrating it into Virgo alongside other Virgo commands. :-)
>> 
>> In general, we put commands behind JMX interfaces so they can be driven both from the Equinox console (or other shells that may come along) and from the admin console. As a next step, we'll review the source code of the classloading command and give you some more feedback. Perhaps we could then point you at some existing JMX commands and you could try massaging your code into that kind of shape and integrating it into Virgo (and we'll happily guide you through the process as you'll probably be learning a lot about Virgo along the way). Ok?
>> 
>> Glyn
>> On 5 Jul 2010, at 11:40, Iliev, Hristo wrote:
>> 
>> Hi,
>> 
>> We are currently working on some supportability features for OSGi and in particular Equinox. This includes:
>> *         Classloading - by a given class name list all bundles that:
>> o    contain it
>> o    export it
>> o    can load it
>> *         Inner frameworks
>> o    lists all inner frameworks in a tree view
>> o    lists details:
>> *  Start time
>> *  Origin bundle
>> *  System bundle's class
>> *  Startup call stack
>> o    executes certain commands in the inner framework (list, start/stop, install/uninstall/update)
>> 
>> The classloading commands (bundle) can be found here:
>> https://sapmats-de.sap-ag.de/download/download.cgi?id=CUWKAJZQLCZSTY7Z2185H84U6AAYD0DRXF4AYH91J8HGVL9SD7
>> 
>> The inner framework files can be found inside the zip located here:<https://wiki.wdf.sap.corp/wiki/download/attachments/759500197/inner_frk.zip>
>> https://sapmats-de.sap-ag.de/download/download.cgi?id=KK9O6JT63JK03W4QTOZMFW6SJGF77VIK9VKNUZMUWKJCBZX8F3
>> 
>> To install the inner framework bundles & agent:
>> 1.  Place the three main components in one folder (Java agent(FDAgent), Collector library(FDLib), instrumentation library(javassist))
>> 2.  Add the package of the framework collector library (com.sap.osgi.frameworkdetection.lib) to the bootdelegation property (org.osgi.framework.bootdelegation). Before starting the server add -javaagent:<path-to-the-agent>FDAgent_1.1.jar to the command line after the java keyword.
>> 3.  Install the Framework Detection Command bundle in the Equinox environment you just launched, start that bundle and use the commands it provides.
>> 
>> 
>> We would like to contribute the code to Virgo since we think the commands will make the diagnostics of problems (often needed in server environment) much easier.
>> 
>> What do you about this idea?
>> 
>> Regards,
>> Hristo Iliev
>> 
>> 
>> <ATT00001..txt>
>> 
>> _______________________________________________
>> virgo-dev mailing list
>> virgo-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>> _______________________________________________
>> virgo-dev mailing list
>> virgo-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> 
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev