Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of wuyuehao@gmail.com designates
 209.85.142.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hZJqkoPixeOUq6/MzjzMIlOnFpGbwybaLvoWDtG5Z8B7TXemr8W6y+AXarzdSfO/7OrOktfJz3OHf3hFJWGt8De1V8sXZc11K9gnBqhC68dbgeUtlBVXKkNV+QDw3ruJP0A+KdnY7uCnYRyoCJ7yW7mAqfE7i+fV1K9ZNyZSI5s=
Message-ID: <211709bc0804160314u4b199fe7o1c9374583248bf8a@mail.gmail.com>
Date: Wed, 16 Apr 2008 18:14:20 +0800
From: "Tony Wu" <wuyuehao@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][jndi][ldap] - Refine implementation of
 LdapSchemaContextImpl (HARMONY-5716)
In-Reply-To: <4805CCEE.90504@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2030893739.1207922765085.JavaMail.jira@brutus>
	 <4805C3F1.9020804@gmail.com> <4805CCEE.90504@gmail.com>

What we need actually is some hashmaps. why we can not create it in
java src code such as setUp method through several/a lot hashmap.set()
. What's your concern on this manner?

On 4/16/08, Regis <xu.regis@gmail.com> wrote:
> I agree that the large binary file is hard to modify and maitain, maybe we
> have another choice to
> construct the schemaTable, using raw text data returned from server. We need
> parse the raw text
> data first, and then construct the hashmap. The data is in text format, so
> it's easy understand and modify.
>
> What i concerned about this way is for unit test it seems a bit complex and
> involve process of
> parsing schema which should be tested separately.
>
> Best Regards,
> Regis.
>
>
> Tim Ellison wrote:
> > Regis Xu (JIRA) wrote:
> >
> > > Let me explain.
> > >
> > > The file contains necessary data to construct LdapSchemaContextImpl
> instance for testing.
> > >
> > > LdapSchemaContextImpl is constructed using schema data queried from LDAP
> server, then
> > > it cached all scehma data in "schemaTable", it's fast for searching.
> > > It's best if we could test LdapSchemaContextImpl with "real data"
> returned from LDAP server. So we serialize the "real" schemaTable to the
> file and deserialize it when testing, then we got a "real"
> LdapSchemaContextImpl without connecting with server.
> > >
> > > for 1)  we can construct the table from java code but the schema data is
> too large, i think it's not reasonable
> > > to put it in java file.
> > >
> > > Maybe we could remove .ser from file name, which cause confusion with
> testing serialization capabilities.
> > >
> > > I hope i had myself explained clearly.
> > >
> >
> > Yes, it is a clear explanation Regis, but I have a concern that this
> serialized file is a large binary blob that is hard for people to modify if
> they choose to change the tests.
> >
> > I realize that we don't want to require an LDAP server to test against,
> and your idea for capturing the "real data" as a serialized data object
> makes sense.  But, what if there is a bug or enhancement that somebody else
> needs to make, and they don't have your LDAP server available to re-create
> the "real data"?  I think it will be a maintenance problem.
> >
> > Maybe I'm being too unreasonable, and right now I can't think of a
> different way to do it (other than write the Java source code to create the
> "real data" hashmap of hashmaps I saw when I deserialized the blob).
> >
> > Regards,
> > Tim
> >
> >
>


-- 
Tony Wu
China Software Development Lab, IBM