Arquivo Discussoes de Programacao e Tecnologia 
Olá Pessoal!
Tenho um sistema com interface Swing conectando num WebService que faz as operações de persistência. Teria como eu utilizar a Injeção de Dependência do Mentawai sem ter uma interface web? Pois estou interessado em usá-lo mais tarde quando alguns módulos web forem implementados, além de poder usar os recursos do Mentabean que eu gostei bastante. Teria alguma forma de eu ter DI sem ter uma Action em si?
Obrigado desde já…
Olá Pessoal!
Tenho um sistema com interface Swing conectando num WebService que faz as operações de persistência. Teria como eu utilizar a Injeção de Dependência do Mentawai sem ter uma interface web? Pois estou interessado em usá-lo mais tarde quando alguns módulos web forem implementados, além de poder usar os recursos do Mentabean que eu gostei bastante. Teria alguma forma de eu ter DI sem ter uma Action em si?Obrigado desde já…
Dá para usar o Mentawai tranquilamente para fazer web services. Você pode fazer uma requisição web retornar JSON como resposta ou qualquer outra coisa (XML, String, etc.) Não será web service propriamente dito (SOAP ou REST) mas funcionará que é uma beleza e será extremamente simples. Agora tente fazer isso usando Hibernate e Spring. Uma zona que só…
Pois é, porém já tenho uma estrutura genérica inteira montada com Axis (via SOAP), e somente estava pensando em utilizar o Mentawai (com os recursos do Mentabean) que deixam os XMLs e Annotations de lado, para fazer ORM, CRUD e DI, porém sem interface web. Acredito que não seja possível nessa estrutura usar DI sendo que as instâncias das classes de serviços são feitas pelo Axis. Me corrija se eu estiver falando bobagem…
Levando isso em conta, neste caso não seria melhor utilizar Mentabean separadamente sem controles de IoC?
Pois é, porém já tenho uma estrutura genérica inteira montada com Axis (via SOAP), e somente estava pensando em utilizar o Mentawai (com os recursos do Mentabean) que deixam os XMLs e Annotations de lado, para fazer ORM, CRUD e DI, porém sem interface web. Acredito que não seja possível nessa estrutura usar DI sendo que as instâncias das classes de serviços são feitas pelo Axis. Me corrija se eu estiver falando bobagem…Levando isso em conta, neste caso não seria melhor utilizar Mentabean separadamente sem controles de IoC?
Sim, utiliza o MentaBean e o MentaConatiner de forma independente. Ambos suportam configuração programática.
hmmm, certo… e depois pra utilizar o Mentawai na parte web sem problemas? Pois classes provindas de BeanSession e até as próprias DAOs, por exemplo, são instanciadas manualmente… E outra, o load dos beans utilizando o BeanConfig também teria que ser feito separadamente? (que no Mentawai ficaria no ApplicationManager)
BeanSession e BeanConfig são coisas do MentaBean… o Mentawai oferece de forma integrada, mas tudo isso está no MentaBean.
Depois para usar o Mentawai vc também pode, mas aí vc vai ter que ver como vc vai integrar as coisas no seu app manager. Eu não tenho como te ajudar aqui, pois isso é coisa do seu sistema. Com certeza há como.
certo, vou dar uma investida para integrar nosso modelo de conexão com o MentaBean separadamente, até porque o pool de conexões que utilizo é gerenciado pelo container (Tomcat, no meu caso) e assim vou poder utilizar as vantagens desse framework sem alterar a estrutura de conexão…
vou colocar o tópico como resolvido, qualquer coisa volto a postar…
Obrigado saoj… e parabéns pelas APIs
mais uma pergunta…
eu teria como fazer a intância das DAOs de forma manual e as outras intâncias (como de BeanManager, Connection e BeanSession, por exemplo) serem injetadas?
Porque o acontece é o seguinte: um sistema swing poderá ter módulos web. Na parte de web service (que o swing invoca), as classes DAO são instanciadas em uma classe onde os serviços herdam, por exemplo, para uma DAO de Produto existe um ProdutoService (invocado pela aplicação swing) que herda de GenericWS, onde este instancia a DAO do produto. Teria como neste caso injetar a BeanSession e suas dpendências mesmo instanciando a DAO manualmente? Ou seja, somente parte das classes não ser injetada pelo Mentawai.
mais uma pergunta…
eu teria como fazer a intância das DAOs de forma manual e as outras intâncias (como de BeanManager, Connection e BeanSession, por exemplo) serem injetadas?Porque o acontece é o seguinte: um sistema swing poderá ter módulos web. Na parte de web service (que o swing invoca), as classes DAO são instanciadas em uma classe onde os serviços herdam, por exemplo, para uma DAO de Produto existe um ProdutoService (invocado pela aplicação swing) que herda de GenericWS, onde este instancia a DAO do produto. Teria como neste caso injetar a BeanSession e suas dpendências mesmo instanciando a DAO manualmente? Ou seja, somente parte das classes não ser injetada pelo Mentawai.
Sim, o MentaContainer possui o método inject que vc pode utilizar para fazer isso, ou seja, instancia um bean na mão e depois manda o container popular ele.
hmm legal… e pelo que vi eu consigo pegar o Container do AppManager, certo? Pois pretendo mesmo o sistema nao tendo interface web ainda, utilizar o Mentawai por completo.
Sim, o AppManager tem um método estático getContainer().
certo…
só estou vendo agora como integrar… provavelmente terei que implementar minha própria ConnectionHandler devido ao pool de conexões ser controlado pelo Tomcat…
Mais uma dúvida… O mentabean tem controle de transações também? Ou vc pega a Connection e faz o controle manualmente?
certo…
só estou vendo agora como integrar… provavelmente terei que implementar minha própria ConnectionHandler devido ao pool de conexões ser controlado pelo Tomcat…
Sim. Eu controlo o meu próprio pool de conexão logo não preciso ter esse integração com o pool do tomcat. O Mentawai oferece três pools de conexões. DBCP, C3P0 e BoneCP. O BoneCP é o melhor na minha opinIão.
Ele não tem como saber o que vc quer fazer com as transações. Então vc pega a connection e faz isso vc mesmo da maneira que precisar.
pois é, já tentei o uso do BoneCP mas pela versão do jar que baixei do site (mentawai-all-2.5.2.jar) o BoneCP não está embutido:
é necessário importar alguma lib externa?
Ele não tem como saber o que vc quer fazer com as transações. Então vc pega a connection e faz isso vc mesmo da maneira que precisar.
Estanho o all.jar deveria vir com o BoneCP. Pega o jar aqui enquanto não corrigimos isso:
<dependency>
<groupId>com.jolbox</groupId>
<artifactId>bonecp</artifactId>
<version>0.7.1.RELEASE</version>
</dependency>
blz… baixei o jar, vou importar ele separado…
Só para informação, importei o BoneCP mas ainda precisa de outra lib, mas nem se estressa q vou pegando elas separadamente e importando sem problemas…
valeu
de acordo com os testes aqui precisei baixar mais 2 libs adicionais além da lib do BoneCP, slf4j-1.6.6 e uma lib do google que contém a classe com.google.common.base.FinalizableReferenceQueue, porém inserindo essa última ocorre o seguinte erro:
não sei se é o certo, somente fui baixando as libs que apontavam como dependência essas classes e aí cheguei neste erro…
Nuca vi esse erro. Eu uso Maven e importo no maven. Nunca usei o mentawai-all.jar.
http://www.mentaframework.org/mtw/Page/RefApp/mentawai-aplicacao-de-referencia
Pois é, já vi essa aplicação de referência, inclusive baixei os fontes do svn para entender alguns detalhes, porém estou tentando alguma forma de utilizar o jar na lib do WEB-INFO e fazer o build com o ant. Pois importando o jar no braço necessita dessas dependências…
Tu vai ter que googlar para entender esse erro aí de IllegalAccessError. Não é um erro comum. Talvez o Jar esteja corrompido? Ou vc baixou versões incompatíveis?
Só quebrando a cabeça mesmo agora. Depois me fala como vc resolveu!
blz… na verdade procurei a dependência na web e achei alguns releases do google e baixei algumas versões porém todas deram esse mesmo problema… mas to na briga ainda, de alguma forma ou de outra vou tentar resolver aí eu volto aqui…
valeu!
Consegui resolver o problema importando uma lib específica no projeto também, então ao todo para utilizar o pool de conexões BoneCP (tendo em vista já a importação da lib do mentawai-all) são as seguintes:
agora minha briga é outra… como nunca usei Mentawai em nenhum projeto específico (somente para estudo), estou implementando um BeanSession para o PostgreSQL utilizando sequences de retorno tipo Long mas em algum lugar de SequenceType (não olhei o fonte ainda) existe um cast para Integer, estourando um ClassCastException, mas isso é assunto para outro tópico…
O que achei estranho é a presença deste erro no servidor na API do Google
Ago 09, 2012 6:37:47 PM com.google.common.base.internal.Finalizer cleanUp
Grave: Error cleaning up after reference.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.google.common.base.internal.Finalizer.cleanUp(Finalizer.java:154)
at com.google.common.base.internal.Finalizer.run(Finalizer.java:127)
Caused by: java.lang.NullPointerException
at com.jolbox.bonecp.ConnectionPartition$1.finalizeReferent(ConnectionPartition.java:191)
... 6 more
De qualquer forma, como ainda estou trabalhando nesta integração, então ainda não está 100%, e pode estar faltando algum detalhe…
Como ainda não pude fazer o teste do inject manual na DAO e demonstrar a solução real do problema inicial, vou retirar o tópico de resolvido, mas qualquer avanço nesta integração vou postando aqui…
valeu!
Testei basicamente 2 pools de conexão, o BoneCP (depois de importar as libs necessárias) e o DBCP, ambos funcionaram normalmente com PostgreSQL, criando as conexões e utilizando as já criadas para as requisições… porém quando é feito hot undeploy da aplicação, as conexões continuam lá… esse era um problema que eu tinha quando implementava o pool diretamente no código, por isso tive que mudar o pool para o tomcat gerenciar, inclusive aqui tem o tópico onde resolvo o problema fazendo isso…
Utilizando o Mentawai, é necessário algum encerramento manual dessas conexões?
Outro detalhe que notei é a quantidade de memory leaks que a aplicação gera… aparentemente as classes carregadas (contendo classes do Axis e do Menabean) continuam em memória mesmo após o undeploy…
Ago 10, 2012 9:55:19 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
Grave: The web application [/deployer] created a ThreadLocal with key of type [org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value [org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder@79d2af80]) and a value of type [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl] (value [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl@77003afb]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Ago 10, 2012 9:55:19 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
Grave: The web application [/deployer] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@302071c6]) and a value of type [server.database.SistemaDAOImpl] (value [server.database.SistemaDAOImpl@220d96d9]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Ago 10, 2012 9:55:19 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
Grave: The web application [/deployer] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@2a2a9206]) and a value of type [server.database.control.PostgreSQLBeanSession] (value [server.database.control.PostgreSQLBeanSession@50d8dd8a]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Ago 10, 2012 9:55:19 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
Grave: The web application [/deployer] created a ThreadLocal with key of type [org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value [org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder@79d2af80]) and a value of type [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl] (value [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl@4db8b87d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Ago 10, 2012 9:55:20 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
Grave: The web application [/deployer] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1a583e68]) and a value of type [org.mentabean.BeanManager] (value [org.mentabean.BeanManager@17692b5b]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Ago 10, 2012 9:59:40 PM org.apache.catalina.startup.HostConfig deployWAR
Informações: Deploying web application archive deployer.war
Acredito que ambos os problemas se relacionam, pois só pelo fato das conexões não serem removidas já é um fator considerável para o vazamento de memória…
Teria alguma solução para isso?
Filhão, se vc está usando o BoneCPConnectionHandler com o ConnectionFilter do Mentawai isso tudo já foi resolvido pra vc. Como vc está fazendo isso na mão, o que não recomendo pois esse problema já foi resolvido pelo framework, então vou te explicar.
O ConnectionHandler possui um método destroy que precisa ser chamado quando a aplicação sofre um redeploy ou quando ela é terminada para limpar as coisas direitinho.
Logo o BoneCPConnectionHandler implementa esse método destroy, que limpa e fecha o BoneCP.
Daí é o ConnectionFilter que chama esse carinha quando a aplicação está terminando.
Olha o código linkado acima para entender a coisa. Veja que o Controlador do Mentawai, que é um servlet, possui o método destroy(), que é chamado pelo web container quando a coisa está sendo restartada ou terminada. Daí esse cara chama o destroy de todos os filtros, inclusive do ConnectionFilter que por sua vez chama o destroy do BoneCPConnectionHandler.
Se usa o Mentawai de forma high-level, vc não tem que se preocupar com isso. Isso é feito pra vc. Se usar um outro framework qualquer que não seja FULL-STACK, então vc vai ter que perder um dia entendendo e fazendo isso funcionar.
Sei que no seu caso vc não está usando o Mentawai puro, então vai ter que quebrar a cabeça para entender como essas coisas conversam e se integram entre si. Espero ter te ajudado. Qualquer coisa pergunte mais.
Obrigado saoj pelas explicações e pela atenção…
Não sei se eu tinha deixado isso claro antes, mas estou tentando utilizar o Mentawai por completo (a minha ideia é fazer a injeção manual somente na classe de Web Service que chama a DAO, pois essa classe de serviço é instanciada no invoke do ws), no restante, estou utilizando o Mentawai (com a AppManager por enquanto sem mapeamento de Actions pelo fato de não ter interface web no momento)…
Levando em conta o que vc disse adicionei o load do filtro na AppManager
@Override
public void loadFilters() {
filter(new ConnectionFilter(getConnectionHandler()));
};
as conexões realmente foram limpadas no undeploy, mas os memory leaks ainda persistem…
Com o tempo ainda vou pegar bem o jeito, mas pelo que eu já estudei (inclusive fiz o artigo final da matéria de Linguagem III da faculdade só sobre Mentawai) achei muito interessante a forma full-stack e programática que o framework trabalha, é por esses e outros motivos que estou tentando a implementação dele em nossos sistemas, porém integrado com WebService…
Mas como eu citei antes, pretendo utilizar o Mentawai como um todo e somente fazer a injeção manual da parte de WebService através do container do AppManager, e aí vou conseguir integrar numa boa a parte desktop e web sob as mesmas camadas e ambas utilizando Injeção de Dependências controladas pelo Mentawai.
Se vc olhar bem esse warning vai ver que tem haver com a ThreadLocal da JVM. Parece que VM que vc está utilizando exige que o o thread local seja LIMPADO via método remove(). Nem o Mentawai nem o Axis estão fazendo isso. Eu nunca vi esse erro nas minhas aplicações. Talvez isso tenha haver com a sua configuração de tomcat?
Pois é, já tinha lido esse artigo da Apache sobre Memory Leaks, inclusive tentei já com as versões mais novas do Tomcat, mas sem sucesso… O Axis sei que deixa Memory Leaks ao undeploy, mas quando controlo o pool pelo tomcat, a quantidade de vazamentos diminui bastante (Nenhuma classe da aplicação em si fica em memória, apenas algumas do Axis). Já utilizando o Mentawai qualquer DAO invocada fica em memória após o undeploy da aplicação. Outro detalhe é que eu não crio explicitamente nenhuma ThreadLocal, inclusive tem um tópico onde discuto sobre esses memory leaks…
De qualquer forma, vou continuar estudando esse problema ao poucos até achar alguma solução que elimine ou diminua esses vazamentos…
Olhando o código do ConnectionFilter, vejo que ele LIMPA o thread local. Teria que olhar nos outros lugares do Mentawai para saber se ele está fazendo isso sempre.
Dá uma olhada no método afterConsequence:
O MentaContainer tb está removendo:
O MentaBean não usa thread local.
Só não vai me dizer que o threadLocal.set(null) é diferente do threadLocal.remove(). :shock:
Ok… vou dar uma procurada mais a fundo pra ver o por quê desses vazamentos… Só uma coisa, é o MentaContainer o responsável por invocar as classes e fazer a DI certo? Conforme vc me passou ele tb limpa a ThreadLocal no clear, então é estranho uma classe DAO ficar em memória, se é o MentaContainer que tem controle sobre ela. Corrija-me se eu estiver falando bobagem…
Vou fazer mais uns testes chamando o clear explicitamente do container do AppManager e ver o que acontece…
Ok… vou dar uma procurada mais a fundo pra ver o por quê desses vazamentos… Só uma coisa, é o MentaContainer o responsável por invocar as classes e fazer a DI certo? Conforme vc me passou ele tb limpa a ThreadLocal no clear, então é estranho uma classe DAO ficar em memória, se é o MentaContainer que tem controle sobre ela. Corrija-me se eu estiver falando bobagem…Vou fazer mais uns testes chamando o clear explicitamente do container do AppManager e ver o que acontece…
Sim mais como eu falei o clear está dando threadLocal.set(null) ao invés do remove. Não sei se é a mesma coisa. Dá uma olhada no código fonte do menta container e depois me diz o que vc achou.
blz, coincidentemente eu estava olhando um artigo sobre ThreadLocal e memory leak e vi o seguinte:
e logo após:
An explicity destroy method should have been provided on ThreadLocal. In
JDK 1.5, a new method remove
has been added to ThreadLocal?s API to complete its lifecycle management.
Users can call the remove method and avoid such memory leaks.
Vou dar mais uma olhada nos códigos do Container, como vc disse, e vou trocar os set(null) no clear para remove() pra ver no que dá…
blz, coincidentemente eu estava olhando um artigo sobre ThreadLocal e memory leak e vi o seguinte:e logo após:
An explicity destroy method should have been provided on ThreadLocal. In
JDK 1.5, a new method remove
has been added to ThreadLocal?s API to complete its lifecycle management.
Users can call the remove method and avoid such memory leaks.
fonte: http://www.0xcafefeed.com/2004/06/of-non-static-threadlocals-and-memoryVou dar mais uma olhada nos códigos do Container, como vc disse, e vou trocar os set(null) no clear para remove() pra ver no que dá…
Good find! Vou mudar todos os lugares no Mentawai, MentaBean, MentaContainer, MentaXXXX onde estou setando para null.
Fião: boa sacada. Eu não sabia desse detalhe do ThreadLocal. Agora sei. Thanks. 
Nova release do MentaContainer sem esse problema: 0.9.9
Nova release do Mentawai sem esse problema 2.5.3.
Pode baixar do Maven já.
Houve várias alterações no Mentawai, uma delas no ConnectionFilter => http://websvn.soliveirajr.com/diff.php?repname=Mentawai+Web+Framework&path=%2Ftrunk%2Fsrc%2Fmain%2Fjava%2Forg%2Fmentawai%2Ffilter%2FConnectionFilter.java&rev=288
Beleza cara…
Só vi agora o post, mas que bom que consegui ser útil em alguma coisa rsrs…
Vou baixar a nova versão para começar a lidar (provavelmente terei que fazer fora de hora), mas talvez não irei mais integrar com o Axis, e sim com o Apache CXF. Li alguns artigos comparativos e vi que o CXF além de trabalhar com SOAP pode integrar uma arquitetura REST… Me chamou atenção também a possibilidade de integrar com Spring, mas acho que não sou só eu que odeia XML pra tudo rsrs, por isso estou vendo a possibilidade de integrar o Apache CXF com o MentaContainer para IoC… mas ainda é só estudo…
saoj, você já trabalhou com algum framework pra implementação de WebServices em alguma aplicação sua (Axis, CXF, Jersey, JBossWS…)? Se sim, integrou com o Mentawai?
Abraço!
Beleza cara…Só vi agora o post, mas que bom que consegui ser útil em alguma coisa rsrs…
Vou baixar a nova versão para começar a lidar (provavelmente terei que fazer fora de hora), mas talvez não irei mais integrar com o Axis, e sim com o Apache CXF. Li alguns artigos comparativos e vi que o CXF além de trabalhar com SOAP pode integrar uma arquitetura REST… Me chamou atenção também a possibilidade de integrar com Spring, mas acho que não sou só eu que odeia XML pra tudo rsrs, por isso estou vendo a possibilidade de integrar o Apache CXF com o MentaContainer para IoC… mas ainda é só estudo…
saoj, você já trabalhou com algum framework pra implementação de WebServices em alguma aplicação sua (Axis, CXF, Jersey, JBossWS…)? Se sim, integrou com o Mentawai?
Abraço!
Já trabalhei com SOAP => http://www.seducaotecnologica.com.br/tutorial-soa-passo-a-passo-1/
Mas não gosto. Faço web services em cima do Mentawai mesmo, sem me atrelar a um contrato de publicacao como o WSDL. Foi o que eu falei aqui:
Sem querer pedir demais mas você tem algum exemplo de como seria o funcionamento? Você implementa o lado servidor somente com Mentawai? E o cliente para consumir esse serviço pode ser desktop sem problemas?
Veja como o Mentawai suporta Ajax de forma bem simples e flexível => http://www.mentaframework.org/mtw/Page/Ajax/mentawai-ajax
Um web service nada mais é que uma requisição AJAX. SOAP e REST são especificações (ugh!) para PUBLICAR os web services para o mundo. Acho que um cliente qualquer pode dar um parse no WSDL para se preparar para falar com os seus web services. Naquele link lá você pode ver como um cliente Ruby pode parsear o WSDL e começar a falar com os seus web services sem problemas.
Mas ao invés de suportar o WSDL eu posso chegar pra vc e falar assim:
Hey, chama essa URL aqui passando o ID de um usuário que vc vai receber um JSON com todas as informações dele:
https://ws.mycompany.com/mtw/User
Como parametros POST vc pode passar: (acho que é mais seguro do que passar isso via GET - agora fiquei na dúvida se o https encrypta os parametros na URL)
Aí vc vai receber um JSON de volta com todas as informações do seu usuário.
Única pergunta que ficou na minha cabeça é se tem uma maneira de compartilhar o objeto USER no lado do servidor (web services) com os clientes. Acho que isso vc pode fazer e prover um jar para os consumidores do seu web service.
Blz…
Vou seguir os passos do site que você citou, mas o outro site (https://ws.mycompany.com/mtw/User) está fora…
O que faço hoje é serializar todas as informações que vão para o WS (pois somente quem vai consumir esse web service é o cliente desktop que a gente mesmo desenvolve), o sistema todo é desktop e faz as requisições nesses WebServices enviando os objetos compactados e serializados para o (atualmente) Axis. Já no lado server eu simplesmente desserializo esse objeto e faço as operações de persistência e retorno outro objeto serializado… Basicamente é assim que tenho hoje…
A performance do sistema fica bem interessante compactando e mandando os objetos todos como byte[]… quero ver se consigo transmitir de forma simples os objetos fazendo essa serialização neste novo conceito…
Nuca vi esse erro. Eu uso Maven e importo no maven. Nunca usei o mentawai-all.jar.http://www.mentaframework.org/mtw/Page/RefApp/mentawai-aplicacao-de-referencia
O mentawai-all.jar foi consertado para incluir todas as classes. Antes não estava…
opa, beleza…
atualizando o projeto aqui…
abraço!