[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [virgo-dev] Inner framework command
|
Hi Community,
These days i've had serious trouble trying to successfully setup the integration tests for the Inner Framework Supportability Commands, so that they can be contributed to Virgo.
The greatest challenge was to successfully include the "-javaagent:" argument to the running VM.
As Hristo mentioned in the previous post in this thread, we suspected that the "test.vm.args" property located in virgo-build/common/common.properties could be the solution, but it turned out that the property isn't working.
I've created a bug for that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=323847
I guess further discussion about it will be taken there..
Anyway in order to continue with the setup I worked-around the property by hardcoding what I needed directly in the quality.xml.
I met several other issues and I have question about one of them.
After I finally managed to run successfully the inner framework integration tests(with passed result) the integration suite failed on one of the following tests - org.eclipse.virgo.kernel.test.StandardBundleStarterSignalingTests, on Testsuite: org.Batch-With-Multiple-Tests. The error was that the forked java VM exited abnormally.
1. Could you please give me some more details about what this test does and where can I find some logs or traces with the error? (I searched basically everywhere inside org.eclipse.virgo.kernel.tests)
Also I have another question about overriding the test.vm.args property.
2. When used, does it apply to all tests(both unit and integration)?
If that is so then maybe we'll need to override it so that it could be enabled only for the integration tests to avoid overhead while executing the junits.
3. What's your opinion on the matter and can you give some example on how I can override it locally for the integration tests module (I presume that would require overriding the quality.xml too)?
Best Regards,
Borislav
-----Original Message-----
From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Iliev, Hristo
Sent: Monday, August 23, 2010 9:44 AM
To: Virgo Project
Subject: RE: [virgo-dev] RE: Inner framework command
Hi,
I'm trying to add some integration tests for the inner framework commands. However to do so a special VM arguments are needed. Is it possible to add a VM parameter for a single integration test, group of tests, or a project (virgo.kernel.test)?
I found a property test.vm.args in virgo-build/common/common.properties but since it is "common" one changing it will affect all tests which is not a good idea.
Do you think that overwriting the test.vm.args property in a project's build.xml is a good solution? It looks like having a separate project (and its own environment) for such special integration tests is a good option since it does not add VM arguments that may interfere with other tests.
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:07 PM
To: Virgo Project
Subject: Re: [virgo-dev] RE: Inner framework command
You certainly could put the framework stuff behind JMX to make it more generally available in other contexts. The question is how does the framework stuff relate to the current JMX interface which is basically a way of inspecting and manipulating the artefacts which have been deployed into the user region. I think it should be kept in a separate JMX interface for starters. The relationship between multiple frameworks and user region may become more interesting if and when we implement multiple user regions...
Glyn
On 12 Jul 2010, at 09:44, Iliev, Hristo wrote:
> Hi Glyn,
>
> Thanks a lot for the remarks. We'll take care to fix the issues.
>
> Do you think we can have the framework stuff behind JMX too?
>
> 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 11:17 AM
> To: Virgo Project
> Subject: 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
>
> _______________________________________________
> 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
