Hi again,
sorry for cross posting.
I'm providing some information about the GeoTools build break.
Read belove...
On Tue, Jan 20, 2009 at 1:26 AM, Daniele Romagnoli <
[email protected]> wrote:
> Hi Justin,
> I did my ImageIO-Ext, geotools and geoserver build tests against the JAI
> and JAI-ImageIO stable versions available at SUN's site on both Windows and
> Linux.
> They worked fine on my machine as well as on the Simone's one.
> I haven't received no error with Maven nor with Eclipse.
> The new plugin registers itself as the first ImageReaderSpi to be used to
> manage TIFF files in order to handle the double data management issue
> discovered by Simone in the SUN's jai-imageio library. However, it seems the
> problem is in the getJDKImageReaderWriterSPI method which seems isn't
> available in the pure java implementation.
> I'm investigating on it and I will provide you more feedback in 30 minutes.
Actually, I have added a fix to the TIFF plugin to avoid dependency on the
medialib accelerator (mlib_jai_xxx.dll on windows).
Now, only the OperationTest is still failing on my side ( after I have
deleted mlib_jai_xxx DLLs from JRE/BIN).
Anyway, taking a look on that classes, I have found these comments:
* <strong>NOTE:</strong>
* This test may fails when executed on a machine without the
<cite>mediaLib</cite> accelerator.
* On Windows, the {...@code mlib_jai.dll} and {...@code mlib_jai_mmx.dll} files
should exist in the
* {...@code jre/bin} directory, as well as {...@code mlibwrapper_jai.jar} in
{...@code jre/lib/ext}.
* Those {...@code .dll} files should be there if JAI has been installed with
the Sun standard
* installation program ({...@code jai-1_1_2_01-lib-windows-i586-jdk.exe}).
With such installation,
* everything should run fine. The {...@code .dll} files are probably missing
if JAI has been put in
* the classpath by Maven, like our past attempt on the 2.1 branch.
* <p>
* This behavior looks like a JAI bug to me. In theory, the pure Java mode
is supposed to produce
* exactly the same result than the <cite>mediaLib</cite> native mode; just
slower. This test
* failure suggests that it is not always the case. The
<cite>mediaLib</cite> native code seems
* right in this case (the bug would be in the pure Java code).
/*
* For a mysterious reason (JAI bug?), the following
test seems to fail when
* JAI is running in pure Java mode. If you get an
assertion failure on this
* line, then make sure that
"<your_jdk_path>/jre/bin/mlib_jai.dll" (Windows)
* or "lib/i386/libmlib_jai.so" (Linux) is presents in
your JDK installation.
*/
Therefore, it seems that the medialib accelerator is required to pass this
test.
Is the Hudson machine equipped with this library? If not, how this test
worked before?
Please let me know.
Regards,
Daniele
>
>
> Regards,
> Daniele
>
>
>
> On Mon, Jan 19, 2009 at 11:47 PM, Justin Deoliveira
> <[email protected]>wrote:
>
>> So it seems the problem is a recent change to geotools coverage and
>> geotiff modules, for GEOT-2289. The fix introduces a dependency on
>> imageio-ext-tiff which seems to be incompatible with the pure java jai image
>> io we are using.
>>
>> I rolled back the patch in my local checkout and things seem to be ok
>> again. Going to test a bit more but it seems to have resolved the issue.
>>
>> I also think this might be whats causing the geotools 2.5.x build to be
>> down... as there are test failures in the coverage module.
>>
>> I will hold off on committing the rolled back patch until I hear from
>> Daniele.
>>
>> -Justin
>>
>>
>> Justin Deoliveira wrote:
>>
>>> Hi all,
>>>
>>> During testing the release I tried to deploy the war in tomcat and got
>>> this error:
>>>
>>> java.lang.NoSuchMethodError:
>>> com.sun.media.imageioimpl.common.ImageUtil.getJDKImageReaderWriterSPI(Ljavax/imageio/spi/ServiceRegistry;Ljava/lang/String;Z)Ljava/util/List;
>>> at
>>> com.sun.media.imageioimpl.plugins.mtiff.TIFFImageWriterSpi.onRegistration(TIFFImageWriterSpi.java:129)
>>> at
>>> javax.imageio.spi.SubRegistry.registerServiceProvider(ServiceRegistry.java:698)
>>> at
>>> javax.imageio.spi.ServiceRegistry.registerServiceProvider(ServiceRegistry.java:285)
>>> at
>>> javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:189)
>>> at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:120)
>>> at
>>> javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:141)
>>> at javax.imageio.ImageIO.<clinit>(ImageIO.java:46)
>>> at
>>> org.geoserver.jai.JAIInitializer.initJAI(JAIInitializer.java:83)
>>> at
>>> org.geoserver.jai.JAIInitializer.initialize(JAIInitializer.java:30)
>>>
>>>
>>> I thought it might just be a mac issue but I can reproduce the problem on
>>> windows. When I installed the native jai and image io extensions on windows
>>> it worked. I will try to dig deeper but I was hoping someone more familiar
>>> with the jai stuff can comment.
>>>
>>> -Justin
>>>
>>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
>
>
> --
> -------------------------------------------------------
> Eng. Daniele Romagnoli
> Software Engineer
>
> GeoSolutions S.A.S.
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob: +39 328 0559267
>
>
> http://www.geo-solutions.it
>
> -------------------------------------------------------
>
>
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
