On 22.11.2007 18:04:25 Chris Bowditch wrote:
<snip/>
> Approach 2 has 2 nasty negatives, whereas the worst thing about approach 
> 1 is the amount of work involved. Perhaps the choice will be obvious if 
> you can put some actual time estimates against both approaches. I mean, 
> if approach 2 can be implemented in 25% less time than 1 then I'd push 
> for Approach 1, but if Approach 1 requires 400% extra effort then 
> Approach 2 would become the preferred option.

My estimate shows that Approach 1 would take roughly 50% more time than
Approach 2 (only implementing PDF, PS, PCL, AFP and Java2D/PNG/TIFF).

<snip what="J2EE compatibility"/>

The whole J2EE compatibility thing for me calls for the question if as a
project we want FOP to be J2EE compatible (i.e. without the need for JCA
wrappers). I know there are other opinions here, but in my opinion FOP
should not be used directly in the J2EE context (i.e. inside Session
Beans). J2EE was not designed to accomodate such functionality. I've
seen proprietary document production solutions which basically just
ignore many rules of the J2EE spec only so the software runs in a J2EE
context. The only reason: it sells better. The resulting problems were
severe clustering difficulties which J2EE actually tries to address. I
was once forced myself building a session bean interface for document
production whereas I had proposed a much more flexible WebService
approach earlier (this time: company policy rather than sales criteria).
I basically just couldn't avoid stretching the EJB rules to make the
whole thing work. That always leaves a bad feeling.


Jeremias Maerki

Reply via email to