My favorites | Sign in
Project Logo
                
Details: Show all Hide all

Earlier this year

  • Jul 16, 2009
    TenMinuteQuickStart (A 10-minute guide to using jLynx as a persistence framework) Wiki page edited by topmind17
  • Apr 28, 2009
    issue 10 (Allow lifecycle methods) reported by jacek99   -   There should be a way to intercept every time an entity is saved, updated or deleted in order to implement standard audit trail logic in an application.
    There should be a way to intercept every time an entity is saved, updated or deleted in order to implement standard audit trail logic in an application.
  • Apr 28, 2009
    issue 5 (Need Spring integration) commented on by jacek99   -   It should also integrate with a Spring transaction manager, to make it fully usable.
    It should also integrate with a Spring transaction manager, to make it fully usable.
  • Apr 28, 2009
    issue 9 (Allow dynamic mapping of table and column names) commented on by jacek99   -   It should also support setting the standard policy for PK generation, e.g. on most Oracle / PostgreSQL DBs it would be a sequence that follows a particular naming scheme, on MySQL/SQL Server it could just be some hard-coded constant to identity it as autoincrement. One of the shortcomings of JPA is that the DB-specific PK generation annotations are baked right into the POJO entity, so if you have an app that needs to run on multiple DBMSs, it becomes problematic.
    It should also support setting the standard policy for PK generation, e.g. on most Oracle / PostgreSQL DBs it would be a sequence that follows a particular naming scheme, on MySQL/SQL Server it could just be some hard-coded constant to identity it as autoincrement. One of the shortcomings of JPA is that the DB-specific PK generation annotations are baked right into the POJO entity, so if you have an app that needs to run on multiple DBMSs, it becomes problematic.
  • Apr 27, 2009
    issue 9 (Allow dynamic mapping of table and column names) commented on by jacek99   -   yes, but that means I would have to add annotations every where, instead of doing a simple string replace, e.g. public String getTableName(Class<?> clazz) { return "T_" + class.getSimpleName().toUpperCase(); } public String getColumnName(Class<?> clazz, String propertyName) { return "F_" + propertyName.toUpperCase(); } Two simple methods, no need to define annotations all over the place. Most DBs (even legacy ones) follow some sort of naming convention, so this would make it very easy to just map that in code to a java naming convention.
    yes, but that means I would have to add annotations every where, instead of doing a simple string replace, e.g. public String getTableName(Class<?> clazz) { return "T_" + class.getSimpleName().toUpperCase(); } public String getColumnName(Class<?> clazz, String propertyName) { return "F_" + propertyName.toUpperCase(); } Two simple methods, no need to define annotations all over the place. Most DBs (even legacy ones) follow some sort of naming convention, so this would make it very easy to just map that in code to a java naming convention.
  • Apr 27, 2009
    issue 9 (Allow dynamic mapping of table and column names) Status changed by topmind17   -   Wouldn't it be better just to employ annotations just like JPA? Of course this would break JDK 1.3 compatibility. Indeed, we just could re-use JPA annotations in case you wanted to use JPA to persist the entity. I think that would still fit in with the mission to keep it simple. Thoughts... ?
    Status: Accepted
    Wouldn't it be better just to employ annotations just like JPA? Of course this would break JDK 1.3 compatibility. Indeed, we just could re-use JPA annotations in case you wanted to use JPA to persist the entity. I think that would still fit in with the mission to keep it simple. Thoughts... ?
    Status: Accepted
  • Apr 27, 2009
    issue 9 (Allow dynamic mapping of table and column names) reported by jacek99   -   The pain point is manually mapping a legacy DB to a java POJO (so we're without the ability to create tables/column that nicely map to Java classes and properties, but have existing ugly legacy names like T_TABLE or T_TABLE.F_TABLE_PK, etc). It would be great if the jLynx engine would allow to define some sort of dynamic callback when resolving an entity and its properties, e.g interface INameCallback { public String getTableName(Class<?> clazz); public String getColumnName(Class<?> clazz, String propertyName); } I could then automatically figure out that a class called "Person" maps to "T_PERSON", etc, and a Person.firstName property maps to "T_PERSON.F_FIRST_NAME" in a generic fashion without having to manually define literally hundreds of table/column mappings in the jLynx.yaml
    The pain point is manually mapping a legacy DB to a java POJO (so we're without the ability to create tables/column that nicely map to Java classes and properties, but have existing ugly legacy names like T_TABLE or T_TABLE.F_TABLE_PK, etc). It would be great if the jLynx engine would allow to define some sort of dynamic callback when resolving an entity and its properties, e.g interface INameCallback { public String getTableName(Class<?> clazz); public String getColumnName(Class<?> clazz, String propertyName); } I could then automatically figure out that a class called "Person" maps to "T_PERSON", etc, and a Person.firstName property maps to "T_PERSON.F_FIRST_NAME" in a generic fashion without having to manually define literally hundreds of table/column mappings in the jLynx.yaml
  • Apr 27, 2009
    issue 8 (DAOImpl should be reusable across different entities) commented on by jacek99   -   yes, I am trying to see if it could fit into a new Spring-based app. I think you should just have a single DAO instance and a persist() method (or save(), etc.) that would accept any jLynx-aware entity.
    yes, I am trying to see if it could fit into a new Spring-based app. I think you should just have a single DAO instance and a persist() method (or save(), etc.) that would accept any jLynx-aware entity.
  • Apr 27, 2009
    issue 4 (Primary Key Problem) Status changed by topmind17   -  
    Status: WontFix
    Status: WontFix
  • Apr 27, 2009
    issue 7 (Add support for Oracle sequence generators) Status changed by topmind17   -  
    Status: Accepted
    Status: Accepted
  • Apr 27, 2009
    issue 8 (DAOImpl should be reusable across different entities) Status changed by topmind17   -   Yes, this idea goes along with the Spring integration request, right? I guess ideally you would inject beans into the DAO instance, right? or re-use instances? or both?
    Status: Accepted
    Yes, this idea goes along with the Spring integration request, right? I guess ideally you would inject beans into the DAO instance, right? or re-use instances? or both?
    Status: Accepted
  • Apr 27, 2009
    issue 6 (NoSuchMethodError exception in SLF4J) Status changed by topmind17   -  
    Status: Invalid
    Status: Invalid
  • Apr 27, 2009
    issue 8 (DAOImpl should be reusable across different entities) reported by jacek99   -   if I understand correctly, you have to create a new instance of DAOImpl for every entity type you want to persist. This means that if I am running in a Spring context, I would need a separate DAO bean for every entity. It would be great if it could work like a JPA entity manager instead where one instance of DAOImpl (or some new class with similar functionality) could be used to persist any entity type one needs.
    if I understand correctly, you have to create a new instance of DAOImpl for every entity type you want to persist. This means that if I am running in a Spring context, I would need a separate DAO bean for every entity. It would be great if it could work like a JPA entity manager instead where one instance of DAOImpl (or some new class with similar functionality) could be used to persist any entity type one needs.
  • Apr 27, 2009
    issue 6 (NoSuchMethodError exception in SLF4J) commented on by jacek99   -   Sorry, my mistake...I had the SLF4J jars copied from a dependency from another library, instead of the latest version. Sorry once again.
    Sorry, my mistake...I had the SLF4J jars copied from a dependency from another library, instead of the latest version. Sorry once again.
  • Apr 27, 2009
    issue 5 (Need Spring integration) Status changed by topmind17   -   Great idea, have been thinking of doing so.
    Status: Accepted
    Great idea, have been thinking of doing so.
    Status: Accepted
  • Apr 27, 2009
    issue 6 (NoSuchMethodError exception in SLF4J) commented on by topmind17   -   Upgrade to the latest version of SLF4J. trace() was added in v1.4. The latest version of SLF4J is 1.5.6, not 1.3.1.
    Upgrade to the latest version of SLF4J. trace() was added in v1.4. The latest version of SLF4J is 1.5.6, not 1.3.1.
  • Apr 27, 2009
    issue 7 (Add support for Oracle sequence generators) reported by jacek99   -   There seems to be no way to specify an Oracle sequence for generating primary key values when inserting a new entity to the DB.
    There seems to be no way to specify an Oracle sequence for generating primary key values when inserting a new entity to the DB.
  • Apr 27, 2009
    issue 6 (NoSuchMethodError exception in SLF4J) reported by jacek99   -   What steps will reproduce the problem? 1. Latest version of SLF4J 2. Latest version of JLynx 3. Exception at initialization: java.lang.NoSuchMethodError: org.slf4j.Logger.trace(Ljava/lang/String;)V at net.sf.jlynx.YAMLConfigParser.filterComments(Unknown Source) at net.sf.jlynx.YAMLConfigParser.init(Unknown Source) at net.sf.jlynx.ConfigParser.<init>(Unknown Source) at net.sf.jlynx.DAOImpl.<clinit>(Unknown Source) Looking at the SLF4J org.slf4j.Logger class in the latest version one can see that there is no trace() method in it. Probably debug()? What is the expected output? What do you see instead? No error. Get error instead What version of the product are you using? On what operating system? jLynx: 1.6.3 slf4j: slf4j-api-1.3.1.jar
    What steps will reproduce the problem? 1. Latest version of SLF4J 2. Latest version of JLynx 3. Exception at initialization: java.lang.NoSuchMethodError: org.slf4j.Logger.trace(Ljava/lang/String;)V at net.sf.jlynx.YAMLConfigParser.filterComments(Unknown Source) at net.sf.jlynx.YAMLConfigParser.init(Unknown Source) at net.sf.jlynx.ConfigParser.<init>(Unknown Source) at net.sf.jlynx.DAOImpl.<clinit>(Unknown Source) Looking at the SLF4J org.slf4j.Logger class in the latest version one can see that there is no trace() method in it. Probably debug()? What is the expected output? What do you see instead? No error. Get error instead What version of the product are you using? On what operating system? jLynx: 1.6.3 slf4j: slf4j-api-1.3.1.jar
  • Apr 27, 2009
    issue 5 (Need Spring integration) reported by jacek99   -   Is there way to initialize the default connection using a default Spring datasource, instead of hard-coding it in the YAML file?
    Is there way to initialize the default connection using a default Spring datasource, instead of hard-coding it in the YAML file?

Older

  • Dec 16, 2008
    TenMinuteQuickStart (A 10-minute guide to using jLynx as a persistence framework) Wiki page edited by topmind17
  • Dec 16, 2008
    TenMinuteQuickStart (A 10-minute guide to using jLynx as a persistence framework) Wiki page edited by topmind17
  • Dec 16, 2008
    TenMinuteQuickStart (A 10-minute guide to using jLynx as a persistence framework) Wiki page edited by topmind17
  • Nov 01, 2008
    QuickStart Wiki page deleted by gregr20
  • Nov 01, 2008
    FAQ Wiki page deleted by gregr20
  • Nov 01, 2008
    AjaxPlusjLynx Wiki page deleted by gregr20
  • Nov 01, 2008
    HowToUsejLynxAjaxFilter Wiki page deleted by gregr20
  • Sep 28, 2008
    r503 committed by gregr20
  • Sep 28, 2008
    r502 committed by gregr20
  • Sep 28, 2008
    r501 (v1.6.3) committed by gregr20   -   v1.6.3
    v1.6.3
  • Sep 28, 2008
    r500 (v1.6.3) committed by gregr20   -   v1.6.3
    v1.6.3
  • Sep 28, 2008
    r499 (v1.6.3) committed by gregr20   -   v1.6.3
    v1.6.3
  • Sep 28, 2008
    r498 (v1.6.3) committed by gregr20   -   v1.6.3
    v1.6.3
  • Sep 28, 2008
    r497 committed by gregr20
  • Sep 27, 2008
    HowToUsejLynxAjaxFilter (Basic instructions on using the AJAX web filter of jLynx 1.5...) Wiki page edited by gregr20
  • Sep 19, 2008
    issue 4 (Primary Key Problem) Status changed by gregr20   -   With jlynx you can not map a primary key column. This is a known issue since v1.0. As ugly as it sounds you will have will have to have a field named "vt_id" in the pojo "Topic". Side note: your "TopicManager.get()" should return something, shouldn't it? We can address this in a future version.
    Status: Accepted
    With jlynx you can not map a primary key column. This is a known issue since v1.0. As ugly as it sounds you will have will have to have a field named "vt_id" in the pojo "Topic". Side note: your "TopicManager.get()" should return something, shouldn't it? We can address this in a future version.
    Status: Accepted
  • Sep 19, 2008
    issue 4 (Primary Key Problem) reported by elvea.huang   -   What steps will reproduce the problem? 1. entity class Topic() { private Integer id; private String title; } 2. yaml ... class-entity-mappings: - Topic: v_topic ... column-mappings: - Topic.id: vt_id - Topic.title: vt_title 3. TopicManager class TopicManager() { public void get(Integer id) { Topic topic = new Topic(); topic.setId(id); DAO dao = new DAOImpl(entity); dao.select(); } } What is the expected output? What do you see instead? get the record from database successfully. What version of the product are you using? On what operating system? 1.6.2 Windows XP MySQL 2.1.26 Please provide any additional information below. Exception: java.sql.SQLException: Primary Key value is missing! PK=vt_id at net.sf.jlynx.DAOImpl.createFilterStmt(DAOImpl.java:304) at net.sf.jlynx.DAOImpl.createSelectStmt(DAOImpl.java:459) at net.sf.jlynx.DAOImpl.select(DAOImpl.java:1080) I mapped the column 'vt_id' to the field 'id', when i try to get the record from database, in the DAOImpl line 302, code: partKeyValue = BeanUtils.getValue(keys[i], obj); the value of keys[i] is the column name but not the field name. sorry for my bad english, i hope you can understand.
    What steps will reproduce the problem? 1. entity class Topic() { private Integer id; private String title; } 2. yaml ... class-entity-mappings: - Topic: v_topic ... column-mappings: - Topic.id: vt_id - Topic.title: vt_title 3. TopicManager class TopicManager() { public void get(Integer id) { Topic topic = new Topic(); topic.setId(id); DAO dao = new DAOImpl(entity); dao.select(); } } What is the expected output? What do you see instead? get the record from database successfully. What version of the product are you using? On what operating system? 1.6.2 Windows XP MySQL 2.1.26 Please provide any additional information below. Exception: java.sql.SQLException: Primary Key value is missing! PK=vt_id at net.sf.jlynx.DAOImpl.createFilterStmt(DAOImpl.java:304) at net.sf.jlynx.DAOImpl.createSelectStmt(DAOImpl.java:459) at net.sf.jlynx.DAOImpl.select(DAOImpl.java:1080) I mapped the column 'vt_id' to the field 'id', when i try to get the record from database, in the DAOImpl line 302, code: partKeyValue = BeanUtils.getValue(keys[i], obj); the value of keys[i] is the column name but not the field name. sorry for my bad english, i hope you can understand.
  • Sep 10, 2008
    r495 (v1.6.2) committed by gregr20   -   v1.6.2
    v1.6.2
  • Sep 09, 2008
    r494 (v1.6.2-DEV) committed by gregr20   -   v1.6.2-DEV
    v1.6.2-DEV
  • Sep 01, 2008
    r493 (v1.6.1) committed by gregr20   -   v1.6.1
    v1.6.1
  • Sep 01, 2008
    r492 (v1.6.1) committed by gregr20   -   v1.6.1
    v1.6.1
  • Sep 01, 2008
    r491 (v1.6.1) committed by gregr20   -   v1.6.1
    v1.6.1
  • Sep 01, 2008
    issue 3 (DAOImpl - Syntax error: Encountered "<EOF>" at line 1, colum...) commented on by gregr20   -   Ok, adjusted DAOImpl.initPK() Ran test cases with APACHE DERBY and it all worked. Please try the jar in this download (Version 1.6.1).
    Ok, adjusted DAOImpl.initPK() Ran test cases with APACHE DERBY and it all worked. Please try the jar in this download (Version 1.6.1).
  • Sep 01, 2008
    r490 (v1.6.1) committed by gregr20   -   v1.6.1
    v1.6.1
  • Aug 31, 2008
    r489 (v1.6.1) committed by gregr20   -   v1.6.1
    v1.6.1
  • Aug 28, 2008
    issue 3 (DAOImpl - Syntax error: Encountered "<EOF>" at line 1, colum...) commented on by patrick.kimber   -   Brilliant. Thank you very much. I just noticed, I didn't create the field in the database for the Widget, "widgetEntered" field, but, when I remove the field, I still get the same exception.
    Brilliant. Thank you very much. I just noticed, I didn't create the field in the database for the Widget, "widgetEntered" field, but, when I remove the field, I still get the same exception.
  • Aug 28, 2008
    issue 3 (DAOImpl - Syntax error: Encountered "<EOF>" at line 1, colum...) Status changed by gregr20   -   Issue identified and will be corrected shortly, probably just an issue with Derby
    Status: Started
    Issue identified and will be corrected shortly, probably just an issue with Derby
    Status: Started
  • Aug 28, 2008
    issue 3 (DAOImpl - Syntax error: Encountered "<EOF>" at line 1, colum...) Owner changed by gregr20   -   I'll look into it... Question: Was this working on previous versions? In other words do you think this is a result of this release?
    Owner: gregr20
    I'll look into it... Question: Was this working on previous versions? In other words do you think this is a result of this release?
    Owner: gregr20
  • Aug 28, 2008
    issue 3 (DAOImpl - Syntax error: Encountered "<EOF>" at line 1, colum...) reported by patrick.kimber   -   What steps will reproduce the problem? 1. Decompress the attached maven project. 2. Run the Maven goal: mvn package What version of the product are you using? On what operating system? 1.6.0 OS: Windows Vista Database: Apache Derby 10.2.2.0 Here is the exception: 21:54:35.515 [main] ERROR net.sf.jlynx.DAOImpl - Syntax error: Encountered "<EOF>" at line 1, column 20. java.sql.SQLSyntaxErrorException: Syntax error: Encountered "<EOF>" at line 1, column 20. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source) at net.sf.jlynx.DAOImpl.insert(DAOImpl.java:819) at com.sample.WidgetStore.save(WidgetStore.java:15) at com.sample.WidgetStoreTest.testSave(WidgetStoreTest.java:10) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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 org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) 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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Caused by: java.sql.SQLException: Syntax error: Encountered "<EOF>" at line 1, column 20. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 37 more
    What steps will reproduce the problem? 1. Decompress the attached maven project. 2. Run the Maven goal: mvn package What version of the product are you using? On what operating system? 1.6.0 OS: Windows Vista Database: Apache Derby 10.2.2.0 Here is the exception: 21:54:35.515 [main] ERROR net.sf.jlynx.DAOImpl - Syntax error: Encountered "<EOF>" at line 1, column 20. java.sql.SQLSyntaxErrorException: Syntax error: Encountered "<EOF>" at line 1, column 20. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source) at net.sf.jlynx.DAOImpl.insert(DAOImpl.java:819) at com.sample.WidgetStore.save(WidgetStore.java:15) at com.sample.WidgetStoreTest.testSave(WidgetStoreTest.java:10) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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 org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) 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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Caused by: java.sql.SQLException: Syntax error: Encountered "<EOF>" at line 1, column 20. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 37 more
  • Aug 23, 2008
    r488 (v1.6) committed by gregr20   -   v1.6
    v1.6
  • Aug 21, 2008
    r487 committed by gregr20
 
Hosted by Google Code