DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4348>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4348 FOP has no mechanism to extend protocols Summary: FOP has no mechanism to extend protocols Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] To be used in a web environment, FOP needs to have some sort of mechanism to process urls that are relative to a web context. Cocoon uses a "context://" protocol for this purposes--but it can't set the URLProtocolHandlerFactory for the JVM if the servlet container does it first. Both Batik and Cocoon have mechanisms to get around this limitation. Cocoon provides an implementation for Batik so that users can keep using the "context://" protocol. It would be great if FOP either used Cocoon's mechanism or Batik's. That would reduce the number of URL adapters a project needs to write. In fact, since FOP already used Batik for inline SVG graphics, it would be a natural extension to use their mechanism. That way there is a consistent environment throughout. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
