Marina Vatkina wrote on 9/17/09 11:12 AM:
> Bill Shannon wrote:
>> Jane Young wrote on 9/17/09 3:34 AM:
>>
>>> I'm also seeing the build failure in Windows.
>>> Caused by: java.io.EOFException
>>> at java.io.DataInputStream.readInt(DataInputStream.java:375)
>>> at
>>> sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:628)
>>> at
>>> sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
>>> at java.security.KeyStore.load(KeyStore.java:1185)
>>> at
>>> com.sun.enterprise.security.ssl.SecuritySupportImpl.loadKS(SecuritySupportImpl.java:194)
>>>
>>>
>>> at
>>> com.sun.enterprise.security.ssl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:147)
>>>
>>>
>>>
>>> and as Byron pointed out it's because the files in
>>> <home>\.glassfishv3-build\config are empty
>>> The files are empty because the NullPointerException is thrown in
>>> /security/core/src/main/java/com/sun/enterprise/security/common/Util.java:
>>>
>>> line 149
>>>
>>> //Util.java
>>> InputStream iStream =
>>> Util.class.getClassLoader().getResourceAsStream("config"+File.separator
>>> + fileName);
>>>
>>> while (iStream.available() > 0) { <-- line 149
>>> oStream.write(iStream.read());
>>> }
>>>
>>> iStream is null.... but the files are there in
>>> v3\security\core\target\classes\config. Can someone from security
>>> team take a look at this? In the meantime can
>>> we disable the ejb.EmbeddedTest since it's breaking Windows build?
>>
>>
>> No doubt someone is catching Exception and hiding this error? Grrr...
>
> This is per JDK design:
>
> Returns:
> A InputStream object or null if no resource with this name is found
Right, my complaint wasn't that it returned null, but that no one
checked for null, and worse that someone probably catch Exception
and ignored it and didn't report the failure, leading to a failure
much later when the files are empty.
Of course, if you fix the core bug, none of this will be an issue...