It should be Hibernate -- it's very easy to check, just look at the
app/pom.xml, comment one dependency and uncomment the other. (Unless
you're running on GlassFish then it's Eclipselink no matter what.)
Regardless, it should work with either JPA stack because of my fixes
yesterday.
Basically, you add a media directory and then delete it. It should
visually disappear.
(BTW, mvn jetty:run does not yet work with Hibernate JPA, if you're
running that way, the jetty config file needs modification to work with
either stack right now.)
Glen
On 07/31/2013 08:58 AM, Greg Huber wrote:
Glen,
It builds OK now.
I have updated to the trunk but the test is still showing its not
refreshing the association. Are we on hibernate or EclipseLink?
Cheers Greg
On 31 July 2013 13:14, Glen Mazza <glen.ma...@gmail.com> wrote:
Just one failure as a result of the update (mvn clean install worked
before it). And some typos. :)
BTW, the new database script you created, would you mind moving it to
test/resources/sql folder? (like we have main/resources/sql already?)
Also, I'm usually on the #roller IRC so you might want to join if you have
any quick questions.
Thanks,
Glen
testUserAttributeCRUD(org.**apache.roller.weblogger.**business.UserAttributeTest)
Time elapsed: 0.11 sec <<< ERROR!
java.lang.NullPointerException
at org.apache.roller.weblogger.**business.jpa.**
JPAUserManagerImpl.removeUser(**JPAUserManagerImpl.java:75)
at org.apache.roller.weblogger.**TestUtils.teardownUser(**
TestUtils.java:227)
at org.apache.roller.weblogger.**business.UserAttributeTest.**
testUserAttributeCRUD(**UserAttributeTest.java:75)
at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
at sun.reflect.**NativeMethodAccessorImpl.**invoke(**
NativeMethodAccessorImpl.java:**57)
at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
DelegatingMethodAccessorImpl.**java:43)
at java.lang.reflect.Method.**invoke(Method.java:601)
at junit.framework.TestCase.**runTest(TestCase.java:176)
at junit.framework.TestCase.**runBare(TestCase.java:141)
at junit.framework.TestResult$1.**protect(TestResult.java:122)
at junit.framework.TestResult.**runProtected(TestResult.java:**142)
at junit.framework.TestResult.**run(TestResult.java:125)
at junit.framework.TestCase.run(**TestCase.java:129)
at junit.framework.TestSuite.**runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(**TestSuite.java:250)
at org.junit.internal.runners.**JUnit38ClassRunner.run(**
JUnit38ClassRunner.java:84)
at org.apache.maven.surefire.**junit4.JUnit4Provider.execute(**
JUnit4Provider.java:252)
at org.apache.maven.surefire.**junit4.JUnit4Provider.**
executeTestSet(JUnit4Provider.**java:141)
at org.apache.maven.surefire.**junit4.JUnit4Provider.invoke(**
JUnit4Provider.java:112)
at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
at sun.reflect.**NativeMethodAccessorImpl.**invoke(**
NativeMethodAccessorImpl.java:**57)
at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
DelegatingMethodAccessorImpl.**java:43)
at java.lang.reflect.Method.**invoke(Method.java:601)
at org.apache.maven.surefire.**util.ReflectionUtils.**
invokeMethodWithArray(**ReflectionUtils.java:189)
at org.apache.maven.surefire.**booter.ProviderFactory$**
ProviderProxy.invoke(**ProviderFactory.java:165)
at org.apache.maven.surefire.**booter.ProviderFactory.**
invokeProvider(**ProviderFactory.java:85)
at org.apache.maven.surefire.**booter.ForkedBooter.**
runSuitesInProcess(**ForkedBooter.java:115)
at org.apache.maven.surefire.**booter.ForkedBooter.main(**
ForkedBooter.java:75)
On 07/31/2013 08:03 AM, Greg Huber wrote:
Glen,
I have made some changes to enable local testing and after updating from
the trunk nothing is working.
http://repo1.maven.org/ says 501. Why does it not ignore this? :(
Can you see if the tests still work?
Also, I have done the test on the directory and will check this later when
its back working.
Cheers Greg.
On 30 July 2013 21:36, Glen Mazza <glen.ma...@gmail.com> wrote:
Fixed the Eclipselink issue in a way that the code will still work with
Hibernate. We'll keep the Hibernate for awhile to see if it has any
issues.
When we delete a media folder, Eclipselink does indeed remove it from the
database (the Flush Mode COMMIT/AUTO had nothing to do with the problem.)
The issue is that Eclipselink does not refresh the media folder's
parent
to remove that deleted media folder from its child directories list. So
even though its removed from the database the application would still
show
the deleted folder whenever you list a parent folder's (for us, "/")
children. For the change, I just manually removed the deleted folder
from
its parent's subfolder list, which Hibernate is fine with.
I may want to create a bare-bones example of this on StackOverflow
sometime and ask which JPA stack has it right, the losing stack gets a
JIRA
issue.
Glen
On 07/30/2013 07:06 AM, Greg Huber wrote:
Glen,
OK, can you make the changes to the trunk so i can switch to hibernate.
On 30 July 2013 11:47, Glen Mazza <glen.ma...@gmail.com> wrote:
Much appreciated. I was thinking it may be good for us to run on
Hibernate for a few weeks anyway, even if EclipseLink were running
perfectly, just to see if there are any kinks with it where our code
needs
to be tightened up. I can fix EclipseLink's problem in the interim so
if/when *Hibernate* has a kink, we know we can always immediately flip
back
to EclipseLink while fixing the Hibernate issue.
Glen
On 07/30/2013 06:39 AM, Greg Huber wrote:
Glen,
I was trying to add the usecase but ran into the howto debug issue. I
will
sort the test if I manage to get the debug working.
Cheers Greg
On 30 July 2013 11:05, Glen Mazza <glen.ma...@gmail.com> wrote:
Let me play with it today before throwing in the towel and going
with
Hibernate. Even if we jump to Hibernate I still need to figure out
the
EclipseLink matter so our coding is not dependent on one JPA
framework
alone, we should be able to work with both or have a JIRA ticket with
EclipseLink. I'd like to add in a JUnit test case that would have
caught
this regression.
Glen
On 07/30/2013 03:31 AM, Greg Huber wrote:
Glen,
Commenting out the FlushModeType.COMMIT makes no difference,
(assumes
it
switches to auto). Would have thought that createNamedQuery or
createQuery
would behave the same way as they both follow the same logic in
roller.
Where one works and one does not, maybe an EclipseLink issue. I am
no
expert but with hibernate this does not happen.
For me, eclipse does not have a good track record wrt QA, and with
orm
there is just no workaround. It would simpler if we can switch to
something that works without all this pain.
Cheers Greg
On 29 July 2013 14:27, Glen Mazza <glen.ma...@gmail.com> wrote:
This page:
http://docs.oracle.com/javaee/******<http://docs.oracle.com/javaee/****>
<http://docs.oracle.com/**javaee/**<http://docs.oracle.com/javaee/**>
****6/api/javax/persistence/******<http://docs.oracle.com/**
javaee/****6/api/javax/****persistence/**<http://docs.**
oracle.com/javaee/****6/api/**javax/persistence/**<http://docs.oracle.com/javaee/****6/api/javax/persistence/**>
**<http://docs.oracle.com/******javaee/**6/api/javax/******
persistence/**<http://docs.oracle.com/****javaee/**6/api/javax/****persistence/**>
<http://docs.**oracle.com/**javaee/**6/api/**javax/**persistence/**<http://docs.oracle.com/**javaee/**6/api/javax/**persistence/**>
<http://docs.**oracle.com/**javaee/**6/api/**javax/**persistence/**<http://oracle.com/javaee/**6/api/**javax/persistence/**>
<http://docs.**oracle.com/javaee/**6/api/**javax/persistence/**<http://docs.oracle.com/javaee/**6/api/javax/persistence/**>
FlushModeType.html<http://******do**cs.oracle.com/javaee/6/****
api/** <http://cs.oracle.com/javaee/6/**api/**><
http://cs.oracle.com/**javaee/6/api/**<http://cs.oracle.com/javaee/6/api/**>
<http://docs.oracle.com/****javaee/6/api/**<http://docs.oracle.com/**javaee/6/api/**>
<http://docs.**oracle.com/javaee/6/api/**<http://docs.oracle.com/javaee/6/api/**>
javax/persistence/********FlushModeType.html<http://**
docs.oracle.com/javaee/6/api/******javax/persistence/****<http://docs.oracle.com/javaee/6/api/****javax/persistence/****>
FlushModeType.html<http://**docs.oracle.com/javaee/6/api/***
*javax/persistence/****FlushModeType.html<http://docs.oracle.com/javaee/6/api/**javax/persistence/**FlushModeType.html>
<http://**docs.oracle.com/**javaee/6/api/**javax/**persistence/**<http://docs.oracle.com/javaee/6/api/**javax/persistence/**>
FlushModeType.html<http://**docs.oracle.com/javaee/6/api/**
javax/persistence/**FlushModeType.html<http://docs.oracle.com/javaee/6/api/javax/persistence/FlushModeType.html>
says
"If |FlushModeType.COMMIT| is set, the effect of updates made to
entities in the persistence context upon queries is unspecified",
which
is
different from the definition of COMMIT below (where it *only*
occurs
at
a
transaction commit.) If I understand that correctly, that would
mean
Roller can't rely on a flush having occurred or not with COMMIT,
and
EclipseLink and any other JPA implementation is welcome to go
either
way,
and can indeed behave differently between named and dynamic
queries,
as
EclipseLink does.
Might the problem be with our code? We're relying on unspecified
functionality when we set FlushModeType to COMMIT, and we've been
lucky
so
far that OpenJPA and Hibernate just so happen to flush data (as
it's
allowed to do per the spec) while EclipseLink is choosing not to.
I
wonder
if we should have new versions of NamedQuery and DynamicQuery that
*don't*
set it to COMMIT (assuming the default of AUTO is being used
otherwise,
as
specified here: http://www.eclipse.org/****
eclipselink/documentation/2.5/**********<http://www.eclipse.**
org/****** <http://www.eclipse.org/******><http://www.eclipse.**
org/**** <http://www.eclipse.org/****>>
eclipselink/documentation/2.5/********<http://www.eclipse.org/**
**** <http://www.eclipse.org/****>
eclipselink/documentation/2.5/******<http://www.eclipse.org/****
eclipselink/documentation/2.5/****<http://www.eclipse.org/**eclipselink/documentation/2.5/**>
jpa/extensions/p_persistence_**********context_flushmode.htm)-**
-*******
*something<
http://www.eclipse.**org/******eclipselink/documentation/**
2.5/jpa/extensions/p_********persistence_context_flushmode.******
**htm)--something<http://www.******eclipse.org/eclipselink/**
documentation/2.5/jpa/******extensions/p_persistence_**
context_flushmode.htm)--******something<http://www.eclipse.****
org/eclipselink/documentation/****2.5/jpa/extensions/p_**
persistence_context_flushmode.****htm)--something<http://www.**
eclipse.org/eclipselink/**documentation/2.5/jpa/**
extensions/p_persistence_**context_flushmode.htm)--**something<http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/p_persistence_context_flushmode.htm)--something>
that
the Media File stuff could apparently use here.
Glen
On 07/29/2013 08:32 AM, Greg Huber wrote:
Glen,
I think its only on the named queries as if I delete a weblog
entry
it
updates correctly, and uses a dynamic query.
EntityManager em = getEntityManager(false);
Query q = em.createNamedQuery(queryName)**********;
// Never flush for queries. Roller code assumes this behavior
q.setFlushMode(FlushModeType.**********COMMIT);
return q;
EntityManager em = getEntityManager(false);
Query q = em.createQuery(queryString);
// Never flush for queries. Roller code assumes this
behavior
q.setFlushMode(FlushModeType.**********COMMIT);
Cheers Greg
On 29 July 2013 13:14, Glen Mazza <glen.ma...@gmail.com> wrote:
OK, we can switch to Hibernate for the time being, and it
works
fine
there, it's as simple a matter as commenting-out the
EclipseLink
dependency
and uncommenting the Hibernate one in the app/pom.xml and doing
an
mvn
clean install to get a new WAR. Still, I'd like to fix this
EclipseLink
issue, maybe there's some simple setting causing it not to work.
Note
our
EclipseLink is JPA 2.1 vs. Hibernate's (and the OpenJPA's) 2.0,
that
might
be part of the story.
Glen
On 07/29/2013 07:34 AM, Greg Huber wrote:
From google:
"By default, the database flush mode is set to AUTO. This
means
that
the
Entity-Manager performs a flush operation automatically as
needed.
In
general, this occurs at the end of a transaction for
transaction-scoped
EntityManagers and when the persistence context is closed for
application-managed or extendedscope EntityManagers. In
addition,
if
entities with pending changes are used in a query, the
persistence
provider
will flush changes to the database before executing the query.If
the
flush
mode is set to COMMIT, the persistence provider will only
synchronize
with
the database when the transaction commits.However, you should be
careful
with this, as it will be your responsibility to synchronize
entity
state
with the database before executing a query. If you don’t do this
and
an
EntityManager<http://docs.**********or**acle.com/javaee/6/api/*
***** <http://acle.com/javaee/6/api/****>
** <http://acle.com/javaee/6/api/******<http://acle.com/javaee/6/api/****>
javax/**
<http://acle.com/javaee/6/api/******javax/**<http://acle.com/javaee/6/api/****javax/**>
<http://acle.com/**javaee/6/api/**javax/**<http://acle.com/javaee/6/api/**javax/**>
<http://acle.com/
**javaee/6/api/javax/** <http://acle.com/javaee/6/api/**
**javax/** <http://acle.com/javaee/6/api/**javax/**><
http://acle.com/**javaee/6/api/javax/**<http://acle.com/javaee/6/api/javax/**>
<http://oracle.com/**javaee/6/******api/javax/**<http://oracle.com/**javaee/6/****api/javax/**>
<http://**oracle.com/**javaee/6/**api/**javax/**<http://oracle.com/**javaee/6/**api/javax/**>
<http://oracle.**com/**javaee/**6/api/javax/**<http://oracle.**
com/**javaee/6/api/javax/**<http://oracle.com/**javaee/6/api/javax/**>
<http://oracle.**com/javaee/6/****api/javax/**<http://oracle.**
**
com/javaee/6/api/javax/**<http**://oracle.com/javaee/6/api/**
javax/** <http://oracle.com/javaee/6/api/javax/**>>
persistence/EntityManager.**********html<http://docs.oracle.**
com/** <http://docs.oracle.com/**>
** <http://docs.oracle.com/**>
javaee/6/api/javax/**********persistence/EntityManager.******
**html<
http://docs.oracle.com/********javaee/6/api/javax/**<http://docs.oracle.com/******javaee/6/api/javax/**>
<http://**docs.oracle.com/****javaee/6/**api/javax/**<http://docs.oracle.com/****javaee/6/api/javax/**>
<http://**docs.oracle.com/****javaee/6/**api/javax/**<http://docs.oracle.com/**javaee/6/**api/javax/**>
<http:/**/docs.oracle.com/**javaee/6/**api/javax/**<http://docs.oracle.com/**javaee/6/api/javax/**>
persistence/EntityManager.******html<http://docs.oracle.com/**
javaee/6/api/javax/******persistence/EntityManager.****html<
http://docs.oracle.com/****javaee/6/api/javax/**<http://docs.oracle.com/**javaee/6/api/javax/**>
persistence/EntityManager.**html<http://docs.oracle.com/**
javaee/6/api/javax/**persistence/EntityManager.html<http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html>
**>
**>
**>
**>
**>
**>query
returns stale entities from the database, the application can
wind
up
in an inconsistent state."
Did try to change it to auto but made no difference.
On 29 July 2013 12:25, Glen Mazza <glen.ma...@gmail.com> wrote:
OK, I'll check, but what happens if you go to the Roller
maintenance
tab
and click on "Flush blog" (that will normally empty out the
cache) --
problem solved then?
Note I had to bring back your changes after the move to fewer
modules,
I
might have missed something.
Glen
On 07/29/2013 07:20 AM, Greg Huber wrote:
Glen,
Can you test whether you can delete a media file folder?
ie
add
a
folder
and then try and delete it. For me it seems to delete it OK
but
when
you
refresh the media file folder view it is still there. If I
then
shut
down
tomcat and restart it is gone. It seems something to do with
its
cache?
checking:
public Query getNamedQuery(String queryName)
....
q.setFlushMode(FlushModeType.**************COMMIT);
it sets the query to flush on commit, which should in theory
flush
the
query cache when the transaction is committed.
Is there some callback method we need to call to get it to
flush?
Cheers Greg
