Derby
  1. Derby
  2. DERBY-4671

Embedded driver does not work with jbossCache

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.5.3.1, 10.6.1.0
    • Fix Version/s: 10.5.3.1, 10.6.2.1, 10.7.1.1
    • Component/s: SQL
    • Labels:
      None
    • Environment:
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Regression

      Description

      When trying to use jbossCache (version 3.2.5) and an embedded derby driver the following exception is thrown when jbossCache tries to persist information to the database

      48610 [AsyncCacheLoader-0] ERROR org.jboss.cache.loader.JDBCCacheLoader [] - Failed to insert node :Java exception: ': java.lang.NullPointerException'.
      48610 [AsyncCacheLoader-0] WARN org.jboss.cache.loader.AsyncCacheLoader [] - Failed to process async modifications: java.lang.IllegalStateException: Failed to insert node: Java e
      xception: ': java.lang.NullPointerException'.
      48610 [AsyncCacheLoader-0] DEBUG org.jboss.cache.loader.AsyncCacheLoader [] - Exception:
      java.lang.IllegalStateException: Failed to insert node: Java exception: ': java.lang.NullPointerException'.
      at org.jboss.cache.loader.AdjListJDBCCacheLoader.insertNode(AdjListJDBCCacheLoader.java:562)
      at org.jboss.cache.loader.JDBCCacheLoader.addNewSubtree(JDBCCacheLoader.java:367)
      at org.jboss.cache.loader.JDBCCacheLoader.put(JDBCCacheLoader.java:110)
      at org.jboss.cache.loader.AbstractCacheLoader.put(AbstractCacheLoader.java:303)
      at org.jboss.cache.loader.AbstractDelegatingCacheLoader.put(AbstractDelegatingCacheLoader.java:110)
      at org.jboss.cache.loader.AsyncCacheLoader.access$601(AsyncCacheLoader.java:105)
      at org.jboss.cache.loader.AsyncCacheLoader$AsyncProcessor.put(AsyncCacheLoader.java:417)
      at org.jboss.cache.loader.AsyncCacheLoader$AsyncProcessor.run0(AsyncCacheLoader.java:409)
      at org.jboss.cache.loader.AsyncCacheLoader$AsyncProcessor.run(AsyncCacheLoader.java:371)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:619)
      Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
      at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2269)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedStatement.java:148)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(EmbedPreparedStatement20.java:82)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(EmbedPreparedStatement30.java:63)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(EmbedPreparedStatement40.java:40)
      at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Driver40.java:105)
      at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:1607)
      at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:1435)
      at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:213)
      at org.jboss.cache.loader.AdjListJDBCCacheLoader.prepareAndLogStatement(AdjListJDBCCacheLoader.java:90)
      at org.jboss.cache.loader.AdjListJDBCCacheLoader.insertNode(AdjListJDBCCacheLoader.java:545)
      ... 14 more
      Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
      ... 30 more
      Caused by: java.lang.NullPointerException
      at org.apache.derby.impl.sql.compile.CharTypeCompiler.convertible(CharTypeCompiler.java:54)
      at org.apache.derby.impl.sql.compile.CharTypeCompiler.storable(CharTypeCompiler.java:100)
      at org.apache.derby.impl.sql.compile.ResultColumn.checkStorableExpression(ResultColumn.java:887)
      at org.apache.derby.impl.sql.compile.ResultColumn.checkStorableExpression(ResultColumn.java:879)
      at org.apache.derby.impl.sql.compile.ResultColumnList.checkStorableExpressions(ResultColumnList.java:953)
      at org.apache.derby.impl.sql.compile.InsertNode.bindStatement(InsertNode.java:456)
      at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:324)
      at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:90)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:828)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedStatement.java:130)
      ... 23 more

      It works fine using ClientDriver.

      Sample code and configuration files are attached.

      1. CacheIssue.java
        0.9 kB
        Ray O'Hagan
      2. cache-config.xml
        1 kB
        Ray O'Hagan
      3. CacheIssue-eclipseProject.zip
        7.40 MB
        Ray O'Hagan
      4. repro.sql
        0.2 kB
        Knut Anders Hatlen
      5. derby-4671-1a.diff
        5 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Gavin made changes -
          Workflow jira [ 12511434 ] Default workflow, editable Closed status [ 12799129 ]
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
          Rick Hillegas made changes -
          Fix Version/s 10.7.1.1 [ 12315564 ]
          Fix Version/s 10.7.1.0 [ 12314971 ]
          Knut Anders Hatlen made changes -
          Fix Version/s 10.6.2.1 [ 12315343 ]
          Fix Version/s 10.6.2.0 [ 12315342 ]
          Kathey Marsden made changes -
          Fix Version/s 10.6.2.0 [ 12315342 ]
          Fix Version/s 10.6.1.1 [ 12314973 ]
          Knut Anders Hatlen made changes -
          Link This issue is duplicated by DERBY-4780 [ DERBY-4780 ]
          Knut Anders Hatlen made changes -
          Link This issue is duplicated by DERBY-4749 [ DERBY-4749 ]
          Knut Anders Hatlen made changes -
          Link This issue is blocked by DERBY-4672 [ DERBY-4672 ]
          Knut Anders Hatlen made changes -
          Link This issue is duplicated by DERBY-4683 [ DERBY-4683 ]
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-4672 [ DERBY-4672 ]
          Knut Anders Hatlen made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 10.5.3.1 [ 12314182 ]
          Fix Version/s 10.6.1.1 [ 12314973 ]
          Resolution Fixed [ 1 ]
          Hide
          Knut Anders Hatlen added a comment -

          Merged to 10.6 branch (revision 948798) and 10.5 branch (revision 948799). Marking the issue as resolved.

          Show
          Knut Anders Hatlen added a comment - Merged to 10.6 branch (revision 948798) and 10.5 branch (revision 948799). Marking the issue as resolved.
          Knut Anders Hatlen made changes -
          Fix Version/s 10.7.0.0 [ 12314971 ]
          Issue & fix info [Patch Available, Repro attached] [Repro attached]
          Hide
          Knut Anders Hatlen added a comment -

          Thanks for looking at the patch, Bryan.
          Committed revision 948045.

          I plan to backport the fix to 10.6 and 10.5, since the fix that caused the NPE also went into those branches.

          Show
          Knut Anders Hatlen added a comment - Thanks for looking at the patch, Bryan. Committed revision 948045. I plan to backport the fix to 10.6 and 10.5, since the fix that caused the NPE also went into those branches.
          Hide
          Bryan Pendleton added a comment -

          Thanks for the thorough and detailed explanation, it was quite clear and helpful!

          > this statement worked until DERBY-4420 broke it, so the correct fix is to make it work again

          Agreed. I'm comfortable with this approach; your notes helped me understand the distinction.

          I also read your patch and it looks fine to me; there is a good variety of test cases there.

          Show
          Bryan Pendleton added a comment - Thanks for the thorough and detailed explanation, it was quite clear and helpful! > this statement worked until DERBY-4420 broke it, so the correct fix is to make it work again Agreed. I'm comfortable with this approach; your notes helped me understand the distinction. I also read your patch and it looks fine to me; there is a good variety of test cases there.
          Knut Anders Hatlen made changes -
          Issue & fix info [Repro attached] [Patch Available, Repro attached]
          Hide
          Knut Anders Hatlen added a comment -

          All the regression tests ran cleanly with the patch, so I'm setting Patch Available.

          Show
          Knut Anders Hatlen added a comment - All the regression tests ran cleanly with the patch, so I'm setting Patch Available.
          Hide
          Knut Anders Hatlen added a comment -

          > I'm not completely sure I understand why this case is legal and the DERBY-4672 case
          > is an error.
          [...]
          > I suppose what I'm saying is that it seems like this statement should be illegal, too
          > (though it shouldn't throw a NPE, obviously)

          I think we have two different classes of statements here:

          1) INSERT INTO ... SELECT FROM statements that have untyped parameter
          markers in their top-level select lists. Inferring the type of the
          parameter from the context is easy, because it's directly available
          from the target column list. Derby has always accepted statements that
          fall into this category.

          2) INSERT INTO ... SELECT FROM statements that have untyped parameter
          markers in the select list of one of the sub-queries. Inferring the
          type of the parameter from the context is trickier, because the target
          column list is not on the same nesting level in the query. Derby has
          always rejected statements that fall into this category.

          DERBY-4671 belongs to category (1), whereas DERBY-4672 belongs to
          category (2).

          You may be right that category 1 statements are not conforming to the
          standard and should be illegal too. It may even be the case that it
          was unintentional that those statements were accepted by Derby in the
          first place. However, since they have always been accepted, and there
          apparently are applications that depend on this feature, I think it's
          safer to keep the behaviour.

          So I guess my take on this is

          • DERBY-4671 - this statement worked until DERBY-4420 broke it, so the
            correct fix is to make it work again. If there are compelling
            reasons to disallow the statement, and the benefits outweigh the
            disadvantage of breaking existing apps, we could consider
            disallowing it and document the changed behaviour in a release
            note. Currently, I don't see any compelling reasons to disallow it.
          • DERBY-4672 - this statement has never worked, so making it fail
            gracefully is an improvement. Further improvement is possible
            later, though, if someone thinks it should be accepted.

          > What sorts of setXXX calls are allowed to be used with
          >
          > insert into t select ? from t
          >
          > Can I substitute a simple literal value into that statement? Can I substitute a column
          > name into that statement? Can I substitute a sub-query into that statement?

          Only literals.

          The type will be taken from the context, so if T has one INT column,
          as in the example above, the statement will be equivalent to

          insert into t select cast(? as int) from t

          (which is also accepted syntax, by the way). Then you can use
          setInt(), setLong(), setString(), or any other of the setters we
          accept for an INT parameter, to tell which value to insert into T.

          For example, the following code fragment

          ps = c.prepareStatement("insert into t select ? from t");
          ps.setInt(1, 77);
          ps.executeUpdate();

          will double the number of rows in the table, and all the new rows will
          have X=77. This is the same result as you get from this statement:

          s.executeUpdate("insert into t select 77 from t");

          Note also that we allow parameters in the select list of plain SELECT
          statements too, just not untyped ones, since there we don't have
          context to get the type information from:

          ij> prepare ps as 'select ? from t';
          ERROR 42X34: There is a ? parameter in the select list. This is not allowed.
          ij> prepare ps as 'select cast(? as varchar(10)) from t';
          ij> execute ps using 'values ''hello''';
          1
          ----------
          hello
          hello
          hello

          3 rows selected
          ij> prepare ps as 'select x+? from t';
          ij> execute ps using 'values 1';
          1
          -----------
          2
          3
          4

          3 rows selected

          Show
          Knut Anders Hatlen added a comment - > I'm not completely sure I understand why this case is legal and the DERBY-4672 case > is an error. [...] > I suppose what I'm saying is that it seems like this statement should be illegal, too > (though it shouldn't throw a NPE, obviously) I think we have two different classes of statements here: 1) INSERT INTO ... SELECT FROM statements that have untyped parameter markers in their top-level select lists. Inferring the type of the parameter from the context is easy, because it's directly available from the target column list. Derby has always accepted statements that fall into this category. 2) INSERT INTO ... SELECT FROM statements that have untyped parameter markers in the select list of one of the sub-queries. Inferring the type of the parameter from the context is trickier, because the target column list is not on the same nesting level in the query. Derby has always rejected statements that fall into this category. DERBY-4671 belongs to category (1), whereas DERBY-4672 belongs to category (2). You may be right that category 1 statements are not conforming to the standard and should be illegal too. It may even be the case that it was unintentional that those statements were accepted by Derby in the first place. However, since they have always been accepted, and there apparently are applications that depend on this feature, I think it's safer to keep the behaviour. So I guess my take on this is DERBY-4671 - this statement worked until DERBY-4420 broke it, so the correct fix is to make it work again. If there are compelling reasons to disallow the statement, and the benefits outweigh the disadvantage of breaking existing apps, we could consider disallowing it and document the changed behaviour in a release note. Currently, I don't see any compelling reasons to disallow it. DERBY-4672 - this statement has never worked, so making it fail gracefully is an improvement. Further improvement is possible later, though, if someone thinks it should be accepted. > What sorts of setXXX calls are allowed to be used with > > insert into t select ? from t > > Can I substitute a simple literal value into that statement? Can I substitute a column > name into that statement? Can I substitute a sub-query into that statement? Only literals. The type will be taken from the context, so if T has one INT column, as in the example above, the statement will be equivalent to insert into t select cast(? as int) from t (which is also accepted syntax, by the way). Then you can use setInt(), setLong(), setString(), or any other of the setters we accept for an INT parameter, to tell which value to insert into T. For example, the following code fragment ps = c.prepareStatement("insert into t select ? from t"); ps.setInt(1, 77); ps.executeUpdate(); will double the number of rows in the table, and all the new rows will have X=77. This is the same result as you get from this statement: s.executeUpdate("insert into t select 77 from t"); Note also that we allow parameters in the select list of plain SELECT statements too, just not untyped ones, since there we don't have context to get the type information from: ij> prepare ps as 'select ? from t'; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij> prepare ps as 'select cast(? as varchar(10)) from t'; ij> execute ps using 'values ''hello'''; 1 ---------- hello hello hello 3 rows selected ij> prepare ps as 'select x+? from t'; ij> execute ps using 'values 1'; 1 ----------- 2 3 4 3 rows selected
          Hide
          Bryan Pendleton added a comment -

          I'm not completely sure I understand why this case is legal and the DERBY-4672 case
          is an error. What sorts of setXXX calls are allowed to be used with

          insert into t select ? from t

          Can I substitute a simple literal value into that statement? Can I substitute a column
          name into that statement? Can I substitute a sub-query into that statement?

          I suppose what I'm saying is that it seems like this statement should be illegal, too
          (though it shouldn't throw a NPE, obviously)

          Show
          Bryan Pendleton added a comment - I'm not completely sure I understand why this case is legal and the DERBY-4672 case is an error. What sorts of setXXX calls are allowed to be used with insert into t select ? from t Can I substitute a simple literal value into that statement? Can I substitute a column name into that statement? Can I substitute a sub-query into that statement? I suppose what I'm saying is that it seems like this statement should be illegal, too (though it shouldn't throw a NPE, obviously)
          Knut Anders Hatlen made changes -
          Link This issue is blocked by DERBY-4672 [ DERBY-4672 ]
          Knut Anders Hatlen made changes -
          Attachment derby-4671-1a.diff [ 12445168 ]
          Hide
          Knut Anders Hatlen added a comment -

          The attached patch fixes the NullPointerException by reintroducing some code that was removed in the DERBY-4420 fix. Now the type will be initialized for dynamic parameters in the select list of INSERT INTO ... SELECT FROM statements, so that we don't run into a NullPointerException later in the compilation. The patch also adds a regression test case for this bug.

          I'm running the full regression test suite now.

          Show
          Knut Anders Hatlen added a comment - The attached patch fixes the NullPointerException by reintroducing some code that was removed in the DERBY-4420 fix. Now the type will be initialized for dynamic parameters in the select list of INSERT INTO ... SELECT FROM statements, so that we don't run into a NullPointerException later in the compilation. The patch also adds a regression test case for this bug. I'm running the full regression test suite now.
          Knut Anders Hatlen made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Knut Anders Hatlen made changes -
          Link This issue relates to DERBY-4420 [ DERBY-4420 ]
          Knut Anders Hatlen made changes -
          Assignee Knut Anders Hatlen [ knutanders ]
          Affects Version/s 10.5.3.1 [ 12314182 ]
          Hide
          Knut Anders Hatlen added a comment -

          Adding 10.5.3.1 to the affected versions since DERBY-4420 was backported to the 10.5 branch.

          Show
          Knut Anders Hatlen added a comment - Adding 10.5.3.1 to the affected versions since DERBY-4420 was backported to the 10.5 branch.
          Hide
          Knut Anders Hatlen added a comment -

          The NPE was introduced in this commit:

          ------------------------------------------------------------------------
          r832379 | kahatlen | 2009-11-03 11:31:21 +0100 (Tue, 03 Nov 2009) | 16 lines

          DERBY-4420: NullPointerException with INSERT INTO ... from EXCEPT/INTERSECT

          The failing code in ResultSetNode.setTableConstructorTypes() was meant
          to handle the case where the node represented a table constructor (aka
          VALUES clause). UnionNode already had an override to make it a no-op
          unless it actually represented a multi-row VALUES clause that had been
          rewritten to a union of single-row VALUES clauses.

          Since a VALUES clause is never rewritten to EXCEPT or INTERSECT, the
          correct handling is to make setTableConstructorTypes() a no-op in
          IntersectOrExceptNode. Rather than adding an empty override in
          IntersectOrExceptNode, the code was moved from
          ResultSetNode.setTableConstructorTypes() to
          RowResultSetNode.setTableConstructorTypes(), and the default
          implementation in ResultSetNode was left empty.

          ------------------------------------------------------------------------

          Show
          Knut Anders Hatlen added a comment - The NPE was introduced in this commit: ------------------------------------------------------------------------ r832379 | kahatlen | 2009-11-03 11:31:21 +0100 (Tue, 03 Nov 2009) | 16 lines DERBY-4420 : NullPointerException with INSERT INTO ... from EXCEPT/INTERSECT The failing code in ResultSetNode.setTableConstructorTypes() was meant to handle the case where the node represented a table constructor (aka VALUES clause). UnionNode already had an override to make it a no-op unless it actually represented a multi-row VALUES clause that had been rewritten to a union of single-row VALUES clauses. Since a VALUES clause is never rewritten to EXCEPT or INTERSECT, the correct handling is to make setTableConstructorTypes() a no-op in IntersectOrExceptNode. Rather than adding an empty override in IntersectOrExceptNode, the code was moved from ResultSetNode.setTableConstructorTypes() to RowResultSetNode.setTableConstructorTypes(), and the default implementation in ResultSetNode was left empty. ------------------------------------------------------------------------
          Knut Anders Hatlen made changes -
          Bug behavior facts [Crash] [Regression]
          Issue & fix info [Newcomer] [Repro attached]
          Component/s SQL [ 11408 ]
          Knut Anders Hatlen made changes -
          Attachment repro.sql [ 12445143 ]
          Hide
          Knut Anders Hatlen added a comment -

          Attaching an SQL script that reproduces the NullPointerException on Derby 10.6.1.0. No error is raised with 10.5.3.0 and earlier releases.

          Show
          Knut Anders Hatlen added a comment - Attaching an SQL script that reproduces the NullPointerException on Derby 10.6.1.0. No error is raised with 10.5.3.0 and earlier releases.
          Hide
          Knut Anders Hatlen added a comment -

          The zip file contains a derby.log which shows the query that fails:

          INSERT INTO jbosscache (fqn, node, parent) SELECT ?, ?, ? FROM jbosscache_D WHERE NOT EXISTS (SELECT fqn FROM jbosscache WHERE fqn = ?)

          The NPE is easily reproducible in ij:

          ij> create table t (x int);
          0 rows inserted/updated/deleted
          ij> prepare ps as 'insert into t select ? from t';
          ERROR XJ001: Java exception: ': java.lang.NullPointerException'.

          Preparation of the insert statement fails with a NullPointerException in Derby 10.6.1.0, whereas 10.5.3.0 and earlier versions successfully prepare and execute the query.

          I'm not sure if it is intentional that the older versions allow ? in the select list, as the same select statement fails when it's not within an insert statement:

          ij> prepare ps as 'select ? from t';
          ERROR 42X34: There is a ? parameter in the select list. This is not allowed.

          I would have expected the same result from the insert statement. Anyhow, it should not fail with a NullPointerException.

          Show
          Knut Anders Hatlen added a comment - The zip file contains a derby.log which shows the query that fails: INSERT INTO jbosscache (fqn, node, parent) SELECT ?, ?, ? FROM jbosscache_D WHERE NOT EXISTS (SELECT fqn FROM jbosscache WHERE fqn = ?) The NPE is easily reproducible in ij: ij> create table t (x int); 0 rows inserted/updated/deleted ij> prepare ps as 'insert into t select ? from t'; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. Preparation of the insert statement fails with a NullPointerException in Derby 10.6.1.0, whereas 10.5.3.0 and earlier versions successfully prepare and execute the query. I'm not sure if it is intentional that the older versions allow ? in the select list, as the same select statement fails when it's not within an insert statement: ij> prepare ps as 'select ? from t'; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I would have expected the same result from the insert statement. Anyhow, it should not fail with a NullPointerException.
          Ray O'Hagan made changes -
          Attachment CacheIssue-eclipseProject.zip [ 12445107 ]
          Ray O'Hagan made changes -
          Attachment cache-config.xml [ 12445106 ]
          Ray O'Hagan made changes -
          Field Original Value New Value
          Attachment CacheIssue.java [ 12445105 ]
          Hide
          Ray O'Hagan added a comment -

          Also attached a full eclipseProject which contains all jars & code to reproduce the problem.

          Show
          Ray O'Hagan added a comment - Also attached a full eclipseProject which contains all jars & code to reproduce the problem.
          Ray O'Hagan created issue -

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Ray O'Hagan
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development