xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicanor Cristian <deadho...@gmail.com>
Subject Re: extending xmlgraphics-commons
Date Mon, 19 Oct 2009 07:58:30 GMT
Hi Jeremias,

First of all, thank you for your answer. Unfortunately, the imageio
classes are not the only problem. I modified fop to make him ignore
"external-graphic" tags, just to see if there were any other classes not
supported by GAE and yes, there were. After deeper analysis, I decided
not to modify anymore xmlgraphics-common, but fop, because we want to
stay high level with the coding. Therefore I should move this discussion
to one of fop's mailing lists.
The unsupported library is java.awt.geom.AffineTransform. Unfortunately,
this class seems to be used to render blocks, and I suppose, is the
basis of the rendering of all elements. I'll go on in this direction,
for now.
Here is the stack trace, maybe will give you some ideas:

Error for /TestFOP
java.lang.NoClassDefFoundError: java.awt.geom.AffineTransform is a restricted class. Please
see the Google App Engine developer's guide for more details.
	at com.google.apphosting.runtime.security.shared.stub.java.awt.geom.AffineTransform.<clinit>(AffineTransform.java)
	at org.apache.xmlgraphics.java2d.GraphicContext.<init>(GraphicContext.java:59)
	at org.apache.fop.render.intermediate.IFGraphicContext.<init>(IFGraphicContext.java:42)
	at org.apache.fop.render.intermediate.IFRenderer.<init>(IFRenderer.java:127)
	at org.apache.fop.render.RendererFactory.createRendererForDocumentHandler(RendererFactory.java:313)
	at org.apache.fop.render.RendererFactory.tryIFDocumentHandlerMaker(RendererFactory.java:290)
	at org.apache.fop.render.RendererFactory.createRenderer(RendererFactory.java:270)
	at org.apache.fop.area.RenderPagesModel.<init>(RenderPagesModel.java:69)
	at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:130)
	at org.apache.fop.area.AreaTreeHandler.<init>(AreaTreeHandler.java:102)
	at org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:359)
	at org.apache.fop.fo.FOTreeBuilder.<init>(FOTreeBuilder.java:105)
	at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:100)
	at org.apache.fop.apps.Fop.<init>(Fop.java:78)
	at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:255)
	at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:232)
	at cri.almaitalia.AlmaOffice.server.Servlets.TestFOP.genPDF(TestFOP.java:90)
	at cri.almaitalia.AlmaOffice.server.Servlets.TestFOP.doPost(TestFOP.java:56)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
	at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
	at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
	at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:238)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
	at org.mortbay.jetty.Server.handle(Server.java:313)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
	at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
	at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:139)
	at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:239)
	at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5135)
	at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5133)
	at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
	at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:363)
	at com.google.net.rpc.impl.Server$2.run(Server.java:814)
	at com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56)
	at com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:516)
	at com.google.net.rpc.impl.Server.startRpc(Server.java:769)
	at com.google.net.rpc.impl.Server.processRequest(Server.java:351)
	at com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:437)
	at com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319)
	at com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290)
	at com.google.net.async.Connection.handleReadEvent(Connection.java:436)
	at com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:762)
	at com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:207)
	at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101)
	at com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251)
	at com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:396)
	at java.lang.Thread.run(Unknown Source)

Will keep you updated as I go on.
Thanks,
Christian.


Jeremias Maerki wrote:
> Hi Christian
>
> No, that's not entirely true: the whole image loader package makes use
> of at least ImageInputStream which is part of ImageIO. Without that
> class you can't load any image. That was a convenient choice because
> ImageIO is guaranteed to be available in any J2SE >=1.4 environment. Of
> course, GAE plays you a bad joke here. You can probably retrofit the
> minimal necessary parts of ImageIO in a separate JAR to make the image
> loading work. You may want to look into the Apache Harmony [1] which has
> a incomplete, but (for this case) probably sufficient clean-room
> implementation available (bundled in a JAR) that could fill the gap here.
>
> I guess one problem with ImageIO is that one of the ImageInputStream
> implementations uses a temporary file to achieve random access to the
> image data. If configured properly you can force that into memory:
> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/ImageIO.html#setUseCache(boolean)
>
> What we have as documentation on the image loading framework is here:
> http://xmlgraphics.apache.org/commons/image-loader.html
>
> If possible, try to avoid rewriting larger parts of the code as
> you'll end up maintaining it on your end. It's better to analyze just
> what can be improved in our code to make that unnecessary. You may also
> want start a little document on the wiki about running FOP on GAE for
> the benefit of anyone trying to do the same thing later.
>
> Please keep us in the loop about your progress to run FOP in GAE. I'm
> curious how well it goes. Good luck!
>
> [1] http://harmony.apache.org
>
>
> On 16.10.2009 12:52:45 Nicanor Cristian wrote:
>   
>> Hello everyone!
>>
>> This is my first email to this group.
>> I have a couple of questions regarding xmlgraphics-commons (and also
>> it's integration with fop). Here we go:
>>
>> I must port some java code that generates pdfs from xslfo to google
>> application engine. Unfortunately, GAE (google application engine) does
>> not support javax.imageio classes. My idea is to improve
>> xmlgraphics-commons in some way, in order to do the same operations, but
>> using the GAE imaging apis.
>> Also I would consider as an option the rewriting of the only parts that
>> are called by fop when converting xslfo to pdf and that are using
>> javax.imageio classes. What is your advice? How could I accomplish that?
>> Where could I find some good documentation about the classes?
>>
>> I took a fast look at the sources and it seemed to me that the classes
>> using javax.imageio classes reside in the
>> org.apache.xmlgraphics.image.loader.impl.imageio package only. Is that true?
>>
>>
>> Thanks a lot,
>> Christian.
>>     
>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message