adicionar ao web.xml
<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>
Onde devem ficar os arquivos
This filter intercepts the response and runs Flying Saucer ITextRenderer on it, returning a pdf instead.
Just put the filter on your code and configure the url patterns where it will run on web.xml. The filtered pages will return as pdf documents.
public class AutoboxTest { | |
public static void main(String[] args) { | |
Integer i1 = 127; | |
Integer i2 = 127; | |
System.out.println(i1 + " == " + i2 + "? " + (i1==i2)); | |
i1 = 128; | |
i2 = 128; | |
System.out.println(i1 + " == " + i2 + "? " + (i1==i2)); | |
i1 = -128; | |
i2 = -128; |
ArrayList<BigDecimal> v = new ArrayList<>(Collections.nCopies(15, BigDecimal.ZERO); |
Add this to the xhtmls that you want to disable compatibility rendering, because the meta X-UA-Compatible must come before any tag that starts the rendering engine.
<h:head>
<f:facet name="first">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
Quando uma entidade possui relacionamentos no JPA e a entidade do relacionamento é acionada, o provedor de persistência executa um select no banco. Isso leva a um problema conhecido como ORM n+1, que ocorre quando n entidades é obtida e para cada entidade da lista precisamos acessar um relacionamento, o JPA executará a um select para obter a lista, e para cada elemento da lista executará um select, totalizando n+1 selects no banco. Este é um motivo de lentidão de páginas JSF que contém tabelas e listas que deveriam ser simples.
Colocar o relacionamento como EAGER não é uma solução correta, pois EAGER apenas informa que o relacionamento deve ser carregado, podendo o provedor fazer um novo select para cada relacionamento EAGER de uma entidade.
Existem duas soluções comuns implementadas em provedores de persistência para resolver este problema, JOIN FETCH e BATCH FETCH, que serão explicadas abaixo.
JOIN FETCH