Problemas com Paginação ao Migrar para o Demoiselle 2.5.2

[eversonmauda]

Estavamos usando a versão 2.4.2 no projeto do SICAF, quando recebemos a informação que deveríamos migrar para a ultima versão 2.X do demoiselle no caso a 2.5.2.

Realizamos a migração, mas desde então a paginação deixou de funcionar.

Estamos utilizando a PaginationContextImpl do demoiselle

Pesquisando na web, achei alguns relatos do mesmo problema que ainda não foram resolvidos. https://pt.stackoverflow.com/questions/62995/pagina%C3%A7%C3%A3o-utilizando-demoiselle-2-5-0 https://demoiselle.atlassian.net/browse/FWK-236

Necessitamos de uma solução o mais breve possível, pois estamos com o projeto em produção sem funcionar a paginação.

Obrigado.

Everson Mauda

[botelhojp]

@eversonmauda, recomendo que volte, assim que possível, para a versão anterior (2.4.2). Assim teremos mais tranquilidade para avaliar o problema reportado.

[eversonmauda]

Sem possibilidade de voltar a versão.

Paliativamente vou criar um novo PaginationContextImpl com o escopo de Session.

Como esse erro está aberto, de acordo com o stack overflow, há mais de 3 anos, qual o prazo que vocês colocam para a correção?

Obrigado.

[botelhojp]

@eversonmauda, o gestão de mudanças do Framework Demoiselle é mantida no GitHub, antigamente usávamos o Jira, o reporte feito no stack overflow não estava em nosso Roadmap.

Como seu problema envolve ambiente produtivo, entendo que será necessário maior prioridade nossa. Caso seu projeto seja do SERPRO peço que acione o time de suporte interno (SUPSD). Manteremos a Issue atualizada, mas internamente atuaremos diretamente com a sua equipe.

[eversonmauda]

Ok. De qualquer forma o segundo link enviado (https://demoiselle.atlassian.net/browse/FWK-236) era do Jira aberto há mais de 2 anos.

Vou abrir um acionamento para suporte interno para estar de acordo com burocracia interna nossa.

Obrigado.

[botelhojp]

O chamado do JIRA não foi reaberto no GitHub, conforme recomendação. Sua issue está marcada para análise do roadmap da versão 2.X Caso tenha sugestões para a correção, sua contribuição será muito bem vinda.

[eversonmauda]

O ponto principal q eu vejo é da utilização deste PaginationContextImpl. Existe um Map interno que armazena as instancias de pagination criadas de nome cache.

Qual é realmente a utilização deste cache? Se colocar esse PaginationContextImpl como @RequestScoped, código atual do 2.5.2, haverá um problema, pois a página JSF realiza uma requisição, mesmo que ajax. Com esse escopo de vida o PaginationContextImpl sempre será recriado. Assim ao clicar na segunda página, ou outra qualquer, esse map será reinicializado.

Se você deixar como @ViewScoped, enquanto você estiver na página, transitando por requisições ajax, teremos no Map as referencias corretas. Talvez esse caso seria o mais apropriado, MAS, você poderá ter sistemas que façam uma pesquisa, apresentem o resultado, mas ao clicar no detalhar haveria uma requisição não ajax para outra página e ao voltar para a tela do resultado, a paginação deveria retornar na mesma página em que o usuário estava. Seria muito ruim a usabilidade de voltar na página 1 ou até mesmo dar um bug na pesquisa. Por fim se colocar a @SessionScoped você estaria trabalhando com a sessão daquele usuário. Dessa forma ao realizar requisições não Ajax para outras páginas, como citado na parte de ViewScoped, não haveria o problema. Só que isso poderia acarretar de o usuário receber uma instancia de paginação de uma classe já criada anteriormente na sessão dele. Isso pode ser tratado através do override do método load() da classe org.primefaces.model.LazyDataModel, o qual estamos utilizando para apresentar o resultado ao usuário, criando uma Pagination nova quando o usuário realizar uma nova pesquisa, assim sobreescrevendo o que existia anteriomente.

Por fim, existe um problema nesse Map, independente do escopo, no caso dele ter 2 listas da mesma instância para apresentação do resultado, por exemplo itens ativos e inativos de uma mesma classe. Haverá sobrescrita da instância do Pagination pelo ultimo inserido no Map.

A minha solução para o primeiro caso seria o SessionScoped, devido a utilização do framework por uma gama diferente de sistemas. Para o segundo caso uma possível solução seria ao invés de deixar a key como a Class, deixar uma String, que na maioria das vezes representa o Class.getName(), com um overload do método getPagination(), com o parâmetro como String.

Meus dois centavos são esses. Se tiver alguma duvida a respeito dos comentários estou a disposição.

Obrigado.