Gostaria de Saber como faço para criar uma sessão dentro de uma action??
Valeu!!!
Acho que não entendi bem o que você quis dizer com “criar uma sessão dentro de uma ação”…mas bem. Uma ação pode acessar a sessão atual da seguinte maneira:
- Faça sua ação implementar a interface com.opensymphony.webwork.interceptor.SessionAware
- Com isso você deverá implementar o método setSession(Map) para armazenar a seção (que, suponho, é o que você precisa)
- Modifique a entrada da sua ação no xwork.xml para incluir o interceptor servlet-config (o que acontece se você usar a defaultStack). Ou seja, inclua, na definição da sua ação, uma das duas linhas a seguir (incluir as duas é redundante):
<interceptor-ref name="servlet-config" />
<interceptor-ref name="defaultStack" />[]'s e boa sorte
Vai precisar de um boa sorte mesmo !!!
Com certeza isso deve ter mudado recentemente, pois fazer algo básico que é pegar uma session dessa maneira bastante simples e rápida aí é realmente inadmissível.
E coo vc invalida a session se ela é um map ???
Acho que hoje em dia vc pega isso do contexto do webwork, sem interface enabler e essa papagaiada toda.
No mentawai a session já vem dentro de toda action, logo vc pode fazer assim em qualquer lugar da sua action:
User u = (User) session.getAttribute("user");
E para resetar:
session.reset();
Repare que essa session aí é um org.mentawai.core.Context, assim como CookieContext, ApplicationContext, etc.
Eu vi que é possivel criar uma classe UserSession e um interface UserSessionAware.
Depois eu adiciono os dois numa Classe SystemAction que extende um ActionSuporte, assim:
public class SystemAction extends ActionSupport implements UserSessionAware {
private static final Log log = LogFactory.getLog(SystemAction.class);
protected UserSession userSession;
protected SystemAction(){
}
public UserSession getUserSession() {
return userSession;
}
public void setUserSession(UserSession userSession) {
this.userSession = userSession;
}
}depois tem que criar um arquivo components.xml e mapear a classe UserSession e um interface UserSessionAware.
<?xml version="1.0" encoding="ISO-8859-1"?>
<components>
<component>
<scope>session</scope>
<class>br.com.clickideia.capacitacao.components.UserSession</class>
<enabler>br.com.clickideia.capacitacao.components.UserSessionAware</enabler>
</component>
</components> Mas parece que estou com problema no web.xml, que não está configurado certo.
Alguém já fez desse jeito ???
PS.:Obrigado pelas dicas!!
PS.:A opção de fazer com mentawai não é possivel , mas me parece interessante, principalmente porque estou tendo muitos problemas com configuração.
Tão simples quanto:
Map session = ActionContext.getContext().getSession();Ele só precisava fazer uma busca no Wiki do Webwork.
[quote=saoj]Com certeza isso deve ter mudado recentemente, pois fazer algo básico que é pegar uma session dessa maneira bastante simples e rápida aí é realmente inadmissível.
E coo vc invalida a session se ela é um map ???
[/quote]
ActionContext.getContext().setSession(new HashMap())Sim, é verdade. E desde de que eu conheço o WebWorks (a muito, muito tempo)
ActionContext.getContext().getSession()[quote=saoj]No mentawai a session já vem dentro de toda action, logo vc pode fazer assim em qualquer lugar da sua action:
User u = (User) session.getAttribute("user");E para resetar:
session.reset();Repare que essa session aí é um org.mentawai.core.Context, assim como CookieContext, ApplicationContext, etc.[/quote]
O WebWork têm uma fisolofia diferente, o WebWork usa o framework XWork, que é um framework POJO de commands (pode ser utilizado em swing, JMS e diversas outras coisas). Por isso, toda action não têm necessáriamente tudo que um action web deveria ter, por que nem sempre essa action é web.
Se invez de usar action diretamente você importar DefaultActionSupport, você terá também um monte de métodos de suporte, inclusive continuation.
É sempre legal, você criar a sua própria classe ActionBase.
Eu vi que é possível criar um objeto dentro da ActionSuprte como se fosse uma sessão, usando UserSession e UserSessionAware. Alguém conhece??
Eu já vi essa questão da session em diversos lugares feito com enablers, ioc, xml, etc.
Aqui mesmo no GUJ tem um tutorial que vai por esse caminho, por isso que eu achei que essa mudança para pegar a session do ActionContext tinha sido feito recentemente. (recentemente = a 1 ano atrás).
Quando vc diz que para invalidar a session vc faz:
ActionContext.getContext().setSession(new HashMap())Vc tem certeza que session.invalidate() está sendo chamada por trás ??? Não é o que parece pois parece apenas que vc está criando uma nova Map. Mas o que aconteceu com o objeto HttpSession ? É obrigatório chamar invalidate para criar uma nova sessionId e para trigar callbacks como HttpSessionBindingListener.
Acho que session.reset() fica mais claro que tudo isso está acontecendo por trás dos panos.
E os cookies ??? Como vc trata cookie dentro de um map ? Se vc dá um clear no map todos os cookies serão removidos do browser ?
Deve ter workaround pra isso no webwork, com certeza. Mas o cara vai ter que sair procurando na documentação do webwork, que não é muito boa/clara/organizada.
Por isso que eu prefiro ter uma interface org.mentawai.core.Context implementada por CookieContext, ApplicationContext, SessionContext, QualquerCoisaContext.
http://www.mentaframework.org/api/org/mentawai/core/CookieContext.html
O mentawai tb tem a interface Action, que vc pode implementar, mas 99.9% das actions de um projeto web só serão executads no projeto web. Essa de executar uma action em outro ambiente que não seja web é legal e o menta suporta, mas na prática é ignorada pois 99% não precisa ou quer fazer isso.
Assim como o webwork tem ActionSupport o mentawai tem BaseAction.
Mas mesmo quando vc herda ActionSupport vc ainda assim tem que usar o ActionContext e um bucado de enablers. Sim o webwork só faz IoC via enablers. Não sei agora como ficou depois da integração com o spring.
Bom, isso é apenas um comparativo rápido sobre algumas pequenas diferenças entre webwork e mentawai. Nada muito crítico que torne o webwork um framework ruim, muito pelo contrário. O webwork é um ótimo framework web. Apenas acreditamos que o mentawai é muito, mas muito mais simples que o webwork.
Sim, em um projeto web sim. Mas o XWork (que é utilizado pelo WebWork) é um framework genérico.
[quote]Assim como o webwork tem ActionSupport o mentawai tem BaseAction.
Mas mesmo quando vc herda ActionSupport vc ainda assim tem que usar o ActionContext e um bucado de enablers. Sim o webwork só faz IoC via enablers. Não sei agora como ficou depois da integração com o spring.
Bom, isso é apenas um comparativo rápido sobre algumas pequenas diferenças entre webwork e mentawai. Nada muito crítico que torne o webwork um framework ruim, muito pelo contrário. O webwork é um ótimo framework web. Apenas acreditamos que o mentawai é muito, mas muito mais simples que o webwork.[/quote]
Sim, o WebWork é muito bom. Faz mais de uma ano que eu não mexo com ele, e não tenho acompanhado muito. Mas se eu fosse olhar para o WebWork como ele estava a 1 ano atráz diria que ele está meio ultrapassado. Mas olhando a documentação para responder esse post eu li até sobre suporte a Continuation (utilizando o continuation do Rife, percebi pelo nome do pacote) o que é beeeem legal.
Uma coisa eu acompanhei de perto, ate por ser commiter do PicoContainer, foi o suporte transparente ao Pico e Spring que foi implementado no WebWorks. Simplemente genial.
Embora XML sejá o mais utilizado, saiba que o WebWork (assim como Spring e o Pico) suportam configuração programatica. Eu inclusive já utilizei uma vez no WebWork (aonde configuração programatica foi vantajoso para mim). (Por favor, não me peça por exemplo, faz muuuuuuito tempo).
Isso vai ser bom para o webwork, pois acho que era consenso que o suporte do webwork a IoC e DI não era bom. Enablers pra tudo, xml, impossibilidade de reutilizar variantes de um mesmo componente sem ter que criar outro componente (e outro enabler com mais xml), injeção apenas em setter, etc.
O suporte do menta a IoC e DI ainda pode melhorar, principalmente documentação e cookbook, mas está bastante legal e totalmente transparente, mais ou menos como o PicoContainer.
Acho que vc poderia dar uma dicas, já que vc é committer do PicoContainer.
Link sobre WebWork x Spring em relacao a IoC: http://www.theserverside.com/news/thread.tss?thread_id=21962
[quote=saoj][quote]
Uma coisa eu acompanhei de perto, ate por ser commiter do PicoContainer, foi o suporte transparente ao Pico e Spring que foi implementado no WebWorks. Simplemente genial.
[/quote]
Isso vai ser bom para o webwork, pois acho que era consenso que o suporte do webwork a IoC e DI não era bom. Enablers pra tudo, xml, impossibilidade de reutilizar variantes de um mesmo componente sem ter que criar outro componente (e outro enabler com mais xml), injeção apenas em setter, etc.[/quote]
Não era mesmo não, mas agora está chuchu beleza.
[quote=saoj]O suporte do menta a IoC e DI ainda pode melhorar, principalmente documentação e cookbook, mas está bastante legal e totalmente transparente, mais ou menos como o PicoContainer.
Acho que vc poderia dar uma dicas, já que vc é committer do PicoContainer.[/quote]
Sim, claro. E só você perguntar. Mas não ache eu sou um gênio em IoC não, que estou longe disso. Só que eu usava muito o Pico e queria ver algumas coisas implementadas nele, fui lá e implementei. (suporte a Hibernate3, DataSource, Webservices e NanoWeb).
Para mim o grande beneficio de um container e o controle do ciclo de vida de um componente (e nisso o Pico é fantástico) e AOP de forma transparente (e nisso o Spring 2.0 arrassa).
Também não sou. Peguei as idéias desse link que eu coloquei mais acima.
Quanto a ciclos de vida de um componente de IoC de um projeto web:
-
Request: uma nova instancia é criada para cada novo request
-
Session: uma nova instanciia é criada para cada nova session
-
Application: uma instancia é criada para cada aplicacão e como aplicacao é uma só entao teremos apenas uma instancia
Existe outras possibilidades/cenarios para um componente de um projeto web ?
Ja quanto a AOP não posso falar pois não manjo nada…
[quote=saoj]Também não sou. Peguei as idéias desse link que eu coloquei mais acima.
Quanto a ciclos de vida de um componente de IoC de um projeto web:
- Request: uma nova instancia é criada para cada novo request
- Session: uma nova instanciia é criada para cada nova session
- Application: uma instancia é criada para cada aplicacão e como aplicacao é uma só entao teremos apenas uma instancia
Existe outras possibilidades/cenarios para um componente de um projeto web ?
[/quote]
Sim, denominado hoje em dia de conversação, algo como o contexto de um conjunto de request. Como um wizard ou algo do tipo. O JBoss Seams e o Spring WebFlow implementam esse contexto de forma graciosa.
Isso é um ponto chave para perfomace de aplicações web hoje, você econimiza trafico de rede (você não precisa fica passando os parametros em toda requisição), conexão com banco de dados etc…
Com conversação você pode por exemplo está preenchendo dois formularos iguais (e com flow) em duas janelas separadas.
Um outro contexto é o que se chama de flash hoje (o primeiro lugar que eu vi isso foi no Raisl, e vários frameworks já estão implementando).
Que é um contexto que dura 2 requisições, ótimo para quando ocorre um erro e você invez de dar forward na tela de erro vc dá redirect, evitando assim refresh.
É bem interessante. Cuidado com o over AOP, mas AOP aonde aplicado ajuda em muito. Controle de transação, segurança, cache e otimização.
Hummmm. Interessante. Vamos pensar nisso…
A solucao padrão pra isso é ir guardando as coisas na sessão, mas concordo que esse esquemo é mais bonito e limpo, pois não polui a sessão e separa as coisas.
[quote=saoj]Hummmm. Interessante. Vamos pensar nisso…
A solucao padrão pra isso é ir guardando as coisas na sessão, mas concordo que esse esquemo é mais bonito e limpo, pois não polui a sessão e separa as coisas.[/quote]
Sim, mas é ineficiente. Imagine você tendo duas janelas do browser aberta ao mesmo tempo? Uma fonte de bugs em sistemas web é justamente essa.
Até da para contorna, gerando uma chave única e ficar passando ela entre as requisições… Mas é muito trabalho manual, prefiro como é no seam
@Scope(CONVERSATION )
private Session session;
Pronto, essa session do hibernate está no scopo da conversação.
Ou então
@In @Scope(CONVERSATION)
private Cliente cliente;
Pronto, o Bean cliente que é preenchido automaticamente pelos parametros dos requests são mantidos durante toda a conversação.
Existem ainda outros scopos, de uma olhada em http://docs.jboss.com/seam/latest/api/org/jboss/seam/ScopeType.html para ver alguns.
Como é definido onde acaba e onde começa uma conversação ?
Você define em qual evento termina:
@End
public String acaba(){}
Assim, quando você chamar o evento acaba ele vai ser processado e a conversação vai terminar.
Da uma olhada em http://www.jboss.org (procure por Seam) que a documentação dele é bem legal.
[]'s
Jose Peleteiro
Só para ver se eu entendi, para poder implementar no menta. 
:shock:
Um problema clássico de qualquer aplicação web é:
Quero dar um redirect para a página: Meus livros
Só que tb quero mostrar uma mensagem de sucesso, do tipo: "Livro adicionado com sucesso!"
Possíveis soluções:
-
passo a mensagem na URL como parametro (porco)
-
passo um id ou alguma indicação na url que ela precisa mostrar uma mensagem que está na session, talvez com esse id (porco tb)
-
coloco a mensagem na session e como o jsp não vai encontrar no request (não tem request pois foi redirect) ele vai pegar automaticamente da session e mostrar. (ok mas tem problemas continue lendo)
Todas as tags do Mentawai utilizam cascateamento de escopo (acabei de inventar esse nome), ou seja, procura no request, se não tiver procura na session, se não tiver procura no application. (EL é assim tb, so whatever, só para enfatizar que isso é bom…)
Logo antes de dar o redirect eu coloco a mensagem de sucesso na session e faço o redirect.
Problema: Quem vai remover isso da session ?
Pelo que entendi esse é o problema que o scope conversation resolve. Várias sessions independentes dentro de uma session geral do usuário, carregando informações de um lado para o outro.
Como o conversation scope resolveria o meu problema acima ??? Acho que como a action showLivros é um ponto final da conversa (pelo menos um deles, pois poderão haver mais), eu daria um reset no context dentro da action ShowBooks
minhaConversa.reset(); // ou addBookContext.reset();Hoje como eu resolvo isso?
Como eu só tenho uma mensagem de sucesso no meu contexto, eu dou um:
session.removeAttribute("message");Dá praticamente no mesmo, mas se minha conversa vc gigantesca eu teria que ficar limpando sujeira da sessão a todo momento.
Então esse escopo de conversação é bonito mesmo !!! Vamos implementar !!! Como:
:arrow: Contextos de conversação podem ser únicos (apenas um por sessão) ou múltiplos (vários por sessão)
:arrow: Contextos de conversação são controlados por cookies assim como a session (se o cara não tiver cookie azar o dele pois eu não vou implementar url rewrite que é um saco total)
:arrow: Contextos expiram assim como a sessão.
:arrow: Pro futuro pode-se implementar um ContextBindingListener, no mesmo esquema do HttpSessionBindingListener
E o principal.
Todas as tags do mentawai vão procurar seus parametros assim:
request -> contextos de conversação seguindo a ordem LIFO -> session -> application
O que vc achou juzepeleteiro? Faz sentido isso?
Não é trivial implementar isso, ainda mais que depois tem que dar um jeito de integrar o IoC com isso…
PS: O reset no context ou na mensagem que está na session teriam que ser feitos após a execução da action, provavelmente por um AfterConsequenceFilter.
Sim, mais oumenos. Se eu tiver dois contextos (um para cada janela do browser) qual que a tag do menta vai pegar? Na janela A ela deve pegar o contexto da janela A, e na B o contexto da janela B.
Essa gerência de contexto têm que ser rica, timeout, opções de armazenamento (imagine eu ficar armazendo minha session (do Hibernate) dentro da session do HTTP?), eventos (start, stop, dispose, page…).
Se não é apenas uma feature para dizer que tem. E só vai servir para attributos da página.
E, please, não use cookie. Cookie têm que ser utilizado ao mínimo sempre, por a cada requisição o browser enviar todos os cookies para o servidor, aumentando assim o consumo de banda. E quando estamos falando de aplicações de alta-disponibilidade isso é bem importante. (10 conversações eu estaria gastando 10x mais em cookie, do que um só se eu passa-se o conversionId por parametro.)
IoC sem eventos não é IoC, e apenas coleção de objetos.
[]'s
Jose Peleteiro
Quer realmente fazer algo útil nesse sentido no Menta? Pega o SpringFlow, que pode ser utilizado programaticamente ou com uma IDE fantatica aonde você define os flows graficamente e integra ao Menta.
Ele já lhe dá toda essa história de conversação de forma graciosa. E que não é simples de ser feito, principalmente quando você começa a falar de depedencias entre contextos.
Como fica hoje no menta, quando um componente do scopo de applicação precisa de um do escopo de sessao? Ou seja, ele vive para aplicação, mas aquela instancia do componente B e diferente para cada sessão?
Pode parecer simples, mas não é não.