Mais um blog inútil.

Ois, amiguinhos. Tenho andado um pouco afastado desta rambóia por motivos sérios e profissionais, embora volta e meia faça um ou outro comment a um ou outro post. Sim, confirmo, a vida de pseudo-trabalhador / pseudo-estudante é, de facto, desgastante aborrecida, por vezes. Hoje deparei-me com um drama aqui no trabalhinho que até foi fácil resolver após uns minutinhos a pensar e a pesquisar no gugal. Na minha aplicação existe o try / catch habitual para handlar as exceptions. Existe também um finally para fazer qualquer coisa nomatter what. No entanto, e como estou a correr a aplicação na consola, caso faça um CTRL+C , o troçozinho de código que consta no finally não é executado, o que é uma maçada…Então pensei: “Ora o que eu queria mesmo…era uma forma de handlar este signal….em Java!!” . Em C isto seria coisa simples, mas nunca me tinha deparado com este drama em Java, apesar de a solução ser igualmente simples. Aqui vai a solução e espero que possa ajudar alguém (e também poupar alguma pesquisa):

public class AMinhaClass
{
      public static void main( String[] args )
      {
         Runtime.getRuntime().addShutdownHook( new Thread() {
                 public void run()
                 {
                     System.out.println( "Handler code goes here..." );
                 }
             }
         );
      }
 }

Ahmm…ok, aquilo deveria estar dentro de um ciclo ou qualquer coisa que justifique um handler, mas não me apetece estar a reeditar o post porque não me estou a dar bem com as formatações e o camandro e tenho de voltar para o trabalho. Adeus.

Ois.  Os dramas não me largam…ou se calhar não são dramas, eu é que ando particularmente melodramático com esta história toda porque, tal como o disse,  estou fartinho do Java. Deveras…!! Chego a pensar em estupidezes só para desanuviar… Hoje uma simples frase dita por alguém no departamento despertou em mim uma súbita vontade de aprofundar o meu interesse pela filosofia…porque estava farto do Java. “Faz o que quiseres!!” . Hmmmm…é interessante porque, se fizermos o que nos apetece estamos a fazer a vontade à outra pessoa…No entanto, se não fizermos o que queremos, estamos a tomar a liberdade de a contrariar, fazendo o que nos dá na gana…portanto mais uma vez estamos a ceder à vontade dessa pessoa. Confesso que a reflexão sobre este tema me deu uma enorme cólica. Mas não era sobre isto que eu queria blogar. Hoje resolvi mais um Java drama…inútil. O objectivo era fazer com que a aplicação (que está a correr no JBoss, que por sua vez usa o Tomcat como webserver) suportasse NTLM Authentication. Basicamente, caso um user (logado num determinado NT Domain) fizesse um http request à aplicação, não seriam pedidas quaisquer credenciais. Ora, isto é tudo muito bonito quando se usa o IIS + m$ technologies (ASP, ou whatever…). Em Java começou por se revelar uma PITA até ter descoberto o jCIFS. O jCIFS não é mais do que uma biblioteca que suporta o protocolo SMB/CIFS e é 100% Java. Lindo, ahm? Poderão estar a perguntar-se “Mas porque é que esta besta não se limita a ver o resultado retornado ao invocarmos o método getRemoteUser() ao objecto request (HttpServletRequest) ? “. Pois…porque sem esta treta, será sempre null. Então, a solução passa por ir ao ficheiro web.xml da nossa aplicação, adicionar lá um pequeno filtro, adicionar o jcifs-versiongoeshere.jar à classpath do nosso projecto e voilá! O filtro é algo deste género:

<filter>
    <filter-name>NtlmHttpFilter</filter-name>
    <filter-class>jcifs.http.NtlmHttpFilter</filter-class>

    <init-param>
        <param-name>jcifs.netbios.wins</param-name>
        <param-value>10.169.10.77,10.169.10.66</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.domain</param-name>
        <param-value>NYC-USERS</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.username</param-name>
        <param-value>somenycuser</param-value>
    </init-param>
    <init-param>
        <param-name>jcifs.smb.client.password</param-name>
        <param-value>AReallyLoooongRandomPassword</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>NtlmHttpFilter</filter-name>
    <url-pattern>/*</url-pattern>

</filter-mapping>

Podem omitir os parametros “username” e”password”. Ora, caso o request venha de uma máquina que esteja logada no domínio que consta no filtro, o HttpServletRequest já contém informação necessária para ser processada, mais precisamente informação correspondente à nossa continha do Windows. Lindo!! Adeus.

Ois miçadinhas. As partidas que a vida me tem pregado não me permitem mais que uns meros suspiros e desabafos de vez em quando no IRC para me queixar dos meus dramas com Java. Sim, eu era o maior defensor de Java à face da Terra…até ter de trabalhar com Java no meu dia a dia e deparar-me que maior merda só mesmo aquela que está a percorrer o meu intestino grosso de momento e me vai fazer acelerar o processo de escrita deste post. Não obstante, resolvi partilhar convosco alguns dos dramas que me têm apoquentado ao longo destes intermináveis dias de experiência laboral. Preparem-se, pois segue-se uma série de posts, todos eles repletos de Java dramas e com enorme propensão para provocarem vómitos aos estômagos mais sensiveis. Amo-vos.

Como aceder à JMX…em Java. Pois bem…foi-me apresentado um desafio no trabalho (não propriamente um desafio…foi mais uma tarefa que TINHA de fazer desse por onde desse) que consistia em disponibilizar estatísticas e para tal precisava de aceder a variáveis da JMX do JBoss. Segue-se um pequeno excerto de código que o permite fazer sem grandes stresses. Não espero que algum de vocês algum dia venha a precisar disto (não por ser difícil, mas por ser chato e useless), mas em caso afirmativo, aqui fica a tip:

public class AhETalJMX
{
	public static void main( String[] args )
	{
		InitialContext ic = new InitialContext();
		RMIAdaptor server = ( RMIAdaptor ) ic.lookup( “jmx/invoker/RMIAdaptor” );
		ObjectName name = new ObjectName( “slee:service=AlarmMBean” );
		MBeanInfo info = server.getMBeanInfo( name );
		MBeanOperationInfo[] opInfo = info.getOperations();
		for( MBeanOperationInfo o: opInfo ) {
			System.out.println( ” + ” + o.getReturnType() + ” ” + o.getName() );
		}
	}
}

Lindo, não é…? Adeus.