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:
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.