You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@kc.rr.com> on 2006/09/18 03:59:24 UTC
HARMONY-1407: Contribution of Java code for package java.lang.management
Are there any documents or anything that needs to be resolved before I can
start working on the code in HARMONY-1407?
http://issues.apache.org/jira/browse/HARMONY-1407
-Nathan
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Yes. I have some docs that need to be put in SVN - I hope to do that
> today. Once we do that, we need to simply vote to accept the code.
>
> If you start working with it ahead of time, that will be good :)
>
> geir
Are we ready to vote yet? I can't hold my breath much longer <gasp> :-)
Regards,
Tim
> Nathan Beyer wrote:
>> Are there any documents or anything that needs to be resolved before I
>> can
>> start working on the code in HARMONY-1407?
>>
>>
>>
>> http://issues.apache.org/jira/browse/HARMONY-1407
>>
>>
>>
>> -Nathan
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Andrey Yakushev <an...@gmail.com>.
> Why not write LogManager.getLoggingMXBean like this:
> return com.ibm.lang.management.ManagementUtils.getLoggingBean();
Yes, it also possible, but tightly binds logging module to
lang-managment implementation.
> I found the problem about "StackTraceElement" when I used "luni-kernel.jar"
> (in jre/bin/default) in build-path of project, it could not compile; and
> when I replaced it with "luni-kernel-stubs.jar" (in jre/lib/boot), it was
> OK. Maybe your problem is not exactly as mine.
Yes, you are right. Deeper investigation showed that problem was in
CompositeDataSupport constructor and exists not only for
StackTraceElement class. This is minimal test that fails on DRLVM but
works well on J9:
---8<----------------------------------------------
import javax.management.openmbean.*;
class CompositeDataTest {
public static void main(String[] args) throws Exception {
String[] names = { "goodName" };
OpenType[] te = { SimpleType.STRING };
CompositeType ct = new CompositeType("goodName", "goodName",
names, names, te);
CompositeData[] cda = { new CompositeDataSupport(ct, names, names) };
Object[] values = { cda };
OpenType[] typeTypes = { new ArrayType(1, ct) };
CompositeType ct2 = new CompositeType("goodName", "goodName",
names, names, typeTypes);
new CompositeDataSupport(ct2, names, values);
System.out.println("Passed");
}
}
---8<-------------------------------------------------------------
> I think the vote is coming, we'd best move on after voting, :-)
It's a pity but I've already created
http://issues.apache.org/jira/browse/HARMONY-1821 :-)
Thanks,
Andrey
On 10/11/06, Rui Hu <ro...@gmail.com> wrote:
> On 10/5/06, Andrey Yakushev <an...@gmail.com> wrote:
> >
> > I've tried to follow you suggestions. The result:
> >
> > 1. The fix for unimplemented
> > java.util.logging.LogManager.getLoggingMXBean could be simple, like:
> >
> > return LoggingMXBeanImpl.getInstance()
> >
> > But it bind logging module to LoggingMXBean implementation.
> > Probably more clean solution would be:
> >
> > ObjectName loggingMXBeanName = new
> > ObjectName(LOGGING_MXBEAN_NAME);
> > MBeanServer platformBeanServer =
> > ManagementFactory.getPlatformMBeanServer();
> > Set loggingMXBeanSet =
> > platformBeanServer.queryMBeans(loggingMXBeanName, null);
> >
> > if(loggingMXBeanSet.size() != 1) {
> > throw new AssertionError("There Can Be Only One
> > logging MX bean.");
> > }
> >
> > Iterator i = loggingMXBeanSet.iterator();
> > ObjectInstance loggingMXBeanOI = (ObjectInstance) i.next();
> > String lmxbcn = loggingMXBeanOI.getClassName();
> > Class lmxbc = Class.forName(lmxbcn);
> > Method giMethod = lmxbc.getDeclaredMethod("getInstance");
> > giMethod.setAccessible(true);
> > LoggingMXBean lmxb = (LoggingMXBean) giMethod.invoke(null,
> > new Object[] {});
> >
> > return lmxb;
> >
> > But this approach also supposes that implementation contains
> > getInstance method, which is not always true as far as I know.
> > Probably some other solution exists?
>
>
> Sorry for reply so late.
> Why not write LogManager.getLoggingMXBean like this:
> return com.ibm.lang.management.ManagementUtils.getLoggingBean();
>
> The similar implementation can be found in some public methods in
> java.lang.management.ManagementFactory
>
> 2. One more problem fount is that
> >
> > \management\src\main\java\org\apache\harmony\lang\management\CompilationMXBeanImpl.java
> > uses System.getProperty("java.compiler") which is not defined and it
> > lead to NullPointerException in
> > testGetAttribute(
> > tests.org.apache.harmony.lang.management.CompilationMXBeanImplTest)
> >
> > Running tests with -Djava.compiler=jitrino removes this test error.
> >
> > It is interest that test_getProperty_Str from
> >
> > inincubator\harmony\enhanced\drlvm\trunk\vm\tests\kernel\java\lang\SystemExtensionTest
> > tries to check that but couldn't due to error in test (using ||
> > instead of &&).
>
>
>
>
> 3. As to StackTraceElement problem, I obtain the fail:
> >
> > javax.management.openmbean.OpenDataException: itemValue at index 12 is
> > not a valid value for itemName stackTrace and itemType
> > javax.management.openmbean.CompositeData(typename=[
> > Ljavax.management.openmbean.CompositeData;,dimension=1,elementType=
> > javax.management.openmbean.CompositeData
> > TypeName: java.lang.StackTraceElement contains data:
> > ItemName: className OpenType value:
> > javax.management.openmbean.SimpleType(name = java.lang.String)
> > ItemName: fileName OpenType value:
> > javax.management.openmbean.SimpleType(name = java.lang.String)
> > ItemName: lineNumber OpenType value:
> > javax.management.openmbean.SimpleType(name = java.lang.Integer)
> > ItemName: methodName OpenType value:
> > javax.management.openmbean.SimpleType(name = java.lang.String)
> > ItemName: nativeMethod OpenType value:
> > javax.management.openmbean.SimpleType(name = java.lang.Boolean)
> > )
> > at javax.management.openmbean.CompositeDataSupport.validateContents
> > (CompositeDataSupport.java:104)
> > at javax.management.openmbean.CompositeDataSupport.init(
> > CompositeDataSupport.java:81)
> > at javax.management.openmbean.CompositeDataSupport.<init>(
> > CompositeDataSupport.java:28)
> > at
> > tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.createGoodCompositeData
> > (ThreadInfoTest.java:124)
> > at
> > tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.setUp(
> > ThreadInfoTest.java:96)
> > ...[skip]...
> >
> > First look at CompositeData for java.lang.StackTraceElement shows that
> > names, types and values are Ok. This error appears even if
> > StackTraceElement array length is equal to zero, so probably problem
> > in CompositeData implementation. I will try to continue investigation,
> > but any help is welcome.
>
>
> I found the problem about "StackTraceElement" when I used "luni-kernel.jar"
> (in jre/bin/default) in build-path of project, it could not compile; and
> when I replaced it with "luni-kernel-stubs.jar" (in jre/lib/boot), it was
> OK. Maybe your problem is not exactly as mine.
>
> 4. Final note (Is anybody still continue reading such a long text? :)
> >
> > I'm going to donate the written native method stubs but because they
> > suppose some renaming in HARMONY-1407 they may demand some correction
> > in future. Should I wait until HARMONY-1407 voting and committing?
>
>
> I think the vote is coming, we'd best move on after voting, :-)
> Thanks.
>
>
> Thanks,
> > Andrey
> >
> >
> >
> > On 9/20/06, Rui Hu <ro...@gmail.com> wrote:
> > > On 9/20/06, Andrey Yakushev <an...@gmail.com> wrote:
> > > >
> > > > Do I understand correctly, that j.l.management support could be
> > > > implemented for DRLVM as follows:
> > > >
> > > > 1. Integrate HARMONY-1407 into classlib and obtain
> > > > UnsatisfiedLinkError on DRLVM.
> > > > 2. Implement native methods in kernel classes as stubs returning some
> > > > realistic values. It could allow test and jconsole running.
> > > > 3. Replace these stabs one by one with possible adding of the
> > > > interface functions in DRLVM modules like GC and TM.
> > >
> > >
> > > Great. It's a good plan.
> > >
> > > Really I have tried to go through this plan "ahead of time" :)
> > > > Currently I wrote native methods stubs and made run for the tests from
> > > > HARMONY-1407. The result is:
> > > > Tests run: 90, Failures: 15, Errors: 9
> > > > 13 failures is StackTraceElement similar as Rui mentioned.
> > >
> > >
> > > It's easy to fix.
> > >
> > > 8 errors due to not implemented method
> > > > at java.util.logging.LogManager.getLoggingMXBean(
> > LogManager.java
> > > > :154)
> > >
> > >
> > > It's easy to fix too. Just add one simple method to LogManager.
> > >
> > > Other 3 problems needs additional investigation
> > >
> > >
> > > Can you list out them?
> > > I found that most native methods of this component are related with VM
> > > platform, and some Java methods are called by native code(e.g. [1]) .
> > Maybe
> > > some of them are hard to replaced by simple stubs.
> > >
> > > Is my activity helpful?
> > >
> > > Ya, so helpful, I have more faith on this contribution now.
> > >
> > > [1] MemoryMXBeanImpl.createMemoryManagerHelper(String name, int
> > internalID,
> > > boolean isGC)
> > >
> > > Nathan, do you have similar or different plan for HARMONY-1407
> > integration?
> > > >
> > > > Thanks,
> > > > Andrey
> > > >
> > > >
> > > > On 9/18/06, Rui Hu <ro...@gmail.com> wrote:
> > > > > As I know so far, there is only java code in HARMONY-1407
> > > > > So, you can build the code on RI, Harmony(only fail on a signal bug
> > of
> > > > > java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK
> > > > successfully.
> > > > > But the native code of j.l.management is not available now, so
> > you'll
> > > > fail
> > > > > if you run the tests on Harmony, and got an UnsatisfiedLinkError.
> > > >
> > > >
> > > > On 9/18/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > > Yes. I have some docs that need to be put in SVN - I hope to do that
> > > > > today. Once we do that, we need to simply vote to accept the code.
> > > > >
> > > > > If you start working with it ahead of time, that will be good :)
> > > > >
> > > > > geir
> > > > >
> > > > >
> > > > > Nathan Beyer wrote:
> > > > > > Are there any documents or anything that needs to be resolved
> > before I
> > > > can
> > > > > > start working on the code in HARMONY-1407?
> > > > > >
> > > > > >
> > > > > >
> > > > > > http://issues.apache.org/jira/browse/HARMONY-1407
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Nathan
> > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail:
> > harmony-dev-help@incubator.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Robert Hu
> > > China Software Development Lab, IBM
> > >
> > >
> >
> > Thanks,
> > Andrey
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Robert Hu
> China Software Development Lab, IBM
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Rui Hu <ro...@gmail.com>.
On 10/5/06, Andrey Yakushev <an...@gmail.com> wrote:
>
> I've tried to follow you suggestions. The result:
>
> 1. The fix for unimplemented
> java.util.logging.LogManager.getLoggingMXBean could be simple, like:
>
> return LoggingMXBeanImpl.getInstance()
>
> But it bind logging module to LoggingMXBean implementation.
> Probably more clean solution would be:
>
> ObjectName loggingMXBeanName = new
> ObjectName(LOGGING_MXBEAN_NAME);
> MBeanServer platformBeanServer =
> ManagementFactory.getPlatformMBeanServer();
> Set loggingMXBeanSet =
> platformBeanServer.queryMBeans(loggingMXBeanName, null);
>
> if(loggingMXBeanSet.size() != 1) {
> throw new AssertionError("There Can Be Only One
> logging MX bean.");
> }
>
> Iterator i = loggingMXBeanSet.iterator();
> ObjectInstance loggingMXBeanOI = (ObjectInstance) i.next();
> String lmxbcn = loggingMXBeanOI.getClassName();
> Class lmxbc = Class.forName(lmxbcn);
> Method giMethod = lmxbc.getDeclaredMethod("getInstance");
> giMethod.setAccessible(true);
> LoggingMXBean lmxb = (LoggingMXBean) giMethod.invoke(null,
> new Object[] {});
>
> return lmxb;
>
> But this approach also supposes that implementation contains
> getInstance method, which is not always true as far as I know.
> Probably some other solution exists?
Sorry for reply so late.
Why not write LogManager.getLoggingMXBean like this:
return com.ibm.lang.management.ManagementUtils.getLoggingBean();
The similar implementation can be found in some public methods in
java.lang.management.ManagementFactory
2. One more problem fount is that
>
> \management\src\main\java\org\apache\harmony\lang\management\CompilationMXBeanImpl.java
> uses System.getProperty("java.compiler") which is not defined and it
> lead to NullPointerException in
> testGetAttribute(
> tests.org.apache.harmony.lang.management.CompilationMXBeanImplTest)
>
> Running tests with -Djava.compiler=jitrino removes this test error.
>
> It is interest that test_getProperty_Str from
>
> inincubator\harmony\enhanced\drlvm\trunk\vm\tests\kernel\java\lang\SystemExtensionTest
> tries to check that but couldn't due to error in test (using ||
> instead of &&).
3. As to StackTraceElement problem, I obtain the fail:
>
> javax.management.openmbean.OpenDataException: itemValue at index 12 is
> not a valid value for itemName stackTrace and itemType
> javax.management.openmbean.CompositeData(typename=[
> Ljavax.management.openmbean.CompositeData;,dimension=1,elementType=
> javax.management.openmbean.CompositeData
> TypeName: java.lang.StackTraceElement contains data:
> ItemName: className OpenType value:
> javax.management.openmbean.SimpleType(name = java.lang.String)
> ItemName: fileName OpenType value:
> javax.management.openmbean.SimpleType(name = java.lang.String)
> ItemName: lineNumber OpenType value:
> javax.management.openmbean.SimpleType(name = java.lang.Integer)
> ItemName: methodName OpenType value:
> javax.management.openmbean.SimpleType(name = java.lang.String)
> ItemName: nativeMethod OpenType value:
> javax.management.openmbean.SimpleType(name = java.lang.Boolean)
> )
> at javax.management.openmbean.CompositeDataSupport.validateContents
> (CompositeDataSupport.java:104)
> at javax.management.openmbean.CompositeDataSupport.init(
> CompositeDataSupport.java:81)
> at javax.management.openmbean.CompositeDataSupport.<init>(
> CompositeDataSupport.java:28)
> at
> tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.createGoodCompositeData
> (ThreadInfoTest.java:124)
> at
> tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.setUp(
> ThreadInfoTest.java:96)
> ...[skip]...
>
> First look at CompositeData for java.lang.StackTraceElement shows that
> names, types and values are Ok. This error appears even if
> StackTraceElement array length is equal to zero, so probably problem
> in CompositeData implementation. I will try to continue investigation,
> but any help is welcome.
I found the problem about "StackTraceElement" when I used "luni-kernel.jar"
(in jre/bin/default) in build-path of project, it could not compile; and
when I replaced it with "luni-kernel-stubs.jar" (in jre/lib/boot), it was
OK. Maybe your problem is not exactly as mine.
4. Final note (Is anybody still continue reading such a long text? :)
>
> I'm going to donate the written native method stubs but because they
> suppose some renaming in HARMONY-1407 they may demand some correction
> in future. Should I wait until HARMONY-1407 voting and committing?
I think the vote is coming, we'd best move on after voting, :-)
Thanks.
Thanks,
> Andrey
>
>
>
> On 9/20/06, Rui Hu <ro...@gmail.com> wrote:
> > On 9/20/06, Andrey Yakushev <an...@gmail.com> wrote:
> > >
> > > Do I understand correctly, that j.l.management support could be
> > > implemented for DRLVM as follows:
> > >
> > > 1. Integrate HARMONY-1407 into classlib and obtain
> > > UnsatisfiedLinkError on DRLVM.
> > > 2. Implement native methods in kernel classes as stubs returning some
> > > realistic values. It could allow test and jconsole running.
> > > 3. Replace these stabs one by one with possible adding of the
> > > interface functions in DRLVM modules like GC and TM.
> >
> >
> > Great. It's a good plan.
> >
> > Really I have tried to go through this plan "ahead of time" :)
> > > Currently I wrote native methods stubs and made run for the tests from
> > > HARMONY-1407. The result is:
> > > Tests run: 90, Failures: 15, Errors: 9
> > > 13 failures is StackTraceElement similar as Rui mentioned.
> >
> >
> > It's easy to fix.
> >
> > 8 errors due to not implemented method
> > > at java.util.logging.LogManager.getLoggingMXBean(
> LogManager.java
> > > :154)
> >
> >
> > It's easy to fix too. Just add one simple method to LogManager.
> >
> > Other 3 problems needs additional investigation
> >
> >
> > Can you list out them?
> > I found that most native methods of this component are related with VM
> > platform, and some Java methods are called by native code(e.g. [1]) .
> Maybe
> > some of them are hard to replaced by simple stubs.
> >
> > Is my activity helpful?
> >
> > Ya, so helpful, I have more faith on this contribution now.
> >
> > [1] MemoryMXBeanImpl.createMemoryManagerHelper(String name, int
> internalID,
> > boolean isGC)
> >
> > Nathan, do you have similar or different plan for HARMONY-1407
> integration?
> > >
> > > Thanks,
> > > Andrey
> > >
> > >
> > > On 9/18/06, Rui Hu <ro...@gmail.com> wrote:
> > > > As I know so far, there is only java code in HARMONY-1407
> > > > So, you can build the code on RI, Harmony(only fail on a signal bug
> of
> > > > java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK
> > > successfully.
> > > > But the native code of j.l.management is not available now, so
> you'll
> > > fail
> > > > if you run the tests on Harmony, and got an UnsatisfiedLinkError.
> > >
> > >
> > > On 9/18/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > Yes. I have some docs that need to be put in SVN - I hope to do that
> > > > today. Once we do that, we need to simply vote to accept the code.
> > > >
> > > > If you start working with it ahead of time, that will be good :)
> > > >
> > > > geir
> > > >
> > > >
> > > > Nathan Beyer wrote:
> > > > > Are there any documents or anything that needs to be resolved
> before I
> > > can
> > > > > start working on the code in HARMONY-1407?
> > > > >
> > > > >
> > > > >
> > > > > http://issues.apache.org/jira/browse/HARMONY-1407
> > > > >
> > > > >
> > > > >
> > > > > -Nathan
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Robert Hu
> > China Software Development Lab, IBM
> >
> >
>
> Thanks,
> Andrey
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Robert Hu
China Software Development Lab, IBM
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Andrey Yakushev <an...@gmail.com>.
I've tried to follow you suggestions. The result:
1. The fix for unimplemented
java.util.logging.LogManager.getLoggingMXBean could be simple, like:
return LoggingMXBeanImpl.getInstance()
But it bind logging module to LoggingMXBean implementation.
Probably more clean solution would be:
ObjectName loggingMXBeanName = new ObjectName(LOGGING_MXBEAN_NAME);
MBeanServer platformBeanServer =
ManagementFactory.getPlatformMBeanServer();
Set loggingMXBeanSet =
platformBeanServer.queryMBeans(loggingMXBeanName, null);
if(loggingMXBeanSet.size() != 1) {
throw new AssertionError("There Can Be Only One
logging MX bean.");
}
Iterator i = loggingMXBeanSet.iterator();
ObjectInstance loggingMXBeanOI = (ObjectInstance) i.next();
String lmxbcn = loggingMXBeanOI.getClassName();
Class lmxbc = Class.forName(lmxbcn);
Method giMethod = lmxbc.getDeclaredMethod("getInstance");
giMethod.setAccessible(true);
LoggingMXBean lmxb = (LoggingMXBean) giMethod.invoke(null,
new Object[] {});
return lmxb;
But this approach also supposes that implementation contains
getInstance method, which is not always true as far as I know.
Probably some other solution exists?
2. One more problem fount is that
\management\src\main\java\org\apache\harmony\lang\management\CompilationMXBeanImpl.java
uses System.getProperty("java.compiler") which is not defined and it
lead to NullPointerException in
testGetAttribute(tests.org.apache.harmony.lang.management.CompilationMXBeanImplTest)
Running tests with -Djava.compiler=jitrino removes this test error.
It is interest that test_getProperty_Str from
inincubator\harmony\enhanced\drlvm\trunk\vm\tests\kernel\java\lang\SystemExtensionTest
tries to check that but couldn't due to error in test (using ||
instead of &&).
3. As to StackTraceElement problem, I obtain the fail:
javax.management.openmbean.OpenDataException: itemValue at index 12 is
not a valid value for itemName stackTrace and itemType
javax.management.openmbean.CompositeData(typename=[Ljavax.management.openmbean.CompositeData;,dimension=1,elementType=javax.management.openmbean.CompositeData
TypeName: java.lang.StackTraceElement contains data:
ItemName: className OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: fileName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: lineNumber OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Integer)
ItemName: methodName OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.String)
ItemName: nativeMethod OpenType value:
javax.management.openmbean.SimpleType(name = java.lang.Boolean)
)
at javax.management.openmbean.CompositeDataSupport.validateContents(CompositeDataSupport.java:104)
at javax.management.openmbean.CompositeDataSupport.init(CompositeDataSupport.java:81)
at javax.management.openmbean.CompositeDataSupport.<init>(CompositeDataSupport.java:28)
at tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.createGoodCompositeData(ThreadInfoTest.java:124)
at tests.org.apache.harmony.lang.management.threads.ThreadInfoTest.setUp(ThreadInfoTest.java:96)
...[skip]...
First look at CompositeData for java.lang.StackTraceElement shows that
names, types and values are Ok. This error appears even if
StackTraceElement array length is equal to zero, so probably problem
in CompositeData implementation. I will try to continue investigation,
but any help is welcome.
4. Final note (Is anybody still continue reading such a long text? :)
I'm going to donate the written native method stubs but because they
suppose some renaming in HARMONY-1407 they may demand some correction
in future. Should I wait until HARMONY-1407 voting and committing?
Thanks,
Andrey
On 9/20/06, Rui Hu <ro...@gmail.com> wrote:
> On 9/20/06, Andrey Yakushev <an...@gmail.com> wrote:
> >
> > Do I understand correctly, that j.l.management support could be
> > implemented for DRLVM as follows:
> >
> > 1. Integrate HARMONY-1407 into classlib and obtain
> > UnsatisfiedLinkError on DRLVM.
> > 2. Implement native methods in kernel classes as stubs returning some
> > realistic values. It could allow test and jconsole running.
> > 3. Replace these stabs one by one with possible adding of the
> > interface functions in DRLVM modules like GC and TM.
>
>
> Great. It's a good plan.
>
> Really I have tried to go through this plan "ahead of time" :)
> > Currently I wrote native methods stubs and made run for the tests from
> > HARMONY-1407. The result is:
> > Tests run: 90, Failures: 15, Errors: 9
> > 13 failures is StackTraceElement similar as Rui mentioned.
>
>
> It's easy to fix.
>
> 8 errors due to not implemented method
> > at java.util.logging.LogManager.getLoggingMXBean(LogManager.java
> > :154)
>
>
> It's easy to fix too. Just add one simple method to LogManager.
>
> Other 3 problems needs additional investigation
>
>
> Can you list out them?
> I found that most native methods of this component are related with VM
> platform, and some Java methods are called by native code(e.g. [1]) . Maybe
> some of them are hard to replaced by simple stubs.
>
> Is my activity helpful?
>
> Ya, so helpful, I have more faith on this contribution now.
>
> [1] MemoryMXBeanImpl.createMemoryManagerHelper(String name, int internalID,
> boolean isGC)
>
> Nathan, do you have similar or different plan for HARMONY-1407 integration?
> >
> > Thanks,
> > Andrey
> >
> >
> > On 9/18/06, Rui Hu <ro...@gmail.com> wrote:
> > > As I know so far, there is only java code in HARMONY-1407
> > > So, you can build the code on RI, Harmony(only fail on a signal bug of
> > > java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK
> > successfully.
> > > But the native code of j.l.management is not available now, so you'll
> > fail
> > > if you run the tests on Harmony, and got an UnsatisfiedLinkError.
> >
> >
> > On 9/18/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > Yes. I have some docs that need to be put in SVN - I hope to do that
> > > today. Once we do that, we need to simply vote to accept the code.
> > >
> > > If you start working with it ahead of time, that will be good :)
> > >
> > > geir
> > >
> > >
> > > Nathan Beyer wrote:
> > > > Are there any documents or anything that needs to be resolved before I
> > can
> > > > start working on the code in HARMONY-1407?
> > > >
> > > >
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-1407
> > > >
> > > >
> > > >
> > > > -Nathan
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Robert Hu
> China Software Development Lab, IBM
>
>
Thanks,
Andrey
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Rui Hu <ro...@gmail.com>.
On 9/20/06, Andrey Yakushev <an...@gmail.com> wrote:
>
> Do I understand correctly, that j.l.management support could be
> implemented for DRLVM as follows:
>
> 1. Integrate HARMONY-1407 into classlib and obtain
> UnsatisfiedLinkError on DRLVM.
> 2. Implement native methods in kernel classes as stubs returning some
> realistic values. It could allow test and jconsole running.
> 3. Replace these stabs one by one with possible adding of the
> interface functions in DRLVM modules like GC and TM.
Great. It's a good plan.
Really I have tried to go through this plan "ahead of time" :)
> Currently I wrote native methods stubs and made run for the tests from
> HARMONY-1407. The result is:
> Tests run: 90, Failures: 15, Errors: 9
> 13 failures is StackTraceElement similar as Rui mentioned.
It's easy to fix.
8 errors due to not implemented method
> at java.util.logging.LogManager.getLoggingMXBean(LogManager.java
> :154)
It's easy to fix too. Just add one simple method to LogManager.
Other 3 problems needs additional investigation
Can you list out them?
I found that most native methods of this component are related with VM
platform, and some Java methods are called by native code(e.g. [1]) . Maybe
some of them are hard to replaced by simple stubs.
Is my activity helpful?
Ya, so helpful, I have more faith on this contribution now.
[1] MemoryMXBeanImpl.createMemoryManagerHelper(String name, int internalID,
boolean isGC)
Nathan, do you have similar or different plan for HARMONY-1407 integration?
>
> Thanks,
> Andrey
>
>
> On 9/18/06, Rui Hu <ro...@gmail.com> wrote:
> > As I know so far, there is only java code in HARMONY-1407
> > So, you can build the code on RI, Harmony(only fail on a signal bug of
> > java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK
> successfully.
> > But the native code of j.l.management is not available now, so you'll
> fail
> > if you run the tests on Harmony, and got an UnsatisfiedLinkError.
>
>
> On 9/18/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Yes. I have some docs that need to be put in SVN - I hope to do that
> > today. Once we do that, we need to simply vote to accept the code.
> >
> > If you start working with it ahead of time, that will be good :)
> >
> > geir
> >
> >
> > Nathan Beyer wrote:
> > > Are there any documents or anything that needs to be resolved before I
> can
> > > start working on the code in HARMONY-1407?
> > >
> > >
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-1407
> > >
> > >
> > >
> > > -Nathan
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Robert Hu
China Software Development Lab, IBM
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Tim Ellison <t....@gmail.com>.
Andrey Yakushev wrote:
> Do I understand correctly, that j.l.management support could be
> implemented for DRLVM as follows:
>
> 1. Integrate HARMONY-1407 into classlib and obtain
> UnsatisfiedLinkError on DRLVM.
> 2. Implement native methods in kernel classes as stubs returning some
> realistic values. It could allow test and jconsole running.
> 3. Replace these stabs one by one with possible adding of the
> interface functions in DRLVM modules like GC and TM.
>
> Really I have tried to go through this plan "ahead of time" :)
> Currently I wrote native methods stubs and made run for the tests from
> HARMONY-1407. The result is:
> Tests run: 90, Failures: 15, Errors: 9
> 13 failures is StackTraceElement similar as Rui mentioned.
Can you give details of the problems in StackTraceElement and we can fix
them -- raise a JIRA and let us know the number.
Thanks
Tim
> 8 errors due to not implemented method
> at
> java.util.logging.LogManager.getLoggingMXBean(LogManager.java:154)
> Other 3 problems needs additional investigation
>
> Is my activity helpful?
> Nathan, do you have similar or different plan for HARMONY-1407 integration?
>
> Thanks,
> Andrey
>
>
> On 9/18/06, Rui Hu <ro...@gmail.com> wrote:
>> As I know so far, there is only java code in HARMONY-1407
>> So, you can build the code on RI, Harmony(only fail on a signal bug of
>> java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK
>> successfully.
>> But the native code of j.l.management is not available now, so you'll
>> fail
>> if you run the tests on Harmony, and got an UnsatisfiedLinkError.
>
>
> On 9/18/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> Yes. I have some docs that need to be put in SVN - I hope to do that
>> today. Once we do that, we need to simply vote to accept the code.
>>
>> If you start working with it ahead of time, that will be good :)
>>
>> geir
>>
>>
>> Nathan Beyer wrote:
>> > Are there any documents or anything that needs to be resolved before
>> I can
>> > start working on the code in HARMONY-1407?
>> >
>> >
>> >
>> > http://issues.apache.org/jira/browse/HARMONY-1407
>> >
>> >
>> >
>> > -Nathan
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Andrey Yakushev <an...@gmail.com>.
Do I understand correctly, that j.l.management support could be
implemented for DRLVM as follows:
1. Integrate HARMONY-1407 into classlib and obtain
UnsatisfiedLinkError on DRLVM.
2. Implement native methods in kernel classes as stubs returning some
realistic values. It could allow test and jconsole running.
3. Replace these stabs one by one with possible adding of the
interface functions in DRLVM modules like GC and TM.
Really I have tried to go through this plan "ahead of time" :)
Currently I wrote native methods stubs and made run for the tests from
HARMONY-1407. The result is:
Tests run: 90, Failures: 15, Errors: 9
13 failures is StackTraceElement similar as Rui mentioned.
8 errors due to not implemented method
at java.util.logging.LogManager.getLoggingMXBean(LogManager.java:154)
Other 3 problems needs additional investigation
Is my activity helpful?
Nathan, do you have similar or different plan for HARMONY-1407 integration?
Thanks,
Andrey
On 9/18/06, Rui Hu <ro...@gmail.com> wrote:
> As I know so far, there is only java code in HARMONY-1407
> So, you can build the code on RI, Harmony(only fail on a signal bug of
> java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK successfully.
> But the native code of j.l.management is not available now, so you'll fail
> if you run the tests on Harmony, and got an UnsatisfiedLinkError.
On 9/18/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Yes. I have some docs that need to be put in SVN - I hope to do that
> today. Once we do that, we need to simply vote to accept the code.
>
> If you start working with it ahead of time, that will be good :)
>
> geir
>
>
> Nathan Beyer wrote:
> > Are there any documents or anything that needs to be resolved before I can
> > start working on the code in HARMONY-1407?
> >
> >
> >
> > http://issues.apache.org/jira/browse/HARMONY-1407
> >
> >
> >
> > -Nathan
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Yes. I have some docs that need to be put in SVN - I hope to do that
today. Once we do that, we need to simply vote to accept the code.
If you start working with it ahead of time, that will be good :)
geir
Nathan Beyer wrote:
> Are there any documents or anything that needs to be resolved before I can
> start working on the code in HARMONY-1407?
>
>
>
> http://issues.apache.org/jira/browse/HARMONY-1407
>
>
>
> -Nathan
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Posted by Rui Hu <ro...@gmail.com>.
As I know so far, there is only java code in HARMONY-1407
So, you can build the code on RI, Harmony(only fail on a signal bug of
java.lang.StackTraceElement in luni-kernel.jar), and IBM JDK successfully.
But the native code of j.l.management is not available now, so you'll fail
if you run the tests on Harmony, and got an UnsatisfiedLinkError.
On 9/18/06, Nathan Beyer <nb...@kc.rr.com> wrote:
>
> Are there any documents or anything that needs to be resolved before I can
> start working on the code in HARMONY-1407?
>
>
>
> http://issues.apache.org/jira/browse/HARMONY-1407
>
>
>
> -Nathan
>
>
>
--
Robert Hu
China Software Development Lab, IBM