Assigned
Status Update
Comments
lb...@gmail.com <lb...@gmail.com>
ju...@google.com <ju...@google.com>
je...@google.com <je...@google.com> #2
I need imageio to use the geotiff-jai library for extracting GeoTIFF tags so I can
create a KML server.
create a KML server.
lb...@gmail.com <lb...@gmail.com> #3
Also the native implementation of javax.imageio and the associated Sun jai-imageio
stuff eg com.sun.media.imageio.plugins.*.
This will significantly speed up image processing and will reduce used CPU hours/load
(which will be beneficial to Google too)
stuff eg com.sun.media.imageio.plugins.*.
This will significantly speed up image processing and will reduce used CPU hours/load
(which will be beneficial to Google too)
mi...@google.com <mi...@google.com> #4
How about using a pure Java imaging library? For example, is anybody willing to try
Sanselan and see if it meets their needs?
http://incubator.apache.org/sanselan/site/index.html
Sanselan and see if it meets their needs?
lb...@gmail.com <lb...@gmail.com> #5
Thanks for that link sounds interesting.
It's amazing what you can find on Apache these days!
Hmm, it could be very usefull for people after a pure Java replacement for ImageIO.
Pnly problem I have is that it doesn't have a GeoTIFF wrapper, but I'm sure that
won't be too hard.
May I suggest a wiki page be created with a list of alternative class libraries for
the blacklisted java.* classes?
I would still prefer the ImageIO classes be accessible (along with the other
blacklisted standard java.* packages...) as ImageIO allows for a speedy native
implementation of the core algorithims. And is generally more compatible with a lot
of existing software.
Only reason I can see this being blacklisted is because you want to force us to user
your imaging API which is billable (per call).
It's amazing what you can find on Apache these days!
Hmm, it could be very usefull for people after a pure Java replacement for ImageIO.
Pnly problem I have is that it doesn't have a GeoTIFF wrapper, but I'm sure that
won't be too hard.
May I suggest a wiki page be created with a list of alternative class libraries for
the blacklisted java.* classes?
I would still prefer the ImageIO classes be accessible (along with the other
blacklisted standard java.* packages...) as ImageIO allows for a speedy native
implementation of the core algorithims. And is generally more compatible with a lot
of existing software.
Only reason I can see this being blacklisted is because you want to force us to user
your imaging API which is billable (per call).
st...@gmail.com <st...@gmail.com> #6
te...@gmail.com <te...@gmail.com> #7
Would richfaces works ?
I need an answer please
I need an answer please
ap...@gmail.com <ap...@gmail.com> #8
I got the same error coming from Spring framework 3.0:
Caused by: java.lang.NoClassDefFoundError: javax.imageio.ImageIO is a restricted class. Please see the
Google App Engine developer's guide for more details.
at com.google.apphosting.runtime.security.shared.stub.javax.imageio.ImageIO.<clinit>(ImageIO.java)
at
org.springframework.http.converter.BufferedImageHttpMessageConverter.<init>(BufferedImageHttpMessageC
onverter.java:70)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.<init>(AnnotationMethod
HandlerAdapter.java:166)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.google.apphosting.runtime.security.shared.intercept.java.lang.reflect.Constructor_.newInstance(Construc
tor_.java:60)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:127)
Caused by: java.lang.NoClassDefFoundError: javax.imageio.ImageIO is a restricted class. Please see the
Google App Engine developer's guide for more details.
at com.google.apphosting.runtime.security.shared.stub.javax.imageio.ImageIO.<clinit>(ImageIO.java)
at
org.springframework.http.converter.BufferedImageHttpMessageConverter.<init>(BufferedImageHttpMessageC
onverter.java:70)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.<init>(AnnotationMethod
HandlerAdapter.java:166)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
com.google.apphosting.runtime.security.shared.intercept.java.lang.reflect.Constructor_.newInstance(Construc
tor_.java:60)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:127)
so...@gmail.com <so...@gmail.com> #9
Please add rich faces support on GAE
k....@gmail.com <k....@gmail.com> #10
Yes... please add RichFaces support!
de...@gmail.com <de...@gmail.com> #11
please add richfaces support
jb...@plentyoffish.com <jb...@plentyoffish.com> #12
[Comment deleted]
[Deleted User] <[Deleted User]> #13
yes.. richfaces would be perfect on google appengine
je...@google.com <je...@google.com> #14
Wonder if you could provide and adapter for ImageIO that would use the Google image
libraries.
libraries.
me...@gmail.com <me...@gmail.com> #15
Along with ImageIO, google appengine would also need to lift restrictions on
java.awt.Dimension, java.awt.Color, and some Graphics2D classes for RichFaces to work
on AppEngine. I would urge google to allow these classes so that at least some simple
functionality of RichFaces would work.
java.awt.Dimension, java.awt.Color, and some Graphics2D classes for RichFaces to work
on AppEngine. I would urge google to allow these classes so that at least some simple
functionality of RichFaces would work.
lb...@gmail.com <lb...@gmail.com> #16
Please add richfaces support. Thanks.
lo...@gmail.com <lo...@gmail.com> #17
please add richfaces support
un...@gmail.com <un...@gmail.com> #18
does anybody knows why richfaces using ImageIO?
ha...@gmail.com <ha...@gmail.com> #19
Please provide richfaces support. It's very impoprtant since many people use
richfaces and would like to deploy these applications to App Engine
richfaces and would like to deploy these applications to App Engine
me...@gmail.com <me...@gmail.com> #20
I want to add some valication code image in the register form of my app. If ImageIO
is not in the whitelist, how can I do this? Google App Engine is such a toy!
is not in the whitelist, how can I do this? Google App Engine is such a toy!
wo...@gmail.com <wo...@gmail.com> #21
Please add richfaces support.
PS: Richfaces also references java.awt.Dimension, which is another restricted class.
Thanks.
PS: Richfaces also references java.awt.Dimension, which is another restricted class.
Thanks.
ga...@google.com <ga...@google.com> #22
Please, add RichFaces support. Thank you.
jt...@gmail.com <jt...@gmail.com> #23
Please, add RichFaces support. We can't port our devs to GAE because of that.
jb...@plentyoffish.com <jb...@plentyoffish.com> #24
Please, add it!!!!! I can't use GAE without RichFaces
ma...@gmail.com <ma...@gmail.com> #25
Another vote for richfaces support for GAE
mi...@google.com <mi...@google.com> #26
I vote.......
RichFaces for GAE
RichFaces for GAE
at...@gmail.com <at...@gmail.com> #27
Please, add RichFaces support. Thank you.
pu...@gmail.com <pu...@gmail.com> #28
You sure do have my vote for this issue. I've been waiting for java.awt.* classes for
a long time to be white-listed on GAE.
a long time to be white-listed on GAE.
mi...@google.com <mi...@google.com>
je...@google.com <je...@google.com> #29
Please, do not add comments to say "Yay!, please please please support rich faces yes
yes yes". It notifies everyone following the issue (and apologies for this comment
too). Star the issue instead ! (like 98 people did so far!)
Thanks :)
Have fun !
yes yes". It notifies everyone following the issue (and apologies for this comment
too). Star the issue instead ! (like 98 people did so far!)
Thanks :)
Have fun !
Description
STEPS TO REPRODUCE:
1. Open a large project, build&run
2. Change anything in it, such as in some layout file.
3. Try to build&run
The bug is that very often, the IDE claims it can't delete some files.
In most cases, the error is something like that:
"
Couldn't delete C:\Users\User\AndroidStudioProjects\...\build\intermediates\compile_and_runtime_not_namespaced_r_class_jar\debug\R.jar
"
It can also complain differently.
The workaround is one or more of these:
1. Clean project
2. Delete the file/folder myself, unlocking if needed
3. Kill some sub-processes of the IDE
4. Close the IDE completely, and restart it .
------------------
Studio Build:
Version of Gradle Plugin:
Version of Gradle:
Version of Java:
OS:
Android Studio Giraffe | 2022.3.1 Canary 11
Build #AI-223.8836.35.2231.9848316, built on March 30, 2023
Runtime version: 17.0.6+0-b2043.56-9746777 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 10048M
Cores: 12
Registry:
external.system.auto.import.disabled=true
debugger.watches.in.variables=false
ide.text.editor.with.preview.show.floating.toolbar=false
Non-Bundled Plugins:
cn.jxzhang.plugin.json-formatter (1.4)
com.intellij.marketplace (223.8836.56)
com.dubreuia (2.3.0)
Show As ... (1.0.3)
String Manipulation (9.7.1)
GenerateSerialVersionUID (3.0.3)
idea.plugin.protoeditor (223.8214.6)
com.dethlex.numberconverter (1.5.0)
izhangzhihao.rainbow.brackets (2023.2.6)
com.ppismerov.ksvu (0.0.1)
com.google.mad-scorecard (1.2)
net.aquadc.mike.plugin (0.28)
com.developerphil.adbidea (1.6.8)
GenerateSerializationHelpers (1.0.6)