xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: extending xmlgraphics-commons
Date Mon, 19 Oct 2009 08:27:07 GMT
Ouch, I didn't realize that practically all of AWT is forbidden. In that
case you'll run into problems with many more classes:
- java.awt.Point
- java.awt.Dimension
- java.awt.Rectangle
- java.awt.geom.Rectangle2D
- java.awt.image.*
- java.awt.Color
- java.awt.color.ColorSpace
- java.awt.color.ICC_ColorSpace
...and many more

If I look at that, you'll end up changing half of FOP (introducing
parallel geometric, color and image infrastructure to AWT) as you can't
directly use some very basic infrastructure from J2SE. In that light,
you should rather talk to Google to open up a few unproblematic classes
from these packages. These restrictions are just too hard for an
application like FOP. Note that you can also pretty much forget SVG
because Batik is completely based on AWT. If I were you, I'd look for a
different platform to run FOP on. This looks like it's going to be VERY
painful on GAE.

On 19.10.2009 09:58:30 Nicanor Cristian wrote:
> 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




Jeremias Maerki


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


Mime
View raw message