extending xmlgraphics-commons

[Nicanor Cristian]

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.

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

[Jeremias Maerki-2]

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@...
For additional commands, e-mail: general-help@...

[Nicanor Cristian]

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@...
> For additional commands, e-mail: general-help@...
>
>
>  

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

[Jeremias Maerki-2]

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@...
> > For additional commands, e-mail: general-help@...
> >
> >
> >  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...

Jeremias Maerki


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