2011-11-26 12 views
10

Acabo de empezar a utilizar la versión beta de Netbeans 7.1 y está llamando a errores de un tipo que nunca he visto antes. Específicamente:¿Por qué no puedo tener campos públicos estáticos en mis beans administrados?

A managed bean with a public field should not declare any scope other than @Dependent.

Los campos que se queja de son public static final. Puedo entender la restricción en campos no estáticos, pero no puedo pensar en una buena razón para que esto no esté permitido para un campo estático. Lamentablemente uso muchos de ellos ya que no me gusta tener constantes en mi código.

Observo que aunque obtengo el punto rojo en el margen del editor, la compilación manejada por maven todavía funciona y GlassFish todavía ejecuta mi aplicación de la manera que yo esperaría.

¿Cuál es mi explicación sobre este tema? ¿Tendré que mover mis campos estáticos a otra parte o hay otra forma de manejar esto?

+2

Nota: JSF no lo prohíbe. Es Netbeans quien lo hace por alguna razón poco clara, tal vez por alguna restricción de especificaciones CDI. Como aparentemente es una versión beta, solo reportaría un error a los chicos de Netbeans. – BalusC

Respuesta

5

Citando al javax.enterprise.injectpackage javadocs:

Si un bean gestionado tiene un campo público, debe tener @Dependent alcance.

Pero estoy de acuerdo con @BalusC que si esto se compila, Netbeans debería informarlo como Advertencia (¿o sí?).

De todos modos, ¿esas constantes realmente forman parte de la API? Quiero decir, ¿accedes a ellos en cualquier otro lugar pero dentro de sus propias clases? De lo contrario, reduzca la visibilidad a privada. (Si solo necesita acceder a las constantes desde la vista, también puede crear accesos para la constante privada). Si es así, te sugiero que los muevas a otro lugar de todos modos.

+0

NetBeans 7.1 beta (no versiones anteriores) marque la línea de la clase con un punto rojo en el margen izquierdo. Sin embargo, ese error no se extiende a la ventana de proyectos como lo hacen otros errores. Tiene razón en que muchas de mis constantes se pueden designar como privadas en lugar de públicas, y podría refactorizar las constantes exportables para obtener (¡no setters!). Esto me tomó por sorpresa, sin embargo. La mayoría de los requisitos de JSF tienen un sentido intuitivo cuando los examinas; este todavía no lo hace. – AlanObject

+0

Se arregló la parte de mutador para una referencia posterior, caso grave de desarrollador cansado de café después de la medianoche, jejeje. De todos modos, si desea reportar un error para el equipo de Netbeans, [aquí] (http://netbeans.org/community/issues.html) es el lugar. Si compila y funciona bien, tal vez el equipo de Netbeans malinterpretó las [especificaciones] (http://jcp.org/aboutJava/communityprocess/final/jsr299/index.html) (o tal vez las especificaciones no son claras acerca de las variables estáticas, y se deja como un detalle específico de implementación ...). Por si acaso, lea las especificaciones y prepárese para un debate abierto, sigue por ese camino. –

+1

Aquí está la cita de las especificaciones vinculadas: (Página 27, - 3.1 beans administrados): 'Si un bean administrado con un campo público declara cualquier ámbito que no sea @Dependent, el contenedor detecta automáticamente el problema y lo trata como error de definición. No dice nada acerca de las variables de clase frente a los campos de objetos, pero quizás esta es una buena pregunta para Gavin King: D. –

4

Los campos públicos (estáticos o no) no son proxy, por eso solo pueden depender del ámbito. Para evitar esto, obviamente puede acceder a ellos a través de métodos getter.

Cuestiones relacionadas