Jump to content
Excelsior Forums

escobar

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About escobar

  • Rank
    Newbie
  • Birthday 01/01/01
  1. Hi! We are evaluating if we should compile our product to Windows executable. On some parts the Jet seems to be competent product and on some parts not. Jet is not really a script friendly, for example setting up for nightly build seems to be quite hard. I've tried to create a path from building to jar and compiling it to executable and packing it with JetPack. The packing seems to be problematic somehow. And the Derby started to cause problems again with 5.0 beta2. Labour Day caused a little halt and I didn't have time to test the same configuration with 4.8.
  2. Hi! I checked everything out from version control again to make fresh and clean start. I cleaned everything manually and made a new Excelsior project and compiled for the 10th time with 5.0 beta 2 and it started to work. The amount of processed classes is lower in the cleaned version of the project than in the broken version. I don't know which classes/jars caused the problem, but there propably was some garbage in the source packages.
  3. Got the compilation done with 4.8. Works like charm. Seems like there is something to fix in 5.0. I'll try the next build with 5.0 again.
  4. Hi! After two hours of compilation it is bit frustrating to notice that Excelsior Jet uses absolute path to splash image. If splash image cannot be found it breaks the build. In our environment the build process is made on separate machine and the paths aren't the same as on development machine. Solution: Check all the used resources before compilation process.
  5. Hi! First exception comes from a call to ResultSet-objects next-method. And the latter exception comes from a call to PreparedStatement-objects execute-method. Databasecode creates the database and connects to it without problems. It also creates the PreparedStatement-objects without problems. But first call to the ResultSet after the statement execution throws the NullPointerException. java.lang.NullPointerException at org.apache.derby.impl.sql.execute.BaseActivation.reset(BaseActivation.class:0) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.resetActivations(GenericLanguageConnectionContext.class:0) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(GenericLanguageConnectionContext.class:0) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(GenericLanguageConnectionContext.class:0) at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(TransactionResourceImpl.class:0) at org.apache.derby.impl.jdbc.EmbedConnection.commitIfAutoCommit(EmbedConnection.class:0) at org.apache.derby.impl.jdbc.ConnectionChild.commitIfAutoCommit(ConnectionChild.class:0) at org.apache.derby.impl.jdbc.EmbedStatement.resultSetClosing(EmbedStatement.class:0) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.class:0) at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.class:0) And after that on the next query: java.sql.SQLException: No current connection. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.class:0) at org.apache.derby.impl.jdbc.Util.<init>(SQLException.class:0) at org.apache.derby.impl.jdbc.Util.<init>(EmbedSQLException.class:0) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Util.class:0) at org.apache.derby.impl.jdbc.EmbedStatement.checkExecStatus(EmbedStatement.class:0) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.class:0) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.class:0) Compiled on: AMD Athlon 64 X2 Dual Core Processor 3800+ 2GB memory Ubuntu Dapper 6.06 Windows executable compiled in VMWare virtualized Windows XP SP2. JDK 1.5.0_11 Excelsior Jet 5.0 beta 2 and beta 1 Apache Derby 10.2
×