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
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
>
>
