Arquivo Discussoes de Programacao e Tecnologia 
O BoxSQL, um novo framework para persistência utilizando templates SQL, fornece grande flexibilidade para projetos que utilizam banco de dados fragmentado ou mesmo para projetos onde a performance é obrigatória.
Na página do projeto pode-se encontrar um tutorial bem explicativo e mais detalhes sobre o framework, que está na versão 1.5.
Acesse http://boxsql.dev.java.net
Olá
Onde fica o link para download? Não achei na página do projeto.
[]s
Luca
Fica no link Documents & files
Aí você clica em versões e lá terá o jar do BoxSQL e o jar do Apache-DbUtils que é a unica dependencia do BoxSQL.
Tudo isso em mais ou menos 50KB.
Boa Sorte aí…
qual a diferenca desse seu framework para o suporte do novo JDBC 4 ?
Ao meu ver temos duas diferenças básicas:
O fato de o SQL ficar fora do código java, organizado em arquivos de templates que podem ser armazenados em pacotes, por temas relacionados por exemplo.
Outro fator interessante é que seus beans não terão nenhum acoplamento em relação ao banco de dados, mas não perderão o mapeamento automático que é feito por meio de reflection dentro do codigo do BoxSQL.
Você pode mandar inserir um objeto de qualquer classe, desde que os nomes dos atributos sejam iguais aos parâmetros do seu template de sql.
Isso é um mapeamento (quase) automático, pois você só precisará prestar atenção na convenção para JavaBeans e nos nomes do parâmetros.
Padronização no lugar de configuração.
QQ dúvida posta aí…
mas com o exemplo do JDBC que eu descrevi o beans tmb nao tem nenhuma relacao com o banco de dados… a carga deles / persistencia fica com encargo da interface que define isso com uma anotação…
Sei lá… nao consigo achar que anotações é um “vilão malvado” que vai misturar tudo… é apenas metadata…
Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?
http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html
Qual seria a diferença do BoxSQL para o Ibatis ?
[]s
Douglas
Concordo com você sobre as anotações.
Inclusive existem plano para mapeamento recursivo usando annotations.
Porém os nomes dos campos da tabela, as próprias tabelas e seu banco de dados.
Acho que essa é a vantagem maior e não o fato de usar anotações ou não.
Outra facilidade é a organização dos templates SQL. Isso facilita a migração de um banco de dados para outro, ou até mesmo de um refactoring de banco de dados, sem precisar recompilar a aplicação.
Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html
Qual seria a diferença do BoxSQL para o Ibatis ?
[]s
Douglas
É sim douglas, porém sem a complicação do XML. O Código SQL fica bem mais limpo e flexível.
Acho que JPA é tão simples… fazer os exemplos que são decritos com o iBatis e com o boxSQL é simplesmente piada… vc define um XML com 3 linhas… um @Entity e pronto… tudo funciona…
Nao consigo entender pra que usar frameworks deste genero…
Tenta relacionar 4 tables, chamar funções específicas de um banco de dados, ou subconsultas utilizando o mapeamento da JPA…
Aí você já percebe a diferença do objetivo entre um e outro. Há também a qestão da performance do JPA não ser tão boa quanto a performance do BoxSQL, por se tratar de código JDBC encapsulado com reflection.
Imagine um sistema que acessa bancos de dados já prontos e esses banco de dados são tão fragmentados que é inviável criar uma classe para cada tabela. Com o JPA não seria tão fácil de fazer isso, isso se é que daria pra fazer isso. Mas mesmo conseguindo a produtividade não seria a mesma.
Além disso, são alguns MB (Implementaçoes da JPA) contra ± 50KB (jar do BoxSQL já com o fonte para facilitar o debug.)
Não digo que o BoxSQL é melhor que a JPA, mas digo que é diferente. Atende casos que a JPA não atende. É questão de analisar o sistema e ver qual das opções se encaixa melhor.
É claro que o BoxSQL ainda tem muito o que melhorar. Já temos várias sugestões e alguns issues pra resolver, mas acho que estamos num caminho bom.
JPA(obviamente o hibernate) tambem faz chamadas SQL nativas 
Mas legal sua colocação quanto aos sistemas legados… porem gostaria que os exemplos dados fossem tambem mais realistas… que realmente mostre para que o “boxSQL” veio… e nao o tradicional CRUD.
Com SQL dentro do código e seu sistema altamente acoplado à um Banco de dados.
Agora imagine um sistema em que 90% das tabelas são esse caso.
Pra que usar JPA se voce vai ter que digitar código Nativo em 90% dos casos?
Eu falo isso porque vivi uma situação dessas num projeto recente.
Quanto aos exemplos, realmente os tutoriais que estão no site são básicos do tipo CRUD, porém isso é bomo para o publico menos experiente entender o funcionamento e também serve para o publico mais experiente.
Atualmente somos em 2 desenvolvedores realmente ativos, e isso nos impede de melhorar a documentação.
Há também a necessidade de mais testCases para situações diversificadas, o que fará surgir novas idéias e mais robustez.
Enquanto não der tempo de construir um exemplo mais complexo e melhor, os desenvolvedores terão de usar o BoxSQL para ver a real flexibilidade do produto.
PS.: Também estamos abertos a contribuições em relação a documentação.
Vamos fazer mais um projeto brazuca alcançãr o mundo. 
eu poderia usar nammedquerys e quardar essas querys nativas dentro de anotações em uma unica classe
agora… prq usar JPA ? prq JPA faz isso e MUITO MAIS…
pra que aprender 30 mil frameworks diferentes ?
Já disse… acho muito legal esse tipo de proposta… mas esses novos “falicitadores” devem estar mais alinhados com o que existe de novo no mercado… senao cai na premissa “mais do mesmo”
Dê um exemplo de como alinhar esse framework com o que há de novo (subentende-se JPA).
Dessa forma talvez consigamos melhorar o BoxSQL.
Esquecer esses .sql seria uma ótima… usando anotações…
Acho que talvez colocar as duas opções seria uma saida para esse caso. Só não vejo nenhuma vantagem em se usar anotações para armazenar SQL.
Se for pra criar uma classe só para conter templates, poderíamos usar constantes ao invés de anotations.
Além disso se um sistema tiver muitas queries que devam ser utilizada como nesse caso (300 por exemplo), quantas classes de templates criaríamos?
E a organização do código SQL?
Ah, e a concatenação do SQL (caso ele seja muito grande)?
E as famosa confusão das aspas que são motivos de muitos bugs em sistemas que utilizam SQL no código java?
Tudo isso pra que? Pra usar annotations e ficar na moda?
Sou a favor das annotations sim, como já falei, mas para casos onde elas são necessárias.
PS.: Alguma opinião diferente da nossa? Só pra enriquecer a discussão?
Olá a todos,
Só para lembrar, uma das futuras versões do BoxSQL, vai ser exatamente o recurso de anotações para gerar automaticamente os códigos SQL mais simples e diminuir a necessidade dos arquivos SQL.
Porém, digamos que o BoxSQL, reúne o melhor de 2 mundos, pois ele nasceu em um ambiente de aplicação, onde havia milhares de registros, várias tabelas, e um forte requisito de performance, por isso, era importante ter a possibilidade de usar querys otimizadas apartir de planos de execução (coisa de DBA’s), e como não queria deixar o SQL no próprio código Java, criei esse framework com o objetivo de ser simples, de fácil configuração, leve, que valoriza-se o uso de bons códigos SQL e favorece-se a criação de códigos java simples com forte adoção de padrões e boas práticas de programação.
E desde então, o BoxSQL vem evoluindo, de maneira simples, sem grandes pretensões e agradando um púplico seleto em outros projetos pelo Brasil.
Por isso, sabedores que muito temos a evoluir, aceitamos sugestões, que visem melhora-lo ainda mais.
Grato,
Manoel Pimetel
Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html
Qual seria a diferença do BoxSQL para o Ibatis ?
[]s
Douglas
Olá,
Pelo o que conheço do iBatis, uma das principais diferenças, é que ele usa arquivos XML para conter os códigos SQL e fazer os mapeamentos em cada classe.
E o BoxSQL, usa o conceito de “convenção ao invéis de configuração” , por isso, temos apenas um arquivo .properties para centralizar as configurações de acesso ao banco(JDBC ou JNDI). e os arquivos SQL que seão usados pela aplicação.
Grato,
Manoel Pimentel
manoelpimente.blogspot.com
Olá
Meu pitaco sobre a questão porque fazer isto se já existe aquilo.
Quando surgiu o hibernate o iBatis já existia (ou vice versa) e o JDO também. Quando surgiu sei lá o que outro sei lá o que já existia.
Depois de recentemente ler o livro The Miths of Innovation, aprendi que é melhor não encarar muito negativamente coisas novas.
Se vai pegar, se é melhor do que o que já existe e se promete ter a mesma evolução do que o que já existe é uma outra história. Antes de detonar, o momento ainda é de tentar entender para que serve e quais vantagens deste tal de BoxSQL que eu por exemplo ainda não percebi claramente.
[]s
Luca
Fiquei com uma dúvida. E quando houver relacionamentos entre as tabelas? Como o framework vai identificar a qual entidade pertence o atributo?
Bom, nesse caso ainda não está implementada essa funcionalidade.
Que ainda será implementada utilizando Annotations.
Veja um exemplo que explica como fazer isso:
Imagine que você tenha uma Classe Departamento e nela tem um atributo do tipo Pessoa.
Para você inserir esse departamento completo, incluindo o atributo comples do tipo Pessoa, o código ficaria assim:
public void insertDpto(Departamento dpto) throws Exception {
try{
BoxSQL box = new BoxSQL();
// Insere o departamento
int result1 = box.executeUpdate("insertDpto.sql", dpto);
// Insere o atributo complexo;
int result2 = box.executeUpdate("inserePessoaDpto.sql", dpto.getPessoa());
if(result1 == 0 || result2 == 0)
throw new Exception("não inseriu completo!");
}finally{
box.release();
}
}
Você tb pode setar os parâmetros manualmente, o que seria uma opção um pouco m ais trabalhosa, porém em alguns casos é necessário.
Para recuperar do banco de dados voce terá que fazer assim também. Primeiro recuperar o dpto e depois a pessoa.
Essa funcionalidade está na fila para ser implementada, mas com oeu já disse antes, tá faltando mao-de-obra, hehehhe...
Porém, mesmo sem essa funcionalidade não é tão difícil de realizar essa operaão. O único problema é que terá que ter um SQL para o objeto principal e um SQL para o atributo complexo.
Espero que tenha ajudado.
Felipe
A minha dúvida estava mais para consultas com select. No fim das contas eu gostaria de saber como faço para consultas em mais de uma tabela. Se tem alguma convenção para isso, ou se tem uma maneira de não esperar pela reflection que o framework faz. Estou fazendo essas peguntas porque gostei do framework e pretendo usá-lo em casos que o mapeamento objeo/relaciona não seja viável.
Valeu
Bom, nesse caso ainda não está implementada essa funcionalidade. Que ainda será implementada utilizando Annotations.Veja um exemplo que explica como fazer isso:
Imagine que você tenha uma Classe Departamento e nela tem um atributo do tipo Pessoa.
Para você inserir esse departamento completo, incluindo o atributo comples do tipo Pessoa, o código ficaria assim:public void insertDpto(Departamento dpto) throws Exception { try{ BoxSQL box = new BoxSQL(); // Insere o departamento int result1 = box.executeUpdate("insertDpto.sql", dpto); // Insere o atributo complexo; int result2 = box.executeUpdate("inserePessoaDpto.sql", dpto.getPessoa()); if(result1 == 0 || result2 == 0) throw new Exception("não inseriu completo!"); }finally{ box.release(); } }Você tb pode setar os parâmetros manualmente, o que seria uma opção um pouco m ais trabalhosa, porém em alguns casos é necessário.
Para recuperar do banco de dados voce terá que fazer assim também. Primeiro recuperar o dpto e depois a pessoa.
Essa funcionalidade está na fila para ser implementada, mas com oeu já disse antes, tá faltando mao-de-obra, hehehhe...
Porém, mesmo sem essa funcionalidade não é tão difícil de realizar essa operaão. O único problema é que terá que ter um SQL para o objeto principal e um SQL para o atributo complexo.Espero que tenha ajudado.
Felipe
Ok,
Para consultas voce pode fazer qualquer tipo de cruzamento entre as tabelas, já que você está utilizando SQL normal.
Quando à esperar pela reflection, tb pode ser evitada na hora de setar os parametros, porém não vejo ganho de performance, já que a API de reflection já é bastante otimizada.
Veja um exemplo para fazer sem reflection:
public void getDptoById(String Id) throws Exception {
try{
BoxSQL box = new BoxSQL();
//Define os parametros
box.setParameter("DPTOID", id);
// Obtém o departamento
Departamento dpto = (Departamento) box.getObject("obtemDpto.sql", Departamento.class);
//Obtém a pessoa pelo Id do Departamento (Supondo que exista um relacionamento baseado no ID do DPTO)
dpto.setPessoa((Pessoa) box.getObject("obtemPessoaPorDptoId.sql", Pessoa.class));
if(dpto == null || dpto.getPessoa() == null)
throw new Exception("Deu Pau na hora de pegar do banco!");
}finally{
box.release();
}
}
Viu a simplicidade?
Isso também poderá ser resolvido quando tivermos uma annotation que defina a recursividade de consultas e updates.
Ainda temos que pensar como serão as annotations para esse caso, mas sempre teremos a opção de fazer da forma
mostrada acima.
Olá,
Eu estava lendo todas mensagens pra entender um pouco do framework mas parei quando li essa parte.
Acredito que o problema que voces tiveram não foi qual framework de ORM utilizar, mas sim problema no banco. Pra eu ter que me preocupar com o plano de execucao de uma query meu banco tem que estar trabalhando por regra ou estar com as estatisticas desatualizadas (o mais comum). Entao ao invez do DBA enxer o saco do pessoal do desevolvimento ele devia era se preocupar em fazer o trabalho dele.
Se o problema fosse consultas gigantes por ter muitos relacionamentos sem necessidade eu até entenderia o argumento, mas esse do plano de execucao em pleno 2007 nao tem mais sentido.
]['s
Acredito que o problema que voces tiveram não foi qual framework de ORM utilizar, mas sim problema no banco. Pra eu ter que me preocupar com o plano de execucao de uma query meu banco tem que estar trabalhando por regra ou estar com as estatisticas desatualizadas (o mais comum). Entao ao invez do DBA enxer o saco do pessoal do desevolvimento ele devia era se preocupar em fazer o trabalho dele.Se o problema fosse consultas gigantes por ter muitos relacionamentos sem necessidade eu até entenderia o argumento, mas esse do plano de execucao em pleno 2007 nao tem mais sentido.
Talvez você esteja certo quando nos referimos a sistemas onde podemos modelar o banco de dados do zero, ou mesmo sistemas onde o banco está bem modelado. Mas não é raro encontrar situações onde o Banco de Dados está altamente fragmentado e incompatível com o modelo Orientado a Objetos.
Outra situação bem comum, são casos onde funções do banco devem ser chamadas durente um select ou um insert. Já vi vários sistemas que obtém informações que ao invés de estarem em um campo da tabela, são resultado de uma função, e devem ser adcionados dentro de um select específco.
Bom, eu ainda vejo muitos e muitos programadores PL/SQL por aí, isso significa que planos de execução e funções para tratamento de regras de negócios ainda são muito usadas.
Agora, se fossemos falar sobre um banco de dados perfeitinho, com um DBA compreensivo e alinhado com Orientação a Objetos, aí sim… Concordo plenamente com você.
Note que em nenhum momento eu falei em banco de dados preparado para OOP, o que eu quis dizer é que fazer query baseado em regras é coisa de no minimo uns 7 anos atras. Hoje em dia usar query baseada em custo, as famosas estatisticas do banco, é o mais correto. Se as consultas precisam trabalhar baseadas em regras nos dias de hoje o DBA nao anda fazendo o trabalho dele.
Ja passei por isso tambem, mas não seria essa uma situacao que me faria abandonar as facilidades de um ORM.
O fato de existir muitos programadores PL/SQL por ai não tem nada a ver com o fato de precisar ou não usar RBO. Eu ainda me considero programador PL/SQL e la por 2003 já não usava mais esse tipo de “regra” para minhas consultas.
Certa vez fui até repreendido por um DBA por estar forcando um indice com um hint do Oracle.
Pois é, mas eu nem falei isso, estou falando de banco de dados todo torto mesmo…ja mexeu com IFS Applications? Se sim deve imaginar o que to falando.
]['s
Bom, acho que meu caso se encaixa perfeitamente neste tópico !!!
Trabalho num empresa onde o principal produto é um ERP feito em Delphi + Oracle, que já existe a quase 8 anos. Os projetos web em java é tudo baseado neste banco, onde existem milhares de tabelas com milhares de Triggers e Pkg’s !!!
Estou desenvolvendo um projeto utilizando JSP + VRaptor + Hibernate, neste projeto tive que usar algumas funções específicas do Oracle, por isso 10% do SQL tive que usar Query Nativa.
Agora tenho um caso de um projeto já desenvolvido em JSP + JavaBeans + JDBC, onde pretendo migrar para JSP + VRaptor + Hibernate. Neste novo padrão 50% do SQL deverá ficar em Query Nativa devido ao uso de várias funções específicas do Oracle. Neste caso ficaria melhor usar o BoxSQL ???
Valew.
Pra não dar Quote em cima :
As experiências em cada empresa variam bastante, já encontrei projetos que seguem DDD e outros com tabelas fragmentadas como o amigo citou.
Gostaria só de argumentar em cima de características do Hibernate como Named Queries, para você externalizar e qual o ganho do BoxSQL dessa feature.
Lembrando que pode utilizar de formas diferentes, como XML ou Annotations :
mport javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EntityResult;
import javax.persistence.FieldResult;
import javax.persistence.Id;
import javax.persistence.NamedNativeQuery;
import javax.persistence.SqlResultSetMapping;
@Entity
@SqlResultSetMapping(name = "implicit", entities = @EntityResult(entityClass = data.Employee.class))
@NamedNativeQuery(name = "implicitSample", query = "select e.empno empNumber, e.ename empName, e.job empJob, e.sal empSalary, salg.grade empGrade from emp e, salgrade salg where e.sal between salg.losal and salg.HISAL", resultSetMapping = "implicit")
public class Employee {
private String empNumber;
private String empName;
private String empJob;
private Double empSalary;
private int empGrade;
@Column
@Id
public int getEmpGrade() {
return empGrade;
}
public void setEmpGrade(int empGrade) {
this.empGrade = empGrade;
}
@Column
public String getEmpJob() {
return empJob;
}
public void setEmpJob(String empJob) {
this.empJob = empJob;
}
@Column
public String getEmpName() {
return empName;
}
public void setEmpName(String empName) {
this.empName = empName;
}
@Column
public String getEmpNumber() {
return empNumber;
}
public void setEmpNumber(String empNumber) {
this.empNumber = empNumber;
}
@Column
public Double getEmpSalary() {
return empSalary;
}
public void setEmpSalary(Double empSalary) {
this.empSalary = empSalary;
}
}
Agora tenho um caso de um projeto já desenvolvido em JSP + JavaBeans + JDBC, onde pretendo migrar para JSP + VRaptor + Hibernate. Neste novo padrão 50% do SQL deverá ficar em Query Nativa devido ao uso de várias funções específicas do Oracle. Neste caso ficaria melhor usar o BoxSQL ???Valew.
Eu sugiro utilizar as 2 soluções. Você poderia utilizar o BoxSQL para manter o seu SQL simples e organizado e o JPA ou alguma outra coisa para os outros 50%.
Vale lembrar que o BoxSQL faz isso com 51Kb, então não é nenhum elefante branco para resolver seu problema. É uma API simples, com um objetivo simples.
Mas em minha opinião a flexibilidade que o BoxSQL oferece em relação às NamedQueries do JPA é bem maior, podendo passar várias coisas como parâmetros.
O exemplo do Kenobi ficou muito bom e parece muito simples, mas se você reparar o banco está bem similar ao objeto.
Imagine que essa Classe citada pelo Kenobi tivesse 3 tipos de queries diferentes. Isso pode acontecer por inúmeros motivos.
Uma tabela só de valores e outra só de metadados da entidade. Em momentos você precisa cruzar as duas tabelas para obter os metadados junto com os valores ou momentos que só precisamos dos metadados (para montar telas com campos dinâmicos).
Não gosto da idéia de ter 3 ou quatro queries embutidas em annotations dentro dessa classe.
Aí numa dessa eu pergunto, por que não usar o BoxSQL?
Será que vai ferir muito os conceitos da JPA? O BoxSQL não pode vir a somar num casos como o citado acima ou mesmo o caso do ERP com Java Beans e JDBC? A reestruturação do projeto em JSP + JavaBeans + JDBC para utilização do BoxSQL é bem simples. Remove a linhas de código do DAO, pões as consultas em templates e coloca de 3 a 10 linhas do BoxSQL. E quanto à migração desse projeto para a JPA?
Mais uma vez volto a falar. Em sistemas novos com entidades sólidas e não fragmentadas, não precisamos do BoxSQL (apesar dele atender tb a esse publico). Mas em situações de banco de dados tortos e eu chamo de torto um banco com várias tabelas para formar um único objeto (o que não tem relação com execução por regras), o BoxSQL é realmente uma boa opção para resolver isso.
Lembrando que você pode sempre externalizar isso, não necessariamente precisa ficar como annotation.
Ficaria em XMLs. É válido também, mas se não formos utilizar nenhuma outra funcionalidade da JPA, acho que os templates em .SQL seriam melhores do que os XMLs ou mesmo melhor do que colocar essas annotations em uma única classe.
o que voces acham?
A discussao é… qual a vantagem do BoxSQL ? só estou vendo uma… curva de aprendizado não tão ingrime…
JPA te dá 4 ou 5 maneiras diferentes de fazer o que o boxSQL faz… e ainda é integrado… transacoes etc…
JPA e BoxSQL são diferentes.
Eu uso Ibatis e não tenho problema em ter minhas queries em XML, gosto da maneira do Ibatis.
Você deu dois exemplos gerando exceções.
No ibatis você consegueria fazer o mesmo resultando colocando o retorno da query em um dois objetos.(como foram usado no exemplo)
<select id="findEmployees" resultMap="empResult">
SELECT * FROM emp
<dynamic prepend="WHERE">
<isNotEmpty prepend="AND" property="id">
empno=#id#
</isNotEmpty>
<isNotEmpty prepend="OR" property="name">
ename=#name#
</isNotEmpty>
</dynamic>
</select>
<select id="findByDept" resultMap="empResult">
SELECT * FROM emp
<dynamic prepend="WHERE">
<iterate property="departments" open="(" close=")"
conjunction="OR">
deptno=#departments[]#
</iterate>
</dynamic>
</select>
aew feliperod qual a diferença entre usar o boxsql.properties e nao usa-lo.
Verifiquei que na video aula em q o manoel ministra, este nao usa o .properties,
entou pergunto ha alguma diferença de performace entre usa-lo ou não ?
A versção que ele usava quando gravou a video-aula não possuía o arquivo properties ainda.
Hoje é obrigatório o properties.
Tivemos que fazer isso para que o BoxSQL fizesse a conexão automaticamente, e dar a opção de escolha entre conexão JDBC ou JNDI.
A versão que ele usava era denominada 2.21, mas depois de pensarmos um pouco e acabarmos um refactoring estrutural no BoxSQL, decidimos resetar o numero da versão.
QQ dúvida posta aí.
Seguinte,
Estive testando algumas situações no JPA e não precisei ir muito longe.
Imagine que tenho uma tabela simples, com uma primaryKey e um unique constraint para um campo.
Como faria para obter um objeto a partir daquele unique constraint usando JPA?
Simples, teria que construir uma query. Colocar o SQL no meio do código. Ou como já citado aqui, usar uma named query, que na minha opinião deve ser usado para casos mais complexos.
Dessa forma temos que chamar em.createQuery(“seu sql aqui no meio do código”).getResultList()
Tá, ele já retorna a lista populada, mas o BoxSQL também faz isso. Então fica minha pergunta, quando a funcionalidade de queries simples estiver implementada no BoxSQL, sem precisar de templates e também a funcionalidade de um DAO generico utilizando Generics já embutido no BoxSQL, qual será a vantagem de se usar JPA?
PS.: Falta ainda citar que a parte de Log e Transaction do BoxSQL precisar ser repensada.
Mas o que eu quero dizer é, imagine um framework com 51Kb, que faz tudo que o JPA faz com muito menos configuração. Entre qual do dois você optaria?
Sua situacao eh bem particular… porem…
te devolvou com outra pergunta…
e qual eh a vantagem em NAO usar JPA ?
Sua situacao eh bem particular… porem…te devolvou com outra pergunta…
e qual eh a vantagem em NAO usar JPA ?
Não acho que minha situação seja realmente tão particular assim.
Imagine uma situação simples, de uma tela de login. O cara digita o email e o password.
Mas meu banco de dados tem uma primaryKey pelo CPF e uma unique constraint pelo email.
Tenho que usar uma Query pra fazer isso. Mas e daí? No BoxSQL tb tenho que usar uma query.
Mas o BoxSQL é um framework em evolução e tem apensa 51KB. A curva de aprendizado é bem menor e tem a vantagem de não colocar o SQL dentro do código java.
E para obter uma simples lista de registros usando JPA? Eu preciso de uma Query também. Putz, mas mudou a clausula where, e agora? Compila tudo de novo porque o SQL tá dentro do código. Mas em que classe?
A única vantagem que vejo para JPA é que é especificado pelo JCP. O o torna um padrão no desenvolvimento. Porque os outros itens de vantagem são temporários.
Mapeamento de Herança no BoxSQL é Transparente, indice e constraints também, pois são definidos no código.
Ps.: Eu optei por usar JPA no projeto atual, fato que demonstra que não acho JPA ruim, porém acho o BoxSQL muito promissor.
rapaz… me desculpe… esta estoria de “vai ter que recompilar tudo” para mim eh pura baboseira… hoje em dia um “play” no netbeans e vc tem o .jar na mao pronto. Acho que posso contar nos dedos as vezes que abri um .jar na unha para a alterar o conteudo dele… de alguma conf…
Vantagens temporarias ? Hibernate oferece vantagens temporarias as muito tempo hein ? JPA veio padronizando isso…
Acho que nao tem nada de temporario…
Vou tentar preparar 2 exemplos pra postar…
A mesma estrutura, uma usando o BoxSQL e outra usando JPA.
A todo mundo pode decidir qual se encaixe em seu projeto.
Ps.: Com Vantagem temporária eu me referi às vantagens que o JPA tem sobre o BoxSQL, como geração de queries simples automaticamente, porém que estão sendo implementadas no BoxSQL, por isso chamei de temporárias as vantagens.
Perfeito 
valeu !
JPA e BoxSQL são diferentes.Eu uso Ibatis e não tenho problema em ter minhas queries em XML, gosto da maneira do Ibatis.
Você deu dois exemplos gerando exceções.
Tem como fazer isso?
No ibatis você consegueria fazer o mesmo resultando colocando o retorno da query em um dois objetos.(como foram usado no exemplo)E isso?<select id="findEmployees" resultMap="empResult"> SELECT * FROM emp <dynamic prepend="WHERE"> <isNotEmpty prepend="AND" property="id"> empno=#id# </isNotEmpty> <isNotEmpty prepend="OR" property="name"> ename=#name# </isNotEmpty> </dynamic> </select><select id="findByDept" resultMap="empResult"> SELECT * FROM emp <dynamic prepend="WHERE"> <iterate property="departments" open="(" close=")" conjunction="OR"> deptno=#departments[]# </iterate> </dynamic> </select>
Cara, desculpa a demora em responder ao seu tópico... na verdade eu nãotinah visto sua pergunta.
Agora dessa forma com ofoi feita no iBatis, o BoxSQL não faz, porém é possivel criar a clausula WHERE como uma string no código java, ou mesmo obter somente a clausula WHERE a partir de um template separado, e "concatenar" ao resto do código, como se fosse um parâmetro normal.
Resumindo, dá pra fazer isso de uma forma diferente. ;-)
Faz TUDO o que o JPA faz? Não acha que essa afirmativa foi um pouco exagerada?
Faz TUDO o que o JPA faz? Não acha que essa afirmativa foi um pouco exagerada?
Como falei em um dos posts acima. No momento você tem razão, o BoxSQL não faz tudo o que o JPA faz, mas após conseguirmos diminuir a lista de novas features e issues, ele fará tudo o que o JPA faz. Claro que do ponto de vista de um framework de persistência, sem tocar na parte de EJB3.
Eu me pergunto se a galera só olhou no site ou se tentou usar mesmo, sem preconceito e pensou nas possibilidades.
Experimentem o framework e verão que o BoxSQL é um sério framework em termos de persistência e que com um pouco de ajuda (OpenSource precisa da galera mesmo) o BoxSQL pode se tornar melhor e se livrar de alguns issues.
Acho legal sua iniciativa, não estou querendo de forma alguma desmerecer ou desvalorizar seu projeto.
A questão que eu coloco no aspecto “fazer tudo” é que o hibernate, que acabou definindo os rumos da especificação da JPA, é um framework extremamente maduro, com um respaldo de milhares de programadores espalhados pelo munto e com anos de estrada.
A correta utilização do hibernate exige um conhecimento profundo, existem casos que talvez não ocorram com frequência, mas que são complicantes em grandes projetos e já passei por várias experiências nesse sentido. Mas a flexibilidade do hibernate é enorme, o framework é extensível o suficiente para permitir features em projetos bem específicos e até hoje consegui contornar qualquer restrição do hibernate de forma simples, porque o próprio hibernate me propicia essa facilidade.
Por isso eu digo que o “fazer tudo” é exagerado. Mais cedo ou mais tarde você irá se deparar com questões não tão simples e verá que uma ou outra decisão do projeto não deixou seu framework tão flexível assim.
As vezes um termo usado pode tirar a credibilidade de uma idéia, por isso precisamos ter cuidado.
Um framework ORM que possa prever todas as possibilidades, ser configurável e extensível o suficiente não é uma coisa relativamente simples, e assim como o hibernate pode exigir muitos anos e a participação direta e indireta de milhares de programadores.
Direcione o foco do seu projeto e não tente concorrer, a pricípio, com o hibernate ou com JPA. Quem sabe um dia, se o framework atigir um grau de aceitação e qualidade suficientes isso aconteça por si só.
Olá Alex,
Você pode ter razão, talvez seja um pouco de pretensão dizer que o BoxSQL faz TUDO que o JPA faz, até por tudo isso que você falou. O Hibernate é bem maduro já e seria difícil entrar numa concorrência.
Mas imagine se a galera começa a usar e começa a colocar as características que eles querem no framework. Pela simplicidade do código do BoxSQL, a maioria seria fácil de implementar. Algumas demorariam mais, mas tenho certeza que seria um sucesso.
E tirando algumas excessões cabeluadas, sem comparar a estabilidade do Hibernate já conquistou e a confiança da comunidade, o BoxSQL tem um potencial gigantesco de se tornar um concorrente à altura para o Hibernate.
Ps.: O sistema de annotations para mapear algumas entidades está quase pronto. (Só não está porque o tempo dos desenvolvedores tá meio escasso).
Você é um piadista Feliperod, isso ai nunca vai ser páreo para o Hibernate.
Cara, achei seu comentário de uma inteligência extraordinária. Demonstra de forma bem clara que ou você não leu, ou você não entendeu tudo que foi escrito acima. De qualquer forma peço que deixe os comentários para pessoas capazes.
Olá,
Bem interessante 
Eu já passei muito stress com Hibernate, e acho q tem configuração d+, para projetos grandes que é exigido uma analise mais complexa, pode ser indispensável, mas se eu quero fazer um projeto pequeno e rápido o BoxSql parece vir de encontro com esta necessidade.
Apenas passei o olho por cima do site e li aqui praticamente todas as mensagens.
E já tenho uma dúvida e uma sugestão :roll:
Dúvida: É preciso usar o boxsql.properties? Por exemplo numa aplicação que eu trabalho com vários banco de dados, eu tenho como fazer isto? Teria que ser dois boxsql.properties ou o BoxSql() suporta setar as configurações pro código como o Hibernate? Ou dizer qual “boxsql.properties” deve ser utilizado? Se puder me dar um exemplo agradecia.
Sugestão: Pelo que eu entendi neste exemplo: NOME=’:NOME’, … o :NOME se refere ao método getNome que a classe vai ter associada a esta query, logo sendo assim já deve dar para saber q o método retorna uma String… logo já poderia se por o ’ ’ automáticamente e também fazer o controle/proteção de sql injection, isso ajudaria muito a proteger mais as queres e também não se preocupar na query em colocar os ’ '.
Parabéns pelo projeto e sucesso, vou tentar usar o BoxSql em novos projetos que de para usa-lo, e depois se surgir mais alguma coisa digo
Valew
Pra que usar um framework que ninguém usa ? e se você precisa de alguma documentação ou ajuda ?
ninguém sabe de nada…
por favor isso é coisa de desenvolvedor que quer se aparecer… dizer que faz projetos e tal, quer se aparecer ? trabalhe.
Tanto que esse boxsql está sempre uns 10 passos atrás dos principais frameworks ORM de verdade do mercado, quando
vc disse que vai ter annotations mesmo ???
Isso ai só serve pra fazer gambiarra de fundo de quintal, ou vc acha que alguém vai usar EJB com boxsql ?
fui.
Pra que usar um framework que ninguém usa ? e se você precisa de alguma documentação ou ajuda ?
ninguém sabe de nada…por favor isso é coisa de desenvolvedor que quer se aparecer… dizer que faz projetos e tal, quer se aparecer ? trabalhe.
Tanto que esse boxsql está sempre uns 10 passos atrás dos principais frameworks ORM de verdade do mercado, quando
vc disse que vai ter annotations mesmo ???Isso ai só serve pra fazer gambiarra de fundo de quintal, ou vc acha que alguém vai usar EJB com boxsql ?
fui.
Eu participo e lidero alguns projetos open source… e digo… tu é o cara mais ignorante que já vi, sem saber pra que existe varios projetos com o mesmo fim, é uma ignorancia sem tamanho…
Se fose assim não precisariamos do Gnome nem do Kde basta um dos dois, e então Fluxbox, quem usa Fluxbox? Os caras do Fluxbox fizeram para se aparecer? Sim talvez, mas me deram uma alternativa que gosto e uso!
É mais um projeto de persistência é! Mas é diferente! Não te agrada, ok… mas agrada a mim e a outros, eu já vi aonde isto pode me ajudar, e tu de tão ignorante que é nem tem capacidade para pensar ou imagina uma utilização.
Como dei o exemplo do Gnome, KDE, Fluxbox, pode se aplicar a varios outros projetos, pra tudo tu tem alternativas boas num aspecto e más em outro. Basta ter imaginação e saber usar aonde é preciso.
E o BoxSQL q tem 50kb, tu precisa tanto assim de ajuda é sinal q tu é um péssimo programador e nem capacidade para olhar código opensource consegue…
Te encherga meu, pra q dar uma de flamer, isto te faz feliz?
Pesso desculpa ter decido o nível, mas não consegui evitar!
Seja para se aparecer ou não, tudo isto contribui para a maior diversificação!
Ninguém pode ter opinião aqui que já vem ignorantes detonar.
Programador bom deve ser a turma que desenvolve o BoxSql.
Essas “facilidades” que dizem que o boxsql tem pode seduzir muita gente, afinal não precisa saber de muita coisa pra usar isso ai.
Mas quem começa com isso ai já começa mal, é melhor usar JDBC puro mesmo que usar algum framework que ninguém sabe e nem testa pra saber se
funciona.
E se der pau, bug quem vai corrigir ? nem versão nova sai meu amigo … me poupe, inventar a roda é fácil agora que já está pronta.
Ninguém pode ter opinião aqui que já vem ignorantes detonar.Programador bom deve ser a turma que desenvolve o BoxSql.
Essas “facilidades” que dizem que o boxsql tem pode seduzir muita gente, afinal não precisa saber de muita coisa pra usar isso ai.
Mas quem começa com isso ai já começa mal, é melhor usar JDBC puro mesmo que usar algum framework que ninguém sabe e nem testa pra saber se
funciona.E se der pau, bug quem vai corrigir ? nem versão nova sai meu amigo … me poupe, inventar a roda é fácil agora que já está pronta.
realmente… tu deve viver em outro mundo…
bugs em projetos opensource!? quando ha se a equipe que desenvolve nao esta ativa eu posso corrigir, e me virar, claro q um projeto pequeno e novo tem mais probabilidade de ficar abandonado, mas, se eu vejo que o projeto ja atende as minhas necessidades, fico satisfeito, no futuro se precisar de mais uso outro projeto, e assim por diante, e uma boa iniciativa, nao vejo problemas mas se tu nao quer usar, e se tu acha q e melhor usar JDBC puro ok boa sorte! :twisted:
pois e, tem gente q prefere arrastar as pedras do q rolar…
(desculpa este pc esta com problemas nos acentos )
Olá,Bem interessante
Eu já passei muito stress com Hibernate, e acho q tem configuração d+, para projetos grandes que é exigido uma analise mais complexa, pode ser indispensável, mas se eu quero fazer um projeto pequeno e rápido o BoxSql parece vir de encontro com esta necessidade.
Obrigado pelo feedback. Obrigado por se importar em defender o projeto e a liberdade de iniciativa no mundo openSource. Só sugiro não gastar as teclas com flamers, não vale a pena.
Bom, no construtor do BoxSQL você pode passa o nome do arquivo de properties, podendo assim ter várias configurações num mesmo projeto. Ele não permite setar as configurações pelo código, mas isso é fácil de resolver. Basta criar setters na classe GlobalSettings para poder setar via código e resolver possíveis erros na falta do arquivo de properties. Mas eu recomendo fortemente que use o arquivo.
Ótima sugestão. Na verdade é preciso analisar todos os possíveis casos para isso. Imagine em que o atributo seja int, aí não sei como vai se comportar. O ideal é criar a logica e por nos testes. Você pode criar um issue no projeto, assim nos comprometemos a resolver.
Obrigado mais uma vez. Olha as annotations estão prontas, apenas faltando construir os testes completos. Estou com umas outras idéias pra implementar, mas peguei um projeto grande pra fazer a arquitetura agora e também tô construindo um projeto openSource para controle de projetos. Mas esse ainda é segredo.
De qualquer forma, aproveito o post para agradecer a todos aqueles que tem enviado feedback do projeto e que tem colaborado se cadastrando como desenvolvedor no site do java.net. Peço também para aqueles que tiverem dúvida, utilizar o forum no próprio site do projeto.
Tenho percebido que o BoxSQL facilita em muito para os iniciantes que não tem idéia de como configurar o JPA ou Hibernate. Muitos professores de universidades disseram usar o BoxSQL para ensino.
Por enquanto o BoxSQL não passa de um Wrapper para o JDBC baseado no já famoso DBUtils da apache.
Abração a todos…
Olá!
Meu nome é Dennys e trabalho a muito tempo com Hibernate, usando anotações, e digo que ele me atende muito bem. Porém o uso de Query Nativas (Named Querys) não me agrada muito já que, NA MINHA OPINIÃO, acaba poluindo muito o código JAVA e infelizmente o Hibernate ou qualquer outro ORM não favorece o desacoplamento destes planos de consultas.
Porém o boxSQL possui um potencial INCRÍVEL, e sei que ainda há muito para amadurecer, principalmente em JOINS por classes, mas sabendo que há a possibilidade atual de faze-lo de forma relativamente simples.
Porém gostaria de saber qual será o critério adotado (futuramente) para o Pool de conexões ?
O boxSQL irá definitivamente assumir a responsabilidade de tratar os tipos de Atributos da classe Persistida, ou seja, iremos deixar de sermos obrigados a colocar as ASPAS nos templates, justamente para o tipo String ou até mesmo char ?
Grato,
Dennys
Olá Dennys,
A prioridade do time é tornar operações básicas de select e insert automáticas. Depois é tratar os tipos. A idéia é que não seja mais necessário colocar aspas no template. Porém há alguns detalhes que precisamos resolver nos templates ainda, como por exemplo, a forma de definir que um trecho é parâmetro. Outro ponto importante é tornar a persistência recursiva automática, que representa o uso dos joins.
O mais importante é conseguir implementar tudo isso sem precisar de mais configurações. O BoxSQL tem o objetivo de ser leve e de fácil uso, então estamos pensando em como conseguir todas essas funcionalidades sem trazer complexidade ao uso.
Sugestões e idéias são sempre bem-vindas, como no caso da sua Dennys.
Abração,
Olá, amigo!
Fico feliz que tenha respondido com tanta rapidez.
Estive percorrendo o site boxsql.dev.java.net e até mesmo o forum de discução, porém as informações (dicas, exemplos e assuntos em geral) estão muito segregadas em varias mensagens, ora aqui no GUJ ora seja no forum oficial. Isto dificulta em muito a aceitação do projeto “boxSQL” pela maioria das pessoas. É claro que esta faltando pessoas para ajudar o projeto em varias partes, mesmo em documentação, porém acredito que se for feita uma CHAMADA para que haja colaboração estruturada, muitos estarão dispostos.
Atualmente esta havendo bastante divulgação do projeto, seja por indicação de uso entre os desenvolvedores, por processo de pesquisa “google, yahoo, etc…” ou até pela DevMidia (através de video aulas), no entanto seria importante centralizar tais informações, favorecendo o perfeito aprendizado e a colaboração com dicas, sugestões e implementação de código “mão-de-obra” para o projeto boxSQL.
Eu mesmo em particular já baixei pelo CVS e o estou estudando, para que de alguma forma possa contribuir, pois tenho a intensão de utiliza-lo em novos projetos, deixando assim de utilizar o Hibernate.
Pergunta:
1º) Há em algum local a centralização de códigos de exemplo, dicas ou qualquer assunto relacionado ao boxSQL ?
2º) Há a possibilidade de implementar um código mais complexo, contendo relacionamentos entre entidades, e não somente o que esta na página princial do site boxsql.dev.java.net ?
3º) E o Pool de Conexão (c3pO, SmartPool, Bitmechanic, etc…), já esta sendo planejado ou já existe a implementação na versão boxSQL-1.6.jar ?
4º) De que forma posso colaborar ?
Muito obrigado,
Dennys
Respondedo as perguntas:
No CVS tem o diretório de test. Queremos utilizar esse diretório para todos os test cases, o que já é uma forma de documentar e exemplificar. Além disso queremos deixar os testes como arquivos anexados do projeto e talvez até colocar links para esses arquivos no site da fratech, pois assim dica mais fácil de encontrar. Realmente, falta gente pra ajudar na documentação do projeto.
O problema é que não há tratamento automático no BoxSQL para relacionamentos. Isso deve acontecer com a recursividade da qual falei no meu post anterior. Para fazer isso, devemos tratar no método que faz uso do BoxSQL, realizando iso explicitamente. Precisamos pensar como realmente fazer isso. Acho que uma convenção de parâmetros seria ótimo para esse caso. O detalhe é que teremos que extender algumas funcionalidades do DBUtils para isso, e por isso deve ser bem pensado por causa da estabilidade garantida pelo DBUtils da apache.
Não está implementado ainda. Provavelmente utilizaremos o Apache DBCP para implementação do tratamento de pool de conexões. Se você tiver alguma sugestão nesse quesito seria ótimo.
Acho que está faltando comunicação entre as pessoas que se interessam pelo projeto. Utilizar o fórum para perguntas sugestões e comentários seria um bom começo. A documentação também é importante. Ajudar a organizar o site é importante também. Trabalhar no código é sempre bem vindo, porém acho que precisamos realizar tudo através de issues registrados no issue tracker do java.net.
Não tenho acesso ao email das pessoas que se inscreveram como desenvolvedores no projeto pelo java.net e, isso dificulta a comunicação. Já coloquei algumas chamadas no fórum do projeto, mas ninguém respondeu.
Portanto se alguém pretende ajudar, o ponto de contato deve ser sempre o fórum do projeto e, como segunda opção meu email e o do manoel pimentel, pois estamos sempre envolvidos com o projeto. Meu email é [email removido]
abração,
Descupem ressucitar o tópico, mas não consegui postar no forum do projeto.
Ainda não sou usuário, mas gostaria de dizer que tenho um grande interesse em ver o projeto crescer, pois tive inumeros casos onde precisei de algo assim para substituir coisas muito piores que usar querys separadas em arquivos.
Só gostaria de pedir aos desenvolvedores que ao contrário do que muita gente disse aqui e com muitissimo fundamento, há exceções que parecem ser ignoradas por algum motivo (tipo discução de religião ou futebol), que é o fato de existir muitas situações em que o JPA (hibernate ou toplink) não funcionam e ponto final.
Gostaria de pedir que o projeto focasse justamente o contrário do JPA. Sim adoraria que o projeto fosse para outro rumo.
Não estou loco, se é para usar algo como JPA que use o JPA pô, afinal é uma especificação. Agora se não da para usar JPA eu queria uma alternativa facil de usar, configurar e que me de o que a maioria dos projetos que não pode usar JPA me desse.
A possibilidade de deixar os Analistas Funcionais olharem e alterarem as querys, sem precisar do java e sem medo de ser feliz.
Um arquivo sql externo facilita MUITO esse tipo de trabalho. Para esse tipo de projeto seria perfeito. Só não gostei de ter um para cada query (ou entendi errado?).
Outra coisa que combina com esse perfil de projeto (essas situações de querys montadas na unha) é a performance. Seria bom focar esse ponto tambem. Inclusive na leitura dos arquivos SQL.
Gostaria de saber tambem se ele permite chamada de procedures e functions. Isso seria excencial. O Ibatis me permite tudo isso, mas dar manutenção nos XMLs é horrivel. Eu odeio XML, apesar de admitir ser necessário para muitos casos. Mas prefiro usar somente quando realmente necessário. A ultima equipe que trabalhei tambem demonstrou dificudades com o mapeamento do Ibatis e demorou um tempinho até fluir sem erros bestas, mas que consomem tempo a toa.
Muita gente ignora o fato de que a maioria da mão de obra do mercado não é especializada, e muitos não tem conhecimento suficiente para usar um framework complexo como hibernate (facilidade? Ta brincando né? Ja viu como é trabalhar com chave composta em JPA?). E muitas empresas ja tem um perfil definido de trabalho, com profissionais que sabem muito do negócio e de SQL, mas não tem conhecimento nenhum em em java. Antes do código, o mais importante em um produto é o que ele faz.
Ja trabalhei em projeto que o Hibernate foi proibido pelos gerentes por simplismente não encontrar mão de obra disponivel tornando uma dor de cabeça a manutenção do mesmo.
Não trabalhei com hibernate o suficiênte para afirmar nada, mas não consigo ver ele sendo usado em um RP grande. Com tabelas enormes, equipe grande (de desenvolvedores e funcionais) em um mercado comcorrido e com prazos absurdos como no Brasil.
Espero um dia poder fazer parte de um projeto e equipe assim. (Seria um sonho).
Quando o mysql surgiu, muita gente criticou o fato dele não ter coisas básicas que outros banco de dados tinham e eram considearas excenciais por muias pessoas, o fato dessas coisas excenciais deixarem o BD lento tambem éra ignorado, e algum tempo depois a empresa que criou ele foi adquirida pela Sun por $1 bilhão. Claro depois dele ser reconhecido merecidamente como um (ou o mais ) rápido banco de dados do mercado.
Espero que o BoxSql consiga achar o seu espaço.
E por fim gostaria de agradecer a iniciativa e me descupar pelo texto grande.
Bom dia!
Eu concordo com você mvargens !
Tem casos que o Hibernate é um verdadeiro saco e tenho que acabar reinventando a “roda” para chegar a uma solução plausível.
Infelizmente tenho percebido que o projeto BoxSQL anda meio paradão e também gostaria de vê-lo progredir, principalmente no quesito de tabelas relacionais, posi neste momento é o que mais sinto falta no BoxSQL.
No demais, parabéns aos idealizadores do projeto e bola pra frente!
PS: Não deixem o “espírito” do BoxSQL desaparecer, continuem com algumas novidades, mesmo que sejam pequenas.
Abraços,
Dennys
ja que “uparam” o topico, ao ler um pouco a thread, concordo com os posts do Luca, em questão de não criticar novos projetos e, acho que realmente já é possível fazer isso usando named queries no hibernate. E, se for usar ibatis ainda tem opcoes de querys dinamicas (nao sei se o BoxSQL faz isso)
de qlqer maneira, eu testaria… parece produtivo.
ja que “uparam” o topico, ao ler um pouco a thread, concordo com os posts do Luca, em questão de não criticar novos projetos e, acho que realmente já é possível fazer isso usando named queries no hibernate. E, se for usar ibatis ainda tem opcoes de querys dinamicas (nao sei se o BoxSQL faz isso)de qlqer maneira, eu testaria… parece produtivo.
Exatamente isso que os outros frameworks citados como alternativos não são “produtivos”. Infelizmente onde reina pessoas acostumadas com a época do COBOL, VB e etc, o tempo para se produzir em hibernate e ibatis (sem contar a maneira em que se organiza as coisas) é um absurdo de lerdo e complexo. Em lugar assim não adianta tentar converser as pessoas. É o mesmo que pedir para trocar de time de futebol. Dai é melhor usar uma alternativa assim para persistencia onde os caras podem brincar com a query sem depender totalmente do java e trabalhar sossegado com uma arquitetura robusta e atual no front end. Melhor isso do que perder o projeto por teimosia.
já q ressuscitaram…
há versão nova ou não? esta demorando…
como é?
já q ressuscitaram…há versão nova ou não? esta demorando…
como é? :P
http://code.google.com/p/krank/
Esse framwork não pe parece ser um framework desse tipo. Ele trabalha com JPA e anotações.
Vc ja usou ele? Com procedures inclusive?
já q ressuscitaram…há versão nova ou não? esta demorando…
como é? :P
Pelo que vi o ultimo post no forum do desenvolvedor foi em janeiro de 2008. Mas não tinha novidades.
Isto não quer dizer nada…
Se for ver o site do CajuScript esta “abandonado” a alguns meses, mas temos uma versão fresquinha com data de saida para 1 de Julho…
O site ficar parado é normal, agora quero saber é se os responsáveis estão mantendo o projeto e com tantas melhorias para serem feitas, se já tem alguma, por que já começa a ser muito tempo… ja deu tempo para sair a versao 1.6 sei lá… só se estiverem preparando um versão 2.0 bombástica
Queria usar isto num projeto propicio para isto, mas também precisava de algumas melhorias que já foram citadas…
O caminho ideal seria postar no forum do projeto.
Talvez assim os desenvolvedores se animem de ver que tem gente interessada no projeto.
Mas tentei postar la e não consegui. O java.net é meio confuso.
Mas o ideal seria postar la ou entrar em contato direto com os desenvolvedores.
Como são somente dois pode demorar para ter uma resposta.
mas então eles estão aqui nesta thread, penso eu… devem receber e-mail de notificação…
e o site do projeto… o java.net… afff é muito confuso realmente, comparando com o googlecode, não tem nada a ver, conseguiram complicar coisas tão simples…
para achar o arquivo para download então… mais escondido impossível!
Afinal… o BoxSQL parece q tem uma nova casa:http://code.google.com/p/boxsql/
Vamos ver :P
Opa valew a garimpada.
acho muito legal a iniciativa do boxSQL.
http://code.google.com/p/krank/Esse framwork não pe parece ser um framework desse tipo. Ele trabalha com JPA e anotações.
Vc ja usou ele? Com procedures inclusive?
mvargens.
sim trabalha.
para trabalhar com JPA, use somente crank-core e crank-crud, para persistencia.
agora se tu quiseres utilizar os outros, que no caso eu não utlizo, sem problemas :D.
OBS1: o JPA2.0 será bem semelhante.
OBS2: vc precisa de Spring.
Exemplo simples:
public static List<Pessoa> readPessoaAndjunction(Pessoa pessoa, Junction junction) {
GenericDao<Pessoa, Long> genericDaoPessoa = (GenericDao) context.getBean(“genericDaoPessoa”);
Example e = Example.createExample(pessoa);
e.setJunction(junction);
List<Pessoa> pessoas = genericDaoPessoa.find(e);
return pessoas;
}
public static List<Pessoa> findPorCodPessoa(Long codPessoa){
GenericDao<Pessoa, Long> genericDao = (GenericDao) context.getBean(“genericDaoPessoa”);
Comparison c = new Comparison();
c.setName(“codPessoa”);
c.setOperator(Operator.EQ);
c.setValue(codPessoa);
return genericDao.find©;
}
vc pode fazer consultas com join, group, orderby e por ai vai, sem problema algum, e sem SQL.
T+
Fala aí moçada…
Putz… eu vi o post do mvargens mas não deu pra responder no dia porque eu tava numa correria pra finaliar o material do Worshop sobre DDD. Que por sinal foi muito bom e divertido. Quem não ofi perdeu! Mas terá outro, então aproveitando a deixa vou fazer o merchan… =)
Entra no site da fratech pra ver a segunda turma. http://www.fratech.net e aproveitem pra se inscrever antes que acabem as vagas novamente. =)
Bom, quanto ao BoxSQL fico muito feliz em dizer que a versão 2.0 está no forno e trazendo muitas melhorias. Não decidimos ainda se vamos seguir o caminho da JPA, mas concordo quando dizem que se for para usar JPA use o Hibernate, OpenJPA ou o Toplink que já estão no mercado faz tempo. Aliás, acho que o JPA ainda está muito imaturo perante o próprio Hibernate que já tem soluções para problemas que o JPA ainda não resolveu.
O intuito do BoxSQL como já foi dito aqui várias vezes é oferecer uma alternativa e acho que atende muito bem a vontade de deixar os cara que sacam muito de SQL escrever SQL. Ou alguém aqui discorda do poder que o SQL possui?
Bom, o site anda bem desatualizado, porém como já disseram é culpa do java.net. É muito confuso e como não víamos ninguém postando, também não postávamos. Mas a verdade é que não sei o que acontece. Mas se você olharem a lista de issues, já há alguns resolvidos.
Decidimos mudar o boxSQL pra o google code, mas ainda estamos experimentando. Quero definir branches de desenvolvimento porque a versão 2.0 talvez mude a notação dos parâmetros e queremos manter a compatibilidade. Também implementei o uso do Maven2.0, que vai tornar mais fácil o uso do framework. Acerdito que no google code ninguém terá dificuldade em postar comentários ou mesmo achar o arquivo para download.
Quanto às features, estamos trabalhando basicamente na lista de issues que ainda está no java.net, mas temos alguns pedidos por email que serão considerados. Se alguém mais quiser algo específico, por favor podem me enviar um email ou postar aqui mesmo, assim a galera ajuda a debater.
De qualquer forma fiquei muito feliz com a quantidade de posts e com o apoio de vocês. É um incentivo a mais pra continuar.
Grande abraço,
Valew pelo feedback feliperod , espero que o BoxSql cresça muito e acho que ele tem espaço para ser usado exatamente onde não se pode usar JPA. Continuem com o projeto. :thumbup:
Lembrei que tenho que responder a pergunta sobre Procedures e functions. O BoxSQL tem suporte à procedures sim. Não lembro o nome do método de cabeça, mas é bem fácil de achar.
Outra coisa, estamos trabalhando na geração de queries simples automaticamente, o que acho que vai diminuir um pouco os arquivos SQL.
Também estamos introduzindo tratamento de alguns tipo primitivos que não eram tratados ainda e evoluindo a opções a serem configuradas no arquivo boxsql.properties, como por exemplo o caracter que deve substituir os valores boolean podem ser especificados no properties. Tratamento de Date e algumas outras coisas.
Preciso verificar melhor a parte de transaction. Alguém teve algum problema com isso no Box ou tá funcionando certinho?
Vou pensar na sugestão de permitir várias queries em um mesmo arquivo. Acho que ajudaria na organização dos templates. Mas lembrem-se que tudo isso traz complexidade no uso. Quanto mais features implementamos, mais conhecimento é necessário para usar. Mas acho que é um Trade-Off. =)
Grande Abraço,
opa! gostei dessa novidade realmente é algo muito útil.
No meu caso, uso muito algo parecido no Delphi com os componentes de acesso MDO/IBX
onde é fornecido um SQL padrão tipo: “select * from tabelatal where …” e o componente gera automaticamente os outros SQL´s para insert, update, delete
imagine uma tabela com uns 30 campos? criar na unha tudo?
abraços
Pra que usar um framework que ninguém usa ? e se você precisa de alguma documentação ou ajuda ?
ninguém sabe de nada…
por favor isso é coisa de desenvolvedor que quer se aparecer… dizer que faz projetos e tal, quer se aparecer ? trabalhe.
Tanto que esse boxsql está sempre uns 10 passos atrás dos principais frameworks ORM de verdade do mercado, quando
vc disse que vai ter annotations mesmo ???
Isso ai só serve pra fazer gambiarra de fundo de quintal, ou vc acha que alguém vai usar EJB com boxsql ?
fui.
Lojas Marisa, Websphere + RMI + EJB + Boxsql… (250 lojas, 26 estados, funcionando)
Tenho minhas criticas sobre o box, mas isso não fez com que em um determinado projeto ele se encaixasse bem.
Cara, vc é um imbecil, faz muito tempo que não entro no Guj, por causa da correria,
mas há alguns anos atrás o pessoal do DOPS do GUJ já tinha passado fogo em você.
Não é uma questão de não poder ter opinião, é uma questão de ter educação (no seu caso não ter). E nem adianta responder, que não vou perder meu tempo pra discutir com um cara tão medíocre como você.
Procura um trabalho lá no Alaska e vai viver isolado do mundo, pq vc não sabe viver em grupo. :evil: Muleke…
Felipe,
Estava testando o boxsql e percebi que quando o valor retornado de uma consulta é null o boxsql me retorna zero. Vocês já viram este problema?? Isto ja foi arrumado??
Bom black fire eu também sei que vc baixou o código e alterou algumas coisas para que o framework ficasse mais adaptado ao seu caso. Essa é a essência do open source. Algumas vezes alguém me pede uma alteração ou reclama de algo, mas na verdade basta baixar o código e modificá-lo. No caso do BoxSQL o código é estupidamente simples de ser entendido e corrigido.
Não me lembro desse problema. Talvez ele retorne 0 se o atributo for numérico. Mas se for o caso podemos deixar um default para isso e colocar um parâmetro de configuração para quem quiser mudar o default.
Bom, mas deixando de lado, vou terminar a versão 2.0 do BoxSQL ainda este ano. Demorei porque estou implementando tudo de novo em Groovy (não há um bom motivo a não ser opção pessoal. Enjoei de Java.). O bom é que ele será compilado para BytoCode e todo mundo poderá utilizar na boa o framework. Também vou publicar o projeto com mais conteúdo como tutoriais e documentação, mas só para o ano que vem, pois to muito corrido com a InfoQ.
Oi Felipe, pelo que notei vc é um dos criadores do boxsql, por isso resolvi tentar te contactar por aqui.
Estou trabalhando em um projeto no qual optei por adotar o boxsql devido a sua flexibilidade e etc. Estou neste momento enfrentando um problema que talvez seja de fácil solução para vc.
Logo no momento do login do sistema, ao tentar acessar o BD mysql pela primeira vez, recebo um erro java.lang.IllegalArgumentException: URI is not hierarchical.
Quando rodo o sistema no Eclipse tudo funciona bem, mas quando gero um jar no ANT e rodo o sistema direto no browser, apesar de carregar a tela inicial, no primeiro acesso ao BD para validação de login e senha, recebo este erro.
Não achei nada esclarecedor sobre isso na internet.
Meu arquivo boxsql.properties está configurado assim:
box.connectionType=jdbc
box.pathBase=br/com/atchik/resources
log.path=/c://java/workspace_atchik/
log.active=true
jdbc.url=jdbc:mysql://localhost/quebrabases
jdbc.driver=com.mysql.jdbc.Driver
jdbc.user=root
jdbc.password=2108
O erro ocorre no metodo abaixo quando chamo box.getList :
public static Boolean Login_Validation (String username, String password){
BoxSQL box = new BoxSQL();
try{
box.setParameter("username",username );
box.setParameter("password",password );
List<Login> logged_user = box.getList("check_login.sql", Login.class);
if (logged_user.get(0).getUsername()==null || logged_user.get(0).getUsername().length()==0){
return false;
}
}
catch (IndexOutOfBoundsException iobe){
System.out.println ("IndexOutOfBoundsException on LoginDAO.Login_Validation");
return false;
}
catch (Exception jle){
System.out.println ("Exception on LoginDAO.Login_Validation ==> " + jle.getMessage());
System.out.println (" Cause ==> " + jle.getCause());
return false;
}
finally{
System.out.println ("Will call box.release");
box.release();
}
return true;
}
Qualquer ajuda será muito bem vinda.
Obrigado desde já.
Abs.
Gilberto
Só corrigindo, pois a linha log.path correta é: log.path=c://java/workspace_atchik/. Mas o problema certamente não é esse.
Outro ponto que vale a pena citar é que este projeto utiliza STRUTS2.
Espero que vc possa me dar uma luz nesse problema.
Abs.
Olá Gilberto,
Com base no que você me passou, o problema parece na URL de conexão. Não tá faltando a porta em que o banco roda não?
Porém, pela Exception pode ser erro na hora de ler os templates. Talvez com a stack_trace completa seja mais fácil de identificar.
Isso pode ser erro até mesmo do Struts2. Pelo fato de funcionar de dentro do eclipse e depois não funcionar no Browser, pode ser falta de alguma dependência também. Mas aí acho que Exception seria outra.
E pra terminar, acho que vale a tentativa também, você já experimentou colocar uma barra na frente do ‘br’ na linha ‘box.pathBase=br/com/atchik/resources’ ?
Oi Felipe
Tentei colocando o “/” antes do BR, mas não adiantou.
Abaixo envio todo o stack para que, quem sabe, vc possa identificar se o erro é no acesso ao BD ou na tentativa de ler os templates (.sql).
Agradeço desde já pela ajuda!
May 15, 2009 11:06:01 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
May 15, 2009 11:06:01 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
May 15, 2009 11:06:24 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet default threw exception
java.lang.IllegalArgumentException: URI is not hierarchical
at java.io.File.(File.java:363)
at org.boxsql.ioEngine.IOEngine.readResourceFile(IOEngine.java:23)
at org.boxsql.templateEngine.TemplateEngine.getSQLQuery(TemplateEngine.java:36)
at org.boxsql.BoxSQL.getTemplate(BoxSQL.java:254)
at org.boxsql.BoxSQL.getList(BoxSQL.java:298)
at br.com.atchik.dao.LoginDAO.Login_Validation(LoginDAO.java:25)
at br.com.atchik.actions.LoginAction.checkLogin(LoginAction.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:404)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:267)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:229)
at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:221)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:150)
at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:48)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:123)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:186)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:105)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:83)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:207)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:74)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:127)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at org.apache.struts2.interceptor.ProfilingActivationInterceptor.intercept(ProfilingActivationInterceptor.java:107)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:206)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:115)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:143)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:121)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:170)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:123)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:176)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224)
at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223)
at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221)
at org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:50)
at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:504)
at org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:419)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Oi Felipe
Queria adicionar uma questão:
Se o problema for no acesso aos templates, para eliminar a linha box.pathBase=br/com/atchik/resources ( que no caso, por alguma razão não estaria encontrando os respectivos arquivos). Onde devo colocar os templates (.sql) para que os metodos das classes do pacote br.com.atchik.dao possam encontrá-los por default ?
PS: Só para informação tentei colocar a porta usada pelo BD, mas não adiantou também.
Abs.
Não há uma convenção para isso. Ainda não. =(
Estou trabalhando numa nova versão do BoxSQL, mas as coisas estão corridas demais. Porém posso dizer que será interessante essa nova versão. E pelas funcionalidade e escopo irá receber outro nome.
Votando ao problema:
Sim o erro é na leitura dos templates. Você mencionou que funciona no eclipse?
Se funciona no eclipse e não funciona fora do eclipse o erro só pode estar no ambiente. Falta algo no classpath (como esse pacote em que estão os templates por exemplo).
Voc6e consegue verificar se no servidor de aplicações este pacote existe? Talvez você deva verificar se o .war foi descompactado. Não se isso influenciaria (eu acho que sim).
Pode também passar a sua estrutura de diretórios?
Ah… e se você estiver no windows, mude o path do log para c:\java\workspace_atchik\ e não c://java/workspace_atchik/
Oi Felipe
Para gerar o jar desta aplicacao uso o ANT. O built.xml que construí segue abaixo.
<!-- Project settings -->
<property name="project.title" value="QuebraBases"/>
<property name="project.jar.file" value="QuebraBases.jar"/>
<path id="class.path">
<fileset dir="lib">
<include name="**/*.jar"/>
</fileset>
</path>
<!-- Classpath for Project -->
<path id="compile.classpath">
<pathelement path ="lib/commons-beanutils.jar"/>
<pathelement path ="lib/commons-digester.jar"/>
<pathelement path ="lib/struts.jar"/>
<pathelement path ="lib/BoxSQL-1.5.jar"/>
<pathelement path ="lib/dwr.jar"/>
<pathelement path ="lib/dwr-1.1-beta-3.jar"/>
<pathelement path ="lib/myfaces-jsf-api-1.0.9.jar"/>
<pathelement path ="lib/mysql-connector-java-5.0.5-bin.jar"/>
<pathelement path ="lib/servlet-api-2.4.jar"/>
<pathelement path ="lib/struts2-jsf-plugin-2.0.11.2.jar"/>
<pathelement path ="lib/commons-fileupload-1.1.1.jar"/>
<pathelement path ="lib/commons-io-1.0.jar"/>
<pathelement path ="lib/commons-dbutils-1.1.jar"/>
<pathelement path ="lib/commons-logging-1.0.4.jar"/>
<pathelement path ="lib/freemarker-2.3.8.jar"/>
<pathelement path ="lib/ognl-2.6.11.jar"/>
<pathelement path ="lib/struts2-core-2.0.11.2.jar"/>
<pathelement path ="lib/xwork-2.0.5.jar"/>
<pathelement path ="lib/catalina-ant.jar"/>
<pathelement path ="classes"/>
<pathelement path ="${classpath}"/>
</path>
<!-- Check timestamp on files -->
<target name="prepare">
<tstamp/>
<copy file="src/struts.xml" todir="src/classes"/>
</target>
<!-- Copy any resource or configuration files -->
<target name="resources">
<copy todir="src/classes" includeEmptyDirs="no">
<fileset dir="src/">
<patternset>
<include name="**/*.conf"/>
<include name="**/*.properties"/>
<include name="**/*.xml"/>
</patternset>
</fileset>
</copy>
<copy todir="src/classes/br/com/atchik/resources/" includeEmptyDirs="no">
<fileset dir="src/br/com/atchik/resources/">
<patternset>
<include name="**/*.sql"/>
</patternset>
</fileset>
</copy>
<copy todir="src/classes/" includeEmptyDirs="no">
<fileset dir="src/br/com/atchik/resources/">
<patternset>
<include name="**/*.sql"/>
</patternset>
</fileset>
</copy>
</target>
<!-- Normal build of application -->
<target name="compile" depends="prepare,resources">
<javac srcdir="src" destdir="src/classes" debug="true" debuglevel="lines,vars,source">
<classpath refid="class.path"/>
</javac>
<jar
jarfile="lib/${project.jar.file}"
basedir="src/classes"/>
</target>
<!-- Remove classes directory for clean build -->
<target name="clean"
description="Prepare for clean build">
<delete dir="classes"/>
<mkdir dir="classes"/>
</target>
<!-- Build Javadoc documentation -->
<target name="javadoc" description="Generate JavaDoc API docs">
<delete dir="./doc/api"/>
<mkdir dir="./doc/api"/>
<javadoc sourcepath="./src/java"
destdir="./doc/api"
classpath="${servlet.jar}:${jdbc20ext.jar}"
packagenames="*"
author="true"
private="true"
version="true"
windowtitle="${project.title} API Documentation"
doctitle="<h1>${project.title} Documentation (Version ${project.version})</h1>"
bottom="Copyright © 2002">
<classpath refid="compile.classpath"/>
</javadoc>
</target>
<!-- Build entire project -->
<target name="project" depends="clean,prepare,compile"/>
<!-- Create binary distribution -->
<target name="dist" description="Create binary distribution">
<mkdir dir="${distpath.project}"/>
<jar
jarfile="${distpath.project}/${project.distname}.jar"
basedir="./classes"/>
<copy
file="${distpath.project}/${project.distname}.jar"
todir="${distpath.project}"/>
<war
basedir="../"
warfile="${distpath.project}/${project.distname}.war"
webxml="web.xml">
<exclude name="${distpath.project}/${project.distname}.war"/>
</war>
</target>
<!-- Build project and create distribution-->
<target name="all" depends="project"/>
Tentei, como vc pode ver neste XML acima, copiar os templates para diferentes pastas para ver se a aplicacao os encontrava. Mas não funcionou.
Estou infelizmente usando o windows Vista, mas até agora não havia apresentado nenhum problema, e acho que este especificamente não tem a ver com esse fato.
Inclui no meu classpath a pasta aonde são colocados os templates após rodar o ant, veja abaixo:
.;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip; c:\Java\ANT_HOME; c:\Java\xerces-2_9_1;c:\Java\Tomcat 6.0\webapps\QuebraBases\WEB-INF\src\br\com\atchik\resources;
Porém a aplicação continua não encontrando os templates…alguma luz no fim desse tunel?
Gilberto,
Como eu falei antes, o problema é que os recursos estão em um arquivo compactado (.jar ou .war por exemplo). Esse tipo de arquivo possue um classpath interno apenas. Isso quer dizer que ele só enxerga as classes e pacotes que estão dentro dele, a não ser que seja especificado outros jars para que ele busque.
Esse é o problema. Esse também é o motivo pelo qual o projeto funciona no Eclipse e nõa funciona fora dele.
Uma pequena busca no google sobre essa exception trouxe a solução.
Você terá que adaptar o seu deploy ou a criação do Jar.
Espero ter ajudado…
Oi Felipe,
Muito obrigado. Sem dúvida o caso que vc descobriu é igual ao meu. Porém existe uma pequena diferença que talvez vc tenha alguma dica de como solucionar.
No meu caso, seguindo o seu framework, eu uso o getList para recuperar o template, e este vai buscá-lo de acordo com a linha box.pathBase=br/com/atchik/resources, ou seja, eu não busco por este arquivo .sql diretamente pois pelo que entendi é preciso usar a propriedade box.pathBase.
Como meu procedimento ANT gera um arquivo .jar com o projeto, segundo o artigo em questão, eu deveria acessar os templates usando ClassLoader.getSystemResourceAsStream (DEFAULT_PATH + FILE). A questão é que não sei se é possível fazer isso utilizando o boxsql.
Enfim, a questão é como usar ou substituir o box.getList para que ele pegue o template via ClassLoader.getSystemResourceAsStream.
Novamente agradeço muito a ajuda.
Abs
Neste caso, se não der mesmo pra não colocar dentro do Jar, a solução é baixar o fonte do BoxSQL e modificar a classe org.boxsql.IOEngine na linha 23. Assim você pode colocar a alteração necessária. Depois gera um jar do BoxSQL e pronto.
O BoxSQL é um framework de 7 classes em sua versão 1.5.1. Muito simples de customizar. =)
OI Felipe
Na verdade os templates estão todos dentro do jar, porém a aplicação não consegue exergá-los.
Não existe um caminho fisico ou logico que colocando no boxsql.properties, a aplicação conseguiria encontrar os templates?
Afinal eles estão dentro do jar, e se a aplicação consegue encontrar os arquivos .properties, não há uma forma de fazê-la encontrar os .sql (pois posso colocá-los em qualquer pasta do projeto)?
Queria realmente evitar mexer nos fontes do boxsql…
Gilberto,
Você tem algumas opções aqui:
Porque esses arquivos estão dentro de um jar?
Você pode retirá-los do jar como acontece com aplicações web normal. Pelo menos os .sql
A linha de código da classe IOEngine.java que lê o arquivo é essa:
onde “file” é o pathBase + nomeDoTemplate passado para o getList()
Você pode mudar essa linha de código, o que seria mais rápido do que responder aqui no fórum.
Gerar um Manifest melhor para seu jar
No Manifest você consegue indicar quais outros jars fazem parte do classpath de seu jar. Isso quer dizer que no .war de sua aplicação você precisa ter um Manifest decente, se esse war não for descompactado.
Ir até o issue tracker do BoxSQL e cadastrar um issue para que verifiquemos isso.
Pode demorar bastante.
Particularmente, eu acho a 1 opção mais sensata. A segunda opção não é tão ruim assim também.
Esse também é um problema da forma que voc6e escolheu para fazer o deploy de sua aplicação.
Grande Abraço,
Amigo feliperod.
Estou para iniciar um novo projeto e gostaria de utilizar o BoxSQL, porém gostaria de saber se você já tem uma previsão do lançamento do BoxSQL 2.0 (ou o novo nome) ainda este ano de 2010 ?
Abraços e parabéns pelo projeto.
Cara… estou trabalhando nele, mas numa velocidade menor do que eu gostaria. Se alguém estiver a fim de me ajudar, numa atividade open source, eu ficaria muito feliz e o projeto!
Acredito que eu possa ajudar…
Quais as necessidades do Projeto ?
Olá amigos todo bem?
Vê se vocês podem me ajudar.
Estou com a seguinte dúvida sobre o BoxSQL, que em sua atual versão “2.21” não aceita alguns dos códigos que na versão 1.5 aceitava.
Minha dúvida é? Como faço para instanciar a Classe BoxSQL na versão atual, sendo que não há um construtor visível nesta classe?
O erro acontece quando tento instanciar a classe. Veja.
BoxSQL box = new BoxSQL(); o seguinte erro é mostrado ( The constructor BoxSQL() is not visible )
e também não à mais o método release, que é responsavel por fechar a conexão.
Bom, tentei da seguinte forma:
public List getLast6MonthSales(){
BoxSQL box = BoxSQL.getInstance();
List sales = box.getList(“list6MonthSales.sql”, Sales.class);
BoxSQL.closeConnection();
return sales;
}
Até aí tudo bem más quando executo o teste no JUnit a seguinte mensagem aparece:
BoxSQL - Mensagem de erro: Problemas ao ler ou encontrar arquivo.
BoxSQL - Mensagem de erro: Erro DB: null
O que pode está acontecendo? Os arquivos estão corretos.
Outra pergunta.
Como o arquivo boxsql.properties é iniciado?
Agradeço.
Caro amigo rubensmm.
Eu já tive a oportunidade de utilizar o BoxSQL e gostei muito, pena que seu código não recebe a devida atenção e por este motivo esta praticamente descontinuado.
Procurando na internet alguma solução viável, eu acabei encontrando o QueryDSL-SQL, o qual possui semântica parecida com o BoxSQL, porém mais poderoso e com seu código sendo mantido até a presente data.
Dê uma olhada nos exemplos e surpreenda-se com as facilidades de programação…
Fala Felipe…Aqui é o Igson…kkkkk
EI nao eskece de colocar no boxsql a função pra inserção de arquivo e valores do tipo Date !!!
Espero que essas melhorar sejam pra evoluir o box . Gostei muito de utilizar ele aqui .
Paz e Bem