Well that was a miserable experience. Build failed on the build box as
Logging was not always able to access JAI. I have added try/catch code
around the reference revealing the following:
Logging unable to redirect JAI errors: java.lang.NoClassDefFoundError:
com.sun.media.jai.codec.SeekableStream
The result is a bunch of safety checks and I am not entirely happy with the
result.
Jody Garnett
On Tue, May 13, 2014 at 9:41 AM, Jody Garnett <[email protected]>wrote:
> Okay result is up - https://github.com/geotools/geotools/pull/453
>
> This is much less effort for developers, the pull request also includes a
> second commit with javadoc clarifications for GeoTools.init()
>
> Jody Garnett
>
>
> On Tue, May 13, 2014 at 8:25 AM, Jody Garnett <[email protected]>wrote:
>
>> Got one failure in:
>>
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.395 sec
>> <<< FAILURE! - in
>> org.geotools.gce.imagemosaic.processing.ArtifactsFilterTest
>> testArtifact(org.geotools.gce.imagemosaic.processing.ArtifactsFilterTest)
>> Time elapsed: 0.323 sec <<< ERROR!
>> java.lang.ExceptionInInitializerError: null
>> at org.geotools.util.logging.Logging.<clinit>(Logging.java:115)
>> at
>> org.geotools.image.palette.ColorIndexerDescriptor.<clinit>(ColorIndexerDescriptor.java:43)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:270)
>> at
>> javax.media.jai.RegistryFileParser.getInstance(RegistryFileParser.java:227)
>> at
>> javax.media.jai.RegistryFileParser.registerDescriptor(RegistryFileParser.java:352)
>> at
>> javax.media.jai.RegistryFileParser.parseFile(RegistryFileParser.java:287)
>> at
>> javax.media.jai.RegistryFileParser.loadOperationRegistry(RegistryFileParser.java:57)
>> at
>> javax.media.jai.OperationRegistry.registerServices(OperationRegistry.java:2033)
>> at
>> javax.media.jai.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:612)
>> at
>> javax.media.jai.OperationRegistry.initializeRegistry(OperationRegistry.java:365)
>> at javax.media.jai.JAI.<clinit>(JAI.java:560)
>> at
>> org.geotools.gce.imagemosaic.processing.ArtifactsFilterTest.setup(ArtifactsFilterTest.java:37)
>>
>> This is due to JAI.getDefaultInstance() returning null? Simple enough to
>> check for, but not sure what this test is doing to JAI :)
>>
>>
>> Jody Garnett
>>
>>
>> On Tue, May 13, 2014 at 7:51 AM, Jody Garnett <[email protected]>wrote:
>>
>>> Briefly GeoTools.init() was going to register an ImagingListener. The
>>>>> rejected pull request added GeoTools.init() to each test case @Before
>>>>> method.
>>>>>
>>>>
>>>> Mind, I did not mean to reject the pull request, just wanted to express
>>>> concern on its (lack of) future maintability
>>>>
>>>
>>> Based on your feedback I am happy to reject the pull request. I actually
>>> had both ideas yesterday and took the least short-term risk in order to try
>>> out the change and confirm it does not have undue side effects.
>>>
>>> In todays meeting we hit on another approach. In the static init of our
>>>>> logging class I will check if JAI has an ImagingListener, and if it is
>>>>> null
>>>>> I will add in our own.
>>>>>
>>>>
>>>> Right. Anyone knows if that might present issues we haven't considered?
>>>>
>>>
>>> I think it will be fine, I was more concerned that introducing
>>> GeoServer.int() everywhere would slow down tests - as it plays some silly
>>> games to try and connect to first commons logging and then log4j before
>>> defaulting to Java logging.
>>> --
>>> Jody
>>>
>>
>>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
