I've done a lot with the CXF multi-part support, and I could have sworn that it's an implementation of the JAX-RS standard.
Spring is no longer required for CXF, though I'm accustomed to using it ,and there's considerable OSGi fermentation at CXF that I'm not always qualified to comprehend. For the 'here's a war, drop it into tomcat' case, it seems to me that the mass of CXF with or without Spring is not an issue, though obviously a lighter version would be easier to disassemble and reassemble into something else, like OSGi. I'm not denying that a claiming that a pure servlet would be intractable, just noting that I've been knocking out JAX-RS services, often with multi-part, so it would be straightforward *for me*. I await other commentary. On Thu, Mar 10, 2011 at 3:53 AM, Jeremias Maerki <d...@jeremias-maerki.ch> wrote: > As already mentioned in a different place: sounds interesting. > > Some thoughts of mine on this: > I'd prefer a REST service over a SOAP service. Ideally, this would work > with plain JAX-RS so it is independent of the implementation but since > such a service would certainly require multipart support that seems > impossible. A real pity that hasn't been standardized, yet. > > We already have basic (demo) servlets in Apache FOP but they are not > suitable for real-life scenarios. The problem with that one is mainly > that the caller needs to know the location of the stylesheets and give > them as local file names which is totally against the idea of a servlet. > Furthermore, there's also no guard against DoS attacks which are easy > with a CPU- and sometimes memory-hungry FOP. Just throw a handful of > jobs at it simultaneously and see what happens. > > If I had to come up with a set of requirements, it would look like this: > - Ability to set up a config file. > - Ability to set up a URIResolver that can be used to access the > stylesheets, fonts, images etc. without the requirement to know where > exactly these resources are (file-system, CMS, website etc.) > - Caching of stylesheets (Templates instance) > - Ability to configure pre-defined processing scenarios, identified by a > name, that include stylesheet(s) and other resources. [1] > - HTTP POST payloads can be XML files or URIs identifying XML content > lying elsewhere (configured URIResolver must be able to resolve that). > - Semaphore for limiting concurrency. > > [1] Basically, I would want to just HTTP POST an XML file with a > "Scenario" header entry and get back my PDF (or whatever MIME type I > specify in the "Accept" header). > > I must say that I have all that (and more) already for myself as part of > a larger solution. I recently threw out Apache CXF in favor of Jersey to > take Spring out of the equation which in an OSGi environment constantly > caused grieve in production (Spring OSGi services simply don't come up > reliably for me). So, you can guess by now that even though I find this > an interesting topic and a useful addition to FOP, I wouldn't need that > myself. But I'm pretty sure that there are people who could profit from > that since they don't have to integrate FOP into such a service > themselves. But it would have to be easy to set up. > > Generally, CXF seems extremely heavy-weight for something like this. > Most of my requirements above have nothing to do with the REST service > itself. The tricky thing on the service-side is just the multipart > support. So basically outfitting a servlet with multipart support and > covering the requirements above would already solve the whole problem. I > don't think that CXF (or any other JAX-RS implementation) would make the > whole task that much easier. > > On 10.03.2011 00:01:18 Benson Margulies wrote: >> It occurred to me that some might find it congenial to be able to >> download a .WAR file that drops into Tomcat or Jetty and provides a >> REST (or, perhaps, SOAP?) web service that runs FOP. Using Apache CXF, >> this would be a rather straightforward exercise. This would make it >> easier to set up FOP once, with whatever configuration appeals to you, >> and then use it on your network. >> >> I could bang such a thing together using Apache CXF if you all, who >> have a much better sense of how FOP gets used than I do, think it's >> worthwhile. >> >> It would be an independent build from the main fop tree, and, warning, >> it would get built with Maven. > > > > > Jeremias Maerki > >
