Como migrar do JSF 1.1.01 para o JSF 1.2?

Assuntos Gerais
#1

Opa,

Seguinte fiquei na simples tarefa de migrar do JSF 1.1.01 para o JSF 1.2 ,
a empresa tem alguns componentes proprios por exemplo.

public class ColumnItemsTag extends com.sun.faces.taglib.BaseComponentTag{
   // codigo proprietario
}

E na nova versão do JSF simplesmente nao existe essa classe.
Ja pensei na seguinte gambiarra, copiar ela do JSF 1.1 e deixa-la no projeto. :stuck_out_tongue:

Fora algumas outras classes como com.sun.faces.util.Util que tiveram metodos e constantes arrancadas fora.

Util.LIFECYCLE_ID_ALREADY_ADDED_ID;
Util.NULL_PARAMETERS_ERROR_MESSAGE_ID;
Util.renderPassThruAttributes(x,y,z);
Util.getExceptionMessageString( x );

O que posso fazer? :roll:

*Será que eles usaram testes unitarios? Acredito que não… :frowning:

#2

isto é por que tu ta usando classes da implementação da sun, e não da especificação …
tudo o que faz parte da especificação ainda ta la :smiley:

como tu sabe a diferença?
todas as classes que fazem parte da especificação estão a baixo do pacote javax.faces

as outras não :smiley:

solução pra isto? bom, simular o comportamento desejado que era feito por uma classe especifica da implementação antes, ou usar apenas a especificação, o que vai garantir que no proximo upgrade vocês não passem trabalho :smiley:

e também vai garantir que a aplicação funcione com outra implementação de JSF alem da da SUN, coisa que pelo código que tu mostrou, não acontecia antes :smiley:

o unico problema, é que tu foi o azarado que pegou esta bomba pra arrumar, mas se tu tiver a chance, manda os caras que fizeram isto bem longe :smiley:

#3

Não sei porque mas me falaram isso e eu nao dei a minima bola… :roll:
Agora eu sei o real sentido disso… :cry:

Poisé pelo que eu conversei com o gerente do projeto eles alteraram o comportamento de alguns componentes pra fazer o que eles queriam…

Então quer dizer , ou eu copio do jsf 1.1.01 o que faltar ou , estudo o que eles realmente queriam alterando o comportamento do JSF e implemento usando apenas a specificação ???

E tu acha que eles tão ligando pra isso ? :roll:
Uma pena mas é a realidade. ( Não se sinta ofendido )

Azarado eu ? Nem , magina. :lol:
Quanto a mandar os caras pra bem longe isso eu não posso mas to tentando incentivar o desuso dos frameworks caseiros que existem por frameworks opensource.

*Que fique claro que não foi eu que inventou de alterar o ciclo do jsf e fazer esse tipo de “gambiarra”. :slight_smile:

#4

só pra constar, não acho que frameworks caseiros sejam um problema …
uso algo pareciso em todas as empresas em que eu passo, mas normalmente, estes são construidos em cima dos padrões, ou em cima do spring :smiley:
dependendo do caso :smiley:

a desvantagem é, tem que matar no peito na hora de dar manutenção …

#5

[quote=urubatan]só pra constar, não acho que frameworks caseiros sejam um problema …
[/quote]

Nem eu desde que não afetem minha sanidade.

Pena que eu nao tive essa sorte. Bom mas cada caso é um caso.

Aff essa é a melhor parte…

Bom mas entao o que faco pra resolver ?
Copio as classes velhas da implementação antiga da sun ?
Ou digo algo do tipo , deixem o JSF 1.2 pra novos projetos. :stuck_out_tongue:

#6

da uma olhada no que estas classes da sun do 1.1 faziam, se for fácil reproduzir o funcionamento, faça uma copia delas utilizando os recursos do 1.2 …

a solução para este “dilema” basicamente seria:
levantar qual o esforço requerido para a migração
largar a bomba de “fazer ou não fazer” no colo do gerente do projeto, mas informando ele de qual seria o esforço, assim ele tera dados para verificar se vale a pena fazer isto agora, ou não :smiley:

#7

Valeu! Eu tinha pensado ou em copiar a classe mas reproduzir o funcionamento foi algo que eu não tinha pensado antes , quem sabe seja mais facil.

Eu ja fiz isso (eu acho , só se ele não entendeu) entao ele me disse o seguinte e se mesmo copiando a funcionalidade o componente passe a ter um comportamento instavel / indesejavel ? R.: Deixamos a migração para JSF 1.2 para novos projetos e começamos a estudar novos frameworks e maneiras alternativas de fazer isso que estavamos fazendo…

Que fique de aprendizado pra min , quando construir um componente pra
parte V(iew) do MVC que nao se amarre a nenhuma especificação , assim nao deixo um legado ruim…

Bom , valeu pelas respostas Rodrigo! :thumbup:
[s]ao

#8