Very cool - thanks for giving me the reason when it's okay to bend these rules re: Assets not needing transactional business stuff
On 25/05/2012, at 9:43 PM, Geoff Callender wrote: > Arno is spot on. The spec is being motherly, but in practice if you're > uploading assets, as opposed to saving something that must be considered part > of a transaction, then there's no harm done in writing to the file system. > Everybody does it! Here's an example: > > > http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/fileupload > > If you're in a clustered environment then just make sure the file is written > to a file location that is shared across the cluster. > > If the saved files are then to be served up in high volume (eg. lots of > images on a page to lots of users) then it may be preferable to return > special URLs for them rather than have Tapestry's return them as asset > addresses. The special URLs could be detected by Apache (in front of > Tapestry) which can then serve them up directly from the file system (rather > than have Tapestry stream them). > > Of course if there are security requirements (ie. who is allowed to see what > files) or the need for a CDN then more is required than I've suggested above. > > Geoff > > On 25/05/2012, at 6:59 PM, Chris Mylonas wrote: > >> 626 pages of spec... and you reply with section number and some copy and >> paste. >> I am grateful Arno, thank you! >> >> >> On 25/05/2012, at 5:45 PM, Arno Haase wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> JEE application servers typically do not actually prevent you from >>> accessing the file system, and the spec does not require them to. So >>> if it works with your specific app server / jee stack, you are home free. >>> >>> The spec prohibits accessing the file system sort of to protect you >>> from yourseslf - the file system is not transactional, needs attention >>> in a clustered environment etc. >>> >>> That is specified in section 21.2.2 "Programming Restrictions" of the >>> EJB 3.1 specification (JSR 318, >>> http://www.oracle.com/technetwork/java/javaee/tech/index.html): >>> >>> >>> •An enterprise bean must not use the java.io package to attempt to >>> access files and directories in the file system. >>> >>> The file system APIs are not well-suited for business components to >>> access data. Business components should use a resource manager API, >>> such as JDBC, to store data. >>> >>> >>> The bottom line is: >>> * the spec allows file system access from a servlet. The restriction >>> applies only to EJBs. >>> * Even from EJBs it works and is likely to continue working. >>> * But accessing the file system from an EJB formally makes an >>> application not strictly JEE6 compliant. >>> >>> I hope that helps >>> >>> - - Arno >>> >>> >>> Am 25.05.2012 03:23, schrieb Chris Mylonas: >>>> Hi Tapestry Users, >>>> >>>> In April there was a thread about AssetFactory help [1] and it >>>> mentioned that the J2EE spec states that you should not read or >>>> write to the file system. Reading up on the collapsed ear from >>>> openejb's website [2] they say (sic) "not quite j2ee but truly >>>> jee6". >>>> >>>> Although openejb is referencing class loading, where would I find >>>> info about whether jee6 allows reading/writing to local >>>> filesystem? It's a handy bad habit I'd like to be able to access - >>>> I know it's something I was doing back in early 2000s with tomcat 5 >>>> unknowingly being a badass. >>>> >>>> Any help would be greatly appreciated, Chris >>>> >>>> >>>> >>>> [1] = >>>> http://tapestry.1045711.n5.nabble.com/File-System-Asset-Factory-help-needed-and-petition-wanted-td5641308.html >>>> >>>> >>> [2] = https://openejb.apache.org/collapsed-ear.html >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk+/OIoACgkQbmZsMyUPuXTk5wCgxKl9YZbk1LBdcupOQp1QuABz >>> zq0AoOBYmu87uYBUgFqr/DqCtdCYBb0M >>> =VkAE >>> -----END PGP SIGNATURE----- >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
