Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of andrey.yakushev@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RvE7Xun5t4msXlANv7R58JY5crqlqYNGw3GIE4Bk49ti6e++Wa0p/jOmdzciyl/C80wD69NF2LKy+4NjjehYy4glWs/tMUlhLAooUhW2L/8TRakqLaWSONVL2Q7olM+Wx/IxbEE/PBZ7Jb0uE3zK6C6hIjFTwEcXz7f9w9cT3Do=
Message-ID: <3c7e1c080610110628t699c0f6dt57beeda3dd318475@mail.gmail.com>
Date: Wed, 11 Oct 2006 17:28:06 +0400
From: "Andrey Yakushev" <andrey.yakushev@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: HARMONY-1407: Contribution of Java code for package
 java.lang.management
In-Reply-To: <b6dc17480610101931p444ca634yd87fcb613ed50ce6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <002001c6dac6$112f4c50$0401a8c0@LITTLEGUY>
	 <450E3647.70602@pobox.com>
	 <3c7e1c080609192300v1a5431e4vea0e3531aa96668d@mail.gmail.com>
	 <b6dc17480609192343v3c50e8cbkf545d18401b83fbb@mail.gmail.com>
	 <3c7e1c080610050500i60a414bgfd2df69003e4e429@mail.gmail.com>
	 <b6dc17480610101931p444ca634yd87fcb613ed50ce6@mail.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 <roberthurui@gmail.com> wrote:
> 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
>
>

---------------------------------------------------------------------
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