66 comentários

• Gustavo da Rocha Barreto Pinto(usuário não autenticado)

  14 de Março de 2012, 10:23

   

  Roque, o build.properties dos dois projetos informam o security 1.1.2.

  Envio em anexo os dois builds.

  Gustavo

  
  

  • Roque Pinel(usuário não autenticado)

    14 de Março de 2012, 10:57

     

    Seria interessante fazer um teste com o InitialService de cada serviço.

    Para isso, faça o deploy de ambos os projetos e antes de iniciar o JBoss, edite o arquivo META-INF/jboss-service.xml de cada PROJETO-initial-1.0.sar, conforme:

    Substitua o termo "mdarte", do atributo name da tag mbean, por um valor único. Por exemplo, no Projeto A podemos substituir por "mdarteA" e no B por "mdarteB".

    Com esse teste, quero ver se o InitialService de um projeto está interferindo no do outro.

    
    

    • Gustavo da Rocha Barreto Pinto(usuário não autenticado)

      14 de Março de 2012, 11:10

       

      Roque,

       uma das aplicações não possui o SAR.

       Será que este pode ser o problema ?

      Lembre-se que as versões de cartucho que elas utilizam são diferentes tb. 

       

       

      
      

      • Roque Pinel(usuário não autenticado)

        15 de Março de 2012, 14:01

         

        Olá Gustavo,

        Fiz alguns testes para confirmar o problema e ele está mesmo sendo ocasionado pelo acesso incorreto ao ControleAcessoImpl. Estarei abrindo um ticket para correção desse bug.

        Por enquanto, tente ver a solução através do encapsulamento ou verificando a possibilidade de se ter uma implementação igual no ControleAcessoImpl das duas aplicações.

        
        
      • Roque Pinel(usuário não autenticado)

        14 de Março de 2012, 11:41

         

        Poderia, mas seria estranho. O único papel do SAR é carregar o controle de acesso e as tarefas agendadas junto com o JBoss, e não na primeira requisição da aplicação, como é feito nas versões anteriores do MDArte.

        Isso possibilita, dentre outras coisas, a criação de aplicações que possuam apenas serviços (JAR), sem necessidade de uma interface web (WAR).

        Voltando ao problema, o mais provável é que a aplicação A esteja acessando o ControleAcessoImpl#trocaSenha da aplicação B, gerando o um erro pois não representa a mesma classe utilizada durante a compilação.

        Uma solução para isso seria encapsular uma aplicação em EAR... Farei alguns testes locais e te retorno com mais informações. 

        
        
      • Roque Pinel(usuário não autenticado)

        11 de Abril de 2012, 13:02

         

        Conforme conversamos, abri o ticket para correção do problema.

        svn.​soft​ware​publ​ico.​gov.​br/t​rac/​mdar​te/t​icke​t/54​&nbs​p;