On 6/20/07, Tony Wu <[EMAIL PROTECTED]> wrote:
On 6/19/07, Stepan Mishura <[EMAIL PROTECTED]> wrote: > On 6/19/07, Tony Wu <[EMAIL PROTECTED]> wrote: > > On 6/19/07, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > On 6/19/07, Tony Wu <[EMAIL PROTECTED]> wrote: > > > > Hi Stepan and Alexei, > > > > > > > > I'm sorry I should post here to discuss before I commit. The reason is > > > > Jndi has different requirement against other modules on ASN1. > > > > For > > > > example, following code throws exception on harmony while passes on > > > > RI. > > > > > > > > String Id="test"; > > > > boolean crit=false; > > > > byte[] ber1={48,1,10,1,0}; > > > > SortResponseControl src=null; > > > > src = new SortResponseControl(Id, crit, ber1); > > > > > > > > > > From the first glance it is incorrect - the encoding doesn't follow to > > > the spec for SortResponseControl. I don't know why RI accepts the the > > > passed encoding in the test above. > > > > > Yes, it is a malformed input, but seems RI has fault rolerance in jndi > > against in security. besides, RI can get the right result with the > > malformed input, say following tests passed on RI: > > assertEquals(src.getResultCode(), 0); > > > > IMHO, it may be not possible (and sometimes doesn't make sense) to > reach 100% compatibility with RI - there are a lot of variants for > malformed input and but the spec. doesn't say how to process it. So > you have to test RI a lot to figure out which malformed input it > accepts and how to interprets it. >According to the Compatibility Guildline[1], we should follow RI if spec does not describe the behavior explicitly unless RI is illegal, especially in Exception case. say, "The Harmony class libary code aims to be fully compatible with the Reference Implementation (RI) of the Java Specification by matching the exception characteristics of each method." please correct if I misunderstand.
The spec for the constuctor says: "Parameters: ... value - The control's ASN.1 BER encoded value..." The ASN.1 encoding rules is common for all applications/protocols. So for me the agrument that "Jndi has different requirement against other modules on ASN1" looks confusing. Can you point out where these requirements are written? I can hardly believe that it says that invalid encodings are acceptable.
I'm afraid that if we throw exception while RI does not in case above, it may break some application which depends on RI's behavior. IMHO, we'd better follow the behavior of RI in jndi. Agree?
Yes, we may beak application that relies on encodings that are invalid according to BER spec ...IMHO it is not good for the application. Well, as far as I see RI just ignores a value of the length byte. Of cause we may do the same to extend BerInputStream and remove this check. This approach looks better for me then copying all encoders/decoders to 'jndi' module. But personally, I'd follow BER spec. and reject invalid encodings. Thanks, Stepan.
[1]http://harmony.apache.org/subcomponents/classlibrary/compat.html > Thanks, > Stepan. > > > > > The stack trace is[1] > > > > > > > > If I fix it in security directly, some regression[2] will be caused. > > > > I'm not an expert on security, so I believe it is a temp workaround > > > > for jndi. > > > > > > I don't agree with doing temp workarounds in such way. Otherwise we'll > > > have a lot of duplicated code in a number of modules. > > > > > > As far as I can see 'jndi' uses ASN.1 BER. And BER functionality was > > > only partly implemented - so a failure may be caused by unimplemented > > > functionality or bug in existing code. I stand for investigating such > > > issues and fix them in one place. > > > > > > But as I wrote above the passed encoding looks invalid. So additional > > > investigation is required. > > > > > Kelvin and I is looking for an elegant way too. > > > > > Thanks, > > > Stepan. > > > > > > > I'd like to roll back this commit and wait for discussion > > > > here. > > > > > > > > [1] > > > > org.apache.harmony.security.asn1.ASN1Exception: Wrong content length > > > > at org.apache.harmony.security.asn1.BerInputStream.<init>(BerInputStream.java:12) > > > > at org.apache.harmony.security.asn1.DerInputStream.<init>(DerInputStream.java:39) > > > > at org.apache.harmony.security.asn1.ASN1Type.decode(ASN1Type.java:98) > > > > at javax.naming.ldap.SortResponseControl.<init>(SortResponseControl.java:114) > > > > at org.apache.harmony.jndi.tests.javax.naming.ldap.TestSortResponseControl.testSortResponseControl019(TestSortResponseControl.java:440) > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > > > at java.lang.reflect.Method.invoke(Method.java:258) > > > > at junit.framework.TestCase.runTest(TestCase.java:154) > > > > at junit.framework.TestCase.runBare(TestCase.java:127) > > > > at junit.framework.TestResult$1.protect(TestResult.java:16) > > > > at junit.framework.TestResult.runProtected(TestResult.java:124) > > > > at junit.framework.TestResult.run(TestResult.java:19) > > > > at junit.framework.TestCase.run(TestCase.java:118) > > > > at junit.framework.TestSuite.runTest(TestSuite.java:28) > > > > at junit.framework.TestSuite.run(TestSuite.java:23) > > > > at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > > > > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > > > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > > > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > > > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > > > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > > > > > > > > > > > > [2] > > > > test_Ctor$LbyteLintLint Failure No expected ASN1Exception > > > > > > > > junit.framework.AssertionFailedError: No expected ASN1Exception at > > > > org.apache.harmony.security.tests.asn1.der.BerInputStreamTest.test_Ctor$LbyteLintLint(BerInputStreamTest.java:136) > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > > > > > > > On 6/19/07, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > > +1 to Stepan's question > > > > > > > > > > On 6/19/07, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > > > Hi Tony,Kelvin, > > > > > > > > > > > > I'm confused with the issue resolution. The ASN.1 encoders/decoders > > > > > > from 'security' module used by other modules (auth, crypto). But I can > > > > > > not understand why 'jndi' module need the separate/own set of > > > > > > encoders/decoders copied from 'security' module (r548598). What's > > > > > > wrong with importing it from 'security' module? Could you comment? > > > > > > > > > > > > Thanks, > > > > > > Stepan. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Tony Wu (JIRA) [mailto:[EMAIL PROTECTED] > > > > > > Sent: Tuesday, June 19, 2007 12:10 PM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: [jira] Commented: (HARMONY-4226) [classlib][jndi] Class > > > > > > SortResponseControl has some failures > > > > > > > > > > > > > > > > > > [ https://issues.apache.org/jira/browse/HARMONY-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506046 > > > > > > ] > > > > > > > > > > > > Tony Wu commented on HARMONY-4226: > > > > > > ---------------------------------- > > > > > > > > > > > > Hi Kelvin, > > > > > > This patch brings extra dependency from security to jndi. I suggest > > > > > > that we use the Messages.java in jndi rather than that in security. > > > > > > > > > > > > > [classlib][jndi] Class SortResponseControl has some failures > > > > > > > ------------------------------------------------------------ > > > > > > > > > > > > > > Key: HARMONY-4226 > > > > > > > URL: https://issues.apache.org/jira/browse/HARMONY-4226 > > > > > > > Project: Harmony > > > > > > > Issue Type: Bug > > > > > > > Components: Classlib > > > > > > > Environment: linux and windows > > > > > > > Reporter: Kelvin Ye > > > > > > > Assignee: Tony Wu > > > > > > > Attachments: harmony-4226.zip > > > > > > > > > > > > > > > > > > > > > Class SortResponseControl will fail in the following test cases, but RI will pass. > > > > > > > String Id="test"; > > > > > > > boolean crit=false; > > > > > > > byte[] ber1={48,1,10,1,0}; > > > > > > > byte[] ber2={48,5,10,1,3}; > > > > > > > byte[] ber3={48,3,10,2,3,3}; > > > > > > > byte[] ber4={48,4,10,1,3,3,3}; > > > > > > > byte[] ber5={48,8,10,1,3,(byte)128,3,'T','e','s','t'}; > > > > > > > SortResponseControl src=null; > > > > > > > src = new SortResponseControl(Id, crit, ber1); > > > > > > > assertEquals(Id, src.getID()); > > > > > > > assertEquals(src.getResultCode(), 0); > > > > > > > src = new SortResponseControl(Id, crit, ber2); > > > > > > > assertEquals(src.getResultCode(), 3); > > > > > > > src = new SortResponseControl(Id, crit, ber3); > > > > > > > assertEquals(src.getResultCode(), 771); > > > > > > > src = new SortResponseControl(Id, crit, ber4); > > > > > > > assertEquals(src.getResultCode(), 3); > > > > > > > src = new SortResponseControl(Id, crit, ber5); > > > > > > > assertEquals(src.getResultCode(), 3); > > > > > > > assertEquals("Tes", src.getAttributeID()); > > > > > > > > > > > > -- > > > > > > This message is automatically generated by JIRA. > > > > > > - > > > > > > You can reply to this email to add a comment to the issue online > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Stepan Mishura > > > > > > Intel Enterprise Solutions Software Division > > > > > > > > > > > > > > > > > > > > > -- > > > > > With best regards, > > > > > Alexei, > > > > > ESSD, Intel > > > > > > > > > > > > > > > > > -- > > > > Tony Wu > > > > China Software Development Lab, IBM > > > > > > > > > -- > > Tony Wu > > China Software Development Lab, IBM > > > -- Tony Wu China Software Development Lab, IBM
