Muito código pra pouco serviço

Quero pegar o facescontext apartir de um filtro que eu uso. Este filtro deve ver qual foi o request do usuário. Este maldito filtro não é JSF! Ou seja, chamadas no request para saber que url o usuário acessou não funcionam. Fui tentar acessar o contexto do JSF para pegar o request mas quem disse que funciona?! Ele vem nulo!
Após procurar na internet achei este lindo código:

[code]// You need an inner class to be able to call FacesContext.setCurrentInstance
// since it’s a protected method
private abstract static class InnerFacesContext extends FacesContext
{
protected static void setFacesContextAsCurrentInstance(FacesContext facesContext) {
FacesContext.setCurrentInstance(facesContext);
}
}

private FacesContext getFacesContext(ServletRequest request, ServletResponse response) {
// Try to get it first
FacesContext facesContext = FacesContext.getCurrentInstance();
if (facesContext != null) return facesContext;

FacesContextFactory contextFactory = (FacesContextFactory)FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
LifecycleFactory lifecycleFactory = (LifecycleFactory)FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);

// Either set a private member servletContext = filterConfig.getServletContext();
// in you filter init() method or set it here like this:
// ServletContext servletContext = ((HttpServletRequest)request).getSession().getServletContext();
// Note that the above line would fail if you are using any other protocol than http

// Doesn’t set this instance as the current instance of FacesContext.getCurrentInstance
facesContext = contextFactory.getFacesContext(servletContext, request, response, lifecycle);

// Set using our inner class
InnerFacesContext.setFacesContextAsCurrentInstance(facesContext);

// set a new viewRoot, otherwise context.getViewRoot returns null
UIViewRoot view = facesContext.getApplication().getViewHandler().createView(facesContext, “yourOwnID”);
facesContext.setViewRoot(view);

return facesContext;
}[/code]

Utilidade: pegar o contexto do JSF… :roll:
Me desculpem aos fãs do JSF, mas isto pra mim é uma gambi que não tem tamanho! Eu só quero saber qual a url do usuário! Porque request.getRequestURL() não funciona mais? Enfim, isto pra mim é ridiculo… não sei se o myfaces resolve este problema, se resolver vou tentar implantá-lo aqui. Já to cansado deste lixo.

O pior é que isto não funciona, só na primeira vez.

o teu problema é que não existe ainda um faces context no momento da execução do filtro, e só a implementação de JSF em uso é que pode criar um FacesContext …

para fazer isto no JSF em vez de criar um filtro, tu tem que usar a API do JSF e colocar um PhaseListener …
ou então fazer isto de dentro do viewresolver …
mas de dentro do filtro, o request.getRequestURI() vai ter a URL acessada pelo usuário sim, des de que o filtro esteja sendo executado no dispatcher REQUEST (na API de servlets 2.4 tu pode dizer para qual dispatcher um filtro deve ser executado: REQUEST, FORWARD, …)

mas a URL acessada pelo usuário é a URL para onde esta sendo feito o POST do JSF, e não a que sera renderizada como retorno …
para um outputLink vai funcionar perfeitamente para o que tu quer, mas para um commandLink, a url acessada pelo usuário é diferente da URL renderizada, pois a URL acessada é a do post, como em qualquer outro framework baseado em actions …

com o phaseListener tu consegue ter acesso a qual a view que sera renderizada dependendo de qual phase tu estiver “ouvindo” …

ou seja, não é um problema da API JSF mas sim um problema de tu não entender como a tua aplicação esta funcionando …

[quote=urubatan]o teu problema é que não existe ainda um faces context no momento da execução do filtro, e só a implementação de JSF em uso é que pode criar um FacesContext …

para fazer isto no JSF em vez de criar um filtro, tu tem que usar a API do JSF e colocar um PhaseListener …
ou então fazer isto de dentro do viewresolver …
mas de dentro do filtro, o request.getRequestURI() vai ter a URL acessada pelo usuário sim, des de que o filtro esteja sendo executado no dispatcher REQUEST (na API de servlets 2.4 tu pode dizer para qual dispatcher um filtro deve ser executado: REQUEST, FORWARD, …)

mas a URL acessada pelo usuário é a URL para onde esta sendo feito o POST do JSF, e não a que sera renderizada como retorno …
para um outputLink vai funcionar perfeitamente para o que tu quer, mas para um commandLink, a url acessada pelo usuário é diferente da URL renderizada, pois a URL acessada é a do post, como em qualquer outro framework baseado em actions …

com o phaseListener tu consegue ter acesso a qual a view que sera renderizada dependendo de qual phase tu estiver “ouvindo” …

ou seja, não é um problema da API JSF mas sim um problema de tu não entender como a tua aplicação esta funcionando …[/quote]
E isso é desnecessáriamente complexo.
Como eu disse, eu só quero filtrar os requests do usuário. O motivo é simples: meu portal precisa ser acessado diretamente apartir de outros sites, ou seja, para eles é impossível chamar um backbean que processe a página antes. As páginas necessitam de pré processamento logo eu preciso filtrar os caminhos acessados e realizar este processamento através de um filtro ou algo assim. Em vez de me ajudar e tornar meu trabalho mais fácil o JSf adicionou complexidade desnecessária, impediu que eu acesse o request diretamente pois não sei porque diabos esta especificação maldita quer encapsular tudo e proteger tudo com a droga do FacesContext que eu não posso acessar via servlet ou filtro!
Enfim, um framework não é pra ajudar? Porque ele mais me atrapalha do que ajuda?