thanks for the info. the comment in the wiki certainly makes more sense now. it seems to be more appropriate for static data though (or am i being dense again?).
the example posted in the wiki seems to be exactly what i need, as i'm programmatically generating a PDF on the fly depending on data a user has selected. the high-level PDF integration is not powerful enough for what i need, so i'm generating the PDF in java code and piping that into the Resource class. is that the right way to do it, or should i be subclassing AbstractResource?
that would involve implementing getResource and piping my byte-array into response.getOutputStream, if i'm reading the code correctly. but how do i tell seam to use this PDFResource? (can org.jboss.seam.servlet.SeamResourceServlet work that out automagically?)
right now, however, the approach in the wiki works a treat for me, but if the other way is the _correct_ way to do it, i don't mind giving that a try.
p.s.: on the topic of documentation, would this be the right place to volunteer to work on adding/extending javadoc to the seam code? if so, i wouldn't mind getting involved with the project.
Yes, I perhaps prefer the approach the wiki article takes but it didn't make it into Seam. Anyway, there is nothing wrong with using it, glancing over it, it all seems current. Seam is all about choices :)
It would be great to get some more javadoc/improvements. Just raise JIRA issues with patches attached and one of us will review and apply them to the source :)