harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rui Hu" <roberthu...@gmail.com>
Subject Re: HARMONY-1407: Contribution of Java code for package java.lang.management
Date Wed, 11 Oct 2006 02:31:57 GMT
On 10/5/06, Andrey Yakushev <andrey.yakushev@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 <roberthurui@gmail.com> wrote:
> > On 9/20/06, Andrey Yakushev <andrey.yakushev@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 <roberthurui@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. <geir@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message