Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] RFC : native support bundles for java advanced imaging

Hello Jody, Hello List,

after a few days of testing I came to the following conclusion:
- the jai and imageio jars have to be within the same bundle, lets say javax.media.jai_imageio
- tested also with separate bundles for jai and imageio but got several exceptions when loading images like arcgrid.asc  files :

java.lang.ExceptionInInitializerError
at org.geotools.gce.arcgrid.ArcGridReader.createCoverage(ArcGridReader.java:511)
at org.geotools.gce.arcgrid.ArcGridReader.read(ArcGridReader.java:422)
at net.refractions.udig.render.internal.gridcoverage.basic.GridCoverageReaderRenderer.render(GridCoverageReaderRenderer.java:192)
at net.refractions.udig.render.internal.gridcoverage.basic.GridCoverageReaderRenderer.render(GridCoverageReaderRenderer.java:454)
at net.refractions.udig.project.internal.render.impl.RenderJob.startRendering(RenderJob.java:108)
at net.refractions.udig.project.internal.render.impl.RenderJob.run(RenderJob.java:213)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassCastException: com.sun.media.jai.imageioimpl.ImageReadWriteSpi cannot be cast to javax.media.jai.OperationRegistrySpi
at javax.media.jai.OperationRegistry.registerServices(OperationRegistry.java:2047)
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)

- in addition to the base bundle I created native fragments for the following platforms, each fragment contains a platform filter:
   win32 win32 x86
   linux gtk x86 and
   linux gtk x86_64

- the bundles net.refractions.udig.jai and its fragment net.refractions.udig.jai.macosx would not be required anymore (which copies the jars into folder resolved by a specific strategy

- the JRE that is shipped with udig releases doesn't have to have the jai/imageio jars in the extension folder anymore

- the JRE is still required for the gdal libraries

- the bundle net.refractions.udig.libs got and additional requirement that will be reexported : javax.media.jai_imageio


Now I have several questions before I request a pull for udig-platfrom:
1. How can I check, whether the native libraries are loaded correctly (API calls, something like isNativSupportAvailable())
2. Where can I find additional data sets to test, whether everything works correctly with JAI/imageio
    I tested with mentioned asc files and tiff files -> everything looks fine (on mac) but it was not possible to load *.sid and *.ecw files -> Add data wizard doesn't finish, no exceptions, Any suggestions here?
3. Could anybody test if I created the pull request the native libs on linux 32/64 bit, I can test on mac os and win32/64 bit with 32 bit runtime
4. Is there a wiki page that describes how to setup the JRE with gdal binaries for native support?

Thanks a lot, 
Frank

2011/12/29 Jody Garnett <jody.garnett@xxxxxxxxx>:
> Back online :-)
>
> Comments inline ...
>
> Jody,yesterday i build spi fly and added SPI-Provider to imageio bundle. The
> services were resolved dynamicly and could uses in any osgi bundle.
>
> That is great news! 
>
> I agree with you that this could be a way for the geotools and  geosolution
> jars as well. We can also test the static way,where it is not necessary to
> start bundles in a specific order (aris.spifly before other SPI providers
> and consumers). i guess i will setup a git repo to try this before moving it
> into udig-plarform.
> I'm not sure whether I got your point with jre and imageio.. what could be
> the problem?
>
> Well if the image-io bundles worked for you then apparently it was not a
> problem :-)
>
> I am just shaky on how imageio SPI formats work; I thought they needed to be
> seen by the Image support in the JRE. But perhaps if only GeoTools is asking
> (and your test above passes) then I am just worrying too much.
>
> So yes - measure more; worry less - great work Frank :-)
>
> Jody
>
> Looking forward..
> Frank
>
> Ps:merry christmas to Australian summer ;) we dont have snow in Germany
> ether
>
> Am 23.12.2011 06:06 schrieb "Jody Garnett" <jody.garnett@xxxxxxxxx>:
>
> Wow that is fun. 
>
> So it uses some tricks on the OSGi publish side:
> - 
>
> It also needs client code to "opt-in" using either:
> - static (i.e. post process your classes)
> - or dynamic (special OSGi class loader that injects stuff around
> ServiceLoader.load(Class) method)
>
> So here is what is making things strange for me; my understanding is that
> ...
> a) this would work great for GeoTools :-) We can load it up in a dynamic
> OSGi class loader thing that forces GeoTools to opt-in
> b) This may not work for ImageIO as it hooks into the image format support
> provided by the JRE (i.e. at a much lower level then OSGi - and I do not
> know how we can for the JRE to "opt-in")
>
> Still you are on to something so by all means give it a go! 
>
> -- 
> Jody Garnett
>
> On Friday, 23 December 2011 at 2:58 PM, Jody Garnett wrote:
>
> Oh cool I was not aware of spi-fly :-) 
>
> I also note if we can solve this problem for JAI then we can solve it for
> GeoTools; which means net.refractions.udig.libs can be retired completly.
>
> -- 
> Jody Garnett
>
> On Thursday, 22 December 2011 at 6:11 PM, Frank Gasdorf wrote:
>
> Quite a solid objection! I assume that all the imageio-ext jars from
> geosolutions in the net.refractions.uidog.libs/lib folder using this
> SPI functionality to contribute other image format readers/writers.
> Hmm .. just found apache aries spy-fly :
> http://aries.apache.org/modules/spi-fly.html taht could be a solution
> for that. But have to investigate a bit ..
>
> Frank
>
> 2011/12/21 Jody Garnett <jody.garnett@xxxxxxxxx>:
>
> into
>
>
>
>


Back to the top