Autenticação

Para autenticação deverá ser configurado o filtro http do autenticador CAS na aplicação web para utilizar o SSO (Single Sign On) do TJPR para login e logout das aplicações.
Após um usuário estar autenticado em uma aplicação que utilize este filtro não será necessário novo login entre outras aplicações que também utilizem-no como o próprio portal.
Exemplo de configuração do filtro do CAS no arquivo web.xml

Autorização

Exceto casos particulares expostos na definiçaõ de cada projeto, a autorização e habilitação deverão ser realizadas pelo Sistema de Segurança do ambiente de testes para desenvolvimento e homologação das aplicações e pelo Sistema de Segurança do ambiente de produção para os usuários finais neste ambiente.
O Struts deverá estar configurado para realizar a filtragem da autorização no nível das ações utilizando as seguintes diretivas:

O mapeamento das ações deverá ser do tipo PermissionActionMapping, conforme exemplo abaixo, utilizando a propriedade resourceKey com o nome do recurso exampleBean cadastrado no sistema de segurança para que seja possível realizar o filtro nas ações utilizando as propriedades Create, Read, Update e Delete com o valor da ação realizada.

<!-- ============ Security Action Mapping Definitions =================== -->
<action-mappings type="gov.tjpr.security.autz.struts.PermissionActionMapping">
<action path="/example"
type="gov.tjpr.example.client.bean.action.ExampleAction"
name="exampleForm"
input="tile.bean.edit"
scope="request"
validate="true"
parameter="actionType" >
<!-- flag for indicating if resource security is required -->
<set-property property="resourceKey" value="exampleBean"/>
<!-- flag for indicating resource security permissions (CRUD) -->
<set-property property="create" value="createBean,saveBean"/>
<set-property property="read" value="listBean"/>
<set-property property="update" value="editBean,saveBean"/>
<set-property property="delete" value="deleteBean"/>
<!-- action mapping forwards -->
<forward name="edit" path="tile.bean.edit"/>
<forward name="list" path="tile.bean.list"/>
<forward name="reload" path="/example.do?actionType=listBean"/>
</action>
</action-mappings>

Obs.: no exemplo acima os valores createBean, saveBean, listBean, editBean, saveBean, deleteBean correspondem ao nome das ações disponíveis na classe ExampleAction que especializa a classe DispatchAction do framework Struts.
O processador das requisições deverá ser do tipo PermissionRequestProcessor, uma especialização do processador das requisições do Tiles TilesRequestProcessor.

<!-- ============ Controller Configuration ========================= -->
<!-- permission required controller (already with tiles) -->
<controller processorClass="gov.tjpr.security.autz.struts.PermissionRequestProcessor"/>
<!-- tiles controller
<controller processorClass="org.apache.struts.tiles.TilesRequestProcessor"/-->

Exemplo do struts-config.xml com esta configuração

Logs

Deverá ser utilizado o logging da JDK utilizando a API do commons logging para gerenciar os logs da aplicação.

Um logger será criado por classe tomando como nome do log o próprio nome da classe.

i.e. private static final Log log = LogFactory.getLog(ExampleServiceImpl.class);
i.e. private static final Log log = LogFactory.getLog(ExampleDAOImpl.class);

Deverá ser logado a entrada no nível DEBUG nos métodos de serviço das camadas enterprise, serviço e persistence explicitando as regras aplicadas.

Não deverá ser generalizado o log na camada cliente: os logs posicionados nas camadas inferiores são suficiente a princípio para seguir a atividade. Se for colocado log na camada cliente, deve haver um motivo específico e não deverá ser redundante aos logs existentes nas outras camadas.

Tratamentos Batch

Por padrão, os tratamentos batch serão considerados como clientes particulares da camada de serviço. Deverão seguir os princípios já enunciados à exceção obviamente aos citados em relação ao IHM.

A execução dos batches deverá ser privilegiada com uma máquina virtual Java independente do servidor de aplicações.

Gestão dos erros

Geralmente, quando os erros não puderem ser tratados, deverão subir para as camadas superiores na forma de exceções por camada (PersistenceException, EnterpriseException ou ServiceException) até a camada cliente.

Quando uma exceção ocorre na camada cliente, ela deverá ser interceptada para associar a mensagem de erro apropriada ao usuário, que retornará por padrão para uma página de erro genérica que indica ao usuário que um erro ocorreu e é efetuado o log completo (stack trace) da exceção e das exceções encapsuladas se for conveniente ligá-las.

Os erros e mensagens de validação de formulário serão gerados pelos mecanismos próprios do Struts e do Struts Validator. As tags do Struts deverão ser utilizadas para mostrar as mensagens correspondentes.

Internacionalização

Deverá ser respeitado as soluções propostas pelo Java e o Struts para gerenciar a internacionalização. Ela passa pela definição das chaves e valores correspondentes em um arquivo ApplicationResource.properties.
Não deverão existir mensagens e labels contruídas por código (Java e JSP).