Putting the data into resources makes sense since you may not always be
able to keep the .ser file next to the .java file anyway.
When we extend the source tree to include platform-specific code there
may be cases where instances of a 'common' (to all platforms)
serializable type has non-transient references to instances of
platform-dependent types. In this case there will need be .ser files
for each platform.
Regards,
Tim
Geir Magnusson Jr wrote:
>
>
> Stepan Mishura wrote:
>> Hi George,
>>
>> I like you idea with loading test's resource files. I don't see any
>> maintenance issues with putting all resource files into
>> "src/test/resources"
>> folder, for example, if a test have several resource files then I'd
>> like to
>> keep them in separate folder rather then in a test's folder. Also don't
>> think that there will be name collision problems: java files go to
>> "test/java" and resource files go to "test/resources". Is anybody
>> going to
>> put class files there?
>
> As long as you keep a parallel package tree, it should be equivalent of
> how we do it now. Not quite sure what we gain other than it's neater...
>
> geir
>
>>
>> George Harley wrote:
>>> 2) The need for the "TEST_SRC_DIR" system property goes away if method
>>> getDataFile() were updated to use java.net.URI.
>>> e.g,
>>>
>>> protected File getDataFile(int index) {
>>> String name = "/" + this.getClass().getName().replace('.', '/') + "."
>>> + index + ".dat";
>>> return new
>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>
>>
>> FYI, SerializationTest.java is not the only one case. There are few
>> places
>> where "TEST_SRC_DIR" system property is used, for example, policy
>> resource
>> files see:
>> modules/security/test/common/unit/javax/security/auth/PolicyTest.java
>> modules/security/test/common/unit/javax/security/auth/jaas_policy1.txt
>> modules/security/test/common/unit/javax/security/auth/jaas_policy2.txt
>>
>> I think it won't be an issue to fix them if your suggestion will be
>> accepted.
>>
>> BTW, as far as I remember we agreed to call new security module 'auth'
>> because of 'JAAS' trademark issues so I guess we should rename two policy
>> files say to auth_policy<n>.txt. I'm going to search all such cases and
>> provide a patch.
>>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>> On 3/11/06, George Harley wrote:
>>> Hi Mikhail (again),
>>>
>>> Just a couple of brief observations about the SerializationTest.java
>>> code as it stands in SVN today :
>>>
>>> 1) The reference/golden .dat files for Serializable classes in a given
>>> module could be added under the module's src/test/resources directory
>>> (in sub-folders corresponding to their package names). In an Ant build
>>> these would be copied under the test bin using a tweaked version of the
>>> "copy-test-resources" target (see the proposed changes to
>>> make/build-java.xml contained in the HARMONY-57). At runtime this would
>>> make the .dat files available from the classpath.
>>>
>>> 2) The need for the "TEST_SRC_DIR" system property goes away if method
>>> getDataFile() were updated to use java.net.URI.
>>> e.g,
>>>
>>> protected File getDataFile(int index) {
>>> String name = "/" + this.getClass().getName().replace('.', '/') + "."
>>> + index + ".dat";
>>> return new
>>> File(URI.create(this.getClass().getResource(name).toString()));
>>>
>>>
>>> It seems to me that the src/test/resources directory would be an ideal
>>> place to keep a module's reference .dat files.
>>>
>>> Best regards,
>>> George
>>>
>>>
>>> George Harley wrote:
>>>> Mikhail Loenko wrote:
>>>>> 2006/3/9, George Harley <[EMAIL PROTECTED]>:
>>>>> ...
>>>>>
>>>>>> Such a testing effort still sounds pretty daunting though.
>>>>>>
>>>>> BTW, there is a framework for serialization testing which is currently
>>>>> in the security module:
>>>>>
>>>>>
>>> modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
>>>
>>>>>
>>>>> It serves to simplify serialization testing and has the docs inside.
>>>>> Actually
>>>>> almost all serializable security-related classes are tested with this
>>>>> framework.
>>>>>
>>>>> Does it make sense to move the framework to a common place?
>>>>>
>>>> Hi Mikhail !
>>>>
>>>> I've spent a little bit of time running this (with a couple of my own
>>>> little concrete subclasses of SerializationTest) and I really like it.
>>>> It was pretty straightforward to create a JUnit error for the case of
>>>> java.util.TimeZone after my overridden version of getData() used
>>>> TimeZone.getDefault() to generate a couple of TimeZone instances from
>>>> the RI.
>>>>
>>>> I can definitely see a case for broadening this approach outside just
>>>> the security classes. Really impressive stuff !
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
