Considerações do Servlet Java

O WebSphere Application Server tradicionalVersão 9.0 suporta a especificação do Servlet 3.1. Saiba sobre os recursos e as mudanças no comportamento para o Servlet 3.1.

Novo Recurso Novo Recurso:
O produto suporta o Servlet 3.1, que inclui recursos e mudanças no comportamento que foram introduzidas na especificação do Servlet 3.0. Consulte Funções do recurso Servlet 3.1 para obter mais informações. Se você estiver migrando do Servlet 2.5 ou anterior para o Servlet 3.1, considere também as mudanças no comportamento para o Servlet 3.0.newfeat

O Java™ Servlet 3.1 possui muitos recursos avançados. Alguns desses recursos não são completamente documentados na especificação Servlet 3.0 ou eles implicam trocas. Considere os tópicos a seguir para fazer melhor uso dos novos recursos.

Anotações

As anotações Java Servlet 3.0 são selecionadas nos módulos da Web do Servlet 2.5, que podem incluir a exposição de um servlet na Web. Tome cuidado ao fazer upgrade de pré-requisitos de um aplicativo mais antigo, pois as novas anotações são processadas e o arquivo JAR de pré-requisitos pode incluir anotações que não deseja que sejam aplicadas.

Upload de Arquivo

Ao usar o suporte de upload de arquivo (formulários de várias partes) que é novo no Servlet 3.0, o local padrão para gravação de arquivos é o mesmo que o valor do atributo de contexto de servlet javax.servlet.context.tempdir. Por exemplo, C:\opt\WAS\profiles\node1\temp\node1\server1\fragmentTest\fragmentTest24.war é produzido para uma configuração com os atributos a seguir:
  • profile home=C:\opt\WAS\profiles\node1
  • server name=server1
  • enterprise application name=fragmentTest
  • web module name=fragmentTest24.war
Caminhos relativos também são relativos a esse local padrão.

É possível alterar o valor do atributo de contexto de servlet javax.servlet.context.tempdir para ser relativo a um diretório diferente configurando a propriedade de sistema com.ibm.websphere.servlet.temp.dir. Essa propriedade de sistema afeta todos os aplicativos em todo o servidor. Por exemplo, se você configurar com.ibm.websphere.servlet.temp.dir como /foo, o diretório temp do aplicativo será /foo/node1/server1/fragmentTest/fragmentTest24.war. Se você deseja alterar o valor em um nível de aplicativo, use o atributo JavaServer Pages (JSP) scratchdir. Consulte o tópico de parâmetros de configuração do mecanismo JSP para obter informações adicionais sobre o atributo scratchdir.

Configuração de Sessão HTTP Programática ou Dinâmica

A configuração de sessão HTTP programática permite que um aplicativo modifique a configuração de sessão em uso, por meio da configuração do arquivo web.xml ou por meio de chamadas de método da API. Depois que o aplicativo inicia, um nome de cookie modificado dinamicamente não pode ser alterado. Para propósitos de segurança, os administradores podem desativar a configuração de sessão programática para determinados cookies que podem ser compartilhados entre aplicativos. Geralmente, é seguro modificar a configuração de cookie se o aplicativo usar um nome ou caminho de cookie exclusivo. É possível alterar o caminho de cookie padrão para cada aplicativo usar a raiz de contexto por meio do gerenciamento de sessões.
Importante: A mudança do caminho pode afetar determinadas extensões IBM®, como o compartilhamento de sessão ou o método IBMSessionExt.invalidateAll, que dependem do uso de um cookie para diversos aplicativos.
Os cookies dinâmicos têm o impacto a seguir nos serviços intermediários:
  • Um proxy corporativo recupera automaticamente um cookie dinâmico quando um aplicativo inicia e usa o cookie para afinidade de sessão.
  • Um proxy DMZ no modo seguro baixo ou médio também recupera automaticamente um cookie dinâmico quando um aplicativo é iniciado. Para um proxy DMZ no modo seguro alto, a recuperação não é automática; o aplicativo deve estar em execução para que as informações de roteamento sejam exportadas.
  • Um plug-in de servidor da web não pode obter o cookie dinâmico automaticamente porque ele não se comunica com os servidores de aplicativos para informações de configuração. Você deve iniciar o aplicativo, gerar a configuração de plug-in, propagar a configuração para o plug-in e, em seguida, recarregar a configuração para que o plug-in obtenha o cookie.
  • No ambiente em cluster, o nome do cookie dinâmico gerado em cada servidor deve ser o mesmo, caso contrário, os serviços intermediários de front-end talvez não possam rotear solicitações.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_consid
Nome do arquivo: cweb_consid.html