Agree. More testcases shall be added and maybe we need an estimation and a plan before we start. Since the spec of beans module is so unclear that it will give us benefits if we can grasp the global image of the problem and where to refractor and what function shall be added.
On 7/5/07, Yang Paulex <[EMAIL PROTECTED]> wrote:
2007/7/5, Spark Shen <[EMAIL PROTECTED]>: > > 2007/7/5, Yang Paulex <[EMAIL PROTECTED]>: > > > > 2007/7/4, Alexei Zakharov <[EMAIL PROTECTED]>: > > > > > > Spark Chen wrote: > > > > > If no objection, I will go to implement those missing persistence > > > > > functionality. > > > > > > FYI we already have number of persistence delegates classes located in > > > org.apache.harmony.beans package, and FieldPersistenceDelegate is one > > > of them. > > > I agree to utilize existing implementation. But there are still others > missing. For example, java.util.Collection and its subclasses[1]. > > [1]http://issues.apache.org/jira/browse/HARMONY-4327 > > It contains the algorithm that is very close to one you've > > > implemented in the patch for HARMONY-4321. So I don't think we should > > > add new FieldPersistenceDelegate, let's fix the existing one instead > > > (if it needs fixing). BTW, we also have a special folder > > > (src/test/java-internal/org/apache/harmony/beans) where tests for > > > persistence delegates are located. Shouldn't we create something like > > > FieldPersistenceDelegateTest there? > > > > > > Seems the tests in src/test/java-internal/org/apache/harmony/beans are > > implementation tests, all of which fail on RI with message like " > > java.lang.NoClassDefFoundError: > > org/apache/harmony/beans/ArrayPersistenceDelegate ". But I think the > > persistent delegate mechanism are very similar with serialization, on > > which > > we need to be compatible with other Java SE implementation, so it makes > > sense to make them the API tests which pass on RI. Did I miss something? > > > I agree to regard these test cases as API tests. And then these > persistenceDelegate implementations better be placed at > src/main/java/java/beans corresponding to test case layout. IMO, test case layout and implementation class layout are different thing. What I meant is the test cases may need to be written against API factory method instead of construct implementation classes directly via implementation specific constructor/class, and the compatibility tests like serialization tests are needed. I have no preference in where the implementation classes locate. :) Thanks, > > > > > > 2007/7/3, Tony Wu <[EMAIL PROTECTED]>: > > > > On 7/3/07, Spark Shen <[EMAIL PROTECTED]> wrote: > > > > > I find beans.XMLEncoder does not persist > > java.lang.reflect.Fieldproperly. > > > > > And I suspect there are more classes not properly handled. > > > > > > > > > > > > > Yes, I think so. > > > > > I have reported a JIRA: > > > > > https://issues.apache.org/jira/browse/HARMONY-4321 > > > > > > > > > > If no objection, I will go to implement those missing persistence > > > > > functionality. > > > > > > > > > > > > > please go head:) > > > > > > > > > > > > -- > > > Alexei Zakharov, > > > Intel ESSD > > > > > > > > > > > -- > > Paulex Yang > > China Software Development laboratory > > IBM > > > > > > -- > Spark Shen > China Software Development Lab, IBM > -- Paulex Yang China Software Development laboratory IBM
-- Leo Li China Software Development Lab, IBM
