Ooh! I just located the file: ./app/target/derby-system/derby.log --
does this file report anything meaningful to you when you try to run
in-memory mvn clean test?
Glen
On 07/14/2013 06:59 PM, Glen Mazza wrote:
No, I just quickly googled that page, we're using 10.10.1.1
(http://db.apache.org/derby/docs/10.10/devguide/cdevdvlpinmemdb.html).
But one last check: What does the roller-trunk/app/target/roller.log
say when you try to use in-memory Derby, is there any obvious error
message that points out the problem? I don't know how to activate
derby.log when using in-memory, so we can't check that (yet...)
For the time being, go ahead and shut off the in-memory feature so it
works for everyone (we may need to comment out the failing test until
I can figure it out). When I'm testing I can quickly place "memory"
in, maybe create a profile I can use -Pinmem so it will work for me.
Glen
On 07/14/2013 06:40 PM, Dave wrote:
There was a BLOB related issue in Derby that caused Roller tests to fail
and that's why the POM files specify Derby v10.10.1.1 (and not 10.7 that
you refer to).
I'm fine with moving (back) to HSQLDB as the JUnit test database. I just
want the tests to pass on my box and Roller to work on MySQL, which
is what
my ISP provides ;-)
- Dave
On Sun, Jul 14, 2013 at 6:32 PM, Glen Mazza <[email protected]>
wrote:
I don't think we'll need them anymore, but didn't get around to
removing
them yet. I guess I wanted to wait to make sure Derby in-memory (
http://db.apache.org/derby/**docs/10.7/devguide/**cdevdvlpinmemdb.html<http://db.apache.org/derby/docs/10.7/devguide/cdevdvlpinmemdb.html>)
works for everyone.
I wish I had a Mac so I could test the problem here, see what the
matter
is. I'm trying to Google, not much.
Eventually we may switch anyway to HSQLDB which is also in-memory
and can
hopefully work for everyone.
Glen
On 07/14/2013 06:21 PM, Dave wrote:
Also, if we are using "memory" for Derby do we still need the Ant
tasks
that start and stop Derby.
If we don't need them, that seems like a big win.
- Dave
On Sun, Jul 14, 2013 at 6:16 PM, Dave <[email protected]> wrote:
I'm going to look at setting up things so that we only use
"memory" when
NOT running on Mac OS.
- Dave
On Sun, Jul 14, 2013 at 6:14 PM, Glen Mazza <[email protected]>
wrote:
The single test that's failing I can look at (if you can't
immediately
spot the error due to your greater knowledge of the code), since
I can
replicate it. But the "memory" portion should be working OOTB
for you,
everything good (except that test) with a simple "mvn clean test".
In-memory Derby is *fast*, so it would be very nice to keep it
if we
can.
Glen
On 07/14/2013 06:04 PM, Dave wrote:
Hey Matt,
Are you able to run "mvn clean test" on Roller trunk on your
Mac? Does
it
work?
- Dave
On Sun, Jul 14, 2013 at 5:37 PM, Glen Mazza <[email protected]>
wrote:
Hi Dave, tests run fine from my Ubuntu desktop but when I did
a fresh
checkout of roller-trunk and ran from my Ubuntu laptop, I got your
second
result ("memory" works fine but I got the same UserTest error), it
happened
both times I tried it. When I ran from my laptop that test alone,
i.e.,
"mvn test -Dtest=UserTest", *then* it worked fine (all three
times I
ran
it).
I'm not sure what the problem is -- it might be related to
EclipseLink,
I
learned earlier the EclipseLink (as well as Hibernate) requires
explicit
commits in some cases where OpenJPA doesn't:
https://github.com/gmazza/**
blog-samples/blob/master/jpa_******and_junit/src/main/java/**
SampleRun.java#L44<https://**g**ithub.com/gmazza/blog-**<http://github.com/gmazza/blog-**>
samples/blob/master/jpa_and_****junit/src/main/java/SampleRun.**
**java#L44<https://github.com/**gmazza/blog-samples/blob/**
master/jpa_and_junit/src/main/**java/SampleRun.java#L44<https://github.com/gmazza/blog-samples/blob/master/jpa_and_junit/src/main/java/SampleRun.java#L44>
.
That, or maybe the tests aren't fully independent of each other
(one's
requiring another to have run first, I don't know.)
Glen
On 07/14/2013 04:49 PM, Glen Mazza wrote:
That won't do..."memory" refers to Derby's in-memory database,
something
I put in to reduce the build time about 25% (instead of
needing to
manually
create files, etc.)...
I just use "mvn clean install", I don't have any problem on my
machine
with it...
Glen
On 07/14/2013 04:21 PM, Dave wrote:
If I remove the string "memory:" from the two Roller property
files in
test/src/resources then do not get that error and all test pass
except
for
the following:
Results :
Failed tests:
testUserLookups(org.apache.******roller.weblogger.business.******
UserTest):
expected:<[userTest]User> but was:<[admin]User>
testRoleCRUD(org.apache.******roller.weblogger.business.****
UserTest):
expected:<2>
but was:<1>
Tests run: 130, Failures: 2, Errors: 0, Skipped: 0
Still digging...
- Dave
On Sun, Jul 14, 2013 at 4:11 PM, Dave <[email protected]>
wrote:
I'm going to investigate now, but just in case anybody
else knows
what's
up...
--- ROOT CAUSE ---
java.sql.******SQLNonTransientConnectionExcep******tion: The
connection
was
refused
because the database memory:rollerdb was not found.
at
org.apache.derby.client.am.******SQLExceptionFactory40.****
getSQLException(Unknown
Source)
at
org.apache.derby.client.am.******SqlException.getSQLException(*
****
*Unknown
Source)
at
org.apache.derby.jdbc.******ClientDriver.connect(Unknown
Source)
Thanks,
Dave
