[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] RE: Inner framework command
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Fri, 9 Jul 2010 09:04:31 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcsfgGrBGK4iMLDzREyqFHFhDm4sPg==
- Thread-topic: [virgo-dev] RE: Inner framework command
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?
On 7 Jul 2010, at 13:53, Iliev, Hristo wrote:
> The link here contains a fix for this issue:
> 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.
> 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
> 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 ..
> Inner framework  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.
> 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
>> To fix the issue one can simply remove the dot:
>> Boot-Class-Path: javassist.jar com.sap.core.supportability.innerfrk.d
>> Strangely enough - on Windows this did not caused problems as I would expect...
> virgo-dev mailing list
> virgo-dev mailing list