In a transform step (derived from AbstractTransformStep) you want to use getNext().getResponse().
The idea is that each step provides a sink for the output of a prior step (or view), so if you call getResponse() on yourself, you'll be writing to the same place that the previous step wrote to. Not good. If you aren't using AbstractTransformStep, the actual next step comes from TransformContext.getNextStep(), but be careful that this method does not get called more than once per step. AbstractTransformStep.getNext() ensures that this works properly. This pattern is a little confusing at first but it seems to accommodate all the binding mechanisms - both sax events and write() calls can flow efficiently between transforms without being buffered. Of course buffered exchanged work too. I would say release what you feel comfortable with :-) I wouldn't worry too much about a pre-Maverick-2.1 release, unless someone here convinces you otherwise. The limitation of only a single transform in Mav 2.0 makes fop pretty hard to use. The formal 2.1 release will be Real Soon Now. Jeff Schnitzer [EMAIL PROTECTED] > From: jim moore [mailto:[EMAIL PROTECTED]] > > I've uploaded the first opt-fop source files that work with mav 2.0. > There's no release yet, though, so if you want to use them, you'll need > to build them yourself (I still need to upload a build.xml, but all the > necessary jars are in the lib folder). > > I'm working on a sample app right now to upload with the release. It's > just a slightly modified version of friendbook-jsp that lets you view > your friend list as a pdf. > > I've modified my files at home to work with mav 2.1, (heterogenous > transforms) with one problem--I can only write to the outputstream if I > use getRealResponse().getOutputStream(). Using > getResponse().getOutputStream() (getting the FakeHttpServletResponse) > throws an IllegalState exception, saying that getWriter() has already > been called. This isn't really a showstopper at this point--it would > only be an issue if you wanted to perform another transform after > opt-fop. I suppose at some point maybe someone could right a transform > that took a pdf as input and parsed it and did something with it (or > maybe more likely took svg produced by fop, since that is xml after > all), but for now maybe its still worth releasing as is. > > Anyway, what do you guys feel should be released? Should I do an initial > release that works with mav 2.0 for the people still using that, or just > push ahead and only do a release for mav 2.1? Also, if I do a 2.1 > release, should I do a 0.9 release of it as is with the caveat that > opt-fop must be the final transform, or should I wait to try and get > this issue resolved before doing a release? > > --jim > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Mav-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mav-user _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
