programadores Java EE no escriben en archivos

Question

Hoy en día una persona dijo a mí que "programadores Java EE no escriben a los archivos". ¿Por qué no puedo escribir en archivos desde un contenedor Java EE (por ejemplo desde JBoss)? ¿Qué está mal?

Answer 1

La mejor página para tener en cuenta es la siguiente: http://www.oracle.com/technetwork/java/restrictions-142267.html

Se describen en detalle las restricciones sobre el modelo de programación Java EE.

Aparte del punto mencionado anteriormente Seguridad, Portabilidad, Agrupamiento, Subprocesamiento también consideran transacciones y manejo de errores (Los sistemas de archivos no son transaccionales).

Sin embargo, no hay magia negra en la JVM y puede crear archivos (siempre que tenga los derechos correspondientes), usar variables estáticas y crear subprocesos si sabe lo que está haciendo.

Mejor tómese el tiempo para entender por qué se suelen sugerir estas restricciones, que saltar y escribir un conector JCA para cumplir.

Answer 2

Debe hacer todo dentro del contenedor Java EE en sí mismo: no puede tener certeza de que tendrá un acceso consistente al sistema de archivos. Hay muchas razones para esto, el ser más obvio que aplicaciones que se ejecutan dentro de un contenedor tendrá:

• hay certeza de que cualquier invocación subsiguiente de un EJB sería incluso estar en el mismo servidor físico con acceso a la misma archivos/sistema de archivos (por ejemplo, al agrupamiento)
• ninguna posibilidad de interferir unos con otros (múltiples aplicaciones de intentar escribir en el mismo archivo)
• no hay problemas de seguridad (una aplicación para escribir datos confidenciales que podía leer otra aplicación)

También debe asumir que usted no debe :

• crear sus propios hilos (el contenedor se encargará de esto para usted; si crea su propio puede matar de hambre a otras aplicaciones en el contenedor de tiempo de CPU) también tiene problemas de seguridad
• uso socket-IO()

Answer 3

Incluso si tiene acceso al sistema de ficheros, con los sistemas distribuidos que pueda Asegúrese de que la próxima vez que se llame a un método, se maneje en la misma máquina donde se escribió el archivo.

Answer 4

Porque la especificación de Java EE no ofrece una API para escribir archivos. Por supuesto, puede usar la API Java IO normal para crear archivos, pero debe asegurarse de que este código sea seguro para subprocesos, que alguien limpie los archivos, que el nombre de archivo se transfiera al siguiente bean, que el archivo sea migrado cuando su bean se mueve a otro nodo en el clúster, etc.

Así que mientras puede hacerlo, en la práctica, encontrará muchos pequeños problemas que hacen que manejar archivos en Java EE sea realmente difícil.

Answer 5

Si su instancia no está agrupada o si uno puede garantizar que todas las instancias pueden usar una unidad de red, entonces no es realmente un problema utilizar las API de archivos para leer/escribir archivos. Sin embargo, se debe tener cuidado para obtener los caminos correctos y limpiar según corresponda. A menudo no hay una necesidad real de escribir archivos, así que piénselo de nuevo. La razón principal por la que la mayoría de la gente da es que en un clúster, los servidores diferentes no ven el mismo archivo porque las rutas cambian, y así sucesivamente. Al final, la mayoría de las aplicaciones pequeñas no se ejecutan en un clúster ...

Answer 6

Según las especificaciones de Java EE, los EJB tienen estrictamente prohibido el acceso a cualquier recurso externo por cualquier medio que no sea a través de un "administrador de recursos" (JDBC, JNDI, JCA, etc) y esto incluye especialmente el acceso al sistema de archivos local a través de las clases del paquete java.io. Además, tampoco se puede usar ClassLoader para dicho acceso, como para cargar un archivo de propiedades desde el classpath de la aplicación.

Las razones para esto ya se han dado en otras respuestas:

• Las cuestiones de seguridad
• Portabilidad emite
• La agrupación emite
• roscar emite

En última instancia, el mejor recurso para estos asuntos es una base de datos.

Answer 7

Debería considerar un Sistema de archivos como un Sistema de información empresarial (EIS). Luego puede crear un ResourceAdapter que acceda a este EIS, similar a un adaptador JDBC que accede a una base de datos. La especificación está aquí: http://java.sun.com/j2ee/connector/download.html. Esto significa que el acceso a archivos es posible, pero mucho más complicado. Esta especificación incluso le permite crear algún tipo de "subprocesos" llamado Trabajo.

Answer 8

Con el fin de interoperar con sistemas legacy no j2ee, ocasionalmente tiene que hacer "cosas malas" como socket i/o, escribir en archivos, etc. En el mejor de los mundos, la especificación j2ee sería seguido estrictamente, pero la gente se sale con cosas que no son jiras todo el tiempo por la conveniencia y hacer el trabajo. Hay formas de eliminar estas cosas de manera segura y pensativa.