Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] RE: Inner framework command 
Hi Hristo

Finally got this going - thanks for the new zip.

The frk command is very useful, especially for inspecting the kernel region.

A couple of queries/improvements...

Firstly I didn't understand the help:

frk [-d ot details]

frk -d seems to give the detailed view, but I do not understand the 'ot' and 'details' syntax.

Secondly, the identification of bundles could be less ambiguous. For example:

========================
osgi> frk -d
Current state of the OSGi Frameworks:
Avaliable frameworks 2
----------------------------------------------------------
[ 1 ] Equinox [org.eclipse.osgi_3.5.1.R35x_v20091005]
     \___[ 2 ] Equinox [org.springframework.osgi.extender_1.2.1]


[ 2 ] - [Started]
- system bundle classname: [org.eclipse.osgi.framework.internal.core.InternalSystemBundle]
- started from bundle: [org.springframework.osgi.extender_1.2.1]
- started from bundle: [org.eclipse.virgo.kernel.agent.dm_2.1.0.M01]
....
========================

refers to bundle: [org.springframework.osgi.extender_1.2.1], but of course there are two such bundles: bundle id 26 in the kernel region and bundle id 5 in the user region.

You may like to think about how to display the framework number and the bundle id along with the bundle symbolic name and bundle version.

Other than that, it looks really good and I hope we can build this into Virgo in due course. As for the other command, we would want this reworked so that the guts of the command sits behind a JMX interface so it could be exploited both from the Equinox console and the admin console. (I still need to find you an example - sorry for the delay.)

Regards,
Glyn
On 12 Jul 2010, at 07:44, Iliev, Hristo wrote:

> Hi,
> 
> The dot is still inside - sorry for this. Please remove it or simply download the new ZIP:
> https://sapmats-de.sap-ag.de/download/download.cgi?id=ZCYJTQB6HYXCHD098BFZU0XEUOY2QP03KP3S0HUWWKABEB0QWC
> 
> Regards,
> Hristo Iliev
> 
> -----Original Message-----
> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
> Sent: Friday, July 09, 2010 7:05 PM
> To: Virgo Project
> Subject: Re: [virgo-dev] RE: Inner framework command
> 
> Hi Hristo
> 
> Just to say I tried the new level and one of the earlier issues resurfaced so I'll try again next week. You did get rid of the extraneous . this time didn't you?
> 
> Regards,
> Glyn
> On 7 Jul 2010, at 13:53, Iliev, Hristo wrote:
> 
>> Hi,
>> 
>> The link here contains a fix for this issue:
>> https://sapmats-de.sap-ag.de/download/download.cgi?id=MVAKNGY7TWT8IHVDQ3TJOMGYM99L4TKNNZQK3E8MVOIXMN3PAP
>> 
>> I guess it will be easier to just run the modified archive since we made some refactoring of the package names and the build.
>> 
>> The commands has to show this:
>> 	osgi> frk
>> 	Current state of the OSGi Frameworks:
>> 	Avaliable frameworks 2
>> 	----------------------------------------------------------
>> 	[ 1 ] Equinox [org.eclipse.osgi_3.5.1.R35x_v20091005]
>> 	     \___[ 2 ] Equinox [org.springframework.osgi.extender_1.2.1]
>> 
>> So as you can see we are actually talking about nested frameworks.
>> 
>> Regards,
>> Hristo Iliev
>> 
>> P.S. Detailed info is available with -d
>> 
>> 
>> 
>> -----Original Message-----
>> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
>> Sent: Wednesday, July 07, 2010 3:18 PM
>> To: Virgo Project
>> Subject: [virgo-dev] Inner framework command
>> 
>> Hi Hristo
>> 
>> The solution below fixed the basic crash and I can now start Virgo successfully and see the frk command in the Equinox console. However, when I run it without parameters, I get:
>> 
>> osgi> frk
>> java.lang.NullPointerException
>> 	at com.sap.osgi.command.frameworkinfo.FrameworkInfoCommand.processTree(FrameworkInfoCommand.java:549)
>> 	at com.sap.osgi.command.frameworkinfo.FrameworkInfoCommand.processTree(FrameworkInfoCommand.java:563)
>> 	at com.sap.osgi.command.frameworkinfo.FrameworkInfoCommand.list(FrameworkInfoCommand.java:463)
>> 	at com.sap.osgi.command.frameworkinfo.FrameworkInfoCommand._frk(FrameworkInfoCommand.java:152)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> 	at java.lang.reflect.Method.invoke(Method.java:597)
>> 	at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155)
>> 	at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:303)
>> 	at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:288)
>> 	at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:224)
>> 	at java.lang.Thread.run(Thread.java:637)
>> 
>> It does a bit better with a framework id:
>> 
>> osgi> frk 0 ss
>> Listing bundles in framework [0]..
>> Inner framework [0] is not available, check if it is stopped
>> 
>> but that's not very interesting. Is an inner framework is the same thing as a nested framework as currently supported by Equinox? I guess not as the user region is a nested framework.
>> 
>> Glyn
>> PS. I'll comment on the class loading command separately as it's a completely disjoint topic.
>> On 7 Jul 2010, at 10:47, Iliev, Hristo wrote:
>> 
>>> Follow-up for "There is a problem running the nested framework agent on Mac OS X which we will continue to discuss on virgo-dev":
>>> 
>>> The problem turned out to be a misspelled name - dot after the first jar in the manifest of the java agent:
>>> 
>>> 	Boot-Class-Path: javassist.jar. com.sap.core.supportability.innerfrk.d
>>> 	 etectionlib-0.7.0-SNAPSHOT.jar
>>> 
>>> To fix the issue one can simply remove the dot:
>>> 
>>> 	Boot-Class-Path: javassist.jar com.sap.core.supportability.innerfrk.d
>>> 	 etectionlib-0.7.0-SNAPSHOT.jar
>>> 
>>> Strangely enough - on Windows this did not caused problems as I would expect...
>> 
>> _______________________________________________
>> 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

Back to the top